Race Condition inherited from NI Template

[drjdpowell]

Adding a 1 ms delay before enqueuing the "Initialize Panel" message causes multiple UI update messages to fail to show on the UI.  This is a race condition weakness inherited from the original NI template. 

[FabiolaDelaCueva]

I tried with and without the 1ms delay and I didn't see any change in behavior between the original example and the delayed version.

I was running Thermal Chamber Controller Main.vi as a stand alone VI.

Can you please make a video showing the race condition?

Regards,

Fab

[drjdpowell]

FabiolaDelaCueva wrote:

I was running Thermal Chamber Controller Main.vi as a stand alone VI.

Sorry, should have said I was running the "Thermal Chamber Controller.vi" which launches the chamber.   This fires off multiple messages (set point, ramp rate, etc.) within the first ms; these messages are handled before the "Initialize Panel" message (if there is a delay), and so can't update the UI because they can't access the control references.

[FabiolaDelaCueva]

drjdpowell wrote:

FabiolaDelaCueva wrote:

I was running Thermal Chamber Controller Main.vi as a stand alone VI.

Sorry, should have said I was running the "Thermal Chamber Controller.vi" which launches the chamber.   This fires off multiple messages (set point, ramp rate, etc.) within the first ms; these messages are handled before the "Initialize Panel" message (if there is a delay), and so can't update the UI because they can't access the control references.

We were keeping the examples as simple as possible and did not add the event registration. If there is a delay before initializing the panel, then the following modification is needed on the calling code:

[drjdpowell]

The problem with the NI template is that it lacks a way to call a "sub-action", a way of having another case of code execute as if it were an indivisible part of the current action.  Just like a subVI can call another subVI.   Instead, it is too tempting to queue up sub-actions to execute after potentially any other action, leading to race conditions. One can code around them as you find them, but it would be better to have an easy means to call a sub-action to execute immediately regardless of what else is in the Queue.   You could use "enqueue in front", as long as you don't use that for "message priority" from an external loop.  Or you can use a separate "sub-action" queue of some kind that is private to the receiving loop.   The JKI template is an example of this, and I altered the NI template similarly in the example I gave at CSLUG recently.

[FabiolaDelaCueva · Accepted solution]

We have released a new version of the DQMH Toolkit. You can read the full Release Notes here: http://delacor.com/dqmh-2-0-release-notes/

What is relevant to this post is that we followed up on what Dr. James Powell mentioned as well as feedback from others trying out the DQMH Toolkit resulting in the following items in the Release Notes:

"

Addressed possible race condition during Main.vi initialization. The module was not ready to receive requests until the Initialize Data and Initialize Panel had been enqueued and the Queue was ready to receive other requests. Internally, we would encourage developers to not send any requests until the “Module Did init” broadcast would had been received. However once others started using the template, we saw that this was not enforceable and a race condition could happen if the developers sent a request before the module was ready. Also NI QMH Project Template did combine the three initialize messages into one to address a possible race condition there as well in LabVIEW 2015. The fix to DQMH modules consisted in:

1) Moved the Synchronize Caller Events.vi out of the Init.vi and into the Initialize case in the MHL (and into the Error outer case in Main.vi) for both Singleton and Cloneable modules.

2) Combined Initialize, Initialize Data and Initialize Panel into a single Initialize case.

3) Added support code to implement wait for module to stop functionality in Stop Module.vi. This required the creation of Handle Exit.vi that is called in the Exit case in the MHL. Moved Did Stop.vi into Close.vi to be called after the module had stopped. For the cloneable module, moved all the code that keeps the first clone alive to be done inside the Close.vi.

"

This means that adding the event structure, as mentioned earlier, is no longer needed when using DQMH 2.0.