Preallocated Reentrant VI within Parallelized For Loop

[JÞB]

Exactly.  Simultaneous calls to vi clones needs the 40 flag. The 8 flag is equivalent to launching a vit and has extra overhead with the straight up Call async by ref ( both ins and outs)than a 140 flag ref to the same ACBR if the clone pool is smaller than the number of allocated clones since the exact clone instance is specified the pool manager just has to grab that clone rather than deciding if any clone is available first and going through the process of selecting one of the ones available.

The 8 flag works only because the via properties are preallocate clones. 140 makes the caller smaller on disk but about the same memory needed to run.  Run the profiler and metrics tools on all three approaches.  I'd love to see the results with debug disabled.

[nathand]

Jeff - my reading of the documentation is that Kevin has it right. The documentation says:

• If you use the 0x40 option flag to execute instances of a reentrant target VI in parallel, vi reference refers to the target VI rather than to a clone of the target VI. However, both the Call By Reference node and the Start Asynchronous Call node call a clone of the target VI. Therefore, if you call a VI Server property or method on vi reference, the property or method does not affect the clone VIs that those nodes actually call.

To me, this says when you use the 0x40 option, you don't get a reference to a specific instance of a clone, you get a reference to the underlying VI and then a call by reference either runs an available clone or creates a new one. Since Kevin needs a reference to a particular data space, I think he chose correctly.

EDIT: here's a pair of test VIs that demonstrate this. It calls Open VI Reference twice, then calls each reference in sequence. If the options are 0x08, you get two independent data spaces. If options are 0x40, there's only one, because the same clone is reused. Update the path for the VI reference before running.

[JÞB]

I can't wait to see your examples.  But if the calls are not serialized without the 40 flag that note 5 in the help link i specifically pointed to needs updates.  With out that flag no parallel operations.  

A simple equality test of the refnums proves they point to the same object and that is the reentrant original not any clone.  See circle 2 same cite.  

Really, opening one ref to the vi original and CBR in a loop would act almost the same but by opening the refs in a loop after declaring the pool size.  The CBR overhead should be reduced.  Flag 40 let's them run parallel. 

[JÞB]

I guess I should nugget that on top of Darren's nugget.  Darned confusing subject.

[nathand]

---

@JÞB wrote:

I can't wait to see your examples.  But if the calls are not serialized without the 40 flag that note 5 in the help link i specifically pointed to needs updates.  With out that flag no parallel operations.  

---

I don't see that anywhere. The 0x08 flag also gets you parallel operations, and has been around since long before the ACBR node.

---

Jeff·Þ·Bohrer wrote:

Really, opening one ref to the vi original and CBR in a loop would act almost the same but by opening the refs in a loop after declaring the pool size.  The CBR overhead should be reduced.  Flag 40 let's them run parallel. 

---

Is that the same? The refs out of the loop would all point at the same original VI, so if you were to run one of them, how would you know which clone instance would run? Since Kevin needs to know which clone instance is which, seems to me the 0x40 flag won't work.

[JÞB]

---

@nathand wrote:

---

@JÞB wrote:

I can't wait to see your examples.  But if the calls are not serialized without the 40 flag that note 5 in the help link i specifically pointed to needs updates.  With out that flag no parallel operations.  

---

I don't see that anywhere. The 0x08 flag also gets you parallel operations, and has been around since long before the ACBR node.

---

---

Read the darnerd help i linked it is stated exactly that way in notes And then read the whole thing then read the caveates linked in the notes....its there just not clear at a glance and duct tape may be needed (wrap it around your head first.  And take the analgesic of your choice  the 8 flag means open a rrf to a vi with specific properties other flags open refs to originals but ignore those properties.

---

 Jeff·Þ·Bohrer wrote:

Really, opening one ref to the vi original and CBR in a loop would act almost the same but by opening the refs in a loop after declaring the pool size.  The CBR overhead should be reduced.  Flag 40 let's them run parallel. 

---

Is that the same? The refs out of the loop would all point at the same original VI, so if you were to run one of them, how would you know which clone instance would run? Since Kevin needs to know which clone instance is which, seems to me the 0x40 flag won't work.

---

 Yes. Tottaly true.  The refs out of the loop are equal, point to the same object (reentrant original) and property and method nodes wired to them act on the original not the instances.  CBR or ACBR code must handle its own properties and methods see another reason I have my own dialog vit.  Of course, a queu notifier pair named ''vi clone instance" and data type "clone instance original" can be powerful when you really need to punch performance.

[nathand]

I think I see the confusion here. The 0x40 flag allows you to run multiple parallel instances using the same reference. A VI reference opened with the 0x08 flag will execute serially with regard to that reference, but multiple instances opened with the 0x08 flag can run in parallel.

The difference between the two is basically the difference between preallocating clones and shared clones. With the 0x40 flag, yes, you can pre-allocate a number of clones, but you can't guarantee that they'll all be used, or that each will be used exactly once, within a parallel for loop. With an array of references opened with the 0x08 flag, the programmer controls which instances executes when.

Picture the situation where you're calling the same short-running reentrant VI multiple times in parallel - normally, not dynamically - so you drop a bunch of copies on the block diagram. If the clones are set to preallocate, then you can open a separate front panel for each one, and each one maintains its state independently. If the clones are shared, when you open one of them you get the front panel for either the underlying VI (at edit time) or some random clone (at run time). You don't have any control over which instance executes which clone, or whether the same clone is used for multiple instances.

Now let's imagine the same situation with a dynamically-loaded VI. You open a bunch of references with the 0x08 flag, then you have a big index array function giving you access to each reference, which you run. That's the preallocated case. Or, you do this with the 0x40 flag. That's the shared clone case. Yes, you've "preallocated" the clones by opening references to them, but you don't know which clone gets run when. If one clone finishes before another has even started, the first one might get reused, regardless of how many copies of the reference were opened. That will never happen when the refs are opened with 0x08.

If we were making a movie, the 0x08 flag references would be named actors, and the 0x40 references would be anonymous extras. When you need a particular actor you'd use the 0x08 reference, whereas the 0x40 reference would simply say "get me anyone who's available to walk across the set."

Also, I believe you're mistaken about the 0x08 flag being equivalent to opening a VIT. A VIT has much more overhead than opening a clone, regardless of whether with the 0x08 or 0x40 flag, as explained here: https://lavag.org/topic/15640-asynchronous-call-takes-long-time-for-vit-files/#entry94545 It used to be necessary to open a VIT if you wanted multiple copies of a VIs front panel to be visible, but since it's now possible (since about LabVIEW 😎 to open the front panel of a clone, you no longer need a VIT for that purpose.

[Kevin_Price]

nathand,

That post really helped my understanding a lot.  I hadn't ever used the ACBR Start and Wait functions so I wasn't very familiar with the additional option flags 0x40, 0x80, 0x100.  As such, I didn't have an awful lot to add to the discussion but I *have* been following.

I still wish this could be done with simpler syntax as I tried to illustrate in reply #18.   (By the way, there's a reason that the reentrant function bears a striking resemblence to openG's "Periodic Trigger.vi"   I made a very similar function using the newish "High Resolution Relative Seconds" for better resolution but more importantly to correct an off-by-one error I observed in the openG version.)

-Kevin P

[James.M]

Thanks for all the discussion, guys! I think the solution, whether it's easy or not, involves multiple instances of a VI using a Run by Ref node.

Would someone please summarize the solution along with which correct option flags to use, so I can mark that as the solution?

[nathand]

---

Kevin_Price wrote:

I still wish this could be done with simpler syntax as I tried to illustrate in reply #18.

---

The simpler syntax way to do this is to pass the state information into the VI, rather than having the VI remember its state. Then you can use shared clones without any issues, and let LabVIEW determine how many instances to parallelize. Maybe that's not possible for some reason in your specific function, though.