Subject: Operating System

Topic: PROCESS COORDINATION

Difficulty: Medium

A mutual exclusion (mutex) is a program object that prevents simultaneous access to a shared resource. This concept is used in concurrent programming with a critical section, a piece of code in which processes or threads access a shared resource.

Only one thread owns the mutex at a time, thus a mutex with a unique name is created when a program starts.

When a thread holds a resource, it has to lock the mutex from other threads to prevent concurrent access of the resource. Upon releasing the resource, the thread unlocks the mutex. Mutex comes into the picture when two threads work on the same data at the same time. It acts as a lock and is the most basic synchronization tool.

When a thread tries to acquire a mutex, it gains the mutex if it is available, otherwise the thread is set to sleep condition. Mutual exclusion reduces latency and busy-waits using queuing and context switches. Mutex can be enforced at both the hardware and software levels.

Disabling interrupts for the smallest number of instructions is the best way to enforce mutex at the kernel level and prevent the corruption of shared data structures. If multiple processors share the same memory, a flag is set to enable and disable the resource acquisition based on availability.

The busy-wait mechanism enforces mutex in the software areas. This is furnished with algorithms such as Dekker's algorithm, the black-white bakery algorithm, Szymanski's algorithm, Peterson's algorithm and Lamport's bakery algorithm.

Mutually exclusive readers and read/write mutex class codes can be defined for an efficient implementation of mutex.

Mutual Exclusion Conditions

If we could arrange matters such that no two processes were ever in their critical sections simultaneously, we could avoid race conditions. We need four conditions to hold to have a good solution for the critical section problem (mutual exclusion).

No two processes may at the same moment inside their critical sections.No assumptions are made about relative speeds of processes or number of CPU's. No process should outside its critical section should block other processes.

No process should wait arbitrary long to enter its critical section.

Peterson's Algorithm

This is a much simpler algorithm developed by Peterson. In a remarkable 1981 paper of less than two pages, Peterson developed and proved versions of his algorithm for both the 2-process case and the N-process case.

CONCEPT: The Dekker’s algorithm is a complex and tricky to prove method. Peterson provided a simple, elegant solution to it. Both the turn variable and the status flags are used, as in Dekker's algorithm. After setting our flag we immediately give away the turn. We then wait for the turn if and only if the other flag is set. By waiting on the and of two conditions, we avoid the need to clear and reset the flags. • Flag variable indicates position of each process with respect to mutual exclusion

• Turn variable resolves simultaneity conflicts.

• Consider P0. Once it has set flag[0] to true, P1 cannot enter the its CS. If P1 is in its CS, then flag[1] is true and P0 cannot enter CS.

• On the other hand, mutual blocking is prevented here.

• Suppose P0 is in its while loop. Then flag[1] is true and turn=1. P0 can enter its CS when either flag[1] becomes false or turn becomes 0

• Petersons algorithm is generalized to the case of n processes.

INITIALIZATION:

`typedef char boolean;

...

sharedboolean flags[n -1];

sharedint turn;

...

turn = i ;

...

flags[i] = FREE;

...

flags[j ] = FREE;

...

`

**ENTRY PROTOCOL** (for Process i ):

`
{

/* claim the resource */

flags[i ] = BUSY;

/* give away the turn */

turn = j ;

/* wait while the other process is using the resource *and* has the turn 

*/while ((flags[j ] == BUSY) && (turn != i ))

}

`

**EXIT PROTOCOL** (for Process i ):

/* release the resource */

flags[i ] = FREE;

ANALYSIS:

The mutual exclusion requirement is assured. Suppose instead that both processes are in their critical section.

Since only one can have the turn, the other must have reached the while test before the process with the turn set its flag.

But after setting its flag, the other process had to give away the turn. The process at the while test has already changed the turn and will not change it again, contradicting our assumption.

The progress requirement is assured. Again, the turn variable is only considered when both processes are using, or trying to use, the resource.

Deadlock is not possible. If both processes are testing the while condition, one of them must have the turn. That process will proceed.

Finally, bounded waiting is assured. When a process that has exited the CS reenters, it will give away the turn. If the other process is already waiting, it will be the next to proceed.