LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Notifiers and Shared Clone Re-entrancy

Solved!
Go to solution

Hello,

 

Came across this the other day. A quick search didn't yield any immediate results so I thought I'd share.

 

I'm unsure if this is expected behaviour but it still tripped me up.

 

If you have a pre-allocated clone which contains a wait on a notifier and a notification is sent before the VI is called, it is a race as to which clone will exit. The second clone will not execute until another notification is sent. This is despite 'ignore previous' being set to False.

 

You can see this below. The second Shared Clone never executes, unless the second diagram disable is enabled. (I have attached the source so you can try it yourself).

 

Snip Clones.PNG

 

I haven't tested this with Qs but I suspect the result will be similar.

 

This happened to me in a OO project where the clone was a dynamically dispatched VI so could not be a pre-alloc clone. The solution was to simply wrap the wait on notifier in another VI.

 

I'm interested to know your thoughts.

 

 

Nick
0 Kudos
Message 1 of 31
(3,511 Views)

I haven't Heard of it Before, but i'm not very surprised. Since it's a Shared clone i guess you'll only get 1 registration, thus only 1 reaction? It leads to the question if it reacts the same with Events? I'd guess so (Isn't notifiers events 'under the hood'?)

/Y

(And i have no idea why this browser (or is it the forum) randomly sets capital letters)

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 2 of 31
(3,486 Views)

Certainly makes sense Yamaeda. I feel like it shouldn't behave this way? The sell of shared clones is reduced memory usage - not different run-time behavour to pre-alloc clones right?

 

My use-case was a 'master-slave' type thing. The parent called wait on notifier in its 'start' method. The 'master' - a specific child implementation would override start and send the notification before calling the parent node. It confused me somewhat why some of the classes were not executing...

Nick
0 Kudos
Message 3 of 31
(3,473 Views)

Interesting - it seems like it may be that because the first shared clone executes so quickly, that it doesnt actually use a clone, but rather the same instance of the vi. Putting a small wait in the shared clone before the wait on notifier fixes the behavior, and putting a counter on a shift register in the vi seems to indicate the same.

 

I also noticed if I keep running the main vi, (adding the second notification like you did and removing the wait in the shared clone, but keeping the counter) after a few runs a clone is used, and then LabVIEW continues to use the clone for each run after.

Message 4 of 31
(3,462 Views)

I went searching on the Lava forums because I kinda remembered some subtle issues that were discussed there a very long time ago, resulting in a couple of new Notifier functions on the palette to better handle some less common scenarios.

 

Here are a couple threads, I only skimmed them to make sure they had some depth of discussion.  There may be some additional ones if you do some further searching.

 

A thread from 2006, and another one from 2007 (containing links to several more)

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 5 of 31
(3,456 Views)

@niNickC wrote:

The second clone will not execute

 


 

 I suspect the first call finished before the second call, so the first clone was reused, and there was no second clone.   Try adding a small wait in your VI (so LabVIEW is forced to use a second clone).  Regardless, one should never use shared clones with any retained state (like the wait on notification).

 

Edit> paul.r beat me to it.

Message 6 of 31
(3,454 Views)

You are sharing the data space.  So, I would expect that the 2 wait on notifications of the same notifier would each strip the notification meant for the other.  Like dequeueing the data from a queue in two places, only one instance can actually dequeue a single data.

 

Events, behave much differently! 1 event can trigger any and all event structures registered for the event to act... unless it's a filter event and another structure dismissed the event.  

 

I hope someone with a computer comes by and explains it better than I can by phone 


"Should be" isn't "Is" -Jay
Message 7 of 31
(3,450 Views)

There is some optimization stuff that's going on. Looks like LV optimizes the calls of the shared clone, so it actually IS shared - they execute sequentially using the same clone instance (edit: a little explanation: this is actually due to the speed of the clone execution, as some guys mentioned above). So it acts the same as if you'd use non-reentrant execution. Note that the hanging at second call of the same instance of Wait on Notification is expected - see it's details in help.

 

I'd call it expected behaviour. The shared clone configuration says that it may or it may not use the same instance of the clone, it doesn't promise anything. And Wait on Notification promises that it will wait for new notification in subsequent call of the same unique instance. Combine those two, and you get non-deterministic behaviour (it's worse - it is runtime behaviour, because it's decided in runtime how shared clones are used/instantiated).

 

And such nuances of Notifiers made me practically avoid them in most cases (they mostly can be easily replaced by other mechanisms)... 😉

 

 

 

Message 8 of 31
(3,447 Views)

I would say its more of a shared clone nuance than a notifier nuance.

Message 9 of 31
(3,441 Views)

@drjdpowell

 

I came across this in a dynamically dispatched VI which cannot use the pre-alloc type...

Nick
Message 10 of 31
(3,439 Views)