Editing Dekker's algorithm (section)

== Notes ==
{{unreferenced section|date=May 2015}}
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 [[CPU]]s execute their instructions in an out-of-order fashion; even memory accesses can be reordered (see [[memory ordering]]). This algorithm won't work on [[Symmetric multiprocessing|SMP]] machines equipped with these CPUs without the use of [[memory barrier]]s.

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 {{mono|wants_to_enter[0]}} and {{mono|wants_to_enter[1]}} 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 variable|volatile]] variables should be marked as modifiable outside the scope of the currently executing context. For example, in C, C++, C# or Java, one would annotate these variables as 'volatile'.  Note however that the C/C++ "volatile" attribute only guarantees that the compiler generates code with the proper ordering; it does not include the necessary [[Memory barrier#Out-of-order execution versus compiler reordering optimizations|memory barriers]] to guarantee in-order ''execution'' of that code. [[C++11]] atomic variables can be used to guarantee the appropriate ordering requirements — by default, operations on atomic variables are sequentially consistent so if the wants_to_enter and turn variables are atomic a naive implementation will "just work". Alternatively, ordering can be guaranteed by the explicit use of separate fences, with the load and store operations using a relaxed ordering.