Dekker's algorithm in Process Synchronization

Dekker’s Algorithm was the first correct solution to the critical section problem for two processes. It is significant in the history of operating systems because: 

• It avoids the drawbacks of naïve alternation (strict turn-taking).
• It uses only shared memory (Boolean flags and a turn variable).
• It ensures mutual exclusion, progress, and bounded waiting.

A process is generally represented as :

do {
//entry section
critical section
//exit section
remainder section
} while (TRUE);

The solution to the critical section problem must ensure the following three conditions: 

1. Mutual Exclusion
2. Progress
3. Bounded Waiting

Algorithm: It requires both an array of Boolean values and an integer variable:

var flag: array [0..1] of boolean;
turn: 0..1;
repeat
flag[i] := true;
while flag[j] do
if turn = j then
begin
flag[i] := false;
while turn = j do no-op;
flag[i] := true;
end;
critical section
turn := j;
flag[i] := false;
remainder section
until false;

Evolution of Dekker’s Algorithm

Dekker’s Algorithm was developed in five versions, each improving upon the previous one. Let’s analyze them:

1. First Version of Dekker's Solution

The idea is to use a common or shared thread number between processes and stop the other process from entering its critical section if the shared thread indicates the former one already running.

• Idea: Use a shared variable turn to decide whose turn it is.
• Execution: A process can enter only when turn matches its ID.
• Problem: If one process stops entering, the other may wait forever → No progress guarantee.

2. Second Version of Dekker's Solution

To remove lockstep synchronization, it uses two flags to indicate its current status and updates them accordingly at the entry and exit section.

• Idea: Each process uses a Boolean flag to show intent.
• Execution: A process enters and sets its flag; other process checks before entering.
• Problem: If preempted after setting flag, both may enter → Mutual exclusion violated.

3. Third Version of Dekker's Solution

To re-ensure mutual exclusion, it sets the flags before the entry section itself.

• Idea: Process sets its flag before entering waiting loop.
• Execution: Both cannot enter simultaneously, ensuring mutual exclusion.
• Problem: If both set flags at the same time, both wait forever → Deadlock possible.

4. Fourth Version of Dekker's Solution

Uses small time interval to recheck the condition, eliminates deadlock, and ensures mutual exclusion as well. 

• Idea: If conflict, one process resets its flag and retries after delay.
• Execution: Avoids deadlock by letting one back off.
• Problem: One process may repeatedly lose → Starvation (indefinite postponement).

5. Dekker's Algorithm: Final and completed Solution

Idea is to use favoured thread notion to determine entry to the critical section. Favoured thread alternates between the thread providing mutual exclusion and avoiding deadlock, indefinite postponement, or lockstep synchronization. 

• Idea: Combine flags (intent) + turn (priority).
• Execution: If both want to enter, turn decides who goes; after exit, turn is passed.
• Solution: Ensures Mutual Exclusion, Progress, and Bounded Waiting.

This version guarantees a complete solution to the critical solution problem.

Summary of Versions