Company Events Academic NI Developer Zone Support Solutions Products & Services Contact NI MyNI

LabVIEW Threading Model

LabVIEW 8.5 Help
August 2007

NI Part Number:
371361D-01

»View Product Info

All the complex tasks of thread management are transparently built into the LabVIEW execution system. Text-based programmers must learn new, complex programming practices to create a multithreaded application. However all LabVIEW applications are automatically multithreaded without any code modifications.

LabVIEW 5.0 was the first multithreaded version of LabVIEW. LabVIEW 5.0 separated the user interface thread from the execution threads. Block diagrams executed in one, or possibly more than one, thread, and front panels updated in another thread. The operating system preemptively multitasked between threads by granting processor time to the execution thread, then to the user interface thread, and so on. To make an existing pre-LabVIEW 5.0 VI multithreaded, load the VI into LabVIEW 5.0 or later. Expert users who want to have specific control over threads, such as changing thread priorities, can select File»VI Properties and select Execution.

Before LabVIEW 7.0, LabVIEW allocated only one thread for a single priority and execution system by default, which meant that all activity in all VIs in the same priority and execution system had to wait together. LabVIEW 7.0 increased the default number of threads allocated for a single priority and execution system to four, which means that if one thread executes an instruction that causes a wait, other sections of the block diagram can continue to execute.

In addition to the preemptive multitasking of the operating system, LabVIEW employs a cooperative multitasking system. During compilation, LabVIEW analyzes VIs to find groups of nodes that can execute together in what are called clumps. Each priority and execution system combination has a run queue data structure that retains which clumps can run together. When the operating system activates a thread, the operating system retrieves and executes a clump from the run queue. When the operating system finishes executing, it stores additional clumps that meet the input conditions on the run queue, which allows the block diagram to execute in any of the available four execution threads. If the block diagram includes enough parallelism, it can simultaneously execute in all four threads.

LabVIEW does not permanently assign clumps of code to a particular thread. LabVIEW can execute a clump using a different thread the next time you run the VI.


Resources


 

Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
Add Comments 1 2 3 4 5 submit