One sender multiple notifier

[s.h._tech]

Hello everyone,

I have a basic question about the use of Notifiers. I branch of my Notifier-Reference to multiple statemachines. When I send a notification how can I clear this notification in all other References. basically I want the Notification to be called only once. See VI attached

After "Meldung" is notified, Meldung 2 should no be triggered because the message was already received. But the notifier of "Meldung2" is also triggered. 

Is this an intentional behavior? How can I clear other reference notifier after it was called once?

[johntrich1971 · Accepted solution]

More information about your actual application would be helpful. For instance, how do you expect to send a notification to the second Wait for notifier? Did you notice the Cancel notifier function on the palette? As long as your notifications are serialized you could use this to cancel the notification prior to the next Wait for notifier.

[Yamaeda]

---

@s.h._tech wrote:

Hello everyone,

I have a basic question about the use of Notifiers. I branch of my Notifier-Reference to multiple statemachines. When I send a notification how can I clear this notification in all other References. basically I want the Notification to be called only once. See VI attached

After "Meldung" is notified, Meldung 2 should no be triggered because the message was already received. But the notifier of "Meldung2" is also triggered. 

Is this an intentional behavior? How can I clear other reference notifier after it was called once?

---

Yes, that's per design, as the point of a notifier is to notify all ...

If you change it to a queue it'll be first come, first serve, as it'll be consumed upon first read.

/Y

[s.h._tech]

Cancel notification solved it. I did not know that all instances will be released.

@Yamaeda: I can see the intention behind it

[Mark_Yedinak]

Depending on what you are actually implementing and the problem you are trying to solve, using Notifiers may not be the best choice. They may work, but may result in other undesirable side effects or bugs. If your intent is to only send it to one listener, you should be using a point to point mechanism like a queue. Notifiers are broadcast mechanisms. Due to timing limitations, canceling the notification may not always work. Another listener may get the notification before you actually cancel it.

Even if you intent is to have a pool of actors who can process the data and only one needs to do the work and it doesn't matter which one, a queue would be better option. Using a queue the first actor to grab the message will, the element will no longer be on the queue and the other actors will continue to wait.

[johntrich1971]

---

@Mark_Yedinak wrote:

Depending on what you are actually implementing and the problem you are trying to solve, using Notifiers may not be the best choice. They may work, but may result in other undesirable side effects or bugs. If your intent is to only send it to one listener, you should be using a point to point mechanism like a queue. Notifiers are broadcast mechanisms. Due to timing limitations, canceling the notification may not always work. Another listener may get the notification before you actually cancel it.

Even if you intent is to have a pool of actors who can process the data and only one needs to do the work and it doesn't matter which one, a queue would be better option. Using a queue the first actor to grab the message will, the element will no longer be on the queue and the other actors will continue to wait.

---

That's why when I suggested it I added the caveat that the Wait for Notifiers had to be serialized as they were in the example. I totally agree that notifiers might not be the right approach, but without additional information it is impossible to suggest better options.