More Specific Execution State of VI Reserved for Execution (is it actually running?)

[KarstenT]

I would like to use this pattern for launching an asynchronous VI:

The specific use case here is to run a specific subVI, but not have to wait for the subVI to complete (i.e. to launch a daemon-like VI).

There are a few advantages to this method:

1) The Static VI reference makes it very easy to open the VI that is being "launched" and make changes.

2) If I change the connector pane of the Asynch VI, the Asynchronous Call By Reference Node updates or indicates that I broke something (like a regular subVI would).
3) The Asynch VI is automatically included in deployed code (exe's, TestStand deployments), because of the Static VI Ref.

The main problem I have is that I can't determine at run time if the VI is already running or not.  That's because the Static VI Reference causes the Asych VI to be "Reserved for Execution" when my launcher VI runs, and always report "Running" for the Execution State.  In the case structure above, I can't take meaningful action based on the ExecState (like don't run if already running), because the returned value is always running.

This idea proposes that the Execution State property (or some new similar property) be expanded to truly tell us whether a VI is actually running or not (regardless of whether it is a subVI, or reserved for execution somewhere).  Since the "Run" button is capable of showing this difference, there ought to be a way to programmatically access that state information.

[tst]

I was sure that was already suggested, but the only thing I can find is this, which only mentions this as a side point - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Need-a-way-to-visualize-VI-call-chain-hierarchy/idi-p/...

That said, for your specific use case, I think a better option would be if we could simply configure the ACBR node to run a static VI directly and have it do all the management behind the scenes on its own. What I was thinking of was something like the Call Setup dialog you can open today for subVI calls, which essentially allows you to wrap the subVI directly in a CBR node. This could probably work as simply another option in that dialog.

Incidentally, I'm not sure why you're checking the state. Since it's a static daemon, I expect you're only running it in one place and thus you can reasonably expect that it would be idle. My suggestion above is only meant to simplify the code necessary to launch such a daemon to a single node.

[AristosQueue (NI)]

As you note, the C code behind the scenes does have a fifth state for "reserved" that is different from "running". We deliberately filter the "Reserved" state from the VI and merge it with the "Running" state before outputting from the property node.

The decision to do this was made a long time ago, before I was even at NI. I *think*, looking at sparse code comments, the reason for this is that it is generally unsafe to use the "Reserved" state to make any decisions about a VI unless you are the execution system of LabVIEW -- once a VI is reserved, it could start running anywhere. In your case, you would check for running and then decide to skip execution -- but between those two moments, the VI might finish running and be ready for you. Although fine in the simplest cases, generally that leads to undesirable race behavior as programmers stack assumption on assumption.

What you want is something like the "skip subroutine call if busy" property on a subroutine priority subVI. Set your subVI to be VI Properties >> Execution  >> Priority >> Subroutine. Then go to the caller VI, drop the subVI as a regular node, and pop up on the node to enable "skip subroutine call if busy".

This does not give you the async behavior you're seeking, but it is the other half of the puzzle and is probably more what you're wanting to see from this idea.

[KarstenT]

tst,

Good call with the link for the related idea.  I remebered reading that before, but couldn't find it.  Perhaps that idea and my idea as posted here focuses too much on a specific use case, and not on the short-comings of the Execution State property?  If you agree, I would consider re-writing the idea to be more focused.

The idea in your second paragraph seems reasonable. In my specific use case, I want the asynchronous "call and forget" properties of the ACBR node, but not the dynamic launching parts.  They are distinct in my mind.

---

tst wrote:

Incidentally, I'm not sure why you're checking the state. Since it's a static daemon, I expect you're only running it in one place and thus you can reasonably expect that it would be idle.

---

I don't see why this has to be true.  What if I want to access some functionality of the asynchronous VI in multiple places?  I would like to "call" that VI to get it running, but if it's already running, then I should skip the launch operation.

[KarstenT]

AQ:

Thanks for highlighting the race behavior of what I was trying to do.  I think that is a case that I was trying to work around but hadn't quite put my finger on.

[AristosQueue (NI)]

KarstenT: Probably better if you just have that VI continuously running and use a Notifier to give it instructions. In the VI, have it do Wait On Notification with "ignore previous" = True. That way the VI will ignore any instructions that came in while it was executing the previous instruction.

[SteenSchmidt]

Could a solution be to make the Exec.State "Run top level" instead of "Running" when called async, since the async callee isn't part of the caller's hierarchy anyway? I know there's an ACBRProxyCaller above it, but we could maybe ignore that in this case? If so then you could detect a difference between the callee VI being reserved ("Idle" or "Running") and actually running ("Run top level").

/Steen