10

I'm a new electrical engineer so bear with me. I hear some of the other engineers I work with talk about a race condition that exists in one of our circuits.

What does that mean?

Stihl Alighve
  • 238
  • 1
  • 6

3 Answers3

16

It means, very simply that two things at the same time "race" for the result.

An example is a circuit with a Reset and a Set pin, if you trigger the reset, the output becomes 0. If you trigger set, the output becomes 1. If you first trigger set and then reset very, very quickly after it, reset will be seen, so the output is 0.

But, if they are both triggered at the exact same time, what happens?

If the circuit designer paid attention, there should be an answer, if that's important to the function. If there is no certain answer to that question, the circuit has a race condition, where the signal from the set and the reset "race" each other to see which one wins to determine the output.

The path with the least delay will usually win, but then you could see the race condition as the exact trigger in which the most delayed path is triggered exactly that much before the quicker one.

Many circuits, including logic building blocks inside ICs, have certain race conditions, but usually they are such that when you use the circuit the way it is intended, that you will not notice. So often when engineers say "race condition" out loud a couple of times they actually mean that it is also one that could happen in normal use, which would be a problem, because in a race condition normal operation cannot be predicted.

In software the term is also used, but often to indicate timing problems, or lock-ups. It is a similar principle, though. Often when you have two processes in a computer running independently, but using the same memory you protect that memory from being written by one, while the other is using it. If you don't they call that a possible race condition: One process could be reading a value that is just in the process of being updated, or both could be writing to it at the same time and then you don't know what will happen.

Asmyldof
  • 18,389
  • 2
  • 34
  • 53
  • 2
    As an addition to this good answer, I would point out that hardware can behave very poorly in these situations. Real hardware never switches instantaneously from 0 to 1. It always has to rise over a short period between them. Most logic assumes that enough time has passed since such a transition that the transients have resolved to either "really close to 0" or "really close to 1." If the timing is... unfortunate, it can be closer to 0.5. Many circuits become "metastable" in this state, meaning they can take an undetermined amount of time to transition, destabilizing the whole circuit – Cort Ammon Jun 27 '15 at 22:51
  • 1
    Even if your circuit is designed to handle the case where Set and Reset are activated simultaneously, you can't reliably activate them simultaneously, so you won't know which one is activated first. – user253751 Jun 28 '15 at 02:14
  • Non-atomic operations are a better example of race conditions in software. A program could create a new file using C's fopen(), write data to it, fclose() it, then chmod() it to secure it. That brief window between fopen() and chmod() opens a possible race condition where the default file mode could allow an unwanted outsider to work with the file in a way denied after the chmod() call. The solution is to create the file with open() instead, which allows setting the mode as part of the file creation operation. – Warren Young Jun 28 '15 at 18:27
6

The term "race condition" implies that (1) two or more signals may arrive in any order, arbitrarily close to each other, and (2) it is not possible to show analytically that there is essentially zero probability of any possible combination of arrival times posing a problem.

From the point of view of a single flip flop whose data input might change at any time with respect to the clock, near-simultaneous transitions on the clock and data inputs could pose a race condition. From the point of view of overall circuit behavior, however, they would not pose a race condition if they could only occur at times when no downstream circuity would care about what the latch held, and no downstream circuitry would start caring about what the latch held until after the arrival of a clock pulse which couldn't be anywhere near any transitions on the data input.

Further, because it's often not possible to absolutely completely eliminate all possibility of problematic input timings, many analyses of race conditions will say that if the output of one register is fed into another that is controlled by the same clock, the second register will always latch a "clean" high or a "clean" low even if the inputs to the first register caused it to capture an input level that was right at the switching threshold. In theory, it would be possible for the first latch to capture a level that was just enough above or below its exact switching threshold that the output level would switch precisely as the next clock pulse arrived.

As a consequence, if one were to e.g. take an input and pass it into a sequence of three flip flops, and have a circuit which output high whenever the second flop was high but the third one was low, then any rising edge which occurs on the data input which is preceded by a full clock period worth of low time, and followed by a full clock period of high time, would be essentially guaranteed to cause the circuit's output to be high for exactly one clock period.

schematic

simulate this circuit – Schematic created using CircuitLab

In this schematic, a signal with somewhat irregular timing is normalized to a clock in three ways in such a fashion as to generate an output that is high for one clock cycle after each rising edge. The first attempt to normalize the signal generates an output which is nasty looking, and has an obvious race condition if the input and clock change simultaneously. The second approach is a lot better, but still has a race condition (which the simulator can't trigger) if the timing of the clock and data causes the first register to capture an intermediate value. The third approach represents common practice, and would generally be considered safe, since even if the first register fails to capture a clean high or a clean low, it is very unlikely that the output from the first register would have exactly the right behavior to cause the second register to not grab cleanly. If the data changes very close to the clock, it may be grabbed on the current cycle, or not get grabbed until the next, but if either situation would be acceptable there is no race condition.

supercat
  • 46,736
  • 3
  • 87
  • 148
  • You said, "...an output that is nasty looking." Is that another way of saying "metastable state?" – Solomon Slow Jun 27 '15 at 21:27
  • @jameslarge: The simulator doesn't handle metastable states. I describe the first output as ugly because there's no minimum pulse width, and the second output as risky because of the possibility of metastable states. – supercat Jun 27 '15 at 21:46
2

In brief, it means the result of a process will be affected by the sequence of arrival of two inputs, and the that sequence is indeterminate (can not be guaranteed).

JRobert
  • 3,192
  • 14
  • 27