VI mit externer DLL macht kein Multithreading

' schrieb:>VIs haben keinen Parameter "UI-Thread oder beliebigem Thread".
Ja, so ists, die haben keinen solchen Parameter, nur das Call Library Node hat sowas.

Role hat es ja schon gezeigt. Diese Einstellung gibt es eben doch!

Zur Kommunikation mit Netzwerkdevices. Wiederholtes Open-Read-Write-Close für solche Geräte ist keine gute Idee wenn die Schnellheit wichtig ist. Das Öffnen eines Kommunikationskanals an sich kostet typischerweise schnell mal 50 bis 100 ms (Bei Verwendung von IPv6 sockets in Windows XP zumindest, gar das Doppelte). Zudem gibt es bei TCP Write noch den interessanten Nagle Algorithmus. Der verursacht bei kleinen Writepacketen ein Standarddelay von 200ms bevor das Packet den Computer echt verlässt. Den kann man mit der TCPNoDelay Socketoption zwar ausschalten, aber ohne Sicht auf die VS2005 Sourcen ist es unmöglich zu sagen ob Du da Rechnung damit getragen hast. Auch arbeitet Winsock standardmässig in blocked mode und das in C oder dergleichen anders zu machen ist nicht trivial. Je nach dem ob Du also diese Sockets verwendest oder aber eine höhere Kommunikationslibrary, kann das auch noch ein Stolperstein sein.


Ich bin also nicht ganz überzeugt dass das angedeutete Problem durch die verkehrte (oder Nicht-)Verwendung von Ablaufinvarianz verursacht wird, obwohl das natürlich auch noch sein kann. Ich weiss aber ganz sicher und habe das auch schon öfters verwendet, dass LabVIEW auch bei den Netzwerkfunktionen selber ablaufinvarient funktioniert. Das Problem der unerwarteten Laufzeitverzögerung kann also ganz einfach auch inherent an Deiner Implementation in der DLL liegen.