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!
' schrieb:Diese Art der Programmierung widerspricht allerdings dem LV Grundgedanken der datneflussorientierten Programmierung, da lokale Variablen Sprunkbefehle repräsentieren. Datenfluss bedeutet nunmal auch einige Drähte im BD.
Unter einem Sprung-Befehl verstehe ich ein wenig was anderes. Eine Lokale Variable ist doch lediglich ein Konstrukt, um einen bestimmten Speicherbereich auszulesen. Der Datenfluss wird auch nicht "wirklich" gestört, da er ja durch die Case-Strukturen bestimmt ist. Das einzige Problem was im zweiten Screenshot von Lucki auftreten könnte, wären Race-Conditions. Da aber in den beiden Case-Strukturen nicht auf die selben Indizes im Array zugegriffen wird, ist das hier auch kein Problem.
Ein Sprung-Befehl ist in meiner Welt eher eine Art Schleife. Wenn du am Sprung-Befehl angekommen bist, gehe zurück zum Einstiegspunkt und fahre dort fort. Damit eine Terminierung des Codes sichergestellt ist, sollte der Sprung-Befehl in diesen Falle durch einen Case-Anweisung abgesichert sein.
Eine andere Möglichkeit wäre, bestimmte Teile des Codes, zu überspringen. Auch hier bietet siche eine Case-Struktur an.
LG
Torsten
"Über Fragen, die ich nicht beantworten kann, zerbreche ich mir nicht den Kopf!" (Konrad Zuse)
' schrieb:Da aber in den beiden Case-Strukturen nicht auf die selben Indizes im Array zugegriffen wird, ist das hier auch kein Problem.
Das sehe ich anders.
Das Problem tritt nicht auf, weil auf "Indices zugeriffen" wird, sondern weil das Array in zwei Datenflüssen vorhanden ist. Das Problem hierbei ist, dass beide parallel ausgeführt werden (können). Bedenke folgenden Fall: Das Array der einen Schleife wird ausgelesen - und genau in dem Moment, in dem dieser Datenfluß in das Array-Bearbeitungs-Element eintritt, wird die parallele Case-Sequenz ausgeführt. Dort wird jetzt auch das Array ausgelesen und ein Datenfluß erzeugt. Jetzt liegen zwei identische Datenflüsse vor. Jeder der beiden ändern jetzt seine spezifischen Indices. So: Wer von den beiden ist jetzt berechtigt, seine manipulierten Daten in dem Array-Element abzuspeichern? Typischer Fall von Race-Condition - also keine Abhängigkeit von Indix-Manipulieren, sondern nur alleine von zwei Datenflüssen.
Lösung: Cases seqeunzieren mit dem Array.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:da lokale Variablen Sprunkbefehle repräsentieren.
Von einem bestimmten Standpunkt aus, kann man das so sagen: Irgendwann ist ein Datenfluß abgearbeitet, dann "springt" die Abarbeitung zum nächsten Datenfluß. Und der beginnt hier nunmal mit einer Lokalen Variablen. Das impliziert aber, dass es keine parallele Verarbeitung gibt!
Besser ist es aber, es so zu sehen: Alle Datenflüsse, egal mit was sie beginnen - ob mit Lokalen Variablen, Schieberegistern, VI-Ausgängen etc. , beginnen gleichzeitig. Das impliziert, es gibt keine Sprungbefehle!
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Von einem bestimmten Standpunkt aus, kann man das so sagen: Irgendwann ist ein Datenfluß abgearbeitet, dann "springt" die Abarbeitung zum nächsten Datenfluß. Und der beginnt hier nunmal mit einer Lokalen Variablen. Das impliziert aber, dass es keine parallele Verarbeitung gibt!
Besser ist es aber, es so zu sehen: Alle Datenflüsse, egal mit was sie beginnen - ob mit Lokalen Variablen, Schieberegistern, VI-Ausgängen etc. , beginnen gleichzeitig. Das impliziert, es gibt keine Sprungbefehle!
Auf jeden Fall sagte das NI zu mir. Aber die sagten eher Sprungbefehl, als Sprunkbefehl.
' schrieb:Das sehe ich anders.
Jetzt liegen zwei identische Datenflüsse vor. Jeder der beiden ändern jetzt seine spezifischen Indices. So: Wer von den beiden ist jetzt berechtigt, seine manipulierten Daten in dem Array-Element abzuspeichern? Typischer Fall von Race-Condition - also keine Abhängigkeit von Indix-Manipulieren, sondern nur alleine von zwei Datenflüssen.
Über die Race-Condition der parallelen Schleifen hatte ich auch nachgedacht, als ich das Beispiel erstellte, denn die parallele Verwendung von lokalen Variabelen ohne Datenabhängigkeit in einer Schleife ist ja geradezu das Musterbeispiel, wie man es nicht machen soll. Dann habe ich mir aber gesagt: Die Bedenken sind in diesem Beispiel rein akkademisch. Denn kein Mensch würde es schaffen, die beiden Bedienköpfe, die der jeweiligen true-Case auslösen, so schnell hintereinader zu drücken, das es mit dieser diese race-condition ernst wird.
Und wer ganz genau hinschaut, der wird feststellen, das es selbst bei gleichzeitiger Ausfühung nicht kritisch werden kann. Zwar wird in beiden Cases die gleiche lokale Variable verwendet, aber: In der ersten Casestruktur werden nur die ersten beiden Element des Array beschrieben, in der zweiten Strukture nur die letzten beiden. Der optische erste Eindruck, daß es da bei gleichzeitiger Auführung Wettlaufprobleme gibt, erweist sich also bei geauerem Hinsehen als falsch.
Das zweite Argument ist mir erst jetzt eingefallen und macht das erste, schwächere Argument überflüssig. Ich lasse es aber so stehen.
Die Knöpfe müssen nach dem Betätigen nicht wieder in den False-Zustand zurückgehen. Daher ist es durchaus möglich, dass beide schon bei Beginn der Iteration true sind.
' schrieb:Die Knöpfe müssen nach dem Betätigen nicht wieder in den False-Zustand zurückgehen. Daher ist es durchaus möglich, dass beide schon bei Beginn der Iteration true sind.
Ja, Du beziehst Dich jetzt auf mein erstes Argument, welches ich selbst als schwach und überflüssig bezeichnet habe, aber zu faul war es zu löschen. Hätte ich es doch getan
' schrieb:Und wer ganz genau hinschaut, der wird feststellen, das es selbst bei gleichzeitiger Ausfühung nicht kritisch werden kann. Zwar wird in beiden Cases die gleiche lokale Variable verwendet, aber: In der ersten Casestruktur werden nur die ersten beiden Element des Array beschrieben, in der zweiten Strukture nur die letzten beiden. Der optische erste Eindruck, daß es da bei gleichzeitiger Auführung Wettlaufprobleme gibt, erweist sich also bei geauerem Hinsehen als falsch.
Das zweite Argument ist mir erst jetzt eingefallen und macht das erste, schwächere Argument überflüssig. Ich lasse es aber so stehen.
Und da genau liegt doch der Fehler wenn ich es richtig verstanden habe. Wenn beides gleich abgearbeitet wird, dann stimmen auf jeden Fall 2 Werte nicht.
' schrieb:Die Bedenken sind in diesem Beispiel rein akkademisch.
Zitat:In der ersten Casestruktur werden nur die ersten beiden Element des Array beschrieben, in der zweiten Strukture nur die letzten beiden. Der optische erste Eindruck, daß es da bei gleichzeitiger Auführung Wettlaufprobleme gibt, erweist sich also bei geauerem Hinsehen als falsch.
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!
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
. Aber die sagten eher Sprungbefehl, als Sprunkbefehl.
