Single Element Queue vs Notifier?

[SteveChandler]

For all intents and purposes is a notifier the same thing as a single element queue? If so does one perform better?

[Jon Kokott]

They are not the same. A single element queue can be used as a mutex in a by reference style of code. (dequeue locks, enqueue unlocks.) Using a notifier would not allow you to mutex correctly since you cannot wait on notification and cancel it at the same time. You would be required to test that the waited on notificaiton message was identical to the canceled notfication and internally include a modification metric to ensure that you have the correct data in instances where actual data does not change, and retry if you didn' t get the reference (practically speaking I wouldn't even try.)

a notifier would behave the same as an SEQ if you ONLY used the lossy enqueue and preview queue funtions. I'm not sure which one would perform better.

the best performer in this type of by reference structure is the DVR (data value reference)

~Jon

[jdunham]

The basic difference of course is that a Notifier is a broadcast mechanism. If you have ten threads waiting on (listening to) the queue, and enqueue an item, then only one will stop waiting. I think it will be the one that started waiting first but I don't know whether that is guaranteed.

If you have ten or ten thousand threads waiting on a notifier, they will all stop waiting and take the update.

With a single element queue, you can't put any more into the queue until the first item is taken out, but with a notifier, you can put as many in as you want, and if the receiving thread or threads don't finish looping in time, they can miss notifications. There is no way for the sender to know if any or all of the recipients have received a particular notification.

Edited August 20, 2011 by jdunham

[Black Pearl]

I assume the queue might be better in performance.

More use cases (SEQ, producer-consumer) -> NI put more manpower behind the optimization code -> better performance.

I think 8.5 it was a big marketing about Qs and multicore performance, they never adressed notifiers.

But might be completely missleading, as a notifier only needs 1 piece (the current piece) of data while a queue might queue up (as the name suggests), so those optimizations would be unneccesary for a notifier.

Felix

[SteveChandler]

Ah that is what I was missing. I have never really used notifiers. The broadcast part is what I didn't know (or knew at one time and forgot)

[BrokenArrow]

I've never seen a use of Notifiers where you couldn't have done it with a Queue. That being said, I like to use Notifiers to send status messages to a tiny parallel loop that sits there un-spinning and patient - waiting for the Notifier to be updated. Then again, you can do that with a Queue too, but why? A "real" SEQ is bulky to set up and use compared to the Notifier.

[jdunham]

I've never seen a use of Notifiers where you couldn't have done it with a Queue.

If you have 100 listeners, you would need 100 queues to send the same message to all of them simultaneously. It's much easier with a single notifier. Our software detects events which must be handled by a variety of subsystems all able to run in parallel, and a notifier makes short work of it.

[silmaril]

The real cool feature of Single Element Queues is that you can use them as a kind of global variable!

It comes with an integrated semaphore mechanism which helps prevent race conditions (in fact it's the other way round: take a look at LV's semaphore VIs and you will see that they are using Qs internally).

And it can help you to minimize data copies!

Imagine you have an array of one million double value inside an SEQ and you want to read one element from it.

Using the standard dequeue-enqueue mechanism will only make a copy of the extracted element, not of the complete array, since the array buffer can be reused.

Reusing the buffer is only possible in Qs, not in notifiers, since in a notifier the data has to stay inside it in case another process wants to read it afterwards.

Of course the same is true for "Preview Queue Element", so you should not use this if you only want to read a part of the data inside the SEQ.

[jgcode]

The real cool feature of Single Element Queues is that you can use them as a kind of global variable!

It comes with an integrated semaphore mechanism which helps prevent race conditions (in fact it's the other way round: take a look at LV's semaphore VIs and you will see that they are using Qs internally).

And it can help you to minimize data copies!

Imagine you have an array of one million double value inside an SEQ and you want to read one element from it.

Using the standard dequeue-enqueue mechanism will only make a copy of the extracted element, not of the complete array, since the array buffer can be reused.

Reusing the buffer is only possible in Qs, not in notifiers, since in a notifier the data has to stay inside it in case another process wants to read it afterwards.

Of course the same is true for "Preview Queue Element", so you should not use this if you only want to read a part of the data inside the SEQ.

Wouldn't DVR's and IPE be better suited to this task (i.e. easier).

[mje]

Wouldn't DVR's and IPE be better suited to this task (i.e. easier).

I'd say yes, provided you're in LV2010 or later of course.

[jgcode]

I'd say yes, provided you're in LV2010 or later of course.

Yes, my comment was also based on the fact the snippet posted was in 2010.

DVR's came out on 2009 - was there improvements in 2010 etc? (I ask coz I haven't use 2010 much).

[mje]

Ah, my bad, I was getting history confused. I meant 2009.

[jgcode]

Ah, my bad, I was getting history confused. I meant 2009.

Cool.