Aristos Queue Posted October 12, 2014 Report Share Posted October 12, 2014 Let me start by saying what I mean by "race condition": two processes (or threads or execution paths or <your favorite term here>) both simultaneously read some bit of data representing system state, then modify the system state accordingly, and when both are finished, the new state of the system depends upon which one executed first. That is a very broad definition. Most users know the trivial case: you have a global variable representing some sort of counter, and you have two processes, Alpha and Beta, both wanting to increment the value. If the starting value is "1", then the ending value is expected to be "3". The race occurs here: Process Alpha reads the counter: value =1. Process Beta reads the counter: value =1. Alpha adds 1 to the value it read and gets 2. Beta adds 1 to the value it read and gets 2. Alpha writes to the counter: value = 2. Beta writes to the counter: value = 2. Oops. But there can be much more subtle bugs. For example: Alpha is a Producer Loop Beta is a Consumer Loop Beta checks "Is the queue empty?" to decide whether it has finished processing all the data. At some point, Beta is just a bit faster than Alpha and the queue empties, so Beta decides to quit, thinking it is done with all the data. Alpha adds more items to the queue, but Beta never processes them. Race conditions are notoriously hard for users to catch. They have historically been just as hard for compilers to notice in all but the most trivial conditions. As the LabVIEW compiler has gotten better at its analysis over the years, I see some potential for the compiler to recognize when a bit of memory is potentially being used by multiple execution paths in "a race condition like manner". I'm using that deliberately vague term because the definition of what exactly constitutes a race condition may be part of the conversation here. If the LV compiler knows beyond a shadow of a doubt that some egregious behavior, such as an unprotected global VI or shared variable being used for read-modify-write in multiple execution paths, should LabVIEW break the VI? Is that a compiler error? Or is it something more like a coercion dot that should be highlighted but not ruled out? To put it another way: Are there race conditions that you have in code that are desirable conditions? Is that because it is just too hard to program the right way? Or do you have some where the correct program really is one where execution order should matter to program output? If the robot's right hand grabs the apple a microsecond before its left hand grabs the orange, are there cases where it is correct for that to affect which one it chooses to serve you for lunch? Quote Link to comment
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.