You have to keep track on both if you want to analyze if certain Wait on Notification node on the block diagram will complete or not. Notifiers actually have two retained states: one is in the reference (notifier history is there), second one is in the Wait on Notification node (as it "remembers" that it already read the notification - hence our problem here). Its nothing specific to notifiers, you could see the same problem with any function that uses a retained state. The issue is caused by nuances with shared clones - sometimes the same instance is used, sometimes not. One should never use shared clones with any retained state. Naaah, shared clones are straightforward: assume that they will reuse the same instance at some point, which leads to the simple rule that drdjpowell stated: I don't exactly understand what is happening in your code, could you provide some minimal code example for would say its more of a shared clone nuance than a notifier nuance. It confused me somewhat why some of the classes were not executing. The 'master' - a specific child implementation would override start and send the notification before calling the parent node. The parent called wait on notifier in its 'start' method. My use-case was a 'master-slave' type thing. What would you suggest as an alternative? This use-case was a 'master-slave' type thing. It's not possible to recreate the same situation as OP has using event structure - we can't generate event before registration, so it will stuck by such nuances of Notifiers made me practically avoid them in most cases (they mostly can be easily replaced by other mechanisms). So we'd need to generate the event after the registration, and it's the same as sending notification after calling (and waiting in) Wait on Notifier. The main difference in discussed case is that dynamic registration of events does not have any option to "see" the events before the Register for Events node executed: unless it's a filter event and another structure dismissed the event. But they have to be unique, as pointed in my above behave much differently! 1 event can trigger any and all event structures registered for the event to act. Just to clarify: this is not true, two unique instances of Wait on Notification can not ever strip each others notification. Like dequeueing the data from a queue in two places, only one instance can actually dequeue a single data. So, I would expect that the 2 wait on notifications of the same notifier would each strip the notification meant for the other.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |