Need Detailed Explanation of Notifier Wait

[Nathan_S]

I have been researching Notifiers for a while now, but I am still perplexed by some of the explanations in the LabVIEW Help.  Could someone please help me out on this?  I cannot seem to understand what this means...

If ignore previous is FALSE, each instance of the Wait on Notification from Multiple with Notifier History function waits if it has not received notification. If one or more of the notifiers have messages newer than the time stamp most recently received by this function, the function returns all messages. Otherwise, the function waits.

When ignore previous is TRUE, this function always waits for a new message, even if the message currently in the notifier is one it has never seen before.

This function does not remove the message from the notifier. Although a specific instance of the function returns a message only once, other instances of the function or the Wait on Notification function repeat the message until you call the Send Notification function with a new message.

I've been through the examples, but I still don't seem to get it.  Any help is much appreciated and will be kudoed.

[crossrulz]

I admit I have only used the Wait on Notification for receiving notifier messages.  But the others are just a scale of it.  So here's my understanding.

If ignore is TRUE: the function waits for a new notification regardless.  Be careful with this.  I have ran into race conditions with this setting.

If ignore is FALSE: the function waits for a new notification IF a new notification had not been sent since the last call of the function.

[Kevin_Price]

I agree with crossrulz, but here's a little more background:

I don't recall the details now, but I'm pretty sure those "advanced" wait functions were put in place in a fairly recent version of LabVIEW to fix a somewhat subtle bug.  I *think* that the problem could only arise if a specific instance of a "Wait On Notification" could be called with different Notifier Refnum inputs.  The simpler architectures where any given "Wait On Notification" always received the same Notifier Refnum input would not experience the problem.

The key point in this is that the "ignore previous?" input attaches to the instance of the "Wait..." function dropped on the diagram.  If you had 2 loops that each wait on the same Notifier, they would keep independent records of whether they were holding onto an unread notification.

The issue is (it's coming back to me now) the regular "Wait On Notification" functions only tracked whether or not they had been sent *any* unread Notification.  If you had an architecture where a regular "Wait..." function could be fed with any of several possible same-datatype Notifier Refnums, you might get unexpected behavior.  I don't recall whether only the wait / don't wait status was compromised or whether you might actually receive a different Notifier's data back.  Thus the "Wait... with History" functions arose to maintain Notification status based on a combo of function instance AND Notifier Refnum rather than on function instance alone.

That's how I remember it anyway, corrections welcomed.

-Kevin P

[Nathan_S]

Thanks for the help everyone.  I guess I'm stumbling over what the TRUE statement means (for any of the Wait functions, not just the multiple with time stamp) when it says it always waits for a new message.  I ran through the examples in the Example Finder and I can't seem to figure out what it's doing.  I agree that it looks like a race condition or aliasing or something.  What is the cause of this?

[crossrulz · Accepted solution]

If the Ignore is set to TRUE, this means that the Wait... will sit there and wait for a new notification.  This new notification will have to happen AFTER the Wait... started waiting.  If a notification happened before the Wait... started waiting, that notification will be ignored.

Where I ran into a problem was I was using notifiers to communicate between two subsystems and I ran into a race condition as one sent data and waited for an ACK, but the ACK reply was fast enough that it was sent before the start of the Wait on Notification.  And thus I got errors.  Luckily I had timeouts.

[GregFreeman]

---

@crossrulz wrote:

Where I ran into a problem was I was using notifiers to communicate between two subsystems and I ran into a race condition as one sent data and waited for an ACK, but the ACK reply was fast enough that it was sent before the start of the Wait on Notification.  And thus I got errors.  Luckily I had timeouts.

---

GLORIOUS! So this is how they work haha! I had a system where the handshaking got all messed up and I switched things over to, what ben calls, a self addressed stamped envelope. Good to know this is truly how it functions. I assumed the ignore looked at a timestamp or something of the sort between calls. Blah.

[DSTUD]

Hello,

If I may, I would like to present a seemingly related problem that I am experiencing.

I have the following sequence

1) VI-1 sends a notification

2) VI-2 I has a Notifier Wait (Ignore previous set FALSE) which recieves the notification sent by VI-1

3) VI-2 then eventually reaches another Notifier Wait (Ignore previous set FALSE) function.  

At point#3, the Notifier Wait picks up the same notification that was recieved and handled at point#2 even though I have since obtained and handle the notification data

Am I missing something? At what point will the notification actually be cleared?  

I realized that I could avoid this issue by setting second Notifier Wait to ignore previous notifications, I would like to avoid this in case a notification is sent between points 2 and 3.

Thank you in advanced for your help with this.

David

[nathand]

This is exactly what would be expected. Each instance of Wait on Notification independently tracks the last notification it saw, regardless of what any other instances have seen. In your case, the second instance sees a "new" notification (new to that instance, even though another instance in the same VI already saw it) and so it proceeds. Notifications are never automatically cleared; the only way to clear one is to cancel the notification (which you could do after the first wait on notification, although it could lead to a race condition). Possibly what you actually want here is a queue, since then the first dequeue would remove the element, forcing the second one to wait until a new element is enqueued. Another roundabout way to solve this would be to wrap the Wait on Notification in a non-reentrant subVI, so that it's actually the same instance both times.

[DSTUD]

nathand,

Thank you for that clear and concise explanation!