Dynamically-Launched VIs and Context Switching

[TurboPhil]

I'm working on a project that dynamically calls instances of a reentrant VI, which I assume is a pretty common practice. Everything works pretty well, until the number of calls to this dynamic VI gets pretty large--on the order of 1000 or more--at which point, we begin to see performance degradation. My guess is that we are taking hits due to context switching, since the number of threads far exceeds the number of logical processor cores available.

A little more background:

The dynamic VIs being called effectively run as daemons, each running a while loop and waiting on a dedicated input queue to receive data and save it to disk. All are stopped via a globally shared stop notifier (passed as a ControlValue.Set method argument at launch). Each is waiting on its respective queue with a 1 second timeout so that the stop notifier can be polled. Under normal operating conditions, each one will run at some rate between 0.1Hz and 25Hz (the various rates are a large driving factor for separating them and needing to spawn them dynamically).

So, this leads me to the following questions:

• Am I correct that the context switching is the likely culprit in the performance degradation?
• If so, is there a fundamental difference in how LabVIEW handles multithreading with dynamic VI calls versus explicitly drawing separate while loops on a block diagram, or dropping multiple instances of a reentrant VI directly on the block diagram?
• Is it likely that reducing the number of dynamic clones to equal the number of available processor cores would improve performance? (the scope of each clone would grow, as it would have to maintain the state information that was original distributed across multiple clones)

I realize that this question is pretty vague without concrete examples, but I'm hoping someone (AQ? Ben? Any of you NI gurus?) out there could provide some general insight into what's going on under the hood without needing to get too specific.

[Ben]

If you are using call-by-ref then this thread applies.

Otherwise...

If all of the spwaned process are looking a the GUI repeatedly (prop-node etc). then the UI thread could be the issue.

Gotta run!

Ben

[TurboPhil]

Just using the standard Run VI method. LV2010SP1. Need asynchronous calls (since we need to spawn the clones and leave them running in parallel), but since we're still on 2010, we can do the async. CBRN.

And no property node calls inside the clones, although there are some shared resources (functional globals) that can get called sporadically during execution of each clone (typically only on initialization, but occasionally if there is a reconfiguration).

[tst]

---

@TurboPhil wrote:
Each is waiting on its respective queue with a 1 second timeout so that the stop notifier can be polled.

---

There is one relatively easy fix you can probably make here - set the timeout to -1 and destroy the queues to stop the loop (destroying the queue will output an error from the wait primitive). This should at least stop all the code from running all the time, although I'm still not sure how the threading of the different VIs will play with each other. This might be an issue if the queue is only created in the VI, but I'm assuming it isn't.

[Ben]

or add stop command to the Queue at let it stop the daemons.

THe other issues not mentioned is sub-VI that are shared by the Daemons... If not reentratn they could be getting a single file line waiting th execute one after the other.

Ben