Jump to content

Out of order events is not a bug, sort of


Recommended Posts

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)

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

post-5877-1240863300.png?width=400

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.]

Link to comment

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.

Link to comment

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.

Link to comment
  • 4 years later...

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").

Link to comment

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.

Link to comment
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).

Link to comment
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.

Link to comment

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....

Link to comment
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... :yes:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.