Resourcen schonende Kommunikation

Okay, habe es verstanden auch wenn es mit Ereignis gehen würde Abstand davon nehmen....
Wie sieht es nun mit der Queue aus, ist dies "das Gelbe vom EI"? Was muss hier evtl. beachtet werden?
(Außer dass es nach meiner Ansicht etwas unübersichtlicher ist, aber dafür kam ja bereits der gute Hinweiß mit den Clustern.)

Irgendwo habe ich mal gelesen, dass Queues langsamer sein sollen als FGV?

Anzeige

Hallo LV-New,

um das Blockdiagramm übersichtlicher zu machen kannnst Du lokale Variablen verwenden.
LV2018
   

Wenn Du in den Beispielen nach Queue suchst findest Du zB: "Channel Basics.lvproj", dort wird erklärt wie Datenaustausch zwischen parallelen Schleifen auch noch gehandhabt werden kann.

Grüße

kpa

Hallo kpa,

du willst allen Ernstes ein Beispiel mit einer klaren Racecondition empfehlen?

Hallo GerdW,

Raceconditions treten auf wenn veränderbare Variablen von verschiedenen Prozessen geschrieben oder gelesen werden und der Zeitpunkt des Lesens andere Werte ergeben kann. In meinem Beispiel wird die lokale Variable einmal geschrieben und nicht mehr verändert. Jedes Lesen dieser lokalen Variable ergibt den gleichen Wert. Hier kann keine Racecondition auftreten.

Grüße

kpa

edit:

Die Racecondition auf die die zwei nachfolgenden Schreiber hinweisen habe ich nachträglich durch einen Sequenzrahmen beseitigt.

LV2018


   

LabVIEW neigt dazu, lokale Variablen sehr frühzeitig zu lesen. In deinem Beispiel kann es vorkommen, dass die lokale Variable QueueDBL beim ReleaseQueue gelesen wird, bevor ObtainQueue ausgeführt wird. Muss nicht passieren, kann aber. Daher immer vermeiden.

Was passiert, wenn der Code mal wächst, und QueueDBL erst später beschrieben wird?

Hallo kpa,

Zitat:Hier kann keine Racecondition auftreten.

Dann überlege mal, ob ObtainQueue die Referenz schneller in der "Variablen" ablegt, als sie bei ReleaseQueue ausgelesen wird!

Anzeige

Hi,
bin nun auf die nächste Herausforderungen gestoßen...

Ausgangszenario:
Ich habe im aktuellen Beispiel 3 Schleifen:
1. Schleife erzeugt Daten und soll Sie an die 2 anderen Schleifen senden.
Beide Schleifen sollen jeweils die Daten aus der 1. Schleife lesen. Die Schleifen laufen unterschiedlich schnell und kann auch nicht gesagt werden welche von den beiden Schleifen zuerst auf die Daten zugreift. Nach dem Lesen kann die Queue geleert werden nicht gelöscht da für nächsten Durchlauf gebraucht....

Wie kann ich also sicherstellen dass die Daten bei beiden ankommen und die Queue aber auch nicht übermässig groß wird?
Gibt es da eine Lösung, außer evtl. 2 Queues bzw. die Daten von der einen auf die andere Schleife dann weiterzugeben?

Hallo LV-New,

eine Queue folgt dem Prinzip "mehrere Erzeuger, ein Consumer": wenn du zwei Consumer hast und beide alle Daten bekommen sollen, benötigst du zwei Queues.

(Man kann durchaus mehrere Consumer eine Queue leeren lassen, dann bekommt aber nicht jeder Consumer alle Daten…)

Hatte ich befürchtet :-(
Aber kann das untere VI eine Lösung sein, solange wie die Erzeugerschleife langsamer ist als die Leseschleifen?
Oder habe ich was übersehen....?

Hallo LV-New,

Zitat:Aber kann das untere VI eine Lösung sein, solange wie die Erzeugerschleife langsamer ist als die Leseschleifen?

Also "Lösung" würde ich das nicht nennen…
Um sicherzustellen, dass beide Consumer die Daten bekommen, verwendest du jeweils QueuePreview…
Um sicherzustellen, dass beide Consumer den richtigen Wert lesen, verwendest du EnqueueOppositeEnd…
Um sicherzustellen, dass die Queue nicht den gesamten Speicher belegt, verwendest du QueueFlush…
Und du musst auch noch sicherstellen, dass der Producer langsamer läuft als die Consumer…

Insgesamt ein sehr wackliges Konstrukt!

Nimm doch einfach zwei Queues! Oder einen Notifier, solange der Producer so langsam läuft…