Abrupt crash when compiling with controls in parallel for-loop

[shoj]

Whenever I try to save or run my VI with a parallel for loop that contains a control as input to a subVI inside the loop, LabVIEW suddenly closes itself without throwing any errors. This only happens when parallelism is turned on for the loop and the maximum number of threads in the dialog is set to be > 1.

The Tools > Profile > Find Parallelizable Loops feature only gave a very generic warning for the loop: "- A node in the For Loop may have side effects." It actually gave several instances of this warning but did not say which nodes may cause the problem, and moving the control out of the loop prevented the crash and removed one instance of these warnings. As far as I can tell, the code runs fine when the control is moved out of the loop.

What was causing LabView 2009 to close itself when trying to compile the code? Also, are there any plans to add more detailed warnings to the "Find Parallelizable Loops" feature? Do these warnings necessarily mean that my code is not thread-safe (is that the correct term)? Each iteration of the loop should not depend on any other iterations as I've taken out shift registers, etc., but I still get these warnings.

[mfletcher]

The crash when a control (or indicator) is in a parallel for loop is a known issue that has been fixed.

You are getting a warning about having nodes with side effects because you have a subVI in the loop. It's possible the subVI does something that has side effects, like writing to a global variable or enqueueing an element to a queue. LabVIEW is conservative, so it gives that warning any time you have a subVI in a parallel for loop, even if the subVI doesn't have any side effects.

If you turn on warnings in the error list window, you will be able to tell which nodes are causing the warnings.

[mfletcher]

Controls also have side effects, since the state of the control changes when you write to it. (It isn't just data flow.) LabVIEW is probably warning you about the subVI node and the control in the loop.

[Hampden]

Can you direct me to the fix.  I have LV 2009 with SP1 and still get the crash on both 32 bit and 64 bit installations.

[JÞB]

Thinking about it -  parrallel loops don't necessarilly execute each iteration in order.  reading from a control inside a for loop could cause some odd conditions such as Value=x for i=(0,2,4,6,) and value =y for i (1,3,5,7...) if the execution order becomes (1,3,5,7,0,2,9,4,6,10,8,....) and the value is updated while i=0.  Odd behavior and good food for thought.

[mfletcher]

An issue where some For Loops with parallelism enabled containing indicators or controls crashed LabVIEW was reported as CAR 195945, and it was fixed in LabVIEW 2010.

Shoj and Hampden, can you attach your VIs, so I can confirm that this issue is fixed for your use cases?

Thanks,

Mary Fletcher

LabVIEW R&D