Call by Ref Node and Rube Goldberg

[Daklu]

So today I was fiddling around with ways I might be able to start a vi in a parallel process while passing it data at the same time. Doing this always seems more complicated that it should be. One of my experiments ended in this:

I quickly realized that didn't do what I wanted, then after looking at it for a few seconds it dawned on me... I could accomplish the same thing with this:

Sometimes I deserve a slap in the forehead.

(Just in case I'm missing something... is there any advantage to using the first method as shown over calling the vi directly?)

[Aristos Queue]

(Just in case I'm missing something... is there any advantage to using the first method as shown over calling the vi directly?)

Not only is there NOT an advantage to the first over the second, there's a substantial advantage to the second over the first: Because LV knows exactly which VI will be invoked in the subVI model when the caller is compiled, we are able to do a better job reducing data copies*. Technically, we know which VI will be invoked in the second, but the compiler hasn't started constant folding such items at this time, mostly because the Call By Ref is generally not called with such static conditions, and spending time recognizing that diagram setup and optimizing it has been too much of a corner case to spend time on it given that users usually go directly for the solution of "just drop the subVI" in cases where we could apply the optimization.

* The next version of LV will improve the situation some, but there will still be overhead to the CBR compared to the subVI direct.

[shoneill]

So today I was fiddling around with ways I might be able to start a vi in a parallel process while passing it data at the same time. Doing this always seems more complicated that it should be. One of my experiments ended in this:

I quickly realized that didn't do what I wanted, then after looking at it for a few seconds it dawned on me... I could accomplish the same thing with this:

Sometimes I deserve a slap in the forehead.

(Just in case I'm missing something... is there any advantage to using the first method as shown over calling the vi directly?)

Maybe I'm missing something here but this isn't launching a parallel process at all......

It's launching a plain old serial object which must complete before execution of the case can continue....

Again, maybe I'm missing something here......

Shane.

[Daklu]

Maybe I'm missing something here but this isn't launching a parallel process at all......

No, you're not missing anything. Neither diagram accomplished my goal... I just thought it interesting how my fiddling led me to a somewhat abstract equivalent of dropping a sub vi on a block diagram. (Plus I wanted to double check that the two methods are essentially equivalent, minus the performance issues AQ mentioned.)

The only way I've been able to figure out how to pass parameters to a vi while launching a parallel process (thread, actually) is to wrap the sub vi in a by-ref framework such as a Single Element Queue.

[Michael Aivaliotis]

Use the Run VI method to launch a parallel process. If you need to pass data to the process, create a by-reference object and then the parallel process can access the data.

[Yair]

...Doing this always seems more complicated that it should be.

You're right. Go and vote this idea up and hopefully NI will implement it. There are actually a couple of other copies of that idea that people posted, but they all boil down to the same thing.