Race Condition

This is an undesirable state in computer programming when two separate logical processing threads complete tasks in an unpredictable order.

If a computer program only has one thread of execution, a race condition cannot happen. However, when a second thread is introduced, the two threads might interact with shared resources in an order that can’t be predicted and that leads to an undesirable state.

For example, Thread 1 checks a variable and intends to do Action X if the variable is certain value. However, in between checking the variable and taking the action, Thread 2 changes the variable to something that would lead Thread 1 to not execute the action. Since Thread 1 doesn’t recheck the value (why would it?), it executes Action X anyway.

The name comes from the metaphor of the two threads being in a “race,” the outcome of which leads to some condition or action, and we cannot predict who will “win.”

The problem doesn’t have to be literal threads in the same process. It could be two separate programs, for example. Any situation where the timing of completion of more than one computing processes can potentially lead to an undesirable state – this is a race condition.

One of the problems in debugging race conditions is that you can’t predict them. Thread 1 might “win” in some situations, and there’s no way to predict this. It appears entirely random (but, in reality, it’s likely dependent on some underlying unpredictable condition, like the CPU load or something).

Why I Looked It Up

Just got to wondering one day. I was a little surprised to find out that it’s the name for a very general scenario, and not something more specific around concurrent computing.