The document discusses the critical section problem in operating systems and algorithms to solve it. The critical section problem occurs when multiple processes need exclusive access to a shared resource. Three key properties must be satisfied by any solution: mutual exclusion, progress, and bounded waiting. The document presents and analyzes several algorithms to solve the problem for two processes, including using flags and turn-taking variables. It also introduces semaphores as a synchronization primitive and discusses their implementation and usage to solve the critical section problem.

1. CRITICAL SECTION
PROBLEM

2. CS Problem
● When one process is executing in its critical
section, then no process is allowed to execute in its
critical section, thus the execution of CS by the
processes is mutually exclusive in time

3. CS Problem
do
{
entry section
Critical Section
Exit section
Remainder section
}while(1);

4. CS problem
● A solution to CS problem must satisfy
● Mutual exclusion: if process Pi is executing in its CS, then
no other processes can be executing in their CS
● Progress: if no process is executing in its CS and some
processes want to enter thier CS, then only those processes
that are not executing in their remainder section can
participate in the decision on which will enter its CS next,
and this selection cannot be postponed indefinitely
● Bounded Waiting: There exists a bound on the number of
times that other processes are allowed to enter their CS after
a process has made a request to enter its CS and before that
is granted

5. Two process solution for CS
● Assume there are only two processes P0 and P1 at
a time.
● For convenience, when presenting Pi, we use Pj to
denote the other process, that is j=1-i

6. Algorithm 1
Do{
While (turn != i);
Critical section
Turn =j;
Remainder section
}while(1);
if turn==i, then process Pi is allowed to execute CS
● Mutual exclusion is satisfied, but the progress is not
satisfied
● If turn==0 and P1 is ready to enter CS, P1 cannot do,
eventhough P0 may be in its remainder section

7. Algorithm 2
Do{
flag[i] = true;
while(flag[j])'
Critical section
flag[i]=false;
Remainder section;
}while(1);

8. Algorithm 2
● Boolean flag[2];
● If flag[i] is true, then P1 is allowed to enter its CS.
● Mutual exclusion is satisfied and progress is not
satisfied
● P0 sets flag[0]=true;
● P1 sets flag[1]=true;
● Both P0 and P1 are looping forever in their
respective while statements.

9. Algorithm 3
● The processes share two variables
● Boolean flag[2]
● Int turn;
● Initial values of flag[0] and flag[1] is false and turn
value either 0 or 1 (immaterial)
● All the three are satisfied
● Progress
● Mutual exclusion
● Bounded waiting

10. Algorithm 3
Do{
flag[i]=true;
turn=j;
while(flag[j] && turn ==j);
Critical section
flag[i]=false;
Remainder section
}while(1);

11. Algorithm 3
● Pi can enter its CS only when either flag[j]=false
and turn=i
● And if P0 and P1 change the flag[0] and flag[1]
simultaneously to true and wanted to execute its
CS, then turn =0 or 1 can happen only one at a
time, so progress is satisfied.

12. Semaphores
● Two atomic operations
● P – wait – proberen (Dutch)
● V – signal – verhogen
● Pseudocode is
● wait(S)
While (S<=0)
;//no operation
S--;
● }

13. Semaphores
Signal (S)
{
S++;
}
● Modification to the integer value of the semaphore in
the wait and singal operations.
● That is when one process changes the semaphore value,
no other process can simultaneously modify that same
semaphore value.

14. Semaphore implementation
typedef struct {
Int value;
Struct process *L;
}semaphore;
each semaphore has an integer value and list of
processes. When a process must wait on a
semaphore, it is added to the list of processes.
● A signal operation removes one process from the
list of waiting processes and awakens that process

15. Semaphore implementation
Void wait(semaphore S){
S.value--;
if(S.value <0){
Add this process to S.L;
Block();
}
}

16. Semaphore implementation
Void signal(Semaphore S){
S.value++;
if(S.value <=0){
Remove a process P from S.L;
wakeup(P);
}
}

17. Deadlock Situations
• Mutual exclusion. At least one resource must be held in a
non sharable mode; that is, only one process at a time can
use the resource. If another process requests that
resource, the requesting process must be delayed until the
resource has been released.
• Hold and wait. A process must be holding at least one
resource and waiting to acquire additional resources that
are currently being held by other processes.

18. Deadlock
• No preemption. Resources cannot be preempted; that is,
a resource can be released only voluntarily by the process
holding it, after that process has completed its task.
• Circular wait. A set { P0 , Pl, ... , P11 } of waiting processes
must exist such that Po is waiting for a resource held by
P1, P1 is waiting for a resource held by P2, ... , Pn-1 is
waiting for a resource held by P,v and P11 is waiting for a
resource held by Po.

19. Resource Allocation Graph
• The sets P, K and E:
• P == {P1, P2, P3}
• R== {R1, R2, R3, ~}
• E == {Pl -> Rl P2-> R3, Rl->P2, R2->P2, R2-> Pl, R3-> P3}
• Resource instances:
• One instance of resource type R1
• Two instances of resource type R2

20. Resource Allocation Graph

21. Resource Allocation Graph
• One instance of resource type R3
• Three instances of Resource R4
• Process states:
• Process P1 is holding an instance of resource type R2 and is
waiting for an instance of resource type R1 .
• Process P2 is holding an instance of R1 and an instance of R2 and
is waiting for an instance of R3.
• Process P3 is holding an instance of R3nces of resource type R4

22. Resource Allocation Graph
• One instance of resource type R3
• Three instances of Resource R4
• Process states:
• Process P1 is holding an instance of resource type R2 and is
waiting for an instance of resource type R1 .
• Process P2 is holding an instance of R1 and an instance of R2 and
is waiting for an instance of R3.
• Process P3 is holding an instance of R3nces of resource type R4

23. Resource Allocation Graph

24. Resource Allocation Graph
• P1 ->R1-> P3-> R2-> P1 (P4 may release R2 so that the
cycle breaks)

25. Handling Deadlocks
• We can use a protocol to prevent or avoid deadlocks,
ensuring that the system will never enter a deadlocked
state.
• We can allow the system to enter a deadlocked state,
detect it, and recover.
• We can ignore the problem altogether and pretend that
deadlocks never occur in the system. (used in windows
and Unix OS)

26. Deadlock prevention
• Mutual Exclusion
• Handles non-sharable resource
• Read only files are the good examples, so any process can use
that resource, since it is sharable
• But printers are non sharable, they cannot be denied since printers
are intrinsically non sharable

27. Deadlock prevention
• Hold and Wait
• Whenever a process request any resource, it should not hold any
other resource
• Before a process begins its execution, all resource allocated to it.
• But when the process needs any new resource during its
execution, it should release the other resources.
• Starvation is possible in this case, as some process will wait
indefinitely to use a resource.
• Also resource utilization is low, that is the resources are unused for
a long period.
• Example: if a process wanted to copy some files from a DVD to
disk and then sort the files and printing it. A Process may request
DVD and disk, once the copying is done, it may request the Printer
rather than locking everything in the beginning.

28. Deadlock prevention
• No Preemption
• If a process requests some resources, we first check whether they
are available and we allocate them.
• If they are not, we check whether they are allocated to some other
process that is waiting for additional resources. If so, we preempt
the desired resources from the waiting process and allocate them
to the requesting process. If the resources are neither available nor
held by a waiting process, the requesting process must wait. While
it is waiting, some of its resources may be preempted, but only if
another process requests them.
• This protocol is often applied to resources whose state can be
easily saved and restored later, such as CPU registers and memory
space. It cannot generally be applied to such resources as printers
and tape drives.

29. Deadlock prevention
• Circular Wait
• To avoid deadlock with this, a number can be allotted to each
resource
• Any process can request the resource in terms of increasing order
• For example F(tape)=1, F(disk)=5, F(printer) =12, a process which
need tape and printer can request only tape first and then the
printer. Till that time some other process can use the printer
• While releasing the resource also, the processes will release in the
descending order of Numbers.

30. Dining Philosophers Algorithm

31. Dining Philosophers Algorithm
Semaphore chopstick[5]={1};
Int I;
Room=4;
Void philosopher(int i)
{
While(TRUE){
Think();
Wait(room);
Wait(chopstick[i]);
Wait (chopstick[i+1]%5);
Eat();
signal(chopstick[i+1]%5);
signal(chopstick[i]);
Signal(room);
}
}

32. Deadlock Avoidance
• Requires knowledge of future process resource request
• Two approaches
• do not start a process if its demands might lead to deadlock
• Do not grant any incremental resource request to a process if this
allocation might lead to deadlock

33. Deadlock Avoidance
Resource R = (R1,R2,……Rn) Total amount of each resource in
the system
Available V = (V1,V2,V3,…..Vn) Total amount of each resource not
allocated to any process
Claim C= Cij = requirement of process i for
c11 c12 ...... c1m resource j
c21 c22 ...... c2m
....
Cn1 cn2........cnm
Allocation A = Aij = current allocation to process i of
a11 a12 ...... a1m resource j
a21 a22 ...... a2m
....
an1 an2........anm

34. Banker’s algorithm
• Safe State
• Is one in which there is at least one sequence of resource
allocations to processes that does not result in deadlock (All
process run to completion)
• Unsafe state
• A state that is not safe

35. Banker’s algorithm