Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
28.09.2009, 10:43 (Dieser Beitrag wurde zuletzt bearbeitet: 28.09.2009 10:48 von Lucki.)
Bist du dir da sicher?
Das mit dem Index würde stimmen, wenn das Array-Bearbeitungselement direkt in den Speicher des Array-Elementes schreibt. Meinst du das ist so? Ich bin der Meinung, es wird in den Datenfluß geschrieben und der wird dann in das Array-Element und in alle (<=!) Lokalen Variablen geschrieben respektive kopiert!
Das habe ich nicht ganz verstanden. Ich kenne nur diese eine Szenario, in denen es bei lokalen Variablen zu Wettlaufproblemen kommt - und so sind auch die Beispiele von NI:
Es ist wegen der Parallelität der Auführung ungewiss und dem Zufall überlassen, ob die lokale Variable zuerst gelesen oder zuerst geschrieben wird.
Daß es darüber hinaus noch andere Szenarien geben soll, ist mir nicht bekannt. Ich verstehe Dich vielleicht so: Eine Variable wird über ein lokale Variable beschrieben, danach wieder gelesen - entweder direkt oder wieder über ein lokale Variable. Wegen irgendwelcher systeminterner LabVIEW-Speicherquerelen, Kopiereffekten oder was weiß ich, kann es dann vorkommen, daß beim nachfolgenden Lesen der Wert noch nicht richtig bei der Variablem angekommen ist, und damit anders ist als erwartet.
Das kann ich nicht widerlegen, das Einzige was mir dazu einfällt ist: Mein bisheriges Urvertrauen in LabVIEW wäre total erschüttert, wenn so etwas möglich sein sollte.
Was ich an dem Vorwurf, Lokale Variablen seien nicht Datenfluß-orientiert, immer komisch finde: Viele andere Strukturen, eigentlich alles, was entweder keine Ein- und Ausgänge hat oder wenn diese nicht benutzt werden, sind ebenfalls nicht Datenfluß-ortientiert. Es wird suggeriert, daß es insbesondere bei lokalen Variablen in dieser Hinsicht unerwartete Effekte geben kann. In Wirklichkeit liegen diese unerwarteten Effekte überall auf der Lauer.
' schrieb:Was ich an dem Vorwurf, Lokale Variablen seien nicht Datenfluß-orientiert, immer komisch finde: Viele andere Strukturen, eigentlich alles, was entweder keine Ein- und Ausgänge hat oder wenn diese nicht benutzt werden,
Wer macht denn sowas?
' schrieb:...sind ebenfalls nicht Datenfluß-ortientiert.
Das ist richtig und man sollte es deswegen auch nicht machen. LV ist und bleibt nunmal eine datenflussorientierte Programmiersprache und man sollte, wenn man auf guten Programmierstil Wert legt, dementsprechend programmieren.
' schrieb:Es ist wegen der Parallelität der Auführung ungewiss und dem Zufall überlassen, ob die lokale Variable zuerst gelesen oder zuerst geschrieben wird.
Das ist richtig.
Diesen Standpunkt musst du hier nur erweitern. Um den Fall: Welche der beiden Datenflüsse (der eine endet in einer Lokalen Variablen, der andere im Array-Element selbst) wird zuerst zurückgeschrieben? Der, der zuerst zurück geschrieben wird, wird durch den zweiten überschrieben! Eine Information (zwei Indices!) geht also verloren.
Zitat:daß beim nachfolgenden Lesen der Wert noch nicht richtig bei der Variablem angekommen ist
Der Ansatzpunkt "noch nicht richtig" ist in dem speziellen Fall, den ich gerade meine, falsch. Das Beschreiben von Elementen und deren lokaler Variablen selbst ist immer richtig und birgt per se keine Fehler. Das Problem ist eben, dass (z.B.) zuerst der obere Case das Element beschreibt (während dieses Schreibens werden auch alle lokalen Lese-Variablen angepasst) und in der nächsten Mysekunde überschreibt der untere Case die Werte des oberen Cases. Damit geht die Information das oberen Cases (zwei Indices!) verloren.
Solche Probleme hatte ich ja mal: Früher legten wir alle Bedien- und Anzeigeelemente in einen Cluster. Folge: Ständig und parallel musste eine lokale Variable als Eingang für einen Bundle her, der dann wieder eine Lokale Variable überschrieben hat. Und da hab ich das nämlich nachvollziehen können: Waren zwei solcher Konstrukte parallel, waren manchmal die neuen Daten des einen Konstruktes verschwunden, manchmal die des anderen. Lösung: FGV mit Property-Funktionalität.
Im allgemeinen gilt: Das Problem entsteht dadurch, dass zwei parallele Datenflüsse das selbe logische Ziel haben, z.B. eine lokale Variable des selben Elementes. Bearbeitet wird nämlich der Datenfluss, nicht das Element. Und wenn es nur ein einziges Element gibt, können die Daten nur eines der beiden Datenflüsse letztendlich bestehen bleiben.
Zitat:Mein bisheriges Urvertrauen in LabVIEW wäre total erschüttert, wenn so etwas möglich sein sollte.
Mach dir da mal keine Gedanken. Wenn du die Sache mit dem Datenfluß beachtest, kann gar nichts schief gehen.
Das ideale wäre natürlich, wenn es nur einen einzigen Datenfluß gäbe. Probleme machen ja immer nur "Sequenzrahmen" mit sehr viel Inhalt. Da bleibt es nicht aus, dass zwangsläufig mehrere parallele Datenflüsse entstehen. Auch mehrere parallele While-Schleifen sind hier anfällig für RaceConditions. Sobald also irgendwo ein paralleler Datenfluss existiert, muss geprüft werden, ob die Daten am Ende des Datenflusses auch wirklich alle Bestand haben können.
Die beiden theoretischen Fälle, die wir hier untersuchen (echte ReceConditions und das mit dem Überschreiben) sind auch extrem vom Umfeld abhängig. Wenn nämlich alleine durch den Algorithmus festgelegt ist, dass bestimmte Parallelitäten verriegelt bzw. selten sind, wird in der Entwicklungsphase nie ein Fehler auftreten (sondern erst beim Kunden).
Zitat:Was ich an dem Vorwurf, Lokale Variablen seien nicht Datenfluß-orientiert, immer komisch finde: Viele andere Strukturen, eigentlich alles, was entweder keine Ein- und Ausgänge hat oder wenn diese nicht benutzt werden, sind ebenfalls nicht Datenfluß-ortientiert. Es wird suggeriert, daß es insbesondere bei lokalen Variablen in dieser Hinsicht unerwartete Effekte geben kann. In Wirklichkeit liegen diese unerwarteten Effekte überall auf der Lauer.
Ja, das sehe ich auch so.
Was nicht sequenziert ist, muss als parallele Abarbeitung betrachtet werden. Parallel heißt aber: Egal wo in dem einen Datenfluß gerade gearbeitet wird, an jeder Stelle kann er aufgrund des Multitaskings unterbrochen werden. Und dann muss sichergestellt sein, dass es gerade bei abhängigen Datenflüssen (selbe Quelle, selbes Ziel!) nicht zu Inkonsistenzen kommt. Das Problem ist immer die Nicht-Sequenzierung (also nicht die Elemente, die nicht sequenziert sind).
Hinweis 1: Multicode verkompliziert den Effekt noch.
Hinweis 2: "Parallelisierbare Forschleifen": Hier kann man folgenden Effekt einbauen: Die nun parallelen Datenflüsse (!) lesen und beschrieben den selben physikalischen Datenspeicher! Was man alleine dadurch sieht, dass nur ein Wire im BD zu sehen ist.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Vielleicht habe ich selbst mit dazu beigetragen, aber in der Diskussion sollte eines nicht falsch ankommen: In den vielen Fällen ist Parallelität der Auführung unkritisch, es ist egal, was eher oder später ausgeführt wird. Damit die Programmausführung schnell ist, sollte man in dieser Hinsicht LabVIEW so viel wie möglich Spielraum lassen. Dabei ist insbesondere der exzessive Gebrauch von Sequenzstruktueren zu vermeiden. Sequenzstrukturen unterdrücken zwar nicht insgesamt die Parallelität der Auführung, aber wenn eine Struktur 10 Sequenzen hatt, dann kann nur in der jeweils aktiven Sequenz etwas passieren, alle anderen sind für LabVIEW tabu. Wenn das ohne zwingenden Grund so programmiert ist, dann ist das ein Nachteil für die Programmausführung.
Zitat:Das Problem ist eben, dass (z.B.) zuerst der obere Case das Element beschreibt (während dieses Schreibens werden auch alle lokalen Lese-Variablen angepasst) und in der nächsten Mysekunde überschreibt der untere Case die Werte des oberen Cases. Damit geht die Information das oberen Cases (zwei Indices!) verloren.
Da hast recht: Es ist zwar völlig egal, in welcher Reihenfolge die beiden Cases ausgeführt werden, deshalb erscheint die Notwendigkeit einer Sequenzierung der beiden Cases zunächst nicht zu bestehen. Wenn man aber davon ausgeht, daß LabVIEW mitten in der Bearbeitung eines Cases mal plötzlich in den anderen Case springen kann, um erst einmal dort etwas zu erledigen, dann kommt es zu unerwartetem Effekten.
Die Frage ist allerdings, ob mit so einem Verhalten realistischerweise gerechnet werden muß, zumal hier kein Waits in den Cases sind. Aber statt lange draüber zu spekulieren ist es allemal besser, das vorsichtshalber mit in Rechung zu stellen.
Ich selbst bin ein ausgesprochene Fan von Ereignissstrukturen und hätte es niemals so wie in meinem Beispiel gemacht, sondern z.B. so:
Wenn ich mich nicht irre, habe ich diesen Vorschlag (Events) schon in meinem ersten Beitrag genannt.
Und ich bleibe dabei: wer lokale Variablen grundsätzlich meidet, wegen des gestörten Datenflusses, sollte genauso auch Konstanten vermeiden, bzw. diese zum Erhalt des Datenflusses in Sequenzrahmen packen.
LG
Torsten
"Über Fragen, die ich nicht beantworten kann, zerbreche ich mir nicht den Kopf!" (Konrad Zuse)
' schrieb:Die Frage ist allerdings, ob mit so einem Verhalten realistischerweise gerechnet werden muß,
Selbst für die unrealistischen Fälle muss damit gerechnet werden!
Auch diese Fälle hab ich gehabt: Array in Globaler Variable, die gelesen und wieder beschrieben wurde. Einmal pro Monat ist die LV-Applikation mit AccessViolation abgestürzt. Bis ich festgestellt habe: Zu ganz bestimmten Programmzuständen kommt es vor, dass der eine parallele Zweig die Globale Variable löscht (Null-Pointer im Array, Null-Pointer => AccessViolation) und ein anderer einen Datensatz ergänzt. Dann existierte plötzlich ein leeres Array, aus dem Daten gelesen wurden.
Zitat:Aber statt lange draüber zu spekulieren ist es allemal besser, das vorsichtshalber mit in Rechung zu stellen.
Was dadurch geschied, dass von vorne herein an sich kritische Variablen nicht als globale, ggf. auch nicht als lokale, sondern als FGV konstuiert werden.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Koennte bitte jemand erklaeren, warum man in einer Schleife eine Wartezeit braucht? Ich habe leider keine LabVIEW-Vorlesung.
Das ist so nicht richtig. Im Schnitt kann man hier im LVF beobachten, daß Anfänger genau so häufig in eine Schleife überflüssige Waits hineinsetzen wie notwendige Waits unterlassen.
Es geht immer darum, daß eine Schleife nicht mit voller Geschwindigkeit, die der 3GHz-Prozessor hergibt, umläuft und so 100% Prozesserorlast beansprucht - auf Kosten anderer Prozesse, und zwar nicht nur die von LabVIEW, sondern auch die der Windows-Umgebung.
Bei Schleifen aber z.B mit QAQmx Read oder mit Visa Lesen ist eine Wartezeit meist schon durch das Warten auf neue Bytes gegeben. Da noch ein extra Wait in die Schleife reinzupacken wäre verkehrt.
02.03.2010, 21:14 (Dieser Beitrag wurde zuletzt bearbeitet: 02.03.2010 21:17 von GerdW.)
was bei der Diskussion um die (durchaus vorhandene) RaceCondition vergessen wurde zu erwähnen:
Jede lokale Variable belegt ihren eigenen Speicher, d.h. es wird eine Datenkopie angelegt. Dies ist bei einem Array von 4 Werten vielleicht noch unerheblich, aber wenn erstmal 100MB im Array gesammelt sind, kann's langsam kritisch werden. Und wer dann noch 2 (oder mehr) locals anlegt, darf sich über Programmabstürze nicht wundern. Deshalb (unter anderem) sehe ich es sehr kritisch, wenn LV-Einsteigern lokale Variablen auch noch empfohlen werden...
Meine Meinung: lokale Variablen vermeiden, wo es nur geht. Locals haben ihre Berechtigung, aber garantiert nicht zum Draht sparen... "In LabVIEW the wire is the variable!"
Oder auch "And here's where I keep assorted lengths of wire." (Bender)
' schrieb:was bei der Diskussion um die (durchaus vorhandene) RaceCondition vergessen wurde zu erwähnen:
Jede lokale Variable belegt ihren eigenen Speicher, d.h. es wird eine Datenkopie angelegt. Dies ist bei einem Array von 4 Werten vielleicht noch unerheblich, aber wenn erstmal 100MB im Array gesammelt sind, kann's langsam kritisch werden. Und wer dann noch 2 (oder mehr) locals anlegt, darf sich über Programmabstürze nicht wundern. Deshalb (unter anderem) sehe ich es sehr kritisch, wenn LV-Einsteigern lokale Variablen auch noch empfohlen werden...
An sich bin ich seit 2 Jahren Leid, hier über Sinn und Unsinn von lokalen Variablen zu streten. Ich hatte es aufgegeben, nachdem hier Lokale Variablen von einigen Experten in ihrer angeblichen Abscheulichkeit mit dem berüchtigten "Goto"-Befehl in textorientierten Sprachen gleichgesetzt wurden.
Erkläre doch das oben Zitierte mal den Profi-Programmieren von NI, die Deine Empfehlungen und Warungen glatt in den Wind schlagen. Wenn Du mal den "XY-Express-Graph" hineinschaust, kannst Du sehen, daß die Zwischenspeicherung des gesamten Grapheninhaltes - und das kann sehr viel sein - nicht über Shift-Register, sondern über ein lokale Variable erfolgt. Und es funktioniert nach meinen Erfahrungne auch bei großen Datenmengen schnell und fehlerfrei.
Was ich auch nicht mehr hören mag (- ich rede jetzt nicht von Dir -): "Der Grundgedanke von LabVIEW ist die Datenfußsteuerung. Lokale Variablen widersprechen dem Grundgednaken"
Falsch: Das eigentlich Revolutionäre an LabVIEW ist nicht die Datenflußsteuerung, sondern (fast) das Gegenteil davon: die quasiparallele Ausführung des geamten Codes.
Damit das nicht zu Konflikten fährt, bedingt das allerdings notgedrungen als zweites Konzept die Datenflußsteuerung. Wenn es aber keine Datenabhängigkeiten gibt, wäre es ganz und gar verkehrt - und wurde dem Grundkonzept von LabVIEW wirklich widersprechen - die Parallelität der Auführung durch Herstellung künstlicher Datenabhängigkeiten (oder mit Sequenzstrukturen, wie man oft sieht) einzuschränken.
)