LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

User Events vs. Queues vs. Notifiers?

I have a very general question.

 

If I want to call some piece of code I can put that in an event structure and fire a user event. I can also put that code in a loop and call it using a queue or a notifier.

 

Are there any guidelines on when to use user events vs a queue or a notify?

 

More specifically is there something you couldn't do if user events did not exist in LV?

=====================
LabVIEW 2012


Message 1 of 17
(24,523 Views)

Hello,

 

event structure : if you have quick code to execute and quick enough to be imperceptible for user

 

event with notifier if you have code  that take time use it to prevent blocking event structure (waiting for code to respond to another command)

 

event with queue  if you have code that take time and that could occur before the previous is not finished so message to treat is stored in the queue

 

it sayd with my words you could also meet master/slave for notifier  ans producer/consumer for queue

and data to operate called message

 

Best regards

 

Tinnitus

 

 

 

CLAD / Labview 2011, Win Xp
------------------------------------------------------
Mission d'une semaine- à plusieurs mois laissez moi un MP...
RP et Midi-pyrénées .Km+++ si possibilité de télétravail

Kudos always accepted / Les petits clicks jaunes sont toujours appréciés
Don't forget to valid a good answer / pensez à valider une réponse correcte
Message 2 of 17
(24,515 Views)

User Events allow for a buffered (queued) one-to-many communication (as notifiers).

See my community nugget for an example.

Besides this, I also like to use user events when I already have an event structure for handling the GUI; but this can be done using a seperate message handler loop for GUI updates as well.

 

Felix

Message 3 of 17
(24,504 Views)

Thanks. The queued one to many is what I was missing.

 

=====================
LabVIEW 2012


0 Kudos
Message 4 of 17
(24,450 Views)

The nice thing about user events is you can communicate between parallel loops in the producer/consumer architecture very easily. You can use a queue to notify the consumer loop of things happening in the producer loop, and user events to notify the producer loop of certain conditions happening in the consumer loop.

Message 5 of 17
(24,435 Views)

Is a queue a superset of the notifier, in that it can stack up events? I am comparing LabVIEW 2012's Master/Slave and Producer/Consumer design patterns and they appear to be the same thing, except one uses a notifier and the other a queue.

 

What exactly is the difference?

Message 6 of 17
(22,501 Views)

@bmihura wrote:

Is a queue a superset of the notifier, in that it can stack up events? I am comparing LabVIEW 2012's Master/Slave and Producer/Consumer design patterns and they appear to be the same thing, except one uses a notifier and the other a queue.

 

What exactly is the difference?


Think of a queue as a FIFO.  It is meant for a N-to-one communication.

 

A notifier is a single value.  It is meant for a one-to-N communication.

 

The difference between a M/S and P/C is that the M/S only cares about the last command.  The M/S doesn't care if it misses commands.  The P/C makes sure every command is performed.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 17
(22,486 Views)

Ok thanks. I'll stick to queues and not ever use the notifier.

0 Kudos
Message 8 of 17
(22,477 Views)

@bmihura wrote:

Ok thanks. I'll stick to queues and not ever use the notifier.


Don't be too rash in neglecting Notifiers - they most definitely have their place. A good use case for a Notifier instead of a Queue is where you only care about reading the latest status of something in a asynchronous loop. You can also tell whether that status is "fresh" or not, which can be very useful for syncronising multiple loops to the state of one loop. Great places for Notifiers (as an alternative to Queues) are:

 

  • Reading the status of I/O in a asynchronous process. In this case, you don't care about the history of the I/O you're only interested in what the last state was. If you stored a whole history in a Queue, you'd have to either guarantee that the asynchronous proess was faster than the producer, or limit the size of the queue (which means you could potentially lose data anyway and you're no better off than a Notifier). And again - if you only care about the latest, why store more than the latest?
  • Broadcasting a sync message to slave loops to allow them to syncronise their activities to a seperate master asynchronous process - again, Queues could do this with a bit of extra effort (again by limiting the queue size to 1 and peeking or making some guarantees of slave execution) but Notifiers provide a simpler operation, plus the slaves can determine whether the notification is new or not, possibly waiting for a fresh notification. Providing this with queues requires additional developer labour in some way; with Notifiers it's all built in.

 

I personally see Notifiers as a way of providing data on a "state" basis to multiple clients - ie. you can wait for a new notification of data or you can look at the last notification of data. Queues can provide this but at a cost of extra effort to manually implement, most likely both at the master and clients.

Message 9 of 17
(22,465 Views)

@SteveChandler wrote:

More specifically is there something you couldn't do if user events did not exist in LV?


Yeah.  Have a really neat and tidy asynchronous system up and running with tidy code.

 

As soon as your asynchronous process has it's own UI, User Events are the way to go.  I usually have a single event structure firing off a queue or notifiers as required to a consumer loop for updating UI and other things.

 

I love User Events and find them optimal for most inter-process communications.  Of course some applications require queues or notifiers (Like periodic checking of "Did the user quit this operation" actions) but per default, I go with user events.

 

Shane.

Message 10 of 17
(22,432 Views)