LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Queued Message Handler Template - User Event Registration

Hello

 

After looking at the QMH template built into LabVIEW 2015 I have some concerns over the execution order of the lower 'message handler' loop and the point at which the Register for Events is called on the Stop User Event.

 

QMH.png

 

It appears that the lower loop would technically be capable of firing the stop event before the register for events has actually been called meaning that this 'stop' event would not be captured by the underlying event engine.

 

I am aware that this is very pedantic point given the performance of multi-core processors but I feel that it might give users of the QMH the wrong impression of how to use more advanced event-based messaging.

 

My suggested fix would be to place both loops in a shared  'Error/No Error' case structure after the register on events has happened.

 

I would be interested in hearing other's opinions or if I am mistaken then I would appreciate being told where I am going wrong.

 

Cheers

 

John

 

 

 

0 Kudos
Message 1 of 20
(8,642 Views)

The ways that the QMH gets the Exit Message, I believe, are (a) because the User pushed the Exit button, (b) did a Panel Close?, or (c) generated an Error that was set to "Exit if Error" (generating a Message to the QMH).

 

The first two are processed by the Event Loop, so normal Data Flow requires the Register for Events to have been done.  The Error situation requires processing by the QMH, including parsing at least two messages, Initialize and Exit, so only if NI's Round Robin parallel-loop time-slicing algorithm were really awful (or Register for Events took milliseconds instead of sub-microseconds) could this be an issue.  Attempting to remediate it, I suspect, would lead to really "ugly" code and could well introduce yet other subtle bugs.

 

Still, it is probably a Good Thing to have spotted this "potential" for a Race Condition.  If you are still concerned, put a 1 millisecond "Wait" between the Create User Event and Create All Message Queues.

 

Bob Schor

Message 2 of 20
(8,626 Views)

My 2c would be to put the register for events directly after the function which outputs the event itself (before any actual events can be triggered).  By introducing this data flow you are simply coding what is implied in the code, that any events triggered on that event will be registered for.

I don't think this leads to any bugs.  Add "Clear Errors" if that's a cause for concern.

Message 3 of 20
(8,613 Views)

Thank you for your input.

 

I am inclined to agree with Intaris that wiring up the register events after the Create Stop User Event vi is a pretty straight forward solution which enforces correct dataflow without excessive uglification.

 

I guess NI might review it but as Bob Schor pointed out, it will always work so why would they change it?

 

John

0 Kudos
Message 4 of 20
(8,598 Views)

I think drjdpowell has talked about race conditions with the QMH and with the (now fixed) DQMH, so it is perhaps a valid concern.

 

The problem would probably not be with the exit state, for the reasons Bob mentioned. But what if the developer calls the QMH externally followed by a new event "Init". You can argue that the "Init" code should be enqueued into the message loop when the QMH starts up, but it might have a parameter associated with it (e.g. VISA address for an instrument) so the developer thought it would be best to call the event from another VI and pass that parameter in. In this case, I think it is quite possible to generate the "Init" event before "Register for events" has occurred.

Message 5 of 20
(8,593 Views)

My solution would be to have the Event Initialization VI also output the registration.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 20
(8,587 Views)

I talked about another potential race-condition weakness of the NI-QMH template in "Design and Use of Queued Message Handlers".  

0 Kudos
Message 7 of 20
(8,422 Views)

Not only do I agree with Crossrulz (as is usually the case), it's "what I do".  I have a VI that initializes the User Events, and outputs both the User Event Queue and the User Event Refnum.  I wire the RefNum to the Event Loop Dynamic Event terminal, and wire the Event Queue to Generate User Event.

 

Bob Schor 

Message 8 of 20
(8,418 Views)

FWIW, we've adopted exactly the *opposite* habit as crossrulz and Bob_Schor, which is rarely the case.  We explicitly modified the QMH template from LV 2013 to separate event creation and event registration since our normal usage pattern for these system-wide events was to need many distinct registrations for each of the many parallel threads.

 

We've finally started toward upgrading to LV 2016, where I see that the QMH template now does the same kind of separation.  It no longer returns an event registration refnum from the code that creates the system-wide events.  Either way can work if you keep your head straight, we just found the separation helpful as a reminder that *every* event handling loop would then be responsible for its own registration / deregistration.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 20
(8,371 Views)

I agree with the spirit of this suggestion. Even though I've never seen a bug attributed to this issue, it is still possible that it could occur. What do y'all think about me fixing it with this Merge Errors approach in LabVIEW 2017?

q.png

Message 10 of 20
(8,356 Views)