Race hazard

A race hazard or race condition is a flaw in a system or process whereby the output of the process is unexpectedly and critically dependent on the sequence or timing of other events. The term originates with the idea of two signals racing each other to influence the output first.

Race hazards can occur in poorly-designed electronics systems, especially logic circuits, but they can and often do also arise in computer software.

In Asynchronous Finite State Machines

Even after ensuring that single bit transitions occur between states, the asynchronous machine will fail if multiple inputs change at the same time.

Solution: Design a machine so that each state is sensitive to only one input change.

Types

Static Race Hazards : These are caused when a signal and its complement are combined together.
Dynamic race Hazards : These result in multiple transitions when only one is intended. They are due to interaction between gates (Dynamic race hazards can be eliminated by using not more than two levels of gating).
Essential Race Hazards : These are caused 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.

Electronics

A typical example of a race hazard may occur in a system of logic gates, where inputs vary. If a particular output depends on the state of the inputs, it may only be defined for steady-state signals. As the inputs change state, a finite delay will occur before the output changes, due to the physical nature of the electronic system. For a brief period, the output may change to an unwanted state before settling back to the designed state. Certain systems can tolerate such glitches, but if for example this output signal functions as a clock for further systems that contain memory, the system can rapidly depart from its designed behaviour (in effect, the temporary glitch becomes permanent).

For example, consider a two input AND gate fed with a logic signal X on input A and its negation, NOT X, on input B. In theory, the output (X AND NOT X) should never be high. However, if changes in the value of X take longer to propagate to input B than to input A then when X changes from false to true, a brief period will ensue during which both inputs are true, and so the gate's output will also be true.

Proper design techniques (e.g. Karnaugh maps—note, the Karnaugh map article includes a concrete example of a race hazard and how to eliminate it) encourage designers to recognise and eliminate race hazards before they cause problems.

As well as these problems, logic gates can enter metastable states, which create further problems for circuit designers.

See critical race and non-critical race for more information on specific types of race hazards.

Computing

Race hazards may arise in software, especially when communicating between separate processes or threads of execution.

Here is a simple example:

Let us assume that two threads T1 and T2 each want to increment the value of a global integer by one. Ideally, the following sequence of operations would take place:

Integer i = 0;
T1 reads the value of i into a register : 0
T1 increments the value of i : (current value of i) + 1 = 1
T2 reads the value of i into a register : 1
T2 increments the value of i : (current value of i) + 1 = 2

In the case shown above, the final value of i is 2, as expected. However, if the two threads run simultaneously without locking or synchronization, the outcome of the operation could be wrong. The alternative sequence of operations below demonstrates this scenario:

Integer i = 0;
T1 reads the value of i into a register : 0
T2 reads the value of i into a register : 0
T1 increments the value of i : (current value of i) + 1 = 1
T2 increments the value of i : (current value of i) + 1 = 1

The final value of i is 1 instead of the expected result of 2.

For another example, consider the following two tasks, in pseudocode:

global integer A = 0; task Received() { A = A + 1; print "RX"; } task Timeout() // Print only the even numbers { if (A is divisible by 2) { print A; } }

task Received is activated whenever an interrupt is received from the serial controller, and increments the value of A.

task Timeout occurs every second. If A is divisible by 2, it prints A. Output would look something like:

0 0 0 RX RX 2 RX RX 4 4

Now consider this chain of events, which might occur next:

timeout occurs, activating task Timeout
task Timeout evaluates A and finds it is divisible by 2, so elects to execute the "print A" next.
data is received on the serial port, causing an interrupt and a switch to task Received
task Received runs to completion, incrementing A and printing "RX"
control returns to task Timeout
task timeout executes print A, using the current value of A, which is 5.

Mutexes are used to address this problem in concurrent programming.

In filesystems, File locking provides a commonly-used solution. A more cumbersome remedy involves reorganizing the system in such a way that one unique process (running a daemon or the like) has exclusive access to the file, and all other processes that need to access the data in that file do so only via interprocess communication with that one process (which of course requires synchronization at the process level).

In networking, consider a distributed chat network like IRC, where a user acquires channel-operator privileges in any channel he starts. If two users on different servers, on different ends of the same network, try to start the same-named channel at the same time, each user's respective server will grant channel-operator privileges to each user, since neither server will yet have received the other server's signal that it has allocated that channel. (Note that this problem has been largely _timestamping_vs._nick.2Fchannel_delay_protocol by various IRC server implementations.)

In this case of a race hazard, the concept of the "shared resource" covers the state of the network (what channels exist, as well as what users started them and therefore have what privileges), which each server can freely change as long as it signals the other servers on the network about the changes so that they can update their conception of the state of the network. However, the latency across the network makes possible the kind of race condition described. In this case, heading off race conditions by imposing a form of control over access to the shared resource—say, appointing one server to control who holds what privileges—would mean turning the distributed network into a centralized one (at least for that one part of the network operation). Where users find such a solution unacceptable, a pragmatic solution can have the system 1) recognize when a race hazard has occurred; and 2) repair the ill effects.

A race condition exemplifies an anti-pattern.

A particularly poignant example of a race condition was one of the problems that plagued the Therac-25 (a Life-critical system) accidents. Another example is the Energy Management System used by Ohio-based FirstEnergy Corp., that had a race condition in the alarm subsystem; when three sagging power lines were tripped simultaneously, the condition prevented alerts being raised to the monitoring technicians. This software flaw eventually led to the North American Blackout of 2003.

Computer security

A specific kind of race condition involves checking for a predicate (e.g. for authentication), then acting on the predicate, while the state can change between the time of check and the time of use. When this kind of bug exists in security-conscious code, a security vulnerability called a time-of-check-to-time-of-use (TOCTTOU) bug is created.

Examples

Injuries and fatalities caused by the Therac 25 medical linear accelerator treatment machine, partially caused by a race condition between the equipment setup and user interface software routines.

External links

Article "Secure programmer: Prevent race conditions—Resource contention can be used against you" by David A. Wheeler
Chapter "Avoid Race Conditions" (Secure Programming for Linux and Unix HOWTO)
Citations from CiteSeer

Security exploits | Anti-patterns | Concurrency | Programming bugs

Gourt Home::Gourt :: Race hazard