Race Condition

Hallo zusammen,
ich beschäftige mich zur Zeit mit dem Auftreten von Race Conditions.
Verstanden habe ich die Grundproblematik, aber nicht das einfache Beispiel, das man unter der LabVIEW-Hilfe findet:

http://zone.ni.com/reference/en-XX/help/...nd_global/

So wie ich das verstanden habe, muss eigentlich bei jedem Aufruf des VIs ein anderer Wert für x angezeigt werden.
Egal was ich mache und in welcher Reihenfolge ich das VI programmiere, es kommt bei mir immer ´3´ heraus.
Wenn ich die Race Condition-Problematik richtig verstanden haben, müsste doch unbestimmt mal ´3´ oder mal ´7´ angezeigt werden.

Wo liege ich da falsch ?

Vielen Dank.

(31.12.2015 16:26 )Eisbär schrieb:  Wenn ich die Race Condition-Problematik richtig verstanden haben, müsste doch unbestimmt mal ´3´ oder mal ´7´ angezeigt werden.

Race Condition besagt lediglich, dass es die Möglichkeit gibt, dass einmal der eine Zweig schneller sein könnte, ein anderes Mal vielleicht der andere Zweig. Eine Vorhersage, welcher Zweig (wie oft) schneller ist, darf aus dem Prinzip "Race Condition" nicht abgeleitet werden. Sicher ist nur, dass man nicht sagen kann, welcher Zweig zuerst fertig ist.

Im übrigen bin ich der Meinung, dass das Beispiel ein schlechtes ist.

(31.12.2015 16:42 )IchSelbst schrieb:  Im übrigen bin ich der Meinung, dass das Beispiel ein schlechtes ist.

Das soll es ja auch sein . Du meinst - und da stimme ich Dir voll zu - , das ist ein schlechtes "schlechtes Beispiel". Oder wie drückt man das beser aus? Ein schlechtes "bad example"? In einem Lehrbuch waren die schlechten Beispiele zusätzlich noch durchgestrichen - sehr gute Idee.
Gruß Ludwig

Hallo IchSelbst,
vielen Dank für Deine Antwort.

Das Beispiel ist wirklich nicht gut: ich haben einen Vergleich eingefügt, der mir einen Ton ausgibt, wenn x den Wert ´7´ hat. Auch nach längerer Laufzeit des VIs ´piept´ hier nichts, ´7´ wird also (scheinbar) nie erreicht.

Und jetzt: einen guten Rutsch ins Neue Jahr 2016

Eisbär

(31.12.2015 19:47 )Lucki schrieb:  Das soll es ja auch sein . Du meinst - und da stimme ich Dir voll zu - , das ist ein schlechtes "schlechtes Beispiel". Oder wie drückt man das beser aus? Ein schlechtes "bad example"? In einem Lehrbuch waren die schlechten Beispiele zusätzlich noch durchgestrichen - sehr gute Idee

Nein, Nein, Lucki (oder doch Ja, Ja ):
Für ein Programm gemäß Programmierparadigma "Datenflusssteuerung" () ist es ein schlechten Beispiel, weil eines mit RaceCondition. Um eine RaceCondition zu erklären jedoch, ist es ein gutes Beispiel - naja eben auch ein schlechtes.



Oh man, ich bin 12 Minuten zu spät ...

(31.12.2015 20:10 )Eisbär schrieb:  Das Beispiel ist wirklich nicht gut: ich haben einen Vergleich eingefügt, der mir einen Ton ausgibt, wenn x den Wert ´7´ hat. Auch nach längerer Laufzeit des VIs ´piept´ hier nichts, ´7´ wird also (scheinbar) nie erreicht.

Du siehst das falsch: Das Beispiel ist nicht deswegen schlecht, weil du die RaceCondition nicht nachweisen kannst. Du wirst mit an Sicherheit grenzender Wahrscheinlichkeit, praktisch also nie, selbst bei einer statistisch gesehen ausreichenden Anzahl von Versuchen ein anderes Ergebnis bekommen wie beim ersten Versuch. Wenn überhaupt würde eine RaceCondition sporadisch, also praktisch nicht debugbar, auftreten. Du sollst RaceCondition schon auffassen als Wettlauf zweier paralleler (also nicht sequenzierter) Programmabläufe - aber nicht in derart, dass du vorhersagen willst, welcher dieser beiden Abläufe zuerst am Ziel, also komplett abgearbeitet, ist.

Schlecht ist das Beispiel deswegen, weil kaum ein Programmierer auf eine Variable zweimal schreibt (innerhalb einer Struktur). Besser finde ich ein Beispiel, in dem unsequenziert einmal lesend und einmal schreibend auf die Variable zugegriffen wird. Hier stellt sich nämlich die Frage, welchen Wert der Draht hat, der an der gelesenen Variablen hängt. Hat dieser Draht den Wert, der in der geschriebenen Variablen steht oder hat der Draht den Wert, den die Variable hatte, bevor sie beschrieben wurde?

Anzeige

Hallo,
ich wollte auch keine Vorhersage machen, welcher Thread zuerst ankommen wird.
Mir ging es nur darum, einmal festzustellen, ob überhaupt, irgendwann einmal der Wert ´7´ erzeugt wird, denn das wäre ja eine schöne Demo für das Auftreten einer Race Condition.
Wenn aber z.B. nach 1.000.000 Durchläufen des VIs nie der Wert ´7´ auftaucht, ist es schwierig bei diesem Beispiel die Problematik einer Race Condition aufzuzeigen, weil ja ´gar nichts Schlimmes´ passiert, weil das Ergebnis dann ja doch vorhersehbar ist.

(01.01.2016 12:44 )Eisbär schrieb:  Wenn aber z.B. nach 1.000.000 Durchläufen des VIs nie der Wert ´7´ auftaucht, ist es schwierig bei diesem Beispiel die Problematik einer Race Condition aufzuzeigen, weil ja ´gar nichts Schlimmes´ passiert, weil das Ergebnis dann ja doch vorhersehbar ist.

Das Schlimme passiert möglicherweise ja erst dann, wenn du in einem anderen VI, das autark parallel läuft, eine Änderung machst ...

(01.01.2016 12:44 )Eisbär schrieb:  Hallo,
ich wollte auch keine Vorhersage machen, welcher Thread zuerst ankommen wird.
Mir ging es nur darum, einmal festzustellen, ob überhaupt, irgendwann einmal der Wert ´7´ erzeugt wird, denn das wäre ja eine schöne Demo für das Auftreten einer Race Condition.
Wenn aber z.B. nach 1.000.000 Durchläufen des VIs nie der Wert ´7´ auftaucht, ist es schwierig bei diesem Beispiel die Problematik einer Race Condition aufzuzeigen, weil ja ´gar nichts Schlimmes´ passiert, weil das Ergebnis dann ja doch vorhersehbar ist.

Ihr seht das falsch. Wenn der interne Compiler sich einmal für ein bestimmte Reihenfolge entschieden hat, dann bleibt es dabei, da kannst Du viele Versuche machen. Man sollte hier besser sagen: Aus dem Code heraus ist das Ergebnis nicht vorhersagbar. Zufällig ist es deswegen nicht. Trotzdem darf man sich nicht darauf verlssen, dass es immer gut geht, wenn es einmal gut gegangen ist. Wenn z.B der Code in einen anderen Code eingebettet wird, oder bei einer andern LV-Version, oder auf einem anderen PC, oder wenn ein Interrupt dazwischenkommt, oder was weiß ich sonst noch, kann sich die Reihenfolge jederzeit ändern.

Mit dem schlechtem "schlechten Beispiel" meinte ich folgendes: da wird zweimal aus zwei Konstanten eine Summe gebildet. Die Gesamtsumme aus allen 4 Zahlen kann aber so gar nicht entstehen, und das hat mit Race-Conditiones überhaupt nichts zu tun. Im nachfolgenden "richtigen" Beispiel wird aber dann die Gesamtsumme gebildet, als ob das die Berichtigung das ersten Beispiels wäre. Ist es aber nicht, die Beispiele sind einfach verschieden und haben nicht viel miteinander zu tun.