VI mit externer DLL macht kein Multithreading

' schrieb:Genau: Welches musst du nehmen, damit die DLL mehrfach aufgerufen respektive der DLL-Knoten abgearbeitet werden kann. Das weiß ich nicht, hab ich vergessen, hab ich erst einmal gebraucht. Aber mein Vorredner kann dir sagen, was du brauchst.

:DIch denke die Namensgebung sollte da doch schon sehr deutlich sein!

Im UI Thread (beachte das Fehlen eines Plural s am Ende) ausführen bedeutet doch in dem EINEN, SPEZIELLEN Thread, und da es davon eben nur EINEN gibt kann jeweils nur EINE Sache gleichzeitig laufen. Ob das jetzt User Interface Updates sind, aufrufen von Threadunsafen OS Funktionen, oder halt Deiner DLL Funktionen macht nichts aus.

In beliebigem Thread ausführen, bedeutet dann dass die entsprechende Funktion in jedem beliebigen Thread ausgeführt werden darf. Das heisst ganz egal in welchen Thread LabVIEW in dem Moment im VI ist, die Funktion darf ohne Umschweife aufgerufen werden. Und da LabVIEW per Execution System mit Thread Pools arbeitet, bedeutet das halt das innerhalb eines VIs mehrer Code Teile in verschiedenen Threads sein können (je nach LabVIEW Version und Anzahl CPU Cores glaube ich bis zu 16 derzeitig.

Das heisst wenn Du die Call Library Nodes alle in ein VI setzt (mich verwirrt aber der Ausdruck dass die da in einen Case kommen darum meine Frage um ein Beispiel) muss dieses VI ablaufinvariant sein UND alle Call Library Nodes müssen gleichzeitig auf "in beliebigem Thread ausführen" eingestellt sein. Sowohl "nicht ablaufinvarientes VI" als auch "im UI auszuführende Call Library Nodes" serialisieren unabhängig voneinander jede für sich den Aufruf in die DLL.

Nun noch ein Tipp im Zusammenhang mit der erwähnten Case Struktur. Wenn das jetzt so ist wie ich es mir denke, hast Du da ein VI mit einer Case Struktur und in jedem Case eine bestimmte Call Library Node um eine Funktion aufzurufen. Warum? Mach doch einfach ein VI pro Call Library Node. Das ist viel logischer in der Benützung und macht die Einstellung der Ablaufvarianz eines VIs schon mal etwas weniger kritisch. Denn typisch will man Operationen wie Open und Close gar nicht mal ablaufinvarient ausführen. Das bringt nähmlich in den meisten Fällen rein gar nichts ausser einer Chance um unangenehme Race Conditionen zu provozieren. Wo man hingegen bei der Kommunikation mit mehreren Geräten viel gewinnen kann, ist wenn entsprechende Read und Write Operationen ablaufinvarient ausgeführt werden können.