Reliability of SASE (Notifiers)

[Intaris]

I pass commands to code all the time.  When I require data back, I usually include a "Self-Addressed Stamped Envelope" in the form of a newly-created Notifier which the receiving code can use as the return channel.

Using this method, I recently ran into some unusual behaviour.  Some of the thus created Notifiers seemt o miss notifications.  I'm reading them with "ignore previous" set to false, so no data should go missing but it does.  I manage my many notifiers in an array and test each one repeatedly until it has returned a certain value (meaning the asynchronous process has finished).

When I run the code included below, I run into problems but don't quite see why this should be the case.  As usual, I'm probably doing something stupid.

I'm using LV 2015 SP1.

[Intaris]

Ah I found it out.  This is the reason why the node "Wait on multiple Notifiers" exists.......

Two different notifiers with the same timestamp at the same read node will NOT return two values as the node records only a single timestamp and is not aware of the differences between notifiers.

Learned something today again.

Shane

[deceased]

I suspected the same, in having a look I just noticed the "wait on notification from multiple with notifier history" node, which may also solve the problem.

[Intaris]

I have also tried the "Wait on Notifier with Notifier History" fromt he Advanced pallette.

By feeding this node continually new notifiers, does this not require a large allocation of Timestamps in order to maintain correct functionality?  Or does the list somehow react to destruction of the appropriate notifier.  I ask because after letting it run for approximately 20M unique notifiers, my memory usage did not increase.

After over 20 years of programming LV, I finally found out what these other Notifier functions do.  Nice.

[deceased]

I can't comment, I didnt even notice those additional functions until I was looking at your code 10 mins ago....

[terickson]

Yes, a direct replacement into the original VI of the Wait on Notification with Notifier History works.

I never knew the difference between these, thanks for the post.

[Kevin_Price]

Thanks for the reminder.  This was discussed years ago over on LAVA and I believe the Queue-father (aka Aristos Queue) himself investigated the cause of a similar unexpected behavior and was instrumental in the fix, as found in the Notifier's advanced subpalette.

-Kevin P

[Intaris]

Well maybe I need to give AQ a call.  As I see it, the memory usage of the "Wait for Notifier with history" is unbounded.  If I constantly create, read and destroy notifiers, memory usage (presumably due to the node maintaining timestamps for ALL of the notifiers) increases steadily.

I have a tight loop running (approx. 100k Notifiers per second) and will leave it running overnight.  Memory has already increased from 1443 MB to 1670 MB. Presumable it will eventually crash LV.  It would be nice to have the option to "reset" the timestamp memory somehow.

[Intaris]

Now i'm at 2176 MB and waiting for armageddon....

[drjdpowell]

As a tangential question, why are you using Notifiers for this use case?   For a single-use "self-addressed stamped envelopes" I use one-element Queues, not Notifiers.  No timestamps, no history.  To wait on multiple replies I just wait on the Queues one after another; I don't poll them.