AN114 Multithread VIs

[steady]

Application note 114 "Using LabVIEW to Create Multithreaded VIs for Maximum Performance and Reliability" is regardeds as guideline for me, when I want to deepen my knowledge about this topic. I read it really hard for more than 2 times. However I still don't understand it thoroughly. Basically this actical doesn't make me understand anything I didn't know. It repeats several easy points, and cites some difficult terms, but I still don't understand.

The largest confusion is where "multi-thread" really relies on, operation system or LabView. Of cource LabView is running on an OS (I am using Windows). But when it boasts multithread charateristic of LabView, it emphasizes it is the advantage of LabView:

"A graphical programming paradigm lends itself to the development of parallel code execution. Because it is much
easier to visualize the parallel execution of code in a dataflow environment, where two icons or two block diagrams
reside side by side, graphical programming is ideal for developing multithreaded applications. However, the same
problems with communication among threads can arise unless LabVIEW manages the threads for you."

Beautiful! It is what I have known about LabView. And it seems to imply: the parallel execution is multithread. But after it:

"(Windows 2000/NT/9x and Solaris 2) The application is multithreaded. The execution system preemptively multitasks
VIs using threads. However, a limited number of threads are available. For highly parallel applications, the
execution system uses cooperative multitasking when available threads are busy. Also, the operating system
handles preemptive multitasking between the application and other tasks."

What?! Threads are limited? Ok, by whom? For highly parallel application, why is cooperative multitasking needed? What is the actual role OS plays "Also, the operating system handles preemptive multitasking between the application and other tasks"? More importantly, it seems parallel execution is NOT really multi-thread. Because thread is limited, we can suppose there is only 1 thread. Under this condition, if I put 2 while loops without data dependance, aren't they parallel?

In summary, it seems thread in fact can only be in terms of OS. Could any guru clarify the concept? It would be better if the execution system is also included within the explanation.

[steady]

I am still waiting the answer. Maybe it is too complex.

[F._Schubert]

Threads are indeed handled by the operating system. However, there are some calls to allow you a bit of a control on these and they are available in LV. The most important is the priority setting of your VI. Another is the option to assign a specific CPU core to a timed loop (I'm not up-to-date on the details). As far as I did use traditional languages, where you need to manage the threads on your own, this is about everything you can do (I think those were calls to kernel32.dll).

The more important issue is the number of threads you have. If I remember correctly, LV has 2 threads per default (might have changed since more cores are available now). These two threads are per 'Execution System'. An exeption is the UI thread, which is only a single thread and a necessary bottleneck (this is why property nodes are slow, they all require a threadswap to the single UI thread).

Both priority and Execution System are available via theVI properties->Execution (might have changedsince my good old 7.1).

The NI LV R&D team did put a lot of effort to make LV performing better and better since the introduction of multithreading (it was speculated to be introduced in LV 5). So it depends on your LV version. A recent feature is the 'parallel for loop' execution.

If you can ask more specific, we might give better answers than this explanation. But most of these issues are managed so well internally, you don't need to study them.

Felix

[steady]

Schubert,

Thanks for your reply. As I know, normally the subvi is configured as "same as caller" in terms of execution system. So almost all the codes share the same execution system, i.e. 2 threads. If we have more than 2 parallel dataflows running, how should I understand the behavior? Now my guess is LabView can use only 1 thread to handle multiple parallel executions.

I am interested in this topic, because I am working with a relative large LabView program. It comprises a main test program and many sub test functions. Every function has its own front panel. When it comes to the test function, the front panel will be opened. For example, there is an function dealing with errors. When error occures, the function will open its own front panel to show up the errors. Now the problem is, when the errors are too many, this front pannel will always be active in updating the error status, and the system doesn't respond to the operation on the main front panel. I don't know if it is related with multi thread concept.

Steady

[F._Schubert]

The problem you describe seems, that each time your error handler is called it's front panel is made the top level window, hence you cannot click on anything of your other windows.

I think the following should fix this issue:

* Go to vi properties -> Windows appearance.

* Customize

* Use  'Show front panel when loaded' instead of 'Show front panel when called'

Another option would be to use a Subpanel on your Main window to insert the error handler into the SP (and do not show the front panel of the error handler). This would allow to have the error messages in a prominent place so it won't be hidden behind other windows. You can also set the window to floating (but not modal) to have it visible all the time. You coud even switch the floating behaviour off/on depending if you have an error to display.

Felix