' schrieb:[*]Kein Initialisieren. Beim Erstellen der Variable wird diese nicht mit einem Standardwert belegt. Wenn man also ein READ vor einem ersten WRITE ausführen sollte, bekommt man einen undefinierten Zustand.
Falsch. Die sind schon initialisiert beim Laden. LabVIEW intialisiert die nämlich garantiert auf den default Defaultwert für den Datentypen (also null für Zahlen, und leere Arrays und Strings). Dass das manchmal nicht ist was man gern möchte ist ein anderes Problem, aber definiert sind sie eben schon.
Zitat:[*]Möglichkeit auf fehlerhafte Race-Conditions bei gleichzeitigem Schreib-Zugriff auf die Variable. Dies wird mit globalen Variablen über das Anlegen einer Speicherkopie vermieden, habe ich das richtig verstanden? Wie entscheidet diese dann, welcher Wert übernommen werden soll, wenn zwei Werte gleichzeitig geschrieben werden?
Die Möglichkeit besteht auch nicht. Solange das SubVI nicht reentrant ist kann es nur gleichzeitig von einem anderen VI aufgerufen werden. LabVIEW rescheduled (oder wenn diese anderen Aufrufer nichts anderes mehr zu tun haben, blockiert) andere Aufrufer automatisch solange ein non-reentrant SubVI schon von jemandem ausgeführt wird.
Hier ist aber auch gleichzeitig ein möglicher Nachteil. Wenn dieses SubVI nämlich langdauernde Operationen macht (komplexe Berechnungen oder dergleichen) dann werden eben andere Teile des Programms auch aufgehalten.
Zitat:[*]Referenzen (schwierig bei Kommunikation über mehrere Programmmodule hinweg und zwischen völlig unterschiedlichen Sub-VIs)
Referenzen sind in dieser Hinsicht eine katastrophale Verschlimmbesserung. Diese werden immer im UI Thread ausgeführt, können das Programm also extreeeeem verlangsamen und gar blockieren wenn Du irgendwo in Deinem Programm beispielsweise einen Dialog (File Selection oder ein simpler 1 Button Dialog) anzeigen lässt. Die Datenkopie vom Kontrol wird hier ebenso getan als bei einer Globalen, also im Vergleich zur globalen Variable nur Nachteile.
Zitat:[*]FIFOs (funktioniert super, allerdings wird nicht der letzte Wert, sondern der nächste in der Liste abgefragt, was nicht immer zweckmäßig ist)
FIFOs können gut sein. Aber wenn Du es genau wie eine Globale verwendest ist es eigentlich auch nicht unbedingt viel besser, obwohl in LabVIEW 8 sind FIFO so obtimalisiert, dass der Datenbereich der beim Hineineschreiben in die FIFO queue kopiert wurde, automatisch wiederverwendet wird beim Auslesen also eine Kopie weniger ist da schon und wenn Du Daten nicht noch irgendwie anders verwendest (also ohne Verzweigung beim Write FIFO VI) dann wird gar keine Kopie getan. Aber das ist LabVIEW 8.x Funktionalität. In früheren Versionen waren die FIFOs und andere vergleichbare VIs (Notifier) nicht so smart.
Und wenn Dich nur der letzte Wert interessiert ist ein Notifier eigentlich besser. Auch hat das FIFO den Nachteil dass Du einen einmal gelesenen Wert nicht einfach noch mal lesen kannst (oder Du machst einen Peek aber dann muss das FIFO VI genauso eine Kopie machen wie beim Lesen des Notifiers).
Der Vorteil von intelligenten LV2 Style Globalen, wie ich die uninitialisierten Shiftregister VIs nenne, liegt vor allem darin, dass man in diese VIs Intelligenz stecken kann, so dass man wenn man in einem Array nur ein Element überschreiben will dies in diesem VI auch so programmiert und damit jede Kopie von Speicher vermeidet. Wenn Du eine LV2 Style Global genau so verwendest wie eine normale Global, also irgendwo Daten rein und irgendwo anders alle Daten wieder raus, dann sparst Du zwar im Vergleich zu Globalen immer noch eine Datenkopie, ähnlich wie bei Queues, aber optimal ist noch lange anders.
Um bei obigem Beispiel zu bleiben, nehme mal an dass Du ein 10 Millionen Elemente Array in so eine Globale steckst und da gerne ein Element an einem bestimmten Index ersetzen möchtest.
Wenn wir das mit globalen Variablen machen hast Du erstens eine mögliche Race-Condition, (zwischen dem Lesen der Variablen, Verändern und zurückschreiben kann jemand anders ebenfalls diese Variable verändern) und minimal 3 mal soviel Speicher (globale Variable selber, Lesekopie, Schreibkopie).
Bei Verwendung von trivialen LV2 Style Gobals hast Du noch immer die mögliche Race-Condition und doppelter Speicherverbrauch (Variable im Schieberegister, und Lesekopie) vorausgesetzt Du verzweigst den Draht nicht noch vor dem zurückschreiben in die LV2 Style Globale.
Wenn wir aber jetzt eine intelligente LV2 Style Global machen, die ausser den zwei Methoden "Read" und "Write" auch noch eine "Replace Element" Methode hat dann haben wir nicht nur keine Race-Condition mehr, sondern auch keinen extra Speicherbedarf da die Replace Array Funktion innerhalb dieses LV2 Style Global-VIs von LabVIEW automatisch so optimalisiert wird, dass der Buffer aus dem Schieberegister wiederverwendet wird.
Rolf Kalbermatter
