Leaderboard

There is a little trick I found out about a little while back. You can register a UserEvent with a callback VI What this means is that every time you fire a user event, a VI gets asynchronously fired. Now I thought this had a lot of potential because finally we could start a VI running asynchronously and pass it parameters w/ out needing to use crappy VI server methods. The problem is that the Fire User Event node, which up until this point, under all conditions, ran asynchronously, now is blocking, waiting for the Callback VI to complete. See this video http://screencast.com/t/MDQ0NTk1ZGMt <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/0ff19684-4f74-4d3c-97fe-059b5492f207/2010-07-24_2159.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/0ff19684-4f74-4d3c-97fe-059b5492f207/2010-07-24_2159.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/0ff19684-4f74-4d3c-97fe-059b5492f207/2010-07-24_2159.png" width="889" height="401" border="0" /></a> Well this dashed my plans for world domination, but it seems to be that this behavior is wanted in your case. Attached you will find the Main and Callback VI that demonstrates this. I'm curious to hear your thoughts on this tactic. -Norm UECallback.zip

Then let me suggest that the wrong process is creating the event refnum. ;-) This is a problem that I ran into with a listener framework I've been working on lately. Alpha.VI dynamically launches Beta.vi and then gives Beta.vi a queue refnum so Beta can receive messages from Alpha. We had to turn that around -- Alpha launches Beta and then Beta creates the queue and gives the refnum to Alpha. That way the lifetime of the queue is the same as Beta, not Alpha. In your case, it sounds like the correct behavior is for your consumer to create an event refnum and give it to the sender. That way the consumer can dispose the refnum after it handles the event and "destroy what you create" policy is preserved.

Indeed. But still realized that even if you insert a long wait, there is still no guarantee your consumer will execute. If the system is under load from another process (LabVIEW or otherwise), a few seconds still might not be enough. The behavior is by it's very nature undefinable. As LogMAN said, you can also consider adding other synchronization functionality. Passing an occurrence or rendezvous as part of the stop event works, and then the code that trips the stop event can wait for the sync object to be properly signalled before destroying the event registration. But I still believe letting the consumer handle the unregistration is the best way to do it. For the very reason your code is giving you problems, I try to always tie event unregistration with the same event structure that owns/uses the registration.

I don't think this is a bug at all. You've programmed a race condition. Even with the delay call, your code's behavior is undefined. Signaling the event (or generating/broadcasting it in LV language) obviously won't wait for the event to be processed, but it's important to also realize that it doesn't even wait for the event consumer(s) to be invoked. The event is entirely asynchronous. Broadcasting simply queues the event up for each registered consumer of the event. With no wait, your VI will (usually) just blow through the broadcast, then go ahead an unregister the event, which will destroy the event queue, in the process neutralizing the uninvoked event (along with any other events in the queue). Add in a wait as you show, and your program will sometimes yield to a context switch allowing your consumer code to invoke, but you can't be certain it always will. The code behavior is by its very nature undefined. To avoid this, you can handle event unregistration in the consumer portion of code. Once the consumer receives the event, it unregisters itself and finishes up.

Here's a VI that sometimes will show what I mean. Hit the 'Fire' event that fires a user event and a value signalling event (in that specific order) In those events I read the current iteration number of the while loop. If the events are in order the First Iteration should be smaller than SecondIteration Sometimes however that is not always the case. I cannot get a resolution like I expected (it seems like the resolution is 1 ms) so I uses a different timer than the Get Ms. Ton EventOrder.vi