+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: Resourcen schonende Kommunikation (/Thread-Resourcen-schonende-Kommunikation)
RE: Resourcen schonende Kommunikation - LV-New - 06.04.2020 18:24
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?
RE: Resourcen schonende Kommunikation - kpa - 08.04.2020 09:16
Hallo LV-New,
um das Blockdiagramm übersichtlicher zu machen kannnst Du lokale Variablen verwenden.
LV2018
[attachment=60844]
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
RE: Resourcen schonende Kommunikation - GerdW - 08.04.2020 09:19
Hallo kpa,
du willst allen Ernstes ein Beispiel mit einer klaren Racecondition empfehlen?
RE: Resourcen schonende Kommunikation - kpa - 08.04.2020 09:45
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
[attachment=60848]
RE: Resourcen schonende Kommunikation - th13 - 08.04.2020 09:56
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?
RE: Resourcen schonende Kommunikation - GerdW - 08.04.2020 09:56
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!
RE: Resourcen schonende Kommunikation - LV-New - 08.04.2020 10:23
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?
RE: Resourcen schonende Kommunikation - GerdW - 08.04.2020 10:33
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…)
RE: Resourcen schonende Kommunikation - LV-New - 08.04.2020 10:46
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....?
RE: Resourcen schonende Kommunikation - GerdW - 08.04.2020 11:00
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…