Question about race conditions

[SteveChandler]

I am part of a large inherited LabVIEW application that does some very important tests. The code is full of global and local variables and it would make anybodies head spin. There are globals writing to locals which write to other locals for example There are a lot of stacked sequence structures that would avoid some otherwise possible race conditions. But still. The code is fragile and I am obviously terrified of making any changes to it.

It seems logical that if there is a close race condition you can easily and inadvertently change who wins the race by anything that recompiles the code. Resizing a control or straightening a wire bend requires a recompile. Recompiling under a different version of LabVIEW makes major changes to the object code due to different compiler optimizations. Even running the same installer on a different version of the OS seems like it could influence who wins the race condition.

This brings me to my question. Are my assumptions and statements above correct? Specifically: Can even cosmetic changes to code with race conditions change how the program behaves?

[smercurio_fc]

Can it happen? Probably yes. I have seen code behave differently from one compilation to another. This was seen when running the code in highlight execution mode.

Will it happen? Likely no. I say this primarily because it's unlikely that an inherent race condition will be triggered simply because you moved an icon around or straightened a wire. The LabVIEW compiler is not that "touchy". The race condition exists because the order is indeterminate to begin with, not because of the way it was compiled. While it's true that a certain compilation may prevent the race condition from occurring, that doesn't eliminate its existence - it only eliminates its probability of burning you in this particular instance. Things like constant folding and parallel processing may make part of the diagram work a little faster, which could increase the probability of getting burned by the race condition.

It would be real cool if we had a "labview.exe -compile -magicallyWorkAroundRaceConditions myproject.proj" option, though.

[ErnieH]

I have seen it happen when updating. A Vi with a race condition that worked fine for years. This particular one was a local in parallel with another sequence statement. He had the input through the local into the structure. Adding a sequence structure to force the sequence fixed it.

[Darin.K]

I don't think anybody would suggest that the code is well-written, but I have found in many cases that LV is fairly (and even surprisingly) deterministic.  This means that you can have race conditions, but fortunately the winner is always the same.  (Perhaps that should be unfortunately since that is part of what makes them so hard to spot).

You mention locals and globals.  I find that locals (never use globals) are surprisingly robust (it terms of being deterministic).  Due to years of abuse, it appears NI has put a lot of effort into making them efficient despite the best efforts of the users.  I have come across many more problems due to Property Nodes.  They have to compete for the UI thread so it is easy to get non-deterministic behavior depending on the level of UI activity.  If I see a lot of Value PNs floating around (especially without error wiring) then I get nervous.

Kind of makes me miss the good, old single threaded days when I could count on left-to-right execution.  Maybe not.

I would much more worried about the agility of your code than the fragility of it.