Correction of exercises - lesson1
Exercise 1- Forking processes
When a child process is created, it copies the address space of its parent. Hence, despite the
same global variables, their addresses point to different physical addresses. As a consequence, the
modifications that one process (parent or child) does to one global variable, does not affect its copy.
Therefore the line A will show the value 5.
Exercise 2
When the parent uses the child to realize a task for him, the child might need to communicate a
result back to the parent. However there are in two different processes. For this, we use Inter-process
communication (IPC) which are used to make two different processes communicate between each
other. Amongst the IPC, we have the shared memory where processes share a part of their address
space, the signals, the sockets, and the pipes. For instance, the POSIX system call “mmap” is used to
share a part of the address space between two processes.
Exercise 3
An example of a sequence where P1 and P2 enter into the critical section (CS) at the same time.
We assume that no processes have accessed to the mutex.
Trace
P2
P1
P2
P1
P2
wait(mutex)
signal(mutex)
CS_2
CS_1
signal(mutex)
P1
P1
P2
signal (mutex)
NCS_1
NCS_2
Meaning
P2 waits for the mutex but it takes the mutex since nobody took it
P1 frees the semaphore mutex and wake up the other processes that
are waiting for the mutex.
P2 is not waiting for the mutex so it enters in the Critical Section 2
P1 is not waiting for the mutex so it enters in the Critical Section 1
P2 frees the semaphore and wake up the other processes that are
waiting for the mutex.
P1 frees the semaphore and wake up the other processes that are
waiting for the mutex.
P1 enters in the non critical section 1
P2 enters in the non critical section 2
We can see that in the above case, the two processes P1 and P2 execute their critical section at
the same time. The mutual-exclusion requirement is violated. This due to the fact that the process P1
does not wait before executing its critical section.
Exercise 4 – Mutual exclusion
Prove that the Dekker's algorithm satisfies the mutual exclusion and non starvation requirements.
Mutual exclusion
Assume that both processes are in the critical section (CS). We want to show that this is an impossible
case.
If Pi is in the CS (line 15) then flag[j]==false.
Similarly, if Pj is in the CS (line 15) then flag[i]==false.
Let's start by considering flag[j] (the same reasoning could be applied to flag[i] symmetrically). If
flag[j] is to be false at this point it must have been set false by Pj in line 6 at some earlier point. At that
point the “if” test has succeeded thereby we know that turn was equal to i. Following the assignment
flag[j]=false Pj would then remain in lines 8 and 9 busy waiting. The only way that turn could change
after that point would be for Pi to set turn=j (line 17) when leaving the CS . Since Pi is still in line 15
we conclude that Pj cannot have left its “while” loop from line 4. Contradiction!
Starvation
We want to show that if Pi (symetrically Pj) wants to enter the critical section (CS) it is not prohibited
from doing so indefinitely. We will show that Pi will eventually enter its pre-protocol, and once entered
eventually leaves it.
Assume Pi has just expressed the intention to enter the CS (it is at line 2). Either Pi will directly
proceed to line 13 (flag[j]==false), in which case it has a chance to enter CS. Or Pi will enter the preprotocol. We show that Pi will not be stuck in the “while” loop from line 4 forever, i.e.
(a) it will not get stuck in the inner loop forever (lines 8-9)
(b) it will not get stuck in the outer loop forever (lines 4-13)
(a) Assume that Pi has proceeded to the inner loop (lines 8-9). At this point turn=j while Pi is busy
waiting. Pj can be anywhere in its code, except in lines 6-11. We show that in any of the remaining
lines Pj will enter its CS. First if Pj is in line 2, it will proceed to CS (since Pi must have set
flag[i]=false just before busy waiting). Since CS is not infinite Pj will eventually leave the CS and turn
is set to i. This stops Pi from busy waiting (We know that turn cannot be changed again by Pj until Pi
has entered its CS).
(b) Assume Pi is in the pre-protocol (lines 4-13) but not busy waiting (lines 8-9). We are now trying to
show that Pi does not get stuck in the rest of its pre-protocol. The only way that Pi would be stuck in
the pre-protocol (other than the busy waiting case (a)) is if flag[j]==true forever. We need to show that
no matter which line Pj is in, it will eventually set flag[j]=false. Obviously if Pj is anywhere in lines
15-21 there is a step in which flag[j] is set to false. We need to show that while Pj is in line 2-14 it will
not keep flag[j]==true forever. Since Pi is not in line 8-9 as assumed in case (a) then turn==i. Thus Pj
will eventually proceed to line 5 and set the flag[j] to false in the next step. In that case Pj cannot set
flag[j] to true again until it leaves its busy waiting (line 8-9). That will only happen if Pi has set turn=j.
Exercise 5 - Banker's algorithm
(a) To check if the system is safe, first we have to execute the Safety algorithm at the page 221222 [1]. Below is the table containing the needs of each process. The need for a process Pi is computed
as follows: Need(i) = Max(i) – Allocation(i).
Need
A
P0
P1
P2
P3
P4
B
1
3
1
3
2
C
1
1
2
1
1
1
2
4
4
1
By applying the safety algorithm of the book [1],
• Work := Available := (2 3 2)
•
Need[0] <= Work
Finish[0] = false
=> Finish[0] := true and Work := Work + Allocation[0] := (2 4 4)
•
Need[2] <= Work
Finish[2] = false
=> Finish[2] := true and Work := Work + Allocation[2] := (4 5 4)
•
Need[1] <= Work
Finish[1] = false
=> Finish[1] := true and Work := Work + Allocation[1] := (5 5 7)
•
Need[4] <= Work
Finish[4] = false
=> Finish[4] = true and Work := Work + Allocation[4] := (9 6 8)
•
Need[3] <= Work
Finish[3] = false
=> Finish[3] := true and Work := Work + Allocation[3] := (10 6 8)
•
Finish[i] = 0 for all i belonging to {0..4} then the system is in a safe state.
In other words, the sequence <P0, P2, P1, P4, P3> enables the processes to run without ending
up in a deadlock. It is worth noting that it might exist several possible sequences that satisfy the safety
criteria.
b) If P2 requests the resources (1, 2, 0), we can accept it since we have enough available
resources (2, 3, 2). However we have to check if our system is still in safe state.
The new state of our system is as follows:
Allocation
A
P0
P1
P2
P3
P4
B
0
1
3
4
1
Available
C
1
0
3
1
0
1
1
2
2
3
0
1
0
Need
A
P0
P1
P2
P3
P4
B
1
3
0
3
2
1
1
0
1
1
C
1
2
4
4
1
By applying the safety algorithm, we have:
•
Work := Available := (1 1 2)
•
Need[0] <= Work
Finish[0] = false
=> Finish[0] := true and Work := Work + Allocation[0] := (1 2 4)
•
Need[2] <= Work
Finish[2] = false
=> Finish[2] := true and Work := Work + Allocation[2] := (4 5 4)
•
Need[1] <= Work
Finish[1] = false
=> Finish[1] := true and Work := Work + Allocation[1] := (5 5 7)
•
Need[3] <= Work
Finish[3] = false
=> Finish[3] := true and Work := Work + Allocation[3] := (9 6 8)
•
Need[4] <= Work
Finish[4] = false
=> Finish[4] := true and Work := Work + Allocation[4] := (10 6 8)
•
Finish[i] = 0 for all i belonging to {0..4} then the system is in a safe state.
3) If the process P3 requests the resources (1 1 1), then the request can be accepted since we have
enough available resources (1 1 1) <= (2 3 2). However, we have to check if our system is in a
safe state.
The new state of our system is as follows:
Allocation
A
P0
P1
P2
P3
P4
Available
B
0
1
2
5
1
C
1
0
1
2
0
1
2
1
2
3
0
2
0
Need
A
P0
P1
P2
P3
P4
1
3
1
2
2
B
1
1
2
0
1
C
1
2
4
3
1
By applying the safety algorithm, we have:
•
Work := Available := (1 2 1)
•
Need[0] <= Work
Finish0 = false
=> Finish0 := true and Work := Work + Allocation[0] := (1 3 3)
•
Need[2] <= Work
Finish[2] = false
=> Finish[2] := true and Work := Work + Allocation[2] := (4 5 4)
•
Finish[i] = 0 for all i belonging to {0..4} cannot be satisfied and no other processes can
go forward.
In other words, if we accept the requests asked by P3, we will end up in a deadlock.
References
[1] Abraham Silberschatz, Greg Gagne, and Peter Baer Galvin. Operating System Concepts . John
Wiley & Sons, seventh edition, 2005.