Solution
Refer to
LabVIEW Help: Suggestions for Using Execution Systems and Priorities for more information about execution priorities and multithreaded systems.
LabVIEW can run multiple VIs or sub diagrams in parallel. VIs can be assigned one of five priorities: background (lowest), normal, above normal, high and time critical (highest). There exists a sixth priority, or subroutine, that forces a VI to run until completion without sharing its execution system thread with other VIs. Each execution system has a queue made up of sections of code from the VIs in the system. The queue is ordered by priority such that higher priority VIs run before lower priority VIs. As long as high priority items are on the queue, lower priority items cannot work their way to the head of the queue and therefore cannot run. This means that starvation of low priority VIs is possible if higher priority VIs run continuously without pausing for a time-out or other asynchronous activity. Because of this, take care when elevating the priority of a VI.
The LabVIEW execution queue has entry points for each of the five priorities. There is no entry point for subroutine priority. A subroutine priority VI begins running when called from a VI, and dominates its execution system thread until it returns to the calling VI of another priority. It might call other subroutine priority VIs, but not VIs of the other priorities. Subroutine VIs do not update their indicators, cannot perform waits or other asynchronous operations, and therefore never can be put on a queue. In this sense, after they begin running, they are the highest priority VI in an execution system.
In multithreaded systems, there are several execution systems each with a run queue and one or more threads. The threads are set to run at priorities such that the operating system can preempt a low priority thread when a higher priority thread is ready to run. The VI priority is used to select which execution system queue it is best placed upon. A subroutine VI called in a multithreaded system dominates the thread in which it is called but cannot prevent other VIs in other threads from running. This means you cannot use subroutine VIs to block out all other execution of VIs on systems with other threads at equal or higher priority.
On multithreaded systems, the user interface is a thread at normal priority. On some systems, it can be starved by VIs running at higher priority which never pause for a time-out or perform other asynchronous activity. It might not be possible to change a control to stop a high priority VI which never permits the user interface to notice the control. Because of this, take care when elevating the priority of a VI.