Pre-conditions for reentrant SubVIs to run in parallel

[maf3]

Hello!

In my VI I have two preallocated clones of a SubVI, which I thought would run in a seperate thread each. This SubVI simply takes a reference to a double and increments it. The two clones actually run in parallel, but not in seperate threads. For comparison I made SubVI that does not take a reference - those clones run each in an own thread.

I noticed this looking at the CPU usage: in the first case, only one core was used, in the second case two cores were used.

1) I wonder which are the pre-conditions for a SubVI to actually run not only in parallel, but actually in seperate threads?

2) Is there a way to find out during compile-time which parts (clumps) of a VI run in parallel, and which SubVIs get actually their own thread for execution?

Concerning the reference: execution is quite slow. As I understand it, the GUI runs in its own thread, thus not interfering with the SubVIs that are increasing the references. I think there is also no locking of a reference so reads and writes to a reference should be very quick. Is this correct? If yes, why is execution that slow?

Thanks for your answers

Marco

(Test computer has a Quad-Core w/ Hyperthreading, using LabVIEW 2012SP1)

[dkfire · Accepted solution]

One thing that I know of is if you have any handling of UI elements.

In you case you are using a reference to a UI element, and properbly using property node for inserting data.
This limits LabVIEW to have your sub vi's in the UI thread.

If you transfered the values over queue to a vi that handles all the UI stuff, then only that vi will be in the UI thread.

Did that make any sens?

[maf3]

Dear dkfire,

Ok, good to know - working with UI elements is limited to UI thread. I just checked parallel execution with a VI taking Data Value Reference. It worked nicely - but again I was surprised by the slow execution of just incrementing DVR (using in-place structure)..

Might there be any other pitfalls except references to UI elements?

Any possibility to check at compile-time if a SubVI will get an own thread?

[altenbach]

How exactly do you tell if they run in the same or in seperate threads?

The overhead using two property nodes per iteration is extremely high because property nodes execute synchronously.

[maf3]

I'm learning a lot of details here: Property Nodes and Invoke Nodes synchronize with the UI thread. Thus, the slow execution in the SubVI makes totally sense, since it is blocked due to the UI update.

For the number of threads used, I observed the CPU usage: as the SubVI has no wait it completely fills one core with load. As I have 8 cores, I could observe exactly 12.5% CPU usage with the 'Property-Node-SubVI' and 25% CPU usage for the 'DVR-SubVIs' running concurrently (there happens no UI-Update with the 'DVR-SubVIs'. Thus, when CPU usage is 25% there are 2 cores running with full load - which must mean that 2 threads are being used by LabVIEW.

The reason I ask is because we are planning a software, where many things are running in parallel (data acquisition, several TCP-sockets, main logic/command handler, ..) and I must be sure that the execution system won't block parts of the block diagram and that the SubVIs really run in concurrently (there may be > 4). We also think of assigning dedicated threads to critical VIs. Probably we'll have a very close look at the VI's 'priority and execution system' properties.

[altenbach]

---

@maf3 wrote:

For the number of threads used, I observed the CPU usage: as the SubVI has no wait it completely fills one core with load. As I have 8 cores, I could observe exactly 12.5% CPU usage with the 'Property-Node-SubVI' and 25% CPU usage for the 'DVR-SubVIs' running concurrently (there happens no UI-Update with the 'DVR-SubVIs'. Thus, when CPU usage is 25% there are 2 cores running with full load - which must mean that 2 threads are being used by LabVIEW.

---

LabVIEW uses many more threads than you have cores (details). You cannot conclude anything about threads using your data.

---

maf3 wrote:

The reason I ask is because we are planning a software, where many things are running in parallel (data acquisition, several TCP-sockets, main logic/command handler, ..) and I must be sure that the execution system won't block parts of the block diagram and that the SubVIs really run in concurrently (there may be > 4). We also think of assigning dedicated threads to critical VIs. Probably we'll have a very close look at the VI's 'priority and execution system' properties.

---

LabVIEW is very good at managing threads and parallel processes. Most likely you don't have to do anything special except follow good coding practices and avoid data dependencies. Also don't waste a lot of resources constantly allocating new memory, for example. How CPU intensive are your various tasks? Mist likely they complete before you even see a blip on the CPU usage taks manager graph.