Aborting a parallelised for loop

[scwimbush]

Please note that this question is about a single for loop configured to run in parallel (per the image following). It is not about multiple loops running together.

When I have a process that may take a long time to complete, I like to offer the user a means to abort it. They may have initiated it accidentally, they may change their mind partway through, they may realise they have given it the wrong parameters, or it may have some fault (either in the code or in user-supplied parameters) that means it will never complete, or will take months, or will consume all available resources and crash.

In a computation that takes place in a regular for loop, I achieve this using the (optional) conditional terminal to break out of the loop. However, in a parallelised for loop, this terminal is not permitted because some of the later parallel iterations will have completed at the point it is terminated.

It seems to me there is still value in being able to break out of a parallelised loop, i.e. having a global conditional terminal. For purely calculational loops, it would also be possible to simply throw away any subsequent iterations, regardless of whether they had already been calculated or not. This would allow the early completion of some classes of calculation. The presence of nodes within the loop already generates a warning that they may cause side effects, which would be the worst that would happen if a loop terminated prior to an already-executed iteration. Am I overlooking some deeper problem? Is there any other way to achieve my aim?

[altenbach · Accepted solution]

All you need is a small action engine that acts as critical section and bypasses the heavy lifting in the parallel FOR loop if needed. If abort is true, each iteration only executers an empty case.

(EDIT: slightly improved code attached)

[scwimbush]

Thank you. That should do what I need.

It does seem as though empowering the (otherwise unused but confusingly available) conditional terminal of the parallel loop to implement something similar at a lower level would be intuitive and save quite a bit of coding. But possibly there are complications I'm still overlooking.

[rolfk]

There are indeed several complications. Paralleiztion does not let each parallel chunk work on the array in an interleaved way. It rather gets many subsets of the array (which usually are quite a bit larger than one element) and passes them to the various code chunks. Each parallel chunk runs in its own thread and may or may not get a lot of chance to crunch on the data. So there is a decision to be made. To small data chunks cost extra overhead for management, to big ones could run in the situation that all but one parallel thread are long finished with their work while having to wait for the last before the loop can finish, which could destroy much of the advantage of parallel threads.

Aborting in the middle somewhere would make the whole even more complicated and trying to determine where to cut the data when that loop creates an output array could be pretty involved, easily ending up with an almost empty array.
Considering that LabVIEW existed for about 20 years without a conditional loop terminal at all, I never felt bad about the missing conditional option in parallel loops. 😀

[altenbach]

Just some further comments on my solution above

I have a relatively old fitting program that takes great advantage of parallelization. It scales well with the number of cores.

Here, the abort engine is actually read inside the fitting model subVI. It gets written when the user hits the <esc> key, causing the model to return with error  43. ("Operation canceled by user") and stops the parallelized process similar to shown above. Once the fitting completes  (with error), the signal needs to be reset in the main VI.