10-24-2010 11:59 AM
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?
10-24-2010 12:22 PM
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
10-24-2010 02:07 PM
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
10-25-2010 04:49 PM
Thanks. The queued one to many is what I was missing.
10-25-2010 07:01 PM
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.
04-18-2013 12:01 PM
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?
04-18-2013 12:35 PM - edited 04-18-2013 12:35 PM
@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.
04-18-2013 12:54 PM
Ok thanks. I'll stick to queues and not ever use the notifier.
04-18-2013 02:14 PM
@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:
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.
04-18-2013 05:04 PM
@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.