LabVIEW
Why is this vi broken?
I was doing some clean up of a reuse library when I found this gem.
Don't worry, I'll rewrite it and beat the performance myself but....
See that warning? Yup that is telling me that the loop can't actually run in parallel because "Trim Whitespace.vi" is Non-reenterant. Nice warning! it tells me I'm doing something silly. (remember, not my code)
So, since the loop cannot run parallel AND I am 'OR-ing' the loop boolean I said
"Hey, Jeff! (Yes, I do talk to myself) Just Jump out of the For loop when you know the output of "Or Array Elements" Has to be TRUE."
See, All I need is 1 TRUE value in the Array to get the output "Not Empty?" to be TRUE so I should not need to test the rest of the String Array Elements. This breaks the run arrow! WHY?
Source is in 2015SP1f10
Hi Jeff,
the error description is quite clear: conditional terminal is not allowed for parallel execution…
Remove the parallel execution of the FOR loop!
Hi Jeff,
maybe the "precompiler" only sees the "parallel loop setting" together with "conditional terminal" to set an error flag.
From a compiler point of view it is important when (at which iteration) the the FOR loop will "break" - and this might be undefined for conditions in parallel loop execution!
Just tested this on LV2017: I get the same error even without TrimWhitespace in the loop. I guess it's a basic precompiler check…
If the concern is that trim whitespace is slow, and you really have enough string elements to be worth the confusion, I *think* you can use a boolean shift register with a case structure that's empty on true to short circuit after one is found here?
I don't have a computer to check right now but my hope is it would be allowed...
Hi Jeff,
the code breaks because the conditional terminal is not allowed for parallized FOR loop. Point.
(Regardless of the remaining loop content, be it reentrant or not.)
Turns out shift register with case structure counts as a dependency between loop iterations (unsurprisingly) and so my idea doesn't work anyway.
Presumably the same argument is true in both cases: even if the output of the loop is unaffected, if the actions of one iteration can affect another they can't be split out and maybe favouring safety over performance gains in a few unusual cases was the choice (the help talks about specific cases in which it is allowed).
Sorry for the noise.
@JÞB wrote:
Why does it break the code? Why is it not a warning? What "Bad thing" could happen if more than one iteration returned a "True" by operating in parallel? I OR the output!
Well, the compiler team could add a transform that recognizes that you OR the array later and then allow the parallel loop, but currently a conditional terminal is not allowed, because the outcome is not predictable.
In a parallel FOR loop, iterations do not execute sorted in [i], but the value and size of the autoindexed array output critically depends on the order in which the iterations occur. For the same identical inputs, the array could have any size between 1 and N and could be different with every run of the VI.
Also the conditional terminal would have to be a critical section shared between all parallel instances, meaning that there is additional communication overhead that might nullify the parallelization advantage. If a termination condition occurs in iteration j, we would not know if there is an i<j that would also have terminated because some of these iteration might not have not executed yet
I think it is absolutely correct that conditional terminals are not allowed here. I would not want it any other way. 😄
