DQMH and the UI Thread

[Darren]

I was recently asked the following question:

"Since the DQMH Main VI contains UI property and invoke nodes (like FP.Open), doesn't that mean the DQMH Main VI always runs in the UI thread?"

The answer to this question is "no". Or more accurately, "not unless you tell it to". 🙂 For the full answer below, you'll need to have a good understanding of what a clump is in LabVIEW. The tl;dr is that clumps are nodes within the intermediate representation of a LabVIEW diagram that have been grouped together, and can run in parallel assuming no dependencies. The long answer is that you should read this whitepaper. I re-read this paper at least once a year to remind myself the basics of how the LabVIEW compiler works.

Anyway, assuming you now know what a clump is, let's look at the Execution page of the VI Properties dialog:

By default, VIs are set to "same as caller", which means LabVIEW will go up the call chain to see if any VIs have a different execution system selected, and if so, that one will be used. If not, LabVIEW will execute the "clumps" of the compiled code in whatever execution system(s) make the most sense. Now, if there happens to be any UI code that needs to execute, LabVIEW will explicitly schedule those clumps to execute in the UI thread. This means that if there is a VI containing both UI clumps and non-UI clumps, there will be thread-switching while that VI executes. If you happen to have code that is very UI-intensive, with lots of control property nodes, then it might make sense to mark your VI to execute in the "user interface" execution system to avoid thread-switching, which can sometimes be resource-intensive.

Barring that exception though, LabVIEW will schedule your non-UI code to execute in a non-UI thread, regardless of whether you're using DQMH, Actor Framework, or anything else. So no, your DQMH Main VI does not always run in the UI thread. Unless you tell it to.

[joerg.hampel]

I asked Darren if and how the situation changes when there are indicators on the front panel and their terminals (or local variables) are updated while the front panel is hidden or even closed. Here's the reply:

"[..] indicator updates don't post to the UI thread. They get copied to a data buffer which is queried by the UI thread whenever it decides to draw the panel. Hidden and Closed panels never draw the panel, so indicator updates for a hidden panel never post to the UI thread. And technically they don't for a visible panel either, but the periodic drawing of the latest data buffer contents does."

[FabiolaDelaCueva]

Darren,

Thanks for another excellent post. 

I have explicitly made headless modules when I want to ensure that they never go into the UI thread.

When I create headless modules, I hide all the controls and indicators on the front panel and I put a text label that says "This is a headless module" and I remove any value property nodes that may be there. Additionally, if this is hw module or critical for the operation of the application, I may go as far as editing the properties of the DQMH Headless Main VI to run at a higher priority (like instrument I/O or data acquisition). That has come in handy when dealing with high-speed hardware. The critical module sends requests and/or broadcasts for other modules to deal with the displays/logging and those modules can do some buffering as needed.

Happy wiring, 

Fab