Showing results for 
Search instead for 
Did you mean: 

obtain notifier memory



I'm a little confused as too how memory management works with the obtain/release notifier vi's.  I am using notifiers to broadcast data and so I have no way of knowing when a notification is no longer needed. Because of this my current code does not use the release notifier.  However my program dies after ~20 hours complaining of a memory full in the subvi I used to wait on notifications.  


I tried reusing the reference I get from the obtain notifier using the attached vi but this gives me a reference error.


Any advice is appreciated




0 Kudos
Message 1 of 6

Basically, Obtain Notifier will generate a new notifier, Wait on Notifier (or wait on multiple) will pause operation of that node until something elses uses Send Notification to supply data.  Release notifier will destroy the notification reference.


I don't have LV on this computer, but it sounds like you're continuously generating new notifier references and never closing them, hence your memory leak using up all your computer's memory.

Message 2 of 6

The problem with the VI that you created is that you've made it reentrant. You cannot do this for that type of VI. Reentrant means it will use its own memory space with each call, which is exactly what you don't want to happen.


As far as the memory issue is concerned, most likely it is the case that you're simply continuously creating new notifiers, as Jeff alluded to. Without seeing more code it's only a guess.

Message 3 of 6

Thanks for the hints.  I added a release notifier vi after the wait on notification vi which seems to be working so far.  I was confused because from the documentation it sounded like the release notifier cancelled the notification for everyone else.


 I will let you know if I have the same error again.




0 Kudos
Message 4 of 6

That will work, but will be very slow.  Typically the way notifiers work is the following:

  1. Broadcaster creates a notifier.  Optionally, the notifier is named.  Naming the notifier allows other locations to easily acquire the notifier without having the notifier reference, but opens up multi-use issues.
  2.  Listener(s) creates a notifier.  If using a named notifier, this can occur before or after the broadcaster creates the notifier.
  3. Broadcaster loops on sending messages until end of execution, then exits loop.
  4. Listener(s) loop on receiving messages until end of execution, then exits loop.  This exit can be signalled by a message or destruction of the notifier, which causes the notifier listen to immediately run, returning default data and an error.
  5. Broadcaster releases notifier reference.  If desired, the broadcaster can do a force destroy (boolean option on the releas) to destroy all references to the notifier.  This causes the immediate run of all listeners who may be monitoring the notifier.
  6. If necessary, listeners release notifier references.
Note that acquire and release is only done once at any location, broadcast or release.  On the rare occassions I use notifiers, I usually create it once at the initialization of the program and store the reference in a look-up table, usually a single-element queue (see here for this method).  I have used both the message and force destroy methods to end listener loops.  The key, though, is to only acquire a reference once at any location.
This account is no longer active. Contact ShadesOfGray for current posts and information.
Message 5 of 6

Thanks for the heads up about speed.  The example you linked to is a bit deep for me so I will need to chew on it for a while.  I changed the create notifier vi I attached earlier to execute non-reentrantly but I got the same bad reference error.  From this I assume that notifier references cannot be stored in conditional blocks.  I'll let you know when I have tried the queued reverence idea.




0 Kudos
Message 6 of 6