Event Structure vs. Variant Queues

[jfazekas]

I attended a Labview class this week and learned how to use the Dynamic Dispatch events to accomplish communications between parallel loops (threads). This was extremely exciting to me since the event structure queues up events and can pass dispatch data of any data type. The sexiest thing about this technology is the ability to setup multiple event structures to receive the same dynamically generated user event. (Great for shutdown, error, and debug entry notifications.)

Historically I have accomplished most of this functionality using regular Queues that pass variants which are then cast to the appropriate data type.

For the most part, I think it works like a champ. I made a quick test VI to compare performance of the event structure approach to the Queue approach.

Observations:

1. For small data types (in units of bytes) the event structure is at least five times slower than the Queue mechanism.

2. My observations were not altered by using data types of increased complexity (structures of arrays of structures).

3. As the data types became more bulky (in units of bytes) the event structure became far slower than the Queue mechanism.

4. I am suspicious that there is an issue with sending a single event to multiple event structures. The last test case in my example locks up the program when an event is dropped.

Speed is a relative term, I know. But in the best case I could only pass a simple data type 1000 times a second.

Here I attach the test VI for your comments / improvements.

[Dirk J.]

QUOTE(jfazekas @ Jan 26 2008, 03:20 AM)

The sexiest thing about this technology is the ability to setup multiple event structures to receive the same dynamically generated user event. (Great for shutdown, error, and debug entry notifications.)

I'm not sure I understand. I allways thougth that if you send an event to multiple event structures, it gets handled by whichever one receives it first (?)

[mross]

I don't get the point of more than one user event.

Whatever the event may be I already can test the currrent conditions and fire any number of different tasks based on the the event and conditions.

I looked at the vi and without some problem to solve it just looks like much ado about nothing. I am open to education here. Presumably, new functionality was devised that is useful, but I don't get it. I think I need a practical example.

Mike

[Ton Plomp]

QUOTE(Dirk J. @ Jan 26 2008, 05:20 AM)

I'm not sure I understand. I allways thougth that if you send an event to multiple event structures, it gets handled by whichever one receives it first (?)

Hi Dirk,

a user event constist basically of two parts:

1. The user event itself, which functions just like a normal event (window close, key down etc.)
   
2. The user event registration, which subscribes an event structure to that event.
   

It is possible, just like a normal (dynamic) event, to have multiple event structures subscribe to the same user event, so they all get notified of the event.

I have to look at the code of jzafekas because it sounds interesting.

EDIT:

jazefekas, your case 'Event check, missed any?' is wrong every event structer should have a http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=247057#M247057' target="_blank">seperate dynamic event registration refnum.

Ton

So little time :thumbdown:

Ton

[Dirk J.]

QUOTE

It is possible, just like a normal (dynamic) event, to have multiple event structures subscribe to the same user event, so they all get notified of the event.

Ah, that sort-of makes sense...

But the two-event-case situation only seems usefull to me if you could modify the event handling for each event structure separately.

Now, if you unregister an event in a certain ev.struct. it gets unregistered in all of them.

[Justin Goeres]

QUOTE(tcplomp @ Jan 26 2008, 01:26 AM)

every event structer should have a seperate dynamic event registration refnum.

Here's a graphical illustration of that:

[silmaril]

QUOTE(jfazekas @ Jan 26 2008, 03:20 AM)

1. For small data types (in units of bytes) the event structure is at least five times slower than the Queue mechanism.

2. My observations were not altered by using data types of increased complexity (structures of arrays of structures).

3. As the data types became more bulky (in units of bytes) the event structure became far slower than the Queue mechanism.

4. I am suspicious that there is an issue with sending a single event to multiple event structures. The last test case in my example locks up the program when an event is dropped.

Maybe the problem is due to something else.

It seems to me that queues can be handled in any execution system, but events are always handled in the UI thred. Even for firing a user event, LV has to switch to the UI thread.

I had an application that used user events and several parallel loops, which worked fine on my hyperthreading PC.

It didn't work properly on the customer's PC without hyperthreading, until I replaced the user events with queues.

So I think it's fine to use UI events and maybe user events for UI puposes, but for general communication purposes I'll stick to queues and notifiers.

[Ton Plomp]

QUOTE(Justin Goeres @ Jan 26 2008, 06:47 PM)

Here's a graphical illustration of that:

http://lavag.org/old_files/monthly_01_2008/post-2992-1201369706.png' target="_blank">

Mmmm,

is that new, the returning of the 'user event ref'? I never noticed it. :thumbup:

Ton

[PeterB]

QUOTE(silmaril @ Jan 28 2008, 03:42 AM)

Maybe the problem is due to something else.

It seems to me that queues can be handled in any execution system, but events are always handled in the UI thred. Even for firing a user event, LV has to switch to the UI thread.

Sorry to say , but Stephen Mercer seems to think otherwise ! Refer to http://forums.lavag.org/Event-Structure-as-State-Machine-t9502.html&st=15#' target="_blank">this post.

regards

Peter

[Aristos Queue]

QUOTE(tcplomp @ Jan 26 2008, 02:26 AM)

every event structer should have a http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=247057#M247057' target="_blank">seperate dynamic event registration refnum.

I'm a bit surprised to see any discussion of "multiple event structures on the same diagram." Why am I a bit surprised to see this? Well... Anyone using the Event Structure should at some point search the LabVIEW Online Help for this topic:

Caveats and Recommendations when Using Events in LabVIEW

This page has some important advice, among them:

• Avoid placing two Event structures in one loop.
  

You can find the topic and read details about why. Just something I thought should be part of this thread...

[crelf]

QUOTE(Aristos Queue @ Jan 27 2008, 08:49 PM)

Caveats and Recommendations when Using Events in LabVIEW

This page has some important advice, among them:

• Avoid placing two Event structures in one loop.
  

Just to get back on topic a little: the technique Jonathan's talking about doesn't need to have two event structures on one diagram - they can be separated into different VIs. That means you can have a single to single, single to many, many to single or many to many paradigm.

[Rolf Kalbermatter]

QUOTE(PeterB @ Jan 27 2008, 06:34 PM)

Sorry to say Silmaril, but Stephen Mercer seems to think otherwise ! User Events don't require a context switch to the UI thread.

Refer to http://forums.lavag.org/Event-Structure-as-State-Machine-t9502.html&view=findpost&p=38468' target="_blank">this post.

regards

Peter

But they execute in a structure that also handles all the normal UI events that WILL switch to the UI thread for sure. And also might contain a timeout case that will also snoop some time for handling.

ONe extra point. Queues are very specifically optimized to NOT copy data at all but instead use the reference to the data instead. User events might not be able to use the same optimization in all cases or even at all, especially if you use multiple event structures to receive the same event.

Rolf Kalbermatter

[PeterB]

QUOTE(rolfk @ Jan 28 2008, 07:48 PM)

But they execute in a structure that also handles all the normal UI events that WILL switch to the UI thread for sure....

Rolf Kalbermatter

Does this mean that if a User Event is fired there could be times when it won't be serviced "as fast" as the enqueue/dequeue method ? If so, is that because the Event Structure may have previously switched to the UI thread before switching back to another (non UI) thread in order to service the User Event ?

Peter

[Rolf Kalbermatter]

QUOTE(PeterB @ Jan 28 2008, 05:43 AM)

Does this mean that if a User Event is fired there could be times when it won't be serviced "as fast" as the enqueue/dequeue method ? If so, is that because the Event Structure may have previously switched to the UI thread before switching back to another (non UI) thread in order to service the User Event ?

Peter

It means that the event structure might be serving an UI event at the moment the user event arrives and hence not be able to react immediately. A Read Queue waiting for an event to arrive will return instantly or at least as fast as possible, considering the contstraints of available CPU power and load only.

Rolf Kalbemratter

[Justin Goeres]

QUOTE(Aristos Queue @ Jan 27 2008, 06:49 PM)

I'm a bit surprised to see any discussion of "multiple event structures on the same diagram."

QUOTE(crelf @ Jan 27 2008, 06:57 PM)

the technique Jonathan's talking about doesn't need to have two event structures on one diagram - they can be separated into different VIs. That means you can have a single to single, single to many, many to single or many to many paradigm.

Just for the record, I would never write a VI that looks like the snippet I posted. I use it the way crelf pointed out: to register multiple event structures in multiple VIs for the same event. It's just easier to make the point on a single diagram .

[crelf]

QUOTE(Justin Goeres @ Jan 28 2008, 08:39 AM)

Just for the record, I would never write a VI that looks like the snippet I posted.

Suuuuuuuuure...

[Justin Goeres]

QUOTE(crelf @ Jan 28 2008, 07:19 AM)

Suuuuuuuuure...

OK, OK... never again.

[silmaril]

QUOTE(PeterB @ Jan 28 2008, 12:34 AM)

Sorry to say Silmaril, but Stephen Mercer seems to think otherwise ! User Events don't require a context switch to the UI thread.

Refer to this post.

That's interesting, very interesting...

If user events don't force a thread switch, I have absolutely no idea, why my application wasn't able to run properly on a single core CPU. I cannot explain, why changing my user events to queues solved the problem.

QUOTE(rolfk @ Jan 28 2008, 10:48 AM)

But they execute in a structure that also handles all the normal UI events that WILL switch to the UI thread for sure. And also might contain a timeout case that will also snoop some time for handling.

In my case, I had the impression, that the loop that fired the events was delayed. A delay in the UI part of the application wouldn't habe posed any problem.

QUOTE(rolfk @ Jan 28 2008, 10:48 AM)

ONe extra point. Queues are very specifically optimized to NOT copy data at all but instead use the reference to the data instead. User events might not be able to use the same optimization in all cases or even at all, especially if you use multiple event structures to receive the same event.

I transported only a few bytes for every event, so I don't think this really is an issue.

But I don't want to hijack this thread. We could discuss this topic much more easily with an example that shows the behaviour isolated, but I don't think I'll be able to reproduce it easily.

[jfazekas]

This is the conclusion I wanted to verify.

QUOTE(silmaril @ Jan 27 2008, 12:42 PM)

So I think it's fine to use UI events and maybe user events for UI puposes, but for general communication purposes I'll stick to queues and notifiers.

I was hoping to use the event structure for general communication purposes since it would permit 'waiting' for multiple queues simultaneously. LV has a wait on multiple notifiers (if they are of the same data type) but no such function exists for queues -- especially of different data types.

I'll stick to queues and notifiers until LV offers software interrupts that are not built on the UI thread.

[crelf]

QUOTE(jfazekas @ Jan 28 2008, 02:21 PM)

I'll stick to queues and notifiers until LV offers software interrupts that are not built on the UI thread.

...but, http://forums.lavag.org/Event-Structure-as-State-Machine-t9502.html&st=15&p=38468#entry38468' target="_blank">as has been pointed out, the user events aren't.

[jfazekas]

QUOTE(crelf @ Jan 28 2008, 02:49 PM)

...but, http://forums.lavag.org/Event-Structure-as-State-Machine-t9502.html&st=15&p=38468#entry38468' target="_blank">as has been pointed out, the user events aren't.

yes, I see that now. Thanks.

[PeterB]

QUOTE(rolfk @ Jan 28 2008, 08:53 PM)

It means that the event structure might be serving an UI event at the moment the user event arrives and hence not be able to react immediately. A Read Queue waiting for an event to arrive will return instantly or at least as fast as possible, considering the contstraints of available CPU power and load only. Rolf Kalbemratter

Thanks for clarifying Rolf. One solution I thought of is to have another event structure on the BD that is entirely dedicated to User Events. Not as elegant, but that should solve any delay problems if one chose to use User Events rather than queues.

Peter

[Aristos Queue]

QUOTE(PeterB @ Jan 28 2008, 04:43 AM)

Does this mean that if a User Event is fired there could be times when it won't be serviced "as fast" as the enqueue/dequeue method ? If so, is that because the Event Structure may have previously switched to the UI thread before switching back to another (non UI) thread in order to service the User Event ?

Essentially, yes. Events are *always* fully handled in the order they occur. So if you have two separate event structures registered for separate events, and both events occur, the first to occur will finish its event case before the next one begins being handled, even if these are separate event structures. This is important in case the event structures are accessing common queues, global storage, hardware or other refnum type. If multiple event structures are handling the same event, then all of them must finish handling the event before the next one begins being handled.

[JDave]

QUOTE(jfazekas @ Jan 28 2008, 11:21 AM)

I was hoping to use the event structure for general communication purposes since it would permit 'waiting' for multiple queues simultaneously. LV has a wait on multiple notifiers (if they are of the same data type) but no such function exists for queues -- especially of different data types.

I'll stick to queues and notifiers until LV offers software interrupts that are not built on the UI thread.

I have had success with using User Events for this 'broadcast' type communication. However, the events are tied to user interaction. Like a "QUIT" event when the application shuts down or a "RUN" event when the main run button gets pressed. In this situation it seems that there is no speed concern. If the events were produced more regularly, without need of user interaction, then I can see how it could cause you some problems.

[crelf]

QUOTE(Aristos Queue @ Jan 29 2008, 12:33 PM)

...if you have two separate event structures registered for separate events, and both events occur, the first to occur will finish its event case before the next one begins being handled, even if these are separate event structures.

That's the important point right there (emphasis added for emphasis) - and something I didn't know. Is this true, even when the event structures are on different targets?