(08.06.2012 13:29 )jg schrieb: (08.06.2012 12:44 )Kiesch schrieb: P.S: Interessant finde ich an dem Minimalbeispiel, dass scheinbar ein fester Ablauf vorliegt, obwohl ich erwarten würde, dass mal das eine, mal das andere Array eher zum Zuge kommt. Ka ob ich beim "Erzeugen von Gleichzeitigkeit" da noch nen Denkfehler habe...
Dass, sobald das VI gespeichert wurde, immer dasselbe passiert, ist IMHO normal. Denn LabVIEW erzeugt im Hintergrund Maschinencode, der dann natürlich deterministisch und immer identisch abläuft. Hauptproblem bei solchen Race-Condition: Auf Grund des Source-Codes hast du keine Chance vorherzusagen, was nun intern zuerst ausgeführt wird.
Was nicht passieren kann (richtig erkannt), dass am Ende eine "Mischung" aus den beiden unterschiedlichen Arrays rauskommt.
Gruß, Jens
Sollten nicht an der Stelle zwei Threads erzeugt werden die parrallel zueinander sind? So dass der Ablauf durch zwei parrallel laufende Prozesse eben gerade nichtmehr deteministisch ist? So hatte ich das zumindest bisher immer verstanden.
@Lucki
Es gibt genügend Anwendungen in denen Racing Conditions zwar auftreten aber die Abarbeitungsreihenfolge nicht Problematisch ist. Wenn ich mein Programm von nem Modus Datenaufnahme nach Stop umschalten soll ist es in 99 von 100 Fällen (Sprich: Anforderungen an das Program) egal ob ich einen Wert noch mitnehme (weil ich erst lese bevor ich stopp schreibe) oder sofort stoppe. etc. pp.
Falls ich doch das Pech habe den restlichen einen Fall programmieren zu müssen kann ich der Abarbeitungsreihenfolge immer noch Beachtung schenken. Es ist halt nur typischerweise nicht notwendig.
Das wichtigste ist doch nach wie vor sich darüber bewusst zu sein was man tut... Die meisten Fehler entstehen doch eher daraus, dass sich mancher garnicht darüber bewusst ist wenn er sich Racing Conditions einhandelt.
Das man wenn man eine Reihenfolge sicherstellen will die auch im Programm erzwingen muss ist ne ganz andere Frage.
