Concurrency Mutual Exclusion and Synchronization Chapter 5 Part

Concurrency: Mutual Exclusion and Synchronization - Chapter 5 (Part 1) • • • Concurrency –Basic Requirement and Difficulties Operating System Concerns Degree of Awareness for the Process Interaction Competition among Processes for Resources The Need for Mutual Exclusion Cooperation among Processes by Sharing & Communication • Requirements for Mutual Exclusion • Dekker’s Algorithm

Focus ON • Concurrency -Basic Requirement and Difficulties (HW 1) • Mutual Exclusion - Cooperation among Processes by Sharing & Communication (HW 2) • Requirements for Mutual Exclusion (HW 3) • Dekker’s Algorithm (HW 4)

Concurrency z z Concurrency encompasses a host of design issues, including: Communication among processes Sharing resources Synchronization of multiple processes Allocation of processor time

Basic Requirement for Concurrency z Basic Requirement The basic requirement for support of concurrent process is the ability to enforce mutual exclusion; z To Enforce Mutual Exclusion That is the ability to exclude all other processes from a course of action while one process is granted that ability

Difficulties with Concurrency z Sharing global resources If two processes both make use of the same global variable. . . ? ? ? z Management of allocation of global resources One process may request use of an I/O channel and then be suspended before using that channel. It may be inefficient. . . ? ? ? z Programming errors difficult to locate The results are typically not reproducible. . ? ? ?

An Example of Sharing Global Variable (1) procedure echo; var out, in: character; begin input(in, keyboard); out : = in; output(out, display) end.

An Example of Sharing Global Variable (2) Condition (One Processor, Two Processes) z A single-processor multiprogramming system support a single user. z The user can jump from one application to another, and each application uses the same keyboard for input and same screen for output. z Only a single copy of the echo procedure is used, saving space.

An Example of Sharing Global Variable (3) The Second Character y Is Displayed Twice !!! 1. Process P 1 invokes the echo. x is stored in variable in. but x is not displayed yet. Then P 1 is interrupted immediately. (in : = x) 2. Process P 2 is activated and invokes the echo, inputting y and then displaying a single character y on the screen. (in : = y) 3. P 1 is resumed. By this time, the value x has been overwritten in in and therefore lost. Instead in contains y, which is displayed twice!!!

An Example of Sharing Global Variable (4) z z z Condition (Two Processor, Parallel Running) There is no mechanism for controlling access to the shared global variable. in and out are global variables. Processes P 1 and P 2 are both executing, each on a separate processor ( We have TWO processors now!). Both processes invoke the echo procedure. Two processes are running parallel.

An Example of Sharing Global Variable (5) The Second Character y Is Displayed Twice AGAIN!!! (Events on the same line take place in parallel) Process P 1 Process P 2. . . input (in, keyboard). . . input ( in, keyboard) out : = in output (out, display). . . .

Question 1 - Exercise/Home Work (1) z Consider a concurrent program with two processes, P and Q, shown in the following code. A, B, C, D, and E are indivisible statements. z procedure P procedure Q begin A; D; B; E; C; end.

Question 1 - Exercise/Home Work (2) z Assume that the main program does a parbegin (parallel begin) of the two processes. Show all the possible executions of the preceding two processes. begin (*main program*). . . parbegin P; Q parend. . . . end.

Operating System Concerns What design and management issues are raised by the existence of concurrency? z Keep track of active processes z Allocate and deallocate resources y processor time; memory; files; I/O devices z Protect data and resources z Result of process must be independent of the speed of execution since other processes share the processor time

Degree of Awareness for the Process Interaction z Processes unaware of each other Relationship: Competition z Processes indirectly aware of each other Relationship: Cooperation by sharing z Process directly aware of each other Relationship: Cooperation by communication

Competition Among Processes for Resources z Execution of one process may affect the behavior of competing processes z If two processes wish access to a single resource, one process will be allocated the resource and the other will have to wait z Possible the blocked process will never get access to the resource and never terminate

The Need for Mutual Exclusion Control Problems in Competition (1) z Critical Resource Two or more processes require access to a single nonsharable resource, such as printer. We refer to such a resource as a critical resource. z Critical Sections - The portion of the program that uses critical resource is a critical section of the program. - only one program at a time is allowed in its critical section

Control Problems in Competition (2) z Deadlock The enforcement of mutual exclusion creates an additional control problem - deadlock. z Example of Deadlock Processes P 1 and P 2, Resources S 1 and S 2 P 1 is holding S 2 P 2 is holding S 1 P 1 is waiting S 1 P 2 is waiting S 2 P 1 will not release S 2 until it has S 1 P 2 will not release S 1 until it has S 2

Control Problems in Competition (3) z Starvation The enforcement of mutual exclusion created another control problem is starvation. Example of Starvation - Processes P 1, P 2, P 3, and Resource R - Each process requires periodic access to R - If P 1 and P 2 are repeatedly granted access resource R, then P 2 may indefinitely be denied access to R.

Cooperation Among Processes by Sharing z Processes use and update shared data such as shared variables, files, and data bases for cooperation. z Because data are held on resources, the control problems of mutual exclusion, deadlock, and starvation are again present. z The only difference (competition and cooperation) is that data items may be accessed in two different modes, reading and writing, and only writing operations must be mutually exclusive

Cooperation Among Processes by Communication z Communication provides a way to synchronize, or coordinate, the various activities z Nothing is shared between processes, mutual exclusion is not a control requirement. z Possible to have deadlock y each process waiting for a message from the other process z Possible to have starvation y two processes sending message to each other while another process waits for a message

Question 2 - Exercise/Home Work (1) z Consider the following program (next slide) z Determine the proper lower bound and upper bound on the final value of the shared variable tally output by this concurrent program. z Assume processes can execute at any relative speed and that a value can only be incremented after it has been loaded into a register by a separate machine instruction.

const n = 50; var tally: integer; * Question 2 (2) * * Exercise/Home Work * procedure total; var count: integer; begin for count : =1 to n do tally : = tally + 1 end; begin (*main program *) tally : = 0; parbegin total; total parend; write (tally) end.

Requirements for Mutual Exclusion (1) Any facility or capability that is to provide support for mutual exclusion should meet the following requirements: z Only one process at a time is allowed in the critical section for a resource z If a process halts in its noncritical section, it must not interfere with other processes. z A process requiring the critical section must not be delayed indefinitely: no deadlock or starvation

Requirements for Mutual Exclusion (2) z A process must not be delayed access to a critical section when there is no other process using critical resource z No assumptions are made about relative process speeds or number of processes z A process remains inside its critical section for a finite time only

Mutual Exclusion: Software Approaches z Software approaches can be implemented for concurrent processes that execute on a single processor or a multiprocessor machine with shared main memory. z These approaches usually assume elementary mutual exclusion at the memory access level. z No support at the hardware, operating system, or programming-language level assumed.

Busy-Waiting: Example z A process (P 0 or P 1) wishing to execute its critical section first enters the igloo and examines the blackboard. z Igloo has small entrance so only one process at a time may enter to check a number (0 or 1) written on the blackboard. If the number (0) on the blackboard is the same as the process number (P 0), the process (P 0) may proceed to the critical section. z If the number on the blackboard is not the number of the process, the process leaves the igloo to wait. From time to time, the process reenters the igloo to check the blackboard.

Question 3 Exercise/Home Work Is busy waiting always less efficient ( in terms of using processor time) than a blocking wait? Explain.

Dekker’s Algorithm (0) z First Attempt pace of execution is dictated by lower process. z Second Attempt does not guarantee mutual exclusion. z Third Attempt dead lock. z Fourth Attempt mutual courtesy. z Final Version pace of execution is dictated by quicker process, guarantee mutual exclusion, avoid dead lock and mutual courtesy

First Attempt - Dekker’s Algorithm (1) small igloo & door Critical Section 1 turn P 0 P 1 z P 0 and P 1 are wishing to execute its critical section z Only one process at a time may enter to check a number on the blackboard in the igloo.

First Attempt - Dekker’s Algorithm (2) var turn: 0. . 1; * turn is a shared global variable*. . . PROCESS 0 PROCESS 1. . . while turn != 0 while turn != 1 do {nothing}; < critical section > <critical section> turn : = 1; turn : = 0; . . . .

First Attempt - Dekker’s Algorithm (3) Problems of the First Attempt z If one process fails ( global variable turn would not change its number any more), the other process is permanently blocked. z The pace of execution is dictated by the slower of the two processes. If P 0 used its critical section only once per hour, but P 1 would like to use its critical section at a rate of 100 times per hour. P 1 is forced to adopt the pace of P 0 (P 1 should wait the turn value has been changed).

Dekker’s Algorithm (4) flag[0] 1/0 flag[1] 1/0 P 1 critical section P 0 flag[1] = 0 flag[0] = 1 P 1 flag[1] = 1 wait in while loop flag[0] = 0 flag[0] = 1 wait in while loop critical section flag[0] = 0

Second Attempt - Dekker’s Algorithm (5) z Each process (P 0 , P 1) has its own igloo(flag[0], flag[1]). z Each process may examine the other’s blackboard but cannot alter it. z When a process wishes to enter its critical section, it periodically checks the other’s blackboard until it finds “false” written on it, indicating that the other process is not in its critical section. z The process then quickly goes to its own igloo, crawls in, and writes “true” on the blackboard. z The process may now proceed to its critical section. When it leaves its critical section, it alters its blackboard to show “false”.

Second Attempt - Dekker’s Algorithm (6) var flag: array[ 0. . 1]; * a shared global variable*. . . PROCESS 0 PROCESS 1. . . while flag[1] do {nothing}; flag[0]: =true; < critical section > flag[0]: =false; . . while flag[0] do {nothing}; flag[1]: =true; <critical section> flag[1]: = false. . . .

Second Attempt - Dekker’s Algorithm (7) Problems of the Second Attempt z If a process fails inside its critical section or after setting its flag to true just before entering its critical section, then the other process is permanently blocked. z The second attempt does not even guarantee mutual exclusion. (see next slide example)

Second Attempt - Dekker’s Algorithm (8) z z Problems of the Second Attempt P 0 executes the while statement and finds flag[1] set to false. P 1 executes the while statement and finds flag[0] set to false. P 0 sets flag[0] to true and enters its critical section. P 1 sets flag[1] to true and enters its critical section. z Both processes are now in critical sections. z The proposed solution is not independent of relative process execution speeds.

Dekker’s Algorithm (9) flag[0] 1/0 flag[1] 1/0 P 1 critical section P 0 P 1 flag[0] = 1 flag[1] = 0 flag[0] = 1 flag[1] = 1 flag[0] = 0 wait in while loop flag[0] = 1 wait in while loop critical section flag[0] = 0

Third Attempt - Dekker’s Algorithm (10) var flag: array[ 0. . 1]; * a shared global variable*. . . PROCESS 0 PROCESS 1. . . flag[0]: =true; flag[1]: =true; while flag[1] do {nothing}; < critical section > flag[0]: =false; . . while flag[0] do {nothing}; <critical section> flag[1]: = false. . . .

Third Attempt - Dekker’s Algorithm (11) Advantage of the Third Attempt z The second attempt does not even guarantee mutual exclusion. The third attempt solved this problem by setting flag to true before run while loop.

Third Attempt - Dekker’s Algorithm (12) Problems of the Third Attempt z If a process fails inside its critical section or after setting its flag to true just before entering its critical section, then the other process is permanently blocked. z If both processes set their flags to true before either has executed the while statement, then each will think the other has entered its critical section, causing deadlock

Dekker’s Algorithm (13) flag[0] 1/0 flag[1] 1/0 P 1 critical section P 0 P 1 flag[0] = 1 flag[1] = 0 flag[0] = 1 flag[1] = 1 flag[0] = 0 set flag[0]=0 flag[0] = 1 set flag[1]=0 critical section wait in while flag[0] = 0 flag[0]=1 flag[0] = 0 flag[1]=1

Fourth Attempt - Dekker’s Algorithm (14) z In the third attempt, deadlock occurs because each process can insist on its right to enter its critical section; there is no opportunity to back off from this position. z To solve this problem, process can set its flag to indicate its desire to enter its critical section, but is prepared to reset the flag to defer to the other process

Fourth Attempt - Dekker’s Algorithm (15) procedure P 0; . . . flag[0]: = true; *attempt 3 mutual exclusion * while flag[1] do begin *attempt 4 avoiding dead lock* flag[0]: =false; * defer to other process <delay for a short time>; *delay for a short time* flag[0]: =true *desire to enter critical section* end; <critical section> *flag[1]=false, P 0 goes critical section* flag[0]: =false; *P 1 can go critical section *. . .

Forth Attempt - Dekker’s Algorithm (16) Problems of the Forth Attempt - Mutual Courtesy P 0 sets flag[0] to true P 0 checks flag[1] P 0 sets flag[0] to false P 0 sets flag[0] to true. . . . P 1 sets flag[1] to true P 1 checks flag[0] P 1 sets flag[1] to false P 1 sets flag[1] to true This sequence could be extended indefinitely, and neither process could enter its critical section mutual courtesy.

A Correct Solution Dekker’s Algorithm (17) z The array variable flag is used for observing the state of both processes. z The variable turn is used for indicating which process has the right to insist on entering its critical region. z There is now a “referee” igloo with a blackboard labeled “turn”.

Dekker’s Algorithm (18) flag[0] 1/0 turn 1/0 P 0 flag[1] 1/0 P 1 flag[0] = 1 flag[1] = 0 critical section flag[1] = 1 turn = 0 check flog[1] until flag[1] = 0 critical section turn = 1 set flag[0] = 0 if turn = 1 let P 1 goes to critical section set flag[0] = 1 and check flag[1]

var flag: array[ 0. . 1]; * a shared global variable* turn: 0. . 1; * a referee’s message* procedure P 0; begin repeat flag[0]: = true; *attempt 3 mutual exclusion * while flag[1] do if turn =1 then begin *attempt 4 avoiding dead lock* if turn=0 P 0’s turn flag[0]: =false; to check P 1’s igloo while turn: =1 do{nothing}; avoid mutual courtesy flag[0]: =true end; <critical section> *flag[1]=false, P 0 goes critical part* turn: =1; *P 1’s turn to check P 0’s igloo * flag[0]: =false; *P 1 can go critical section * <remainder> forever end;

procedure P 1; begin repeat flag[1]: = true; *attempt 3 mutual exclusion * while flag[0] do if turn =0 then begin *attempt 4 avoiding dead lock* if turn=1 P 1’s turn flag[1]: =false; to check P 0’s igloo while turn: =0 do{nothing}; avoid mutual courtesy flag[1]: =true end; <critical section> *flag[0]=false, P 1 goes critical part* turn: =0; *P 0’s turn to check P 1’s igloo * flag[1]: =false; *P 0 can go critical section * <remainder> forever end;

Dekker’s Algorithm (21). . . Begin flag[0]: =false; flag[1]: =false; turn: =1; parbegin p 0; p 1 parend

Question 4 - Exercise/Home Work (1) Prove that mutual exclusion is enforced in the Dekker’s algorithm. Hint: Show that when Pi enters its critical section, the following expression is true: flag[i] and (not flag[1 -i]) It means that we should prove following expressions: (flag[1] and (not flag[0])) = true (flag[0] and (not flag[1])) = true