Understanding VI Preferred execution system

[sparkymark567]

The LabVIEW scheduler has 6 execution systems: user interface, standard, instrument i/o, data acquisition, other 1 and other 2.

For each level of VI priority within an execution system, there should be 4 threads per CPU.

cRIO-9068 has 2 CPU cores, so I expect each execution system to have 8 threads at each priority level.

I created a reentrant sub VI  that contains a 100ms wait.

Sub VI Reentrancy is set to 'Preallocate clone reentrant execution', Priority is set to 'normal' and the Preferred Execution System is set to 'other 1'

When I run the sub VI inside a parallel for loop (P=8 and N=8), i notice that only 4 instances of the Sub VI run in parallel.

Why does LabVIEW not run all 8 instances in parallel? because there should be 4 threads for each CPU, therefore 8 threads in total?

In my next test, I placed 10 instances of the sub VI, one below the other, into my main VI.

When I run the main VI, I notice that LabVIEW runs all 10 instances of the Sub VI in parallel.
How does LabVIEW run all 10 instances in parallel, when the preferred execution system should have only 8 threads?
I would expect the first 8 instances to run in parallel and then the remaining 2 instances to run afterwards.

Also, is there any way to determine which execution system a VI is/was run in? as without this, I'm just guessing.

[santo_13]

Are you sure that the CPU has 4 threads per core?

Typically all Intel/AMD CPUs support only 2 threads per core

[drjdpowell]

You are actually better off ignoring that "execution system" stuff, except for special cases. 

Also, note that the various "wait" actions in LabVIEW do not block a thread.  They actually schedule something to happen, and the thread is free to do other stuff while the SubVI is waiting.  A single thread can have many subVIs waiting at the same time.

Re the parallel for loop, did you set the number of instances to 8 (in the configuration window), or just set the P input to 8?  I think 4 is the default number of compiled instances; setting a higher P does nothing.

[sparkymark567]

The term 'thread' is used differently by different people, please see here:

https://www.ni.com/docs/en-US/bundle/labview-2020-real-time-module/page/lvrtbestpractices/rt_priorit... 

It seems that each execution system runs as a thread on a pre-emptive RTOS. Then each execution system has it's own co-operative scheduler, to manage the execution of (sub) threads, that reside in priority segregated thread pools.

In my real application, some of my application threads share resources, e.g. DMA channel, so i would like these to run co-cooperatively within a single execution context. I think this will improve performance by reducing resource blocking, that could occur with preemptive context switching.

[sparkymark567]

@drjdpowell

You are correct, i did not configure the number of parallel instances on the for loop, so that likely explains the difference in behavior. I do not normally use parallel for loops and I was unaware of the setting. I will continue in the morning (UK time).