Labview Threads on Process Explorer?

[Gary Rubin]

Process Explorer will list threads associated with an application. There is a lot of information provided about each thread, but it's not clear what it all means. Does anyone know if it's possible to relate a Process Explorer thread to a LabVIEW thread (e.g. Data Acquisiton, Standard, etc.)?

Gary

[Rolf Kalbermatter]

Process Explorer will list threads associated with an application. There is a lot of information provided about each thread, but it's not clear what it all means. Does anyone know if it's possible to relate a Process Explorer thread to a LabVIEW thread (e.g. Data Acquisiton, Standard, etc.)?

Gary

No, I do not think so. First there are no such things like DAQ thread, etc in LabVIEW. There is a DAQ Execution System and some others too, and each of them exists of usually 2, 4, 8 or more threads allocated at startup of LabVIEW. In newer versions the number of threads is even dependant on the number of cores the machine has.

LabVIEW simply allocates those threads at startup and the OS provides them but the OS has no idea what they are used for. There is possibly one exemption which would be the UI Execution System with always only one thread and this is the initial thread that was implicitedly created by the OS when the LabVIEW process started up. This thread is priviliged in Windows terms in many ways as it is for instance the thread that is used to dispatch any Windows events to the application and many technologies like DDE, ActiveX and such in Windows rely on this thread being responsive in order to work properly since the synchronization (for RPC for instance for Remote control of ActiveX) is going through the message dispatcher. It's a piece in Windows that is in fact amazing to work and keep working over all the different Windows versions.

And I have not seen any methods in LabVIEW that would return more specific information about the different threads such as the Windows Thread ID, which could be used to identify the different threads. Windows itself with the exception of the UI thread and that also only by implication, has no idea about what thread would be assigned to what execution system.

Rolf Kalbermatter

[Daklu]

Process Explorer will list threads associated with an application. There is a lot of information provided about each thread, but it's not clear what it all means. Does anyone know if it's possible to relate a Process Explorer thread to a LabVIEW thread (e.g. Data Acquisiton, Standard, etc.)?

Gary

In some cases it is possible to deduce which threads are performing certain actions. Looking at PE, the highlighted thread and the 15 others with the same name are the user threads. If you monitor this you can see which threads become active when you start a new parallel loop. It might be possible to identify certain LV primitives by examining function offsets on the thread call stack, although that would be a lot of work since the call stack is a snapshot and there's no guarantee the thread is executing that prim at any given moment.

It's also not always obvious by looking at the bd when LV will use one of those threads. A spinning loop uses one thread, but a spinning loop with a wait prim uses two and occasionally kicks in a third.

There is possibly one exemption which would be the UI Execution System with always only one thread and this is the initial thread that was implicitedly created by the OS when the LabVIEW process started up.

Is this is the 'UI thread' often talked about on the forums? I've never quite understood if they meant the Labview UI, the VI UI, or maybe even the Windows UI.

I'm also curious about the who does the user thread management. I take it LV is responsible for deciding when to invoke one of the threads from the pool. Does LV also manage all of it's own thread switching? Does the OS get involved in LV threads or does it stay at the process level?

[Vladimir Drzik]

Is this is the 'UI thread' often talked about on the forums? I've never quite understood if they meant the Labview UI, the VI UI, or maybe even the Windows UI.

I'm also curious about the who does the user thread management. I take it LV is responsible for deciding when to invoke one of the threads from the pool. Does LV also manage all of it's own thread switching? Does the OS get involved in LV threads or does it stay at the process level?

Some good startup information can be found here. However, some of the info is outdated, such as the one about two threads per execution system. In the latest LV versions, there can be more than two threads per execution system.

[Rolf Kalbermatter]

Is this is the 'UI thread' often talked about on the forums? I've never quite understood if they meant the Labview UI, the VI UI, or maybe even the Windows UI.

I'm also curious about the who does the user thread management. I take it LV is responsible for deciding when to invoke one of the threads from the pool. Does LV also manage all of it's own thread switching? Does the OS get involved in LV threads or does it stay at the process level?

The UI thread is most likely the main thread that gets started up by Windows when the LabVIEW process is created. This thread then creates additional threads that are used for the different execution systems. The UI Thread is actually the thread that drives the Windows message loop. As such it is in fact responsible for distributing all Windows events to LabVIEW (Windows UI) and it is also the thread LabVIEW uses to draw to the screen for any and all of its windows (so it is the LabVIEW UI and the VI(s) UI too.

Also some other things that need to be synchronized with Windows are done there and also anything the LabVIEW programmer assigns to that Execution System.

LabVIEW is responsible to assign code fragments to the various threads and put them in active and passive state as needed. Windows does the preemptive switching between the active threads (and other tasks/threads in the system).

Rolf Kalbermatter