Race situation
A race situation , from English also Race Condition ( German race condition ) or Race Hazard ( German race risk ), sometimes also "critical race situation", describes in the programming a constellation in which the result of an operation depends on the temporal behavior of certain individual operations or the environment. The term comes from the idea that two signals race to influence the output first. In general, there is the possibility of avoiding a race condition.
Unintentional race situations are a common cause of hard to find, non-deterministic bugs . It is characteristic of such situations that the changed conditions for the program test, such as additional logging or debug mode, can lead to a complete disappearance of the symptoms, see also Heisenbug . To avoid such constellations, semaphores , for example, can be used when creating the program .
example
Two systems running at the same time want to increase the same value. The necessary individual steps that each of the two systems must go through are:
- Read value : The value is read from the external memory into the internal memory.
- Increase value : The value is increased by 1 in the internal memory.
- Write value : The value is written back from the internal memory to the external memory.
Assume that the value is initially 1. The first system is called A, the second system B. If both systems increase the value, the expected new value is 3. If system A works before system B, it will also be:
| time | System A | Saved value | System B |
|---|---|---|---|
| 1 |
Reading in the value Value: 1 |
1 | |
| 2 |
Increase the internal value by one value: 2 |
1 | |
| 3 | Save the value | 2 | |
| 4th | 2 |
Reading in the value Value: 2 |
|
| 5 | 2 |
Increase the internal value by one value: 3 |
|
| 6th | 3 | Save the value |
If both systems work at the same time and the order of the commands is indeterminate, the race situation can lead to the fact that the new value actually received is 2 instead:
| time | System A | Saved value | System B |
|---|---|---|---|
| 1 |
Reading in the value Value: 1 |
1 |
Reading in the value Value: 1 |
| 2 |
Increase the internal value by one value: 2 |
1 |
Increase the internal value by one value: 2 |
| 3 | Save the value | 2 | Save the value |
To avoid the problem, A would have to block access to the value until the change has been completed so that B has to wait until A has finished accessing the value.
| time | System A | Saved value | System B |
|---|---|---|---|
| 1 |
Blocking against unauthorized access (if this is not possible: wait) |
1 | |
| 2 |
Reading in the value Value: 1 |
1 | Attempt: blocking against unauthorized access (as not possible: wait) |
| 3 |
Increase the internal value by one value: 2 |
1 | Waiting for approval ... |
| 4th | Save the value | 2 | Waiting for approval ... |
| 5 | Unlock | 2 |
Blocking against unauthorized access (now successful) |
| 6th | 2 |
Reading in the value Value: 2 |
|
| 7th | 2 |
Increase the internal value by one value: 3 |
|
| 8th | 3 | Save the value | |
| 9 | 3 | Unlock |
Individual evidence
- ^ Simon Hoffmann, Rainer Lienhart: OpenMP. An introduction to parallel programming with C / C ++. Online edition of the corrected reprint. Springer-Verlag, Berlin and Heidelberg 2009, p. 92 ( download via SpringerLink ).