Achieving definite parallelism

[Ken_Brooks]

I need to parse several command files in parallel and merge the outputs, phase by phase. By way of developing my parallel architecture, I did a little experiment.

Strategy: 1. Launch several copies of the "parser"; for this experiment I'm using a random number generator.

2. Send a Notification to them all when it's time to begin a new phase. Each enqueues its output.
3. Collect the outputs in a loop and build an array of them. (For now, I'm using a timeout to terminate collection; in the real program there will be a more sophisticated approach.)

It isn't working. If I start with execution highlighting enabled, I see this. Only instances number 3 is running.

If I start, press the okay button a few times, and then enable execution highlighting, I see this. It would suggest that all four instances are running. But in fact it isn't true. I only ever see output from #3, and a conditional probe in ParaPortion as below if, conditioned on ID < 2, never fires.

So what do I need to do to make sure that four instances of ParaPortion are in fact running and can wait on my notifier all at the same time?

I'm open to all manner of suggestions on how to achieve the parallel feed that I need.

[altenbach · Accepted solution]

1. We are not good and debugging images. Do you have some actual code?
2. Is the subVI reentrant? (it should be!)
3. What's the point of the sequence structure (bottom image)?
4. Are you aware of the concatenating tunnel?

[billko]

I don't think you can simulate parallel execution in highlight execution mode.  (Is that true?  It's what I believe; please correct me if I'm wrong.)

[tyk007]

---

@billko wrote:

I don't think you can simulate parallel execution in highlight execution mode.  (Is that true?  It's what I believe; please correct me if I'm wrong.)

---

My understanding is that it forces execution to the VI to the UI thread (thus removing parallel opportunity). Not sure if that is still true in recent LV versions or called SubVIs.

[Yamaeda]

If OP wires the error out from the enqueue in ParaPortion (or what it was called) the 4 of them can be stopped by killing the queue, which should be done as you exit the event loop.

As Altenbach mentions, if the 4 VI's are reentrant it should work.

/Y

[altenbach]

---

@billko wrote:

I don't think you can simulate parallel execution in highlight execution mode.  (Is that true?  It's what I believe; please correct me if I'm wrong.)

---

I am pretty sure that's incorrect, except for the parallel FOR loop, which has a special mode for debugging and is otherwise just skipped in highlight mode.

[Ken_Brooks]

Reentrant: that was all it took. I wasn't aware that it took special configuration to make a VI reentrant.

I'm presuming that any subVI called by such a VI had better be reentrant as well?

[Bob_Schor]

---

@Ken_Brooks wrote:

I'm presuming that any subVI called by such a VI had better be reentrant as well?

---

That would be a "Yes".  [Several years ago, I failed to do this step, and wondered why things slowed down ...].

Bob Schor

[altenbach]

---

@Ken_Brooks wrote:

Reentrant: that was all it took. I wasn't aware that it took special configuration to make a VI reentrant.

I'm presuming that any subVI called by such a VI had better be reentrant as well?

---

By default a VI is shared by all instances on the diagram. This saves resources.

The answer to your second question is "it depends". If the subVI is inexpensive and returns immediately, it does not need to be reentrant. If it does most of the heavy lifting, it should be. Only you can decide. You might actually have a small action engine shared by all instances that acts as critical section and allows the main program to e.g. keep track of states and overall progress.