01-27-2010 03:10 PM
01-27-2010 03:19 PM
What are you trying to accomplish?
The difference between a notifier and a queue is that a notifier is basically a single element queue. It stores one piece of data. A queue holds multiple pieces of data. So if you were waiting for an element in a queue, and you are also waiting for another element from another source, how is it going to handle it if the first source sends a second piece of data before the second source sends it first?
What do you need queues for that a notifier can't accomplish?
You could create several queues, one from each source, and wait for all of them in parallel. Then you can extract the piece of data out of each queue. You can do a wait for multiple notifiers, and wait for data from a single queue as well. Perhaps the Rendezvous functions would work for you.
If you can tell us your application in terms of how many senders of data there are, how many pieces of data you are dealing with and what that data represents, we might be able to suggest the best scenario.
01-27-2010 03:19 PM
There is no problem in enqueueing at multiple places and consuming the elements one-by-one. You can use an id-element in the queue data if you need to know the sender.
If you want to 'go' when all senders have updated their data, use n dequeue element functions.
But please be more specific what you want to achieve...
Felix
01-27-2010 04:06 PM
Yes. Let me clarify.
The Wait on Notifier from Multiple is a case where a single piece of code must wait until all sources of the notifier have sent a notifier.
A queue has a one to one or many to one relationship. A Dequeue Element will wait unit any one of the Enqueue Elements sources of data have placed an item in the queue. Once it gets an item, it takes it out and works on it no matter where it came from.
If you want to make the Queue similar to the Wait on Notifier from Multiple where you have to wait for all of the multiple sources of data to enqueue their data, then that is complicated. It can be done using multiple queues, or combinations of queues and other synchronization functions. But we really need to know what your goal is before suggesting an answer. If a given scenario is implemented wrong, then you run into the situation where a queue is growing indefinitely because other parts of the scheme are behaving the way you need them to.
01-27-2010 05:45 PM
The Wait on Notifier from Multiple is a case where a single piece of code must wait until all sources of the notifier have sent a notifier.
No, the wait on multiple returns if one notification (from an n-array of input notifications) is received. If your consumer loop rate is fast enough, it is the same asa queue from multiple loops. Only if your consumer loop is slow, you will get an array of notification values, from each notifier 0 or 1 val.
With queues we could use a dequeue+flush to get the same result when no queue would insert more than 1 element.
Felix
01-27-2010 07:47 PM
Dohhh! You're right.
I was just looking through the synchronization palletes the other day because I was thinking of a notification to be a part of a communication scheme I was fleshing out. I skimmed through the wait on Multiple, must not have read it correctly, or just didn't remember it correctly. The title of it makes me think of the way I had just written it up. If I say "I'm waiting on 5 people" in normal English, that means I'm waiting for 5 people to each give me their information before I can move on. So when I read of the Wait on Notification Multiple, that is the way I think of it. In reality, the definintion is more like "I'm waiting on ANY of 5 people" so if any of those 5 give me their information, I can move on.
Thanks for straightening me out.
I can't think of what would be the ideal scenario for using that particular VI. I think my most common use cases would be to use either a Queue (for a many to one, multiple data) or a Notifier (in one to one, many to one, one to many, or many to many scenario, single piece of data with those possible combinations in order from most likely to use, to very unlikely to use)
.
01-28-2010 06:10 AM
01-28-2010 07:52 AM
The queue works fine in a write-many, read-once application. It sounds like that is what you want. You only need one queue (as long as the messages themselves identify the source, if necessary). Enqueue in each of the loops which generates error messages. Dequeue only in the logging loop. If multiple errors occur close together, the queue will accumulate them until the logger gets to them.
Lynn