Race condition
The term race condition was already in use by 1954, for example in David A. Huffman's doctoral thesis "The synthesis of sequential switching circuits".
[1] Race conditions can occur especially in logic circuits or multithreaded or distributed software programs.
A typical example of a race condition may occur when a logic gate combines signals that have traveled along different paths from the same source.
[2] A practical example of a race condition can occur when logic circuitry is used to detect certain outputs of a counter.
If all the bits of the counter do not change exactly simultaneously, there will be intermediate patterns that can trigger false matches.
An essential race condition occurs when an input has two transitions in less than the total feedback propagation time.
Sometimes they are cured using inductive delay line elements to effectively increase the time duration of an input signal.
A race condition can arise in software when a computer program has multiple code paths that are executing at the same time.
Critical race conditions often happen when the processes or threads depend on some shared state.
The memory model defined in the C11 and C++11 standards specify that a C or C++ program containing a data race has undefined behavior.
[3][4] A race condition can be difficult to reproduce and debug because the end result is nondeterministic and depends on the relative timing between interfering threads.
Problems of this nature can therefore disappear when running in debug mode, adding extra logging, or attaching a debugger.
Ideally, the following sequence of operations would take place: In the case shown above, the final value is 2, as expected.
However, if the two threads run simultaneously without locking or synchronization (via semaphores), the outcome of the operation could be wrong.
The alternative sequence of operations below demonstrates this scenario: In this case, the final value is 1 instead of the expected result of 2.
The C++ standard, in draft N4296 (2014-11-19), defines data race as follows in section 1.10.23 (page 14)[6] Two actions are potentially concurrent if The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below [omitted].
[8] This means that in C++, an attempt to execute a program containing a data race could (while still adhering to the spec) crash or could exhibit insecure or bizarre behavior, whereas in Java, an attempt to execute a program containing a data race may produce undesired concurrency behavior but is otherwise (assuming that the implementation adheres to the spec) safe.
Formal memory models that provide such a guarantee are said to exhibit an "SC for DRF" (Sequential Consistency for Data Race Freedom) property.
[9] For example, in Java, this guarantee is directly specified:[8] A program is correctly synchronized if and only if all sequentially consistent executions are free of data races.
A program must be correctly synchronized to avoid the kinds of counterintuitive behaviors that can be observed when code is reordered.
By contrast, a draft C++ specification does not directly require an SC for DRF property, but merely observes that there exists a theorem providing it: [Note:It can be shown that programs that correctly use mutexes and memory_order_seq_cst operations to prevent all data races and use no other synchronization operations behave as if the operations executed by their constituent threads were simply interleaved, with each value computation of an object being taken from the last side effect on that object in that interleaving.
DRFrlx[12] provides a sketch of an SC for DRF theorem in the presence of relaxed atomics.
Race conditions are also intentionally used to create hardware random number generators and physically unclonable functions.
Two or more programs may collide in their attempts to modify or access a file system, which can result in data corruption or privilege escalation.
But eventually enough data may accumulate or enough other software may be added to critically destabilize many parts of a system.
Alternatively, each of those points can be equipped with error handling, or the success of the entire task can be verified afterwards, before continuing.
Race conditions were among the flaws in the Therac-25 radiation therapy machine, which led to the death of at least three patients and injuries to several more.
[19] GE Energy later developed a software patch to correct the previously undiscovered error.
[20][non-primary source needed] Dynamic analysis tools include: There are several benchmarks designed to evaluate the effectiveness of data race detection tools Neuroscience is demonstrating that race conditions can occur in mammal brains as well.
In at least one case, at Winwick in 1934, an accident occurred because the signalman accepted another train before the fireman arrived.
