Jump to content
Aristos Queue

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
how can events be ordered, other than by a timestamp of some kind?

 

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

  • Like 1

Share this post


Link to post
Share on other sites
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  :D

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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:

Share this post


Link to post
Share on other sites

Join the conversation

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

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