parallel for loop order

[Intaris]

Quick Q on a Friday afternoon,

how is the order of processing for a parallel loop defined?

I had thought that with a 4-process parallel for-loop that the first four array entries (data as input in an auto-index tunnel) processed would be 0,1,2,3 but it seems to be 0, 1*N/4, 2*N/4 and 3*N/4 where N is the size of my input autoindex array.

I wanted to construct a parallel for loop which waits on data in a queue but the order gets scrambled this way.  There are workarounds but I'd like clarification on the operation first before I program something unneccessary.

Shane.

[Andrey_Dmitriev]

Hi, Shane,

As far as I can understand, its not defined (and should be not defined). The compiler will does it on better way (from compiler's point of view).

Loop iterations should be absolutely independent (this is rule for parallel for loop), therefore execution order doesn't matter. If its critical for you, then it means, that you have dependencies between iterations, and cannot use parallel loop (or should found your own solution for parallelizing).

Andrey.

[Intaris]

Andrey,

my problem isn't with the EXECUTION order, it's more the order in which the DATA passed to the Loop is accessed.

I don't have any interdependencies between my data but I'm trying to do something out of the box.

I want a parallel for loop to spawn 4 processes which will each wait for an IMAQ image to arrive (I know the total number of image sin advance).  I need a waiting function since the images aren't present when the loop starts.  By passing a single Queue reference and dequeuing from it works fine but if I give in a Queue reference for EACH image then it seems that the parallel loops are waiting for data in the wrong queues, if you know what I mean.

Shane

[Mark_Yedinak]

A good rule of thumb is to only have a single task dequeueing data. It avoids issues associated with multiple listeners and who is processing what data. However, in your case if you simply want to process images in parallel, but aren't concerned with which task processes which image, you could use a single queue to pass the images. The parallel tasks will all be waiting on the queue and one of them will grab the first image posted. While it is processing it a second task will grab the second image and so on. This is one case where it would be OK to have multiple listeners on a single queue. You do have to provide a clean way to stop all of the processes. You may have to experiment a bit with since. I haven't played with parallel for loops much at this point so I am making some assumptions as to how they work.

[Intaris]

Stopping the loops is easy.  Destroy the input queue and the rest of the iterations free-wheel until they're finished.

I know it works fine with a single queue, but I was aiming for an extra level with being able to actually retain the order of images and results.  This could (in some circumstances) get around having to re-order the output array after processing.

I have managed (in a quick mock-up) to force the order of execution using a queue for EACH loop iteration but it's ugly.

Shane.

[mfletcher]

Andrey is right -- you shouldn't have any expectations about the order that the iterations execute in. It sounds like you want iterations 0 to 3 to be processed first, and LabVIEW doesn't make any guarantees about that. In fact, we may make the order that the iterations are executed in less predictable in future versions.

What you observed in LV 2009 is expected, though. Each parallel instance executes one contiguous chunk of iterations, so with your loop, instance 0 executes iterations 0 to (1*N/4 - 1), instance 1 executes iterations (1*N/4) to (2*N/4 - 1), and so on. (You can see this behavior through the example in examples\general\parallelfor\Parallel For Loop Iteration Order.vi.) Do not write code relying on this behavior, as it may change.