Single call of "Open VI Reference" loads multiple clones of reentrant VI?

[RSteinbrück]

Fideling around with asynchronously calling reentrant VIs I observed following effect: after a single call of "Open VI Reference" with option "x40" (simultaneous reentrant calls) 5 clones of the reentrant VI to call showed up in the LabVIEW Taskmanager. This is easy to reproduce using the "Asynchronous Call and Collect" example shipped with LabVIEW:

- Change the order of elements in the "Pass option 0x40?" array on the left.

- Insert a breakpoint right after the call of "Open VI Reference"

- open "LabVIEW Task Manager"

- run the VI and refresh Task Manager view (F5)

I tested it with LV2014SP1 and LV2016 with the same result.

I'm curious, if this is wanted behaviour!? First I thought LV loads a bunch of clones for performance reasons. However a second call to "Open VI Reference" while the first asynchronously called VI is still running doesn't make use of the clones already in memory, but brings up another 5 of them.

In contrast using "Open VI Reference" with the old school option "x08" and the "Run VI"-InvokeNode only a single clone appears in the task manager.

[Labuser16383]

Maybe the Task Manager isn't up to date??? You pass 10 for the number of loop iterations and the number of 5 called reentrant vi's seems very arbitrary here.

That's why i would suspect other things than the labview code.

[RSteinbrück]

As described the VI-Execution is stopped at the breakpoint. The "Populate Asynchronous Call Pool" InvokeNode is not executed yet, hence the "10" has no influence on the state observed with the task manager. And the number of 5 clones seems to occur always. First time I observed it in a completely different project. The standard example is only mentioned to reproduce the effect.

I use the latest version of the taskmanager. Of course I can not exclude that it might show something wrong. But there is some evidence that realy 5 clones are loaded. When I open a frontpanel of the called reentrant VI it shows the clone name in the title: VI_name.vi:[sequential number]. And this sequential number raises in steps of 5 when using the "Start Asynchronous Call" Node.So in the end only one of the clones seems really to be executed.

I just want to be sure, that the other "ghost" clones do not waste any memory.

[nathand · Accepted solution]

Do you have a 4-core processor? I suspect this note in the help for the Asynchronous Call Pool partially explains what you're seeing: "For each VI reference, LabVIEW creates one data space in the asynchronous call pool for each CPU core on the target computer." I assume you don't have 5 cores, so I'm not sure what the 5th clone is but if you were really curious to figure it out I'd try removing the static VI reference and replacing it with a path to the dynamically-called VI.

[JÞB]

I suspect Nathand is completely correct.  Clone 1 is likely the Vi ref for type, create a shell with the correct connector pane and wiring for type and see if it goes away to investigate that yourself.

With a constant 10 wired to the N terminal you really should be using the preallocate clones method (see the example finder for examples)

And yes, a second call to open vi ref SHOULD pre-allocate a new batch of clones at 1/core.  You asked for a new clone batch rather than passing in a ref to the existing pool.  test that by selectively closing the refs from the two open vi ref calls and see which batch goes away (Deallocate memory may be needed to force clean-up)

[RSteinbrück]

@Nathand: Thanks for the docu link, the "Asynchronous Call Pool" docu really explains the main reason of my question! Usually I'm reading documentation carefully, but I missed that part! I just did not expect the "Open VI Reference" Node to populate the "Asynchronous Call Pool".

Since my PC has 4 cores, there is only the fifth clone still to be explained - even though this single clone doesn't really matter if one uses the call pool correctly. I replaced the Static VI Reference by the VI path. But this did not change anything.

@Jeff·Þ·Bohrer: Sorry but what do you exactly mean by: "create a shell with the correct connector pane and wiring for type"? I created an empty VI with a type specifier input and called it with a type specifier constant connected to this input. In this case no clone appeared in the task manager.

[nathand]

---

@RSteinbrück wrote:

I created an empty VI with a type specifier input and called it with a type specifier constant connected to this input. In this case no clone appeared in the task manager.

---

That's exactly what Jeff suggested, so you understood him correctly. Your test indicates that placing a static VI reference on the block diagram creates a clone, even though in this case the clone is used only to define the connector pane. This seems like something that happens in the development environment but could get optimized out when building an application, although I don't know if that actually happens.

EDIT: After a re-read I realized I misunderstood what you wrote. What Jeff suggested that you do is create a new VI with an identical connector pane to the one you're calling dynamically, and use that as the type specifier input to Open VI Reference.  Creating a constant for the type specifier should have the same effect, and maybe that's what's already done in the example VI (I can't tell from the screenshot if the type specifier is linked to a VI, but if it is, try removing that link).

[RSteinbrück]

Thanks again for your answers, that answered my question!