Race Condition
From CasGroup
| Line 1: | Line 1: | ||
| - | |||
A '''race condition''' can be defined as an anomalous behavior | A '''race condition''' can be defined as an anomalous behavior | ||
due to unexpected unexpected ordering of events and critical | due to unexpected unexpected ordering of events and critical | ||
| Line 14: | Line 13: | ||
in a [[Distributed System|distributed system]] may depend on the | in a [[Distributed System|distributed system]] may depend on the | ||
arrival order of two different contradictory messages, the first says | arrival order of two different contradictory messages, the first says | ||
| - | + | "maintain object", whereas the second says "release object", and the message | |
which arrives first - the winner of the race - determines the result. | which arrives first - the winner of the race - determines the result. | ||
A race condition can also occur when multiple processes access and manipulate | A race condition can also occur when multiple processes access and manipulate | ||
| Line 22: | Line 21: | ||
Race conditions are not only undesirable because the program doesn't | Race conditions are not only undesirable because the program doesn't | ||
work as it's supposed to do. In debugging they are also very undesirable, | work as it's supposed to do. In debugging they are also very undesirable, | ||
| - | because you have to | + | because you have to "run the race" many times before you can reproduce a |
situation which a certain fault, error or failure. The error may also | situation which a certain fault, error or failure. The error may also | ||
vanish if you slow the processes down by debugging the computation | vanish if you slow the processes down by debugging the computation | ||
step-by-step. | step-by-step. | ||
