Shared Clone Behavior

[dterry]

Hello All, 

 

Long time reader, first time poster.  I have learned a lot from lavag, and really appreciate what you all do here.  

 

I am building an LVOOP architecture that sort of straddles the line between AMC and AF.  One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones.  I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on.  First some definitions:

• Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, reserved for execution.
• Behavior B: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the active, running clone VI, which is capable of being debugged.

I once thought that behavior A was how LabVIEW worked, however in developing this framework, I have found that some subVIs show behavior B.  Behavior A and B seem to correlate to dynamic and static dispatch methods respectively, but I can't make sense of why.  If I create a simple example without OOP (see attached), I get behavior A.

 

Has anyone ever seen this behavior, and if so, am I missing something really obvious?

 

Secondly, does anyone have any tricks or best practices for getting into active clones to debug?  My only idea at this point is to include some sort of notifier/queue/etc to active a Front Panel Open Method.

 

Thanks in advance!

 

Drew T.

CLA, CTA

[drjdpowell]

In the later LabVIEW versions, one can open the original copy and select View>>Browse Relationships>>Reentrant Items, and that allows one to open the shared clones.

 

In older LabVIEW Versions, one can (temporarily) set the VI to "show front panel when calledâ€.

 

However, if your building a message-based architecture, you can just build in a “show front panel†message to your actors/processes/modules/whatever.

[dterry]

WOW, drjdpowell, it's not often I learn about such an amazingly useful feature, and I've been down some pretty deep rabbit holes in LV.  THANK YOU!  That View menu trick is going to be so helpful!!

 

As for the show front panel message, that is how I am opening the top level endpoint (actor/whatever), but when I would open it's DD subVIs (message router, message handler, ui, auxiliary, etc.), I would get their original copy, which is where your first trick comes in so handy.

 

The View menu trick will pretty much resolve my struggle here, but I am still curious about the behavior if anyone has any thoughts!

 

Thanks,

 

Drew

[Djed]

"Shared Clone" reentrant subVIs are assigned to a callsite from the pool of free (not currently being run) clones *at the last minute*.  This means that generally if you go click on a callsite, LabVIEW can't possibly know which one will actually be run by the caller VI, so LabVIEW just opens the "master copy".

 

However, if that callsite DOES have an assigned clone because the clone is running exactly when you click on the callsite, then LabVIEW can open the right clone!  This can be very hard to do unless the subVI takes a long time to run or you are already debugging thanks to hitting pause or hitting a breakpoint or stepping.

[dterry]

Djed,

 

That's a good line of thinking I hadn't gone down yet.  Unfortunately, it doesn't fully explain my behavior.  True enough, in some cases where I experience Behavior A, the reentrant VIs are being called inside a loop, meaning they may or may not be running at the split second I click.  However, in several other cases, the VIs themselves contain a loop and are running continuously.  Any thoughts on how that detail may affect things?  Just in case it helps, it does seem to correlate (in this, but not all cases) to DD vs static dispatch.

 

Thanks,

 

Drew

[Djed]

The exact details of when the exact clone is exactly "reserved" do vary for many reasons.  It's not necessarily deduce-able from the diagram since the compiler tries to optimize things.  The caller VI might grab a clone once and hold onto it for a while or it might grab it exactly as it needs it.  And yes, SD versus DynD also play into this.  Dynamic Dispatch I believe is always grabbed at the last minute because we have to deduce the right VI to call and it might vary between loop iterations, etc.

[Chris_Collier]

I've seen behavior A almost explicitly with VIs set to "shared clone reentrant execution", and behavior B almost explicitly with VIs set to "preallocated clone reentrant execution" (nomenclature from 2013).  I had assumed that this setting was what caused each of these behaviors.

[Djed]

Yes, that distinction generally determines when you'll see this behavior.

[dterry]

Djed,

 

Thanks for taking the time to reply.  I agree with what you and Chris said, and at this point, I think I'll accept that I can't know everything, and close this discussion out.

 

Thanks!

 

Drew