Race Conditions

Selbstverständlich ist es möglich. Idealerweise lässt du einen Fehlercluster diese Strukturen in gewünschter Reihenfolge passieren. Suche nach dem Begriff "Datenfluss".

Anzeige

' schrieb:und ich lege fest, pro Zyklus soll erst Case 1, dann 2, dann 3 folgen und dann ForSchleife 3, ForSchleife 2 und zum Schluss ForSchleife 1?

Oder meinst Du es so: Bei Schleifenzyklus 1: Case 1 ausführen , bei Zyklus 2: Case 2 ausführen, ... ,bei Zyklus 7 wieder Case 1 ausführen usw.
Dann wäre das ein Fall für ein state-machine

  Test.vi (Größe: 12,94 KB / Downloads: 199)

' schrieb:Gibt es einen Weg festzulegen, in welcher Reihenfolge was abgearbeitet wird? Zum Beispiel in einer While-Schleife habe ich 3 Cases und 3 For Schleifen und ich lege fest, pro Zyklus soll erst Case 1, dann 2, dann 3 folgen und dann ForSchleife 3, ForSchleife 2 und zum Schluss ForSchleife 1? So etwas ist wahrscheinlich nicht möglich, oder?

Wenn du von deinem VI aus diesem Thread ( http://www.labviewforum.de/index.php?showtopic=17385 ) ausgehst, bei dem ist es gerade nicht der Fall. Weshalb dich dort jeder vor Race Conditions gewarnt hat.
Man kann das natürlich anders programmieren, z.B. durch Datenfluss, State-Machine, Sequenzstruktur (igitt), etc. etc. etc.

Gruß, Jens

' schrieb:Danke schonmal:)finde man kann über Race Conditions nicht genug aufgeklärt werden :-D

Ich hab mit das von Jens G. verlinkte VI angekuckt - und muss sagen: ganz böse RaceCondition. Siehe Bild.

Man kann nicht ausschließen, dass folgendes passiert:
Die For-Schleife soll 100mal laufen. Parallel(!) zur For-Schleife läuft der Case "Offset Off". Es passiert folgendes: Die For-Schleife läuft 50mal durch. Während dieser 50mal hat das Array einen bestimmten Wert, der verrechnet werden soll. Zwischen dem 50. und dem 51. Mal drängt sich, weil parallel, der Case, in diesem Falle mit true, zwischenrein - und löscht das Array. Die Schleifendurchläufe 51 bis 100 verwenden also einen anderen Arrayinhalt wie die Schleifendurchläufe 1 bis 50.

' schrieb:Man kann nicht ausschließen, dass folgendes passiert:

Aber kann das wirklch passieren, wenn die For-Schleife gar kein Wait enthält? In einem Buch habe ich gelesen - und so etwas steht auch in der Hilfe zum Wait-VI - daß, wenn man wünscht, daß die CPU während der Ausführung einer Schleife gegebenenfalls die Kontrolle abgeben soll, man ein Wait mit Time=0 in die Schleife platzieren soll.
Im Umkehrschluß würde das aber heißen: Wenn kein Wait oder sonstige Wartezeit in der Schleife ist, dann ist die Schleife während ihrer Ausführung nicht bereit, die Programmausführung zwischenzeitlich abzugeben.
Aber davon angesehen: Schon weil die lokale Veriable langsamer ist sollte man sie besser vor die Schleife stellen, damit sie nicht 1001 Mal gelesen wird.

Wer sagt denn, dass das eine äquivalente Aussage ist?

Ein wait zwingt die Schleife die CPU frei zu geben!
Die Schleife darf es aber auch freiwillig machen!

Ist aber auch nur ne Vermutung, in meinen Programmen verlasse ich mich nicht auf sowas sondern programmiere einen schlüssigen Datenfluss.

Grüße,
Torsten

@Tschac
Hast ja Recht. In dem Bespiel unten zählt die zweite Schleife ganz normal, was sie nicht täte, wenn die erste Schleife die Steuerung nie abgeben würde.
   

@lucki,.. Jetzt lässt du dich aber in die Irre führen. Wer sagt denn bei dem Ausschnitt, dass die zweite Schleife nicht als erstes die Kontrolle bekommt? und in den 499 ms die die Schleife ca wartet ein externer Prozess die CPU belegt?

Ob die Schleife einen logischen Kern für sich beanspruchen kann oder nicht legt nicht die Schleife, sondern das Betriebssystem fest.

In YP VI ist mir, mal abgesehen von den vielen unnötigen Durchläufen in , auch die Differenz der beiden Anzeigen nicht geheuer.
   

Das Betriebssystem weist dem Programm/VI CPU-Zeiten zu. Aber was das Programm damit macht entscheidet die LVRT.