Race Conditions

Da wär ich mir nicht sicher, denn schließlich startet die RT im Idealfall für jede Schleife einen eigenen Thread, und der wird vom OS gesteuert.

Anzeige

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

In Büchern steht viel.

"Dass die CPU ..." impliziert, dass der Prozess, der die FOR-Schleife enthält, die CPU für sich beansprucht. Dem sollte aber nicht so sein. Die CPU sollte alleine dem Betriebssystem unterliegen. Wenn das Betriebssystem also meint, es müsste jetzt ein Timesharing machen, wird der aktuelle Prozess unterbrochen, wo er gerade steht. Und steht der innerhalb einer FOR-Schleife, so wird die FOR-Schleife unterbrochen. (Diese meine Aussage impliziert nun aber, dass LV sich nicht so weit in das Betriebssystem gebohrt hat, dass es das Timesharing des Betriebssystems nicht unterdrückt. Und auch Seiteneffekte durch Multicore lass ich jetzt mal weg).

Was für die CPU gilt, gilt natürlich auch für die parallelen Tasks innerhalb von LabVIEW: Laufen mehrere Tasks parallel, macht hier das "LV-Timesharing-System" mit den Tasks genau das selbe wie das BS mit den Prozessen auf der CPU: While-Schleifen können an beliebigen Stellen unterbrochen werden.

Die Frage ist nun tatsächlich, ob dieses "Timesharing" auch für "parallele Datenflüsse" innerhalb eines Blockes gilt, also z.B. für eine FOR-Schleife, der eine CASE-Struktur parallel ist. Es anzunehmen, schadet nicht.

Das Problem bei diesem Beispiel für RaceCondition liegt in der Wahrscheinlichkeit, dass FOR-Schleife und Case-Sequenz tatsächlich zur gleichen Zeit zur Ausführung kommen. Nur dann, wenn der "Compiler" das Programm genau so übersetzt, dass beide zur gleichen Zeit zur Ausführung kämen, würde der RaceCondition-Effekt sichtbar werden. Und diese Wahrscheinlichkeit ist in dem vorliegenden Beispiel eher klein.

Zitat: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.

Umkehrschlüsse haben einen Nachteil: Sie sind nur gültig für Systeme, die zu 100% bekannt sind. Und wer weis schon genau, was unter BD und FP so alles passiert - außer RolfK, der das mit der FOR_Schleifenunterbrechbarkeit bestimmt genauer weis.

Naja vermutlich habt ihr recht, allerdings hat das alles auch nicht mehr viel mit dem Topic hier zu tun. Und am Ende ists ja auch egal ob LV oder WIN verursacht, dass es bei RaceConditions zu ungewollten Überholmanävern kommt!

An ungewollten Überholmanävern ist immer der Programmierer schuld

Hui, dass sind jetzt aber viele Antworten

@dimitri - vielen Dank für den Hinweis, ich werde mich gleich drüber schlau machen wie man solche Reihenfolgen festlegt. EDIT: Finde leider keine guten Threads zum Thema "Datenfluss" direkt, aber ich schau mal in meine zwei Bücher, die ich noch da habe.

@Lucki, Dein VI habe ich erfreulicher weise sofort gedownloaded und schau es mir nachher an und freu mich schon auf den Inhalt.

@JensG - Ja genau, das Programm meine ich :-D mein LabVIEW Baby und mein erstes richtiges Programm was überhaupt mal was Sinnvolles macht, ausser die Füllstandshöhe anzuzeigen, wie wir es in der Schule als Lernbeispiel hatten;)sry, Uni :-D

@IchSelbst - Ja, also Du meinst wenn ich bei Schleifendurchlauf 50-51 meinen Booleanbutton auf True setze, dann wird mein Array gelöscht? Das ist ja auch so gewollt, denn ich speichere Offsetwerte die mit diesem Knopf genullt werden und wenn man mag, neu gesetzt werden können. Oder meinst Du das da automatisch ein True reinwandern kann, aus einer anderen Case-Abfrage? Ich hät ja auch gerne eine IF-Anweisung im LabView, aber ich finde es nicht, deswegen benutze ich Case.

@TSchAC - da hast Du Recht mit dem Datenfluss, sicher ist sicher. Lieber einbauen, als sich auf Glück zu verlassen.

Der Rest der Antworten spricht für wirklich gutes Fachwissen eurer seids, ich verstehe es, kenn mich aber nicht gut genugt aus um da mit zureden;)Was mich freuen würde, wäre in einem Thread der Race Condition heisst, wenn hier auch zig "Race Condition" - Beispiele samt Lösung zu finden wären. Also wenn ihr mal auf eins stoßt und es auch noch gelöst habt ;-D immer rein damit

' schrieb:..
Was mich freuen würde, wäre in einem Thread der Race Condition heisst, wenn hier auch zig "Race Condition" - Beispiele samt Lösung zu finden wären. Also wenn ihr mal auf eins stoßt und es auch noch gelöst habt ;-D immer rein damit
..

Am Ende entstehen alle RaceConditions durch das gleiche Prinzip. Wenn man das einmal verinnerlicht hat, ist es ein Leichtes

1. soclhe Fälle zu vermeiden
2. falls sie doch auftreten, sie zu finden und zu lösen!

Die Lösung ist immer ein ordentlicher Datenfluss!

' schrieb:Die Lösung ist immer ein ordentlicher Datenfluss!

Dem ist an sich nichts hinzuzufügen, als vielleicht dieses: Die parallele Auführung von Codeteilen, die nicht voneinander datenabhängig ist, ist das Grundkonzept von Labview und dessen hervorragendste Eigenschaft.
Gerade Anfängern ist dies Eigenschaft aber oft suspekt, da sie das einerseits von anderen Sprachen nicht kennen und andererseits - beispielweise bei solchen Forenbesuchen - immer wieder vor unerwarteten Effekten gewarnt werden.
Als Reaktion darauf versuchen sie dann, diese Eigenschaft von Labview möglichst ganz außer Kraft zu setzen. Man sieht das im Code an der exzessiven und überflüssigen Verwendung von Sequenzstrukturen - das ist geradezu die Visitenkarte, mit der sich jemand als Anfänger ausweist.
Deshalb würde ich es so formulieren: Datenflußsteuerung ist lebenswichtig, aber ebenso sollte man Labview die Freiheit gönnen, die Ausführungreihenfolge von nicht datenabhängigen Codeteilen frei zu entscheiden.