it was ever stuck on it). After that it will set to true and settle down to waiting for to become false (since , it will never do the actions in the while loop). The next time p1 tries to enter its critical section, it will be forced to execute the actions in its loop. In particular, it will eventually set to false and get stuck in the loop (since turn remains 0). The next time control passes to p0, it will exit the loop and enter its critical section. If the algorithm were modified by performing the actions in the loop without checking if , then there is a possibility of starvation. Thus all the steps in the algorithm are necessary. Notes One advantage of this algorithm is that it doesn't require special test-and-set (atomic read/modify/write) instructions and is therefore highly portable between languages and machine architectures. One disadvantage is that it is limited to two processes and makes use of busy waiting instead of process suspension. (The use of busy waiting suggests that processes should spend a minimum amount of time inside the critical section.) Modern operating systems provide mutual exclusion primitives that are more general and flexible than Dekker's algorithm. However, in the absence of actual contention between the two processes, the entry and exit from critical section is extremely efficient when Dekker's algorithm is used. Many modern CPUs execute their instructions in an out-of-order fashion; even memory accesses can be reordered (see memory ordering). This algorithm won't work on SMP machines equipped with these CPUs without the use of memory barriers. Additionally, many optimizing compilers can perform transformations that will cause this algorithm to fail regardless of the platform. In many languages, it is legal for a compiler to detect that the flag variables and are never accessed in the loop. It can then remove the writes to those variables from the loop, using a process called loop-invariant code motion. It would also be possible for many compilers to detect that the turn variable is never modified by the inner loop, and perform a similar transformation, resulting in a potential infinite loop. If either of these transformations is performed, the algorithm will fail, regardless of architecture. To alleviate this problem, volatile variables should be marked as modifiable outside the scope of the currently executing context. For example, in C# or Java, one would annotate these variables