Notifiers VS Queues

[NahoY]

Hello all!

I have a pretty simple question... what is the main difference between notifiers and queues?  Which should I use in which case?  Are queues preferable to pass data?  Anyways, you get the point!
Thanks in advance!

Yohan

[smercurio_fc]

Simple question, simple (brief) answer:

From the LabVIEW online help:

Queue: Use the Queue Operations functions to store data in a queue, which you can later retrieve as individual elements or as an array of all the data elements.
Notifier: Use the Notifier Operations functions to suspend the execution of a block diagram until you receive data from another section of the block diagram or from another VI running on the same computer.

So, basically the difference is in what you're trying to do. The notifier is used when you need to specifically wait until something happens before you continue. Also, one key difference is that a notifier does not buffer the data. This means that if you send a notifier and there's nobody waiting to "catch" it, and you then send another notifier, the first one is lost. In other words, the notifier is like a single-element queue.

What are you trying to do?

[NahoY]

Thanks a lot for the answer!  Thats sort of how I saw the notifiers, as a 1 element queue, so I didnt see the usefulness of having them.  I am curretly trying to deceide how to pass data between a master/slave architecture in the software I am writting.  My basic idea was to use the master loop to monitor user interface events and then leave all the "processing work" to the slave loop.  The thing that concerns me is the way I should pass data collected from a UI (for example, configuration data) and feed it to the slave loop.  That is why I was pondering the use of notifiers VS queues!  I hope I am clear as to what I am trying to do...
Thanks again for the help!

Yohan

[smercurio_fc]

You're talking about a "producer-consumer" architecture. This uses queues. You can look at this article for an overview. In your case one of the loops has your event structure to handle events. This is your "producer" part. When an event happens you just add an element to the queue if you need to perform additional processing beyond user interface update. The other loop just loops around to see if there's anything in the queue. This is your "consumer" loop. The key here is that your event handler responds quickly to user events, letting the consumer loop continue processing as necessary.

[NahoY]

I understand the producer-consumer architecture concept. The thing is, I dont see why I should use this because I dont necessarily need to queue multiple tasks, just perform one specific task depending on user input.  In this case, would it be more logical to use the notifiers?
Thanks

[smercurio_fc]

Again, it depends on what you're trying to do. If your application is simple enough you could probably make due with notfiers. Wouldn't give you as much flexibility for future expansion, but they would work. Your initial question was a broad question as far as the difference between notifiers and queues, and is one preferable. The short answer is that it depends on your needs. Still, if we take the supposition to the next step one could ask why you need to even have a secondary processing loop if your actions and events are one-to-one. In this case, you could perform your task right in the case handling the event, and not bother with the second loop, right?

[NahoY]

I understand your point of view.  Funny thing is, I started written my software with a single event structure managing events and actions.  But I started asking myself if the use of notifiers and queues was necessary since I am writting a fairly large application.  Basically, one or the other can lead to the exact same results.  Now, what do you think should be my main deciding point as for what type of architecture I should use?  Keep in mind my application is fairly large (200-300 Vis), it communicates with GPIB instruments, has multiple sub-UIs for configuration and etc.  I had already written the software before but I am currently rebuilding the structure and trying to make it "bulletproof" 🙂  I am just unsure on which direction I should take to accomplish this...
thanks a lot for your time!

Yohan

[smercurio_fc]

OK, not so little of an application. The single loop construct is fine if you're doing a single UI VI since in this case you're not really doing much. In your case you're probably going to need some form of state machine construct, which is where the producer/consumer architecture will come into play. It will give you the flexibility to adjust and expand the program in the future.

As for whether you should use notifiers or queue, that's a call that you will need to make. If your consumer loop is going to be performing a background process you need to use queues. For example, I created a LabVIEW-based test executive for the RF testing we're doing here since we don't have (and are unwilling to buy) TestStand. It uses a producer/consumer architecture with the consumer running a test sequence as well as responding to messages placed in the queue by event handler in the producer loop. Since the consumer loop is running a backgroung process you can't use notifiers in this case. Very simple framework, but extremely efficient, robust, and easy to modify. My suggestion is to use queues as in most cases you end up needing to expand the program in the long run. You don't really lose anything by using queues, and really gain quite a bit.

To the rest of the community: Perhaps someone else may be able to provide additional tips?

Message Edited by smercurio_fc on 05-30-2006 03:36 PM

[NahoY]

Thanks again for your input.  I have decided to use queues like you suggested, I find they make more sens than notifiers in my case.  Funny thing is, I am creating an RF component testing application (load pull, if you are familiar)!  Thanks again for clearing things up.  I find the only thing that is harder to understand using "message" based programming such as producer/consumer architectures etc. is visualizing the structure of the code and getting started.  Guess its just some getting used to, like everything else!

Hope this thread could be useful to some other community members...

Cheers!

Yohan