When speaking of multithreading in LabVIEW, one must not confuse two things. First, there are the "real" threads of LabVIEW system within the operating system. Second, each VI (and all VIs) run "multithreaded" (in parallel) due to the LabVIEW internal scheduler. Thanks to the scheduler, the application behaves as being multithreaded although only one (or a few) real threads in the operating system are used. The following just concerns the "real" multithreading.
- When using event mechanisms of LabVIEW, you can not send events from one execution system (thread) to another execution system (thread). So one must have really good arguments for not running all VIs in one execution system (thread). By default, most VIs run in the default execution system. Note, that the front panels of VIs run in their own thread.
- Do not change the execution system via VI properties -> Execution -> Preferred Execution System, except you have really fundamental reasons for doing so.
- Changing the priorities of a VI via VI properties -> Execution -> Priority will only have a significant effect on LabVIEW RT systems. On Windows OS, changed priorities will have almost no effect.
- In LabVIEW 6.1 and earlier, the default number of threads per execution system was one. In LabVIEW 7.0 and newer versions, the default number of threads per execution system is four. There are reports, that this leads to misbehavior of the event mechanisms (Queues, Notifiers, ...) in LabVIEW. So it might be good to change the number of threads or turn multithreading off (see below).
The recommendation for CS
based systems is either not to change the multithreading settings of LabVIEW, or to switch the multithreading off (see below).
How and why to change the real number of threads
(I copied this from the Website of National Instruments)
Is there a limit to the number of threads I can allocate in LabVIEW?
Yes. Threads use system resources, so the system configuration limits the ultimate number of threads that can be created. Users may set the number of threads LabVIEW uses in a particular execution system by running threadconfig.vi. This VI can be found in ...\LabVIEW\vi.lib\utility\sysinfo.llb\threadconfig.vi . In general, the upper limit is in the hundreds of threads, but the overall performance of the computer is likely to suffer as the number of threads increases due to thread swapping overhead.
How and why to turn multithreading off
(I copied this from the web site of National Instruments)
Why would I want to turn off multithreading?
There are two reasons you would want to turn off multithreading: if you use an older computer or if your VIs inexplicably crash. Multithreading can cause LabVIEW to run slower on older computers due to their limited resources. In these cases, turning multithreading off improves the performance of LabVIEW and the performance of other running applications.
Today multithreading is turned off largely for debugging VIs that crash for no reason. VIs that use ActiveX features or dlls that are incorrectly identified as threadsafe can crash because the ActiveX features or the dll corrupted the computer's memory. If turning off multithreading makes the VI stable, then your focus can be placed on these parts of the code. If you have access to the source code, you can make the corrections yourself. If the dll or ActiveX components are from a third party, then the dlls can be set to run in the user interface thread, but the ActiveX components may require that LabVIEW not be restored to multithreading mode.
You can turn off multithreading by opening LabVIEW -> Tools -> Options -> Performance and Disk -> Run with multiple threads. You will have to reboot your computer in order for the changes to take effect.
Some background information is given in the Application Note 114 from National Instruments "Using LabVIEW to Create Multithreaded VIs for Maximum Performance and Reliability" by Norma Dorst.
- 06 Jul 2005