' 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.
