Notifiers not working, when use consecutive create notifier vis without delay

[Humungousaur]

Hello,

 

I am trying to use notifier for synchronization within my code. My project requires sender program to send a command to multiple receiver programs. The sender program has to wait for response from all the receiver programs to proceed. I am using user event to send the command from sender program to the receiver programs. And receiver program has to set the notifier after it receives the command. Sender program will wait on notifier. 

 

If I don't have any delay between subseqent notifier create vis, my wait on notifier always results in timeout for some of the receiver programs. But when I include a small delay between subsequent create notifier vis, then wait on notifier receives all the notification without timeout.

 

For me it looks like a LabVIEW issue, but I wanted to hear from others, that is there anything wrong in the implementation?.

 

I have attached a small sample program for reference. Open up the sender program, configure no of receivers and run the program. Click the send and receive button to send user events and wait on notifiers.

 

Thanks in advance,

Nanda

Notifier Prototypes.zip

[hooovahh]

Oh it took me a bit but I figured it out.  So in your Sender.vi, in your second for loop you are waiting on the notifier.  You are waiting on them one at a time.  And you know that the first one will not reply until one second, because the receiver has a wait 1000ms after getting the event, before setting the next one.  

 

So you wait for one second before ever looking at the second notifier.  But the second user event (and all of them) have already been generated at this point.  What this means, is you maybe waiting on the first notifier before moving on, but all the other notifiers are already being set.  It is a sorta race condition, where the race is because you set notifiers 1s after getting the user event, but you only wait on notifiers one at a time.  Maybe a dead lock would be a better name for this.

 

A easy solution would be to turn on for loop parallelism in the second for loop, and wire the size of the notifier array to the P terminal.  This way all notifiers will be waiting at the same time.

[Humungousaur]

Ignore previous boolean is set to false in the wait on notification vi. It is supposed to receive notification, even if the it is set in the past. How do we explain adding a wait in the first loop (while creating notifier) solves the issue?. Adding a delay of just 1 ms solves the problem. How do we explain that?

I tried enabling iteration parallelism. And wired the notifier array size to the P terminal. It didn't helped.

[drjdpowell]

I couldn’t ID the problem.  The code looks like it should work but doesn’t.

[Humungousaur]

Hi all,

 

Looks like using wait on notifications from multiple vi is the answer. I have been using wait on notification vi manually indexing the notification reference in the for loop. But wait on notifications from multiple vi is the correct vi to be used. Found another thread discussing the same issue.

 

http://lavag.org/topic/4028-notifier-signals-missed/

 

Thanks,

Nanda

[infinitenothing]

I looked through that thread and I wonder if there's a better implementation of the notifier behavior like using subscribers or something

drjdpowell: Here's how this affects messages. I defeated the reentrancy by wrapping your "wait for notification" in a nonreentrant subVI. If "data 1" executes first, all messages are delivered nicely. If data 2 fires first (as shown in the image below), you get a timeout (or a  deadlock if the timeout is -1)

 

You can make it so both messages are delivered by using the "Wait on notification with history" primitive in your "wait on notification" VI instead of the normal "wait on notification" primitive.

[drjdpowell]

You can make it so both messages are delivered by using the "Wait on notification with history" primitive in your "wait on notification" VI instead of the normal "wait on notification" primitive.

 

Oh yeah, DUH, this is why the “Advanced Notifier Waiting†subpallet exists, isn’t it?  I’ve never used notifiers in such complex ways and so I forgot about it.  If one doesn’t need the many-readers ability of notifiers, one is better off sticking to queues.   The “Future Token†class, which is what I use to solve “wait for something to reply†problems like the OP’s, is a Write-Once, Destroy-on-Reading, single-element queue.

 

I shall add a "Wait on notification with history†method to my NotifierMessenger class in case people find uses for this.  Thanks.

[infinitenothing]

In my opinion the advanced behavior is the more intuitive way. It's not intuitive (as you saw with the original post) that the order of the senders should matter. We normally don't think about the receivers having an internal memory (we expect the primitives to be stateless except for the ones that enable statefullness). The other primitive (no history) maybe should be on the advanced pallet because it's for the power users that go faster.

[drjdpowell]

In my opinion the advanced behavior is the more intuitive way. It's not intuitive (as you saw with the original post) that the order of the senders should matter. We normally don't think about the receivers having an internal memory (we expect the primitives to be stateless except for the ones that enable statefullness). The other primitive (no history) maybe should be on the advanced pallet because it's for the power users that go faster.

 

It is more intuitive, quite true, but it also has the potential ability to consume memory until an app crashes, which is a possible argument for keeping it advanced.

 

Personally, I would advise against using Notifiers in complex ways like this regardless.

[infinitenothing]

I didn't realize there was a potential for a memory leak there. That's unfortunate side effect.

 

On the upside, if you use the history one, you can reenable dynamic dispatch because you don't have to share clones in yourWait For Notification.