Process Synchronization & Mutual Exclusion

Sumit R Vijay Verma

Synchronization Concepts
In uniprocessor systems the only way concurrency is achieved is through interleavings of instruction
In that case ,an instruction executions of one process may affect those of other processes if the instruction executions reference the same piece of shared data

In multiprocess systems,programs execute and access data from their respective private address spaces.
From time to time ,they execute system call service routines from kernel space.

 The system call may access the same kernel data . Here also problems will arise because of concurrency .The operating system must ensure that process see consistent values of shared data .The data values must satisfy a priori specified integrity constraints

Race Condition
A situation where the outcome is unpredictable like in a race ,is called race condition It is also known as data race.A data conflict occurs when proccess access the same shared data concurrently and at least one modifies the data.

When the conflicting accesss are not synchronized a data race is said to occur

Critical section
That part of the program where shared resources are accessed When a process executes code that manipulates shared data (or resource), we say that the process is in a critical section (CS) (for that resource) The value of shared variables collectively determine the state of critical section A state is said to be valid or consistent if it satisfies some integrity constraint

 An integrity constraint specifies permitted values of the shared variables

Critical Section or Synchronization Problem

Problem: is to order executions of the critical section satisfying some specific constraints on the shared variables,so that this constraints are not voilated

Process 1 Process 2

CS1

CS2

Time

The Mutual Exclusion Problem

It is the most fundamental problem of synchronization In this the synchronization constraints specify mutually exclusive executions of the critical section. That is,no two processes can execute the critical section concurrently

Solution to Critical section problem

The process follow some protocols in their executions of the critical section

A solution to a synchronization problem entails designing these protocols for processes to be followed before entering and after exiting the critical section
The steps in the protocol are executed in the parts are called entry section and exit section

A solution to a critical section problem involves designing codes for the entry and exit sections

Framework for analysis of solutions

Each process executes at nonzero speed but no assumption on the relative speed of n processes General structure of a process: repeat entry section critical section exit section remainder section forever No assumptions about order of interleaved execution The central problem is to design the entry and exit sections

Three Key Requirements for a Valid Solution to the Critical Section Problem
Safety :The intented condition will never be violated .For example in mutual exclusion at any time, at most one process can be executing critical section (CS) code Progress: If no process is in its CS and there are one or more processes that wish to enter the CS, this selection cannot be postponed indefinitely
no process in its remainder section can participate in this decision

Bounded Waiting: After a process P has made a request to enter its CS, there is a limit on the number of times that the other processes are allowed to enter their CS, before Ps request is granted
(otherwise the process could suffer from starvation)

Types of Solutions
No special OS mechanisms
(software approach.)

algorithms whose correctness relies only on the assumption that only one process at a time can access a memory location

Hardware solutions
rely on special machine instructions for locking

Operating System and Programming Language solutions (e.g. Java)

provide specific functions and data structures for the programmer to use for synchronization

Faulty Algorithm 1 - Turn taking

The shared variable turn is initialized (to 0 or 1) before executing any Pi Pis critical section is executed iff turn = i Pi is busy waiting if Pj is in CS

Process Pi: //i,j= 0 or 1 repeat while(turn!=i){}; CS turn:=j; RS forever

Process P0: repeat while(turn!=0){}; CS turn:=1; RS forever

Process P1: repeat while(turn!=1){}; CS turn:=0; RS forever

Faulty Algorithm 1 side-by-side view

Analysis
Achieves Mutual Exclusion (busy wait)

But Progress requirement is not satisfied since it requires strict alternation of CSs.
If one process requires its CS more often than the other, it cant get it.

Faulty Algorithm 2 Ready flag

Keep a Boolean variable for each process: flag[0] and flag[1] Pi signals that it is ready to enter its CS by: flag[i]:=true but waits until the other has finished its CS.

Process Pi: repeat flag[i]:=true; while(flag[j]){}; CS flag[i]:=false; RS forever

Process P0: repeat flag[0]:=true; while(flag[1]){}; CS flag[0]:=false; RS forever

Process P1: repeat flag[1]:=true; while(flag[0]){}; CS flag[1]:=false; RS forever

Faulty Algorithm 2 side-by-side view

Analysis
Mutual Exclusion is satisfied but not the progress requirement For the (interleaved) sequence:

flag[0]:=true flag[1]:=true
Both processes will wait forever

Algorithm 3 (Petersons Algorithm)

Initialization: flag[0]:=flag[1]:=false turn:= 0 or 1 Wish to enter CS specified by Process Pi: repeat flag[i]:=true flag[i]:=true; Even if both flags go // I want in up, and no matter how turn:=j; the instructions are // but you can go first! while(flag[j]&& turn==j); interleaved,
..turn will always end up as either 0 or 1
CS flag[i]:=false;
// Im done

RS forever

Petersons Algorithm
Process P0: repeat flag[0]:=true;
// 0 wants in

Process P1: repeat flag[1]:=true;

// 1 wants in

turn:= 1;
// 0 gives a chance to 1

turn:=0;
// 1 gives a chance to 0

while (flag[1]&turn=1); CS flag[0]:=false;

// 0 is done

while (flag[0]&turn=0); CS flag[1]:=false;

// 1 is done

RS forever

RS forever

Petersons algorithm side-by-side view

Petersons Algorithm: Proof of Correctness

Mutual exclusion holds since:
For both P0 and P1 to be in their CS
both flag[0] and flag[1] must be true and: turn=0 and turn=1 (at same time): impossible

Proof (progress)
Progress requirement:
Pi can be kept out of CS only if stuck in while loop
flag[j] = true and turn = j.

If Pj not ready to enter CS then flag[j] = false

Pi can then enter its CS

If Pj has set flag[j], it is also in its while loop, then either Pi or Pj will go depending on value of turn Therefore the progress condition is met

Proof (Bounded Waiting)

Suppose Pj gets to go this time
Process Pi: repeat flag[i]:=true;
// I want in

Can it go a second time without letting Pi go?

If Pj enters CS , then turn=j

but will then reset flag[ j]=false on exit: allowing Pi to enter CS

turn:=j;
// but you can go first!

while(flag[j]&& turn==j) ; //(loop) CS flag[i]:=false;

// Im done

RS forever

What if Pj tries again, and has time to reset flag[ j]=true before Pi gets to its CS?
It must also set turn=i

since Pi is (stuck) past the point where it sets turn= j:

Pi will get to enter CS after at most one CS entry by Pj

What About Process Failures?

If all 3 criteria are satisfied, a valid solution will be robust for failure of a process in its remainder section (RS) since failure in RS is just like having an infinitely long RS. However, no valid solution can provide robustness against a process failing in its critical section (CS). Therefore a process Pi that fails in its CS must signal this fact to other processes.

Algorithm 3 (Petersons Algorithm)

Initialization: flag[0]:=flag[1]:=false turn:= 0 or 1 Wish to enter CS specified by Process Pi: repeat flag[i]:=true flag[i]:=true; Even if both flags go // I want in up, and no matter how turn:=j; the instructions are // but you can go first! while(flag[j]&& turn==j); interleaved,
..turn will always end up as either 0 or 1
CS flag[i]:=false;
// Im done

RS forever

Petersons Algorithm
Process P0: repeat flag[0]:=true;
// 0 wants in

Process P1: repeat flag[1]:=true;

// 1 wants in

turn:= 1;
// 0 gives a chance to 1

turn:=0;
// 1 gives a chance to 0

while (flag[1]&turn=1); CS flag[0]:=false;

// 0 is done

while (flag[0]&turn=0); CS flag[1]:=false;

// 1 is done

RS forever

RS forever

Petersons algorithm side-by-side view

Petersons Algorithm: Proof of Correctness

Mutual exclusion holds since:
For both P0 and P1 to be in their CS
both flag[0] and flag[1] must be true and: turn=0 and turn=1 (at same time): impossible

Proof (progress)
Progress requirement:
Pi can be kept out of CS only if stuck in while loop
flag[j] = true and turn = j.

If Pj not ready to enter CS then flag[j] = false

Pi can then enter its CS

If Pj has set flag[j], it is also in its while loop, then either Pi or Pj will go depending on value of turn Therefore the progress condition is met

Proof (Bounded Waiting)

Suppose Pj gets to go this time
Process Pi: repeat flag[i]:=true;
// I want in

Can it go a second time without letting Pi go?

If Pj enters CS , then turn=j

but will then reset flag[ j]=false on exit: allowing Pi to enter CS

turn:=j;
// but you can go first!

while(flag[j]&& turn==j) ; //(loop) CS flag[i]:=false;

// Im done

RS forever

What if Pj tries again, and has time to reset flag[ j]=true before Pi gets to its CS?
It must also set turn=i

since Pi is (stuck) past the point where it sets turn= j:

Pi will get to enter CS after at most one CS entry by Pj