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] Finish[0] := true and Work := Work + Allocation[0] := (2 4 4)
•
Need[2] Finish[2] := true and Work := Work + Allocation[2] := (4 5 4)
•
Need[1] Finish[1] := true and Work := Work + Allocation[1] := (5 5 7)
•
Need[4] Finish[4] = true and Work := Work + Allocation[4] := (9 6 8)
•
Need[3] 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 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] Finish[0] := true and Work := Work + Allocation[0] := (1 2 4)
•
Need[2] Finish[2] := true and Work := Work + Allocation[2] := (4 5 4)
•
Need[1] Finish[1] := true and Work := Work + Allocation[1] := (5 5 7)
•
Need[3] Finish[3] := true and Work := Work + Allocation[3] := (9 6 8)
•
Need[4] 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)
