Wait im UI Thread (?)

Hallo,

ich habe vom LabVIEW Support von peak-system.com die Aussage bekommen:

"Wenn ich richtig informiert bin, dann verursachen sowohl Wait, Metronom als auch Tick Count einen Taskwechsel in den GUI thread. Das kann unter umständen sehr negativ sein."

Jetzt bin ich verwirrt. Der UI Thread ist doch der böse mit der geringen Prio, der einem die Programmperformance torpediert. Deswegen auch die Misere mit property nodes. Das passt nicht in meine Weltansicht wo die Waits die Guten sind und ungebremste Schleifen die Bösen.

   

Soll die jetzt ohne wait laufen? Nää...



Gruß Dimitri

Hallo Jungs,

was meint ihr?

"... verursachen sowohl Wait, Metronom als auch Tick Count einen Taskwechsel in den GUI thread" ?


Gruß
dimitri

Kein Ahnung, aber man könnte die Aufzählung der Verdächtigen noch erweitern:
Kann man den Taskwechsel vielleicht vermeiden, wenn man eine zeitgesteurte Schleife statt Wait verwendet?
Und was ist mit den Timeouts, z.B bei der Ereignisstruktur? Soll man vielleicht statt Wait eine leere Eeignisstruktur verwenden, die nur den Case Timeout enthält? Vorstellen kann ich mir das nicht, daß das was bringt.

(01.02.2012 20:50 )dimitri84 schrieb:  "... verursachen sowohl Wait, Metronom als auch Tick Count einen Taskwechsel in den GUI thread" ?

Ich kann es mir nicht vorstellen. Vielleicht einfach mal bei NI anfragen und die Aussage bewerten lassen?

Schöne Grüße
Falk

"Probieren geht über studieren". Danach ist der Aufruf von Wait immerhin 30 mal schneller als der Aufruf eines Eigenschaftsknotens - siehe unten. Also Entwarnung, kein Grund zur Panik.
   

Ich werde das in der Tat mal mit dem NI Support besprechen bei nächster Gelegenheit - und berichten.

Vielleicht ist der Satz auch einfach anders zu verstehen: Nicht die Funktion "Wait" selbst verursacht den Taskwechsel, sondern das Betriebssystem nutzt die Verschnaufpause um ausstehende UI Aufgaben auszuführen. (Das würde Luckis Test begründen, denn da ist einfach nix zu tun, wenn gewartet wird.)

Ich erzähl dann was NI sagt.

Anzeige

Hab NI zu dem Thema befragt: Ja, es stimmt. Die drei benannten Funktionen werden im UI-Thread ausgeführt.

Mit Timed-Loops fährt man wohl tatsächlich manchmal besser.

Gruß

(26.01.2012 17:48 )dimitri84 schrieb:  Hallo,

ich habe vom LabVIEW Support von peak-system.com die Aussage bekommen:

"Wenn ich richtig informiert bin, dann verursachen sowohl Wait, Metronom als auch Tick Count einen Taskwechsel in den GUI thread. Das kann unter umständen sehr negativ sein."

Jetzt bin ich verwirrt. Der UI Thread ist doch der böse mit der geringen Prio, der einem die Programmperformance torpediert. Deswegen auch die Misere mit property nodes. Das passt nicht in meine Weltansicht wo die Waits die Guten sind und ungebremste Schleifen die Bösen.



Soll die jetzt ohne wait laufen? Nää...



Gruß Dimitri

Ein Wait verursacht garantiert keinen Taskwechsel, denn der ganze LabVIEW Prozess ist genau ein Task und kann deshalb nicht einfach so in einen anderen Task umschalten. Ein Wait setzt aber den aktuellen Codejunk in eine Warteliste und erlaubt anderen Codejunks um ausgeführt zu werden. Das geht weiter dann Threads da LabVIEW bevor es Multhreading vom OS spendiert bekam schon ein eigenes, allerdings kooperatives Multithreading hatte. Sogenannte Clumps (in sich nicht weiter teilbare Codeteile) werden von LabVIEW in eine Execution Queue gestellt, um ausgeführt zu werden. Ein Wait bewirkt ein explizites Hintenanstellen vom aktuellen Clump in eine Wartequeue, und gibt anderen Clumps die Gelegenheit ausgeführt zu werden, sofern die dann bestehen. In jedem Fall scheduled LabVIEW den Clump um nach der Wartezeit wieder aufgeweckt (in die Execution Queue gesetzt) zu werden. OS Multithreading macht das alles noch etwas komplexer aber verändert am Prinzip nicht viel.

Eine Wait gibt also tatsächlich anderen Teilen in LabVIEW die Möglichkeit um ausgeführt zu werden und das kann auch DER UI Thread sein. Aber hier muss ausdrücklich darauf hingewiesen werden, dass das ein KANN ist und nicht ein MUSS. Und auch wenn Du kein Wait in den Code setzt wird der UI Thread typischerweise eine Anzahl mal pro Sekunde getriggert, sofern denn etwas im UI Thread auszuführen ist. Die Aussage dass ein Wait oder ähnliches automatisch in den UI Thread wechselt ist also völlig falsch. Es gibt die Kontrolle über den aktuellen Thread explizit auf und das KANN bewirken dass der UI Thread aktiviert wird, aber es MUSS nicht so sein und auch ohne Wait wird der UI Thread regelmässig aktiviert.

Die Aussage vom Support ist in diesem Sinne faktisch falsch und klingt eher nach einer faulen Entschuldigung für etwas was sie in ihrem Produkt verbrochen haben.

Danke rolfk, sehr hilfreich.