Register for events causes freezes if used in more than one event structure

[tst]

If you register for dynamic events and use the refnum from the register node as an input for more than one event structure, some of the event structures will sometimes freeze and only unfreeze when the timeout event executes.

For a simple example, see the attached VI. Clicking the OK button fires a dynamic event from the bottom loop. The top loop responds to the event and fires another event (a signaling event in this case) which is registered in the bottom loop. However, at least some of the time, the bottom event structure stops responding and only continues after executing its timeout case (this seems to depend on the version of LV).

To see it in this example click the OK button several times in a row. The i counter should increment by 2 each time, but after a few clicks, the FP stops responding until the timeout event executes. Disconnect the dynamic event reference from the bottom loop and all should return to normal. 

In the case of the original program where I had this problem, my workaround was to seperate the event registration into two nodes - one for each loop, and it seems to me that this should always work.

I believe this is reproducible in any version of LV since 7.0, where dynamic events were introduced.

[AdnanZ]

Hi tst,

I hope you are doing well today! This was reported to R&D (# 47QFCPGF) for further investigation. Thanks for the feedback!

[Craig_S.]

This is expected behavior, not a bug.  Please read the "Caveats and Recommendations" section in the manual on dynamic events.
In particular, I quote:

Make Sure You Have a Register For Events Function for Each Event Structure

If you wire the event registration refnum to more than one Event structure, each Event structure handles dynamic events out of the same event queue. This can occur if you branch the event reg refnum out output of a Register For Events function to another Event structure. This causes a race condition, because the first Event structure to handle the event can prevent the other Event structure from receiving the event if it completes the event case before the other Event structure executes.

To avoid this problem, make sure you wire each Event structure which handles dynamic events to a unique Register For Events function.

[Ben]

---

Craig wrote;

"...If you wire the event registration refnum to more than one Event structure, each Event structure handles dynamic events out of the same event queue."

---

So the wire is a queue..... and the event structures are read from queues.... that are mutually exclusive with the other events....?

Ben

Message Edited by Ben on 04-25-2007 06:37 PM

[tst]

This behavior strikes me as counter-intuitive. If I register a value change event for the same control in two event structures, each structure will have its own queue.
It is not unreasonable to expect that this would be the same for dynamic events.

In any case, in my example, note that the bottom loop doesn't actually use the dynamic event, so I don't see why it gets stuck and waits for the timeout event.
That does strikes me as a bug.

[tst]

Craig, I'm still waiting for an answer on this one.

Basically, there are two questions here.

First, as a tangent to the original question brought on by what you quoted, why is the event structure only removing the event from the event queue after the event case completes and not when the event case starts? This seems to be a source for confusion because multiple event structures might or might not respond to the same event. Is this because of filter events?
A more intuitive implementation for the users would probably be if each event structure which had the dynamic event terminal input wired would create a queue for each selected event and the register\unregister nodes would simply trigger whether or not each of the queues accepts these events. That way, each event structure would have its own queue. I can understand how that would be a problem, though.

Second, and more important, do you still think that the issue I described is not a bug? It is true that the registration refnum in the example is branched, but the bottom loop does not actually use it for anything, so why does it get stuck?

In any case, if this is the case, it would probably be useful if there was an option in the LV editor to lock such wires so that they could not be branched. I assume this option doesn't exist, because it's anti-dataflow and because I know of no other wire which can not be branched, but since you say branching them is always bad, then they should not be "branchable" at all.

[Jim_Kring]

Here's my take on the model...

A user event is an event producer (publishes to a subscription) -- it is similar to an enqueue.
An event registration is a subscription -- it is a queue.
An event structure is a subscriber (reads the subscription) -- it is similar to a dequeue.

Each subscriber needs its own subscription -- for example, if someone (a bad neighbor) takes your newspaper from your porch before you wake up, then you won't get one.  When you fork an Event Registration (subscription) wire and wire it up to two event structures (readers), then one event structure (the bad neighbor) will be stealing events from the other (the actual subscriber).

Event Structures that are subscribed to front panel control events have an implicit Event Registration (subscription) for that event.

[Jim_Kring]

---

@tst wrote:

Second, and more important, do you still think that the issue I described is not a bug? It is true that the registration refnum in the example is branched, but the bottom loop does not actually use it for anything, so why does it get stuck?

---

When an event structure executes, it flushes all events in the registration (subscription queue) that are not handled by the event structure.  This is necessary, in order to avoid a memory leak where the subscription queue grows because there is no event structure dequeing the events, especially since there is no way to explicitly manage the subscription queue.

[tst]

---

@Jim Kring wrote:

For example, if someone (a bad neighbor) takes your newspaper from your porch before you wake up, then you won't get one.

---

Except that dynamic events seem to be miraculous quantum creatures - sometimes, both you and your bad neighbor can have the paper at the same time. You can both grab your heads at the same time when you see that your stock crashed or you can both laugh at the same comic strip.

If dynamic events behaved exactly like queues, it would become evident that you made a mistake much earlier. I guess that the documentation needs to be more explicit about this.

In any case, I still think the behavior I pointed to is a bug, since the bad neighbor in this case only comes to your porch in the morning, but never actually touches your newspaper.

[tst]

I went back to my example now and I noticed (duh) that the event structure doesn't actually get stuck, but only the UI. Canceling the UI lock in the bottom loop stops this as well. I was sure I checked for that.

In any case, I still don't understand why this happens. It's as if the event case in the bottom loop doesn't release the lock it has on the UI until the timeout event executes.

---

Jim wrote:

When an event structure executes, it flushes all events in the registration (subscription queue) that are not handled by the event structure. 

---

That would make sense when you think about it, but is this documented anywhere?

I don't see how that would explain the behavior I described, though.