topic Re: Queued Message Handler Template - User Event Registration in LabVIEW

Queued Message Handler Template - User Event Registration

John_Neutron — Tue, 09 Aug 2016 14:25:42 GMT

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.

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

Re: Queued Message Handler Template - User Event Registration

Bob_Schor — Tue, 09 Aug 2016 14:48:06 GMT

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

Re: Queued Message Handler Template - User Event Registration

Intaris — Tue, 09 Aug 2016 15:29:56 GMT

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.

Re: Queued Message Handler Template - User Event Registration

John_Neutron — Tue, 09 Aug 2016 16:02:20 GMT

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

Re: Queued Message Handler Template - User Event Registration

Gregory — Tue, 09 Aug 2016 16:11:28 GMT

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.

Re: Queued Message Handler Template - User Event Registration

crossrulz — Tue, 09 Aug 2016 16:23:45 GMT

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

Re: Queued Message Handler Template - User Event Registration

drjdpowell — Mon, 05 Sep 2016 20:35:45 GMT

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

Re: Queued Message Handler Template - User Event Registration

Bob_Schor — Mon, 05 Sep 2016 21:09:33 GMT

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

Re: Queued Message Handler Template - User Event Registration

Kevin_Price — Tue, 06 Sep 2016 16:33:05 GMT

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

Re: Queued Message Handler Template - User Event Registration

Darren — Tue, 06 Sep 2016 19:46:39 GMT

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?

Re: Queued Message Handler Template - User Event Registration

Jacobson-ni — Tue, 06 Sep 2016 23:54:54 GMT

I like it. If I understand user events correctly I would agree with Kevin to keep the creation and registration separate as well.

My understanding is that if you want to add another event handling loop somewhere later in this application which is also looking for this global stop user event, you would have to register for the user event separately before that event structure instead of using the same registration refnum. I think the example as-is would do a better job at showing how there should be a unique Register for Events function for each event handler. Probably doesn't matter either way but those are my thoughts.

Re: Queued Message Handler Template - User Event Registration

crossrulz — Wed, 07 Sep 2016 01:55:58 GMT

What I typically do is have a library for the event with an Action Engine to keep the reference for the User Event. I then have public methods for registering for the event and sending the different commands (only 1 in this case), and another one for destroying the User Event. Then anybody can send the message and it (almost) forces a different registration for each module you have.

But for the sake of the example, I would say Darren's fix would be the best solution. I would rather not complicate an example with libraries, etc. Now for project templates, that is a slightly different story.

Re: Queued Message Handler Template - User Event Registration

Darren — Wed, 07 Sep 2016 02:48:30 GMT

This is the QMH project template. But I doubt I'll get easy buy-in on an expansive change like what you describe, which is why I'm hoping the Merge Errors fix is a good compromise.

Re: Queued Message Handler Template - User Event Registration

Darren — Wed, 07 Sep 2016 15:58:24 GMT

I have filed CAR 603854 to add the Merge Errors to the QMH Main VI in a future LabVIEW release.

Re: Queued Message Handler Template - User Event Registration

mcduff — Wed, 07 Sep 2016 17:26:13 GMT

I typically use User Events in multiple loops and subVIs. To make sure those VIs are active and listening I use a modified version of something Hoovah created. In the example I am waiting for 3 loops to become active, a UI, Instrument, and Data loop. The vi will run until it timeouts or the active event loops are found. See snippet and subVI. Link to Hoovahs orginal version in VI.

Cheers,

mcduff

Re: Queued Message Handler Template - User Event Registration

ChrisStrykesAgain — Fri, 26 May 2017 13:13:52 GMT

CAR 603854 was fixed in LabVIEW 2017. See the 2017 LabVIEW Bug Fix List for details: http://www.ni.com/product-documentation/53584/en/

Re: Queued Message Handler Template - User Event Registration

labmaster — Thu, 19 Mar 2020 09:27:24 GMT

As the beginner of user event, I have a question on the design pattern.

I focused on the Exit logic in Queued Message Handler design pattern of Labview (2018).
When exiting the program, the exit event was sent by using user event from the below loop to event loop, and then received again in the below loop .

Is there some special reason or advantage for that?

I am studying the user event but I cannot imagine when I can use the technique in my level.

labmaster.

Re: Queued Message Handler Template - User Event Registration

Yamaeda — Thu, 19 Mar 2020 12:38:58 GMT

@crossrulz wrote:

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

Though some versions ago (i think it works better now), changing the registered events broke the indicator forcing you to recreate stuff. This could be quite annoying if you passed it through some VIs.

I think it works a lot better since ... 2015(?)

Re: Queued Message Handler Template - User Event Registration

Yamaeda — Thu, 19 Mar 2020 12:45:30 GMT

@labmaster wrote:

I focused on the Exit logic in Queued Message Handler design pattern of Labview (2018).
When exiting the program, the exit event was sent by using user event from the below loop to event loop, and then received again in the below loop .

I'd assume it's a fail safe/double whammy. Regardless if the command initiates in the event or queue part, it sends to the other to make sure it stops. This is probably in case something else than the intended commands stop the loops.

Re: Queued Message Handler Template - User Event Registration

billko — Thu, 19 Mar 2020 17:34:15 GMT

I guess if you have multiple ways to stop the application and they all use the same user event, the application will stop "the same way" all the time.