Out of order events is not a bug, sort of

[Aristos Queue]

Yair posted an example where events were fired A then B but the event structure was handling them B then A, which contradicts the stated behavior of the event structure that it handles events in the order they occur.

QUOTE (Yair @ Apr 27 2009, 02:37 PM)

That's the way it should be, definitely. Here's a VI showing an example where they aren't always (which is almost definitely a bug). I'm guessing that this is an issue which has to do with how the event structure handles a timeout when it has user events registered.Download File:post-5877-1240863213.vi

If you look at the block diagram, you'll see this:

You'd expect that the user event would be handled before the control value change event. I followed up on this. It is "regrettable but correct behavior." In other words, not intended behavior but a logical result from the rules of the system, so not really a bug.

When events fire, they are placed in a queue. They record a timestamp of the time they occurred. The timestamp has millisecond resolution.

There are separate event queues for dynamically registered events and statically registered events. In Yair's demo, the user event is registered dynamically and the value change is registered statically, so there are two queues. The event handler looks at each of its queues and takes the earliest timestamp. In this case, the timestamps are identical and the statically registered event wins.

Workarounds:

1. Dynamically register for both the user event and the value change event. [This is the preferred workaround.]

2. Add a millisecond delay after the firing of the user event before firing the value change event to guarantee different timestamps. [This is a hack.]

[Yair]

I can't say I understand this. As far as I'm concerned, this is a bug and the correct rule should be: "Events are ALWAYS handled in the order in which they are fired".

I'll concede that it's a bug of relatively low importance (most of the time), but it could be a serious issue for some people.

Based on the desciption you supplied, I would guess that NI could implement this by having each event go to a shared source when it occurs to get an incrementing counter which will determine its order. That won't solve the bug entirely, but if the counter is a 32 bit counter, I think you'd be relatively safe.

I can't say whether the bug is worth fixing, but I definitely feel it's a bug.

I think this approach highlights nicely the issue we were discussing a few days ago:

QUOTE (Aristos Queue @ Apr 27 2009, 11:19 PM)

...but a logical result from the rules of the system

This only applies if you know the rules of the system (and assuming the rules are correct). If you don't tell the users something officially, you can't expect them to know it.

[Gabi1]

QUOTE (Aristos Queue @ Apr 27 2009, 10:19 PM)

When events fire, they are placed in a queue. They record a timestamp of the time they occurred. The timestamp has millisecond resolution.

There are separate event queues for dynamically registered events and statically registered events. In Yair's demo, the user event is registered dynamically and the value change is registered statically, so there are two queues. The event handler looks at each of its queues and takes the earliest timestamp. In this case, the timestamps are identical and the statically registered event wins.

So effectively this is a race condition between events.

Why are static vs dynamic handled in different queues? just curiosity.

[Yair]

I haven't tested this, but according to what I heard Craig say in the video of Jack's presentation on events, this should no longer happen in LV 2013. I guess as part of the work done on events this was changed as well (for AQ's sake I'm avoiding the term "fixed").

[hooovahh]

I just tested the VI attached by AQ in the first post in LabVIEW 2013.  I clicked Trigger about 20 times, and every time the user event was handled first, and the array showed 0, 1, 2.  It does look like this is fixed.

 

I do wonder however, what other event based bugs will be seen now that 2013 had this major overhaul.  I don't believe there must be new bugs, but it looks like there was quite a few changes, and I'm sure a lot of testing went into it, but when upgrading legacy programs I wonder what unexpected results may occur.

[drjdpowell]

How did they fix this?  Given that the dynamic registration queues are independent of the static queues, how can events be ordered, other than by a timestamp of some kind?

[hooovahh]

How did they fix this?  Given that the dynamic registration queues are independent of the static queues, how can events be ordered, other than by a timestamp of some kind?

Maybe that's it, maybe they used the High Resolution Relative Seconds to get a more accurate time?  Most likely this is not the fix because I think the high resolution time is Windows only which is why it isn't on the palette yet (just speculation).

[Darren]

Maybe that's it, maybe they used the High Resolution Relative Seconds to get a more accurate time?  Most likely this is not the fix because I think the high resolution time is Windows only which is why it isn't on the palette yet (just speculation).

 

High Resolution Relative Seconds.vi works on all desktop platforms, and it also works in RT.

[Yair]

how can events be ordered, other than by a timestamp of some kind?

 

Use a simple shared counter which every event must go through?

[hooovahh]

High Resolution Relative Seconds.vi works on all desktop platforms, and it also works in RT.

It is? Well then there should be no reason to not put it on the palette right 

[Val Brown]

Yes a good example of the difference between a feature and a bug.

 

Feature: Something the program does

Bug: A feature someone doesn't like

 

There may well be a central pipeline feature now that is implemented as a front end to all queuing operations.  This could give a central timing function for all internal dispatching done by LV. This is a legacy solution I've seen in other environments a long time ago, in galaxy far, far away....

[Michael Aivaliotis]

I suggest you all start using the new Event Inspector Window. On the left-most column you'll see a sequence#. This is a globally unique number that each event has and is used to order the events. This is a new (behind the scenes) feature of LabVIEW 2013 that guarantees that events now will always be handled in the order they are fired.

[Val Brown]

I suggest you all start using the new Event Inspector Window. On the left-most column you'll see a sequence#. This is a globally unique number that each event has and is used to order the events. This is a new (behind the scenes) feature of LabVIEW 2013 that guarantees that events now will always be handled in the order they are fired.

 

RIght, probably some form of 

"upfront" pipeline to set the appropriately numbered flag...