|
|
race condition An error condition in which two signals or sets of data collide. It can take place within a chip, a circuit, a network or an application. It can be due to a timing malfunction in the hardware or poorly written software.
race condition [ ′rās kən‚dish·ən] (electricity) An ambiguous condition occurring in control counters when one flip-flop changes to its next state before a second one has had sufficient time to latch.
race condition - Anomalous behavior due to unexpected critical dependence on
the relative timing of events.
For example, if one process writes to a file while another is
reading from the same location then the data read may be the
old contents, the new contents or some mixture of the two
depending on the relative timing of the read and write
operations.
A common remedy in this kind of race condition is file locking; a more cumbersome remedy is to reorganize the system
such that a certain processes (running a daemon or the like)
is the only process that has 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.
As an example of a more subtle kind of race condition,
consider a distributed chat network like IRC, where a
user is granted 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 will
yet have received the other's signal that that channel has
been started.
In this case of a race condition, the "shared resource" is the
conception of the state of the network (what channels exist,
as well as what users started them and therefore have what
privileges), which each server is free to 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
be in charge of 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 this
is not acceptable, the more pragmatic solution is to have the
system recognize when a race condition has occurred and to
repair the ill effects.
Race conditions also affect electronic circuits where the
value output by a logic gate depends on the exact timing of
two or more input signals. 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, there will be a brief
period during which both inputs are true, and so the gate's
output will also be true. If this output is fed to an
edge-sensitive component such as a counter or flip-flop then
the temporary effect ("glitch") will become permanent. | |
Want to thank TFD for its existence? Tell a friend about us, add a link to this page, add the site to iGoogle, or visit the webmaster's page for free fun content. |
|