Misplaced Pages

Race condition: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 02:45, 24 January 2005 editSimonP (talk | contribs)Administrators113,128 editsmNo edit summary← Previous edit Revision as of 02:21, 30 March 2005 edit undoPedant17 (talk | contribs)5,619 edits editingNext edit →
Line 1: Line 1:
A '''race hazard''' (or '''race condition''') is a ] in a system or process where the output exhibits unexpected critical dependence on the relative ] of ]s. The term originates with the idea that two ]s are racing each other to be the first to cause the ]. A '''race hazard''' (or '''race condition''') is a ] in a ] or process where the output exhibits unexpected critical dependence on the relative ] of ]s. The term originates with the idea of two ]s racing each other to influence the ] first.


Race hazards are found in poorly designed ] systems, especially ] ]s, but they may also arise in ] ]. Race hazards occur in poorly-designed ] systems, especially ] ]s, but they may also arise in ] ].


==Electronics== ==Electronics==


A typical example of a race hazard is in a system of ]s, where inputs are changing. 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, there is a finite delay before the output will change, 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. For many systems, such '']es'' can be tolerated, but if for example this output signal is used to act 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). A typical example of a race hazard may occur in a system of ]s, 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 '']es'', 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, there will be a brief period during which both inputs are true, and so the gate's output will also be true. 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. ]s - note, the Karnaugh map article includes a concrete example of a race hazard and how it can be eliminated) ensure that race hazards are acknowledged and eliminated before they can become a problem. Proper design techniques (e.g. ]s - note, the Karnaugh map article includes a concrete example of a race hazard and how to eliminated it) encourage designers to recognise and eliminate race hazards before they cause problems.


As well as these problems, it is possible for logic gates to enter ]s, which create further problems for circuit designers. As well as these problems, logic gates can enter ]s, which create further problems for circuit designers.


==Computing== ==Computing==


Race hazards may arise in software, especially when communicating between separate processes or threads of execution. For example, if one ] 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. Race hazards may arise in software, especially when communicating between separate processes or threads of execution. For example, suppose one ] writes to a file at the same time that another process reads from the same location. The data reader may get 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 hazard is ]ing; a more cumbersome remedy is to reorganize the system such that a certain process (running a ] 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. ]ing provides a commonly-used solution for this kind of race hazard; a more cumbersome remedy involves reorganizing the system in such a way that one unique process (running a ] 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.


As an example of a more subtle kind of race hazard, consider a distributed chat network like ], 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. As an example of a more subtle kind of race hazard, consider a distributed chat network like ], where a user aquires 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.


In this case of a race hazard, the "shared ]" 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 ] 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, a pragmatic solution is to have the system recognize when a race hazard has occurred and to repair the ill effects. In this case of a race hazard, the concept of the "shared ]" 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 ] 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 is an example of an ]. A race condition exemplifies an ].


==See also== ==See also==

Revision as of 02:21, 30 March 2005

A race hazard (or race condition) is a flaw in a system or process where the output exhibits unexpected critical dependence on the relative timing of events. The term originates with the idea of two signals racing each other to influence the output first.

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

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 eliminated 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.

Computing

Race hazards may arise in software, especially when communicating between separate processes or threads of execution. For example, suppose one process writes to a file at the same time that another process reads from the same location. The data reader may get the old contents, the new contents or some mixture of the two -- depending on the relative timing of the read and write operations.

File locking provides a commonly-used solution for this kind of race hazard; 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.

As an example of a more subtle kind of race hazard, consider a distributed chat network like IRC, where a user aquires 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.

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.

See also

External links

Category: