concurrency: mutual exclusion and synchronization - chapter 5 (part 1) concurrency –basic...
Post on 19-Dec-2015
236 views
TRANSCRIPT
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 (HW1)
• Mutual Exclusion - Cooperation among Processes by Sharing & Communication (HW2)
• Requirements for Mutual Exclusion (HW3)
• Dekker’s Algorithm (HW4)
Concurrency
Concurrency encompasses a host of design issues, including:
Communication among processesSharing resourcesSynchronization of multiple
processesAllocation of processor time
Basic Requirement for Concurrency
Basic Requirement The basic requirement for support of concurrent process is the ability to enforce mutual exclusion;
To Enforce Mutual ExclusionThat is the ability to exclude all other processes from a course of action while one process is granted that ability
Difficulties with Concurrency
Sharing global resourcesIf two processes both make use of the same global variable ..... ???
Management of allocation of global resourcesOne process may request use of an I/O channel and then be suspended before using that channel. It may be inefficient ......???
Programming errors difficult to locateThe 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)A single-processor multiprogramming system
support a single user.The user can jump from one application to another,
and each application uses the same keyboard for input and same screen for output.
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 P1 invokes the echo. x is stored in variable in. but x is not displayed yet. Then P1 is interrupted immediately. (in := x)
2. Process P2 is activated and invokes the echo, inputting y and then displaying a single character y on the screen. (in := y)
3. P1 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)
Condition (Two Processor, Parallel Running)There is no mechanism for controlling access to the
shared global variable. in and out are global variables.Processes P1 and P2 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 P1 Process P2
..... ......
input (in, keyboard) ......
...... input ( in, keyboard)
out := in out := in
output (out, display) .......
...... output (out, display)
......... ......
Question 1 - Exercise/Home Work (1)Consider a concurrent program with two
processes, P and Q, shown in the following code. A, B, C, D, and E are indivisible statements.
procedure P procedure Qbegin begin
A; D; B; E; C; end.
end.
Question 1 - Exercise/Home Work (2)
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?
Keep track of active processesAllocate and deallocate resources
processor time; memory; files; I/O devicesProtect data and resourcesResult of process must be independent of
the speed of execution since other processes share the processor time
Degree of Awareness for the Process Interaction
Processes unaware of each otherRelationship: Competition
Processes indirectly aware of each otherRelationship: Cooperation by sharing
Process directly aware of each otherRelationship: Cooperation by communication
Competition Among Processes for Resources
Execution of one process may affect the behavior of competing processes
If two processes wish access to a single resource, one process will be allocated the resource and the other will have to wait
Possible the blocked process will never get access to the resource and never terminate
The Need for Mutual ExclusionControl Problems in Competition (1)
Critical ResourceTwo or more processes require access to a single nonsharable resource, such as printer. We refer to such a resource as a critical resource.
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)
DeadlockThe enforcement of mutual exclusion creates an additional control problem - deadlock.
Example of DeadlockProcesses P1 and P2, Resources S1 and S2
P1 is holding S2 P2 is holding S1 P1 is waiting S1 P2 is waiting S2
P1 will not release S2 until it has S1P2 will not release S1 until it has S2
Control Problems in Competition (3)
StarvationThe enforcement of mutual exclusion created another control problem is starvation.
Example of Starvation- Processes P1, P2, P3, and Resource R
- Each process requires periodic access to R- If P1 and P2 are repeatedly granted access resource R, then P2 may indefinitely be denied access to R.
Cooperation Among Processes by Sharing
Processes use and update shared data such as shared variables, files, and data bases for cooperation.
Because data are held on resources, the control problems of mutual exclusion, deadlock, and starvation are again present.
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
Communication provides a way to synchronize, or coordinate, the various activities
Nothing is shared between processes, mutual exclusion is not a control requirement.
Possible to have deadlock each process waiting for a message from the
other processPossible to have starvation
two processes sending message to each other while another process waits for a message
Question 2 - Exercise/Home Work (1)
Consider the following program (next slide)Determine the proper lower bound and upper
bound on the final value of the shared variable tally output by this concurrent program.
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; * Question 2 (2) *
var tally: integer; * Exercise/Home Work *
procedure total;var count: integer;begin
for count :=1 to n do tally := tally + 1end;
begin (*main program *)tally := 0;parbegin
total; totalparend;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:Only one process at a time is allowed in the
critical section for a resource If a process halts in its noncritical section, it
must not interfere with other processes.A process requiring the critical section must
not be delayed indefinitely: no deadlock or starvation
Requirements for Mutual Exclusion (2)
A process must not be delayed access to a critical section when there is no other process using critical resource
No assumptions are made about relative process speeds or number of processes
A process remains inside its critical section for a finite time only
Mutual Exclusion: Software Approaches
Software approaches can be implemented for concurrent processes that execute on a single processor or a multiprocessor machine with shared main memory.
These approaches usually assume elementary mutual exclusion at the memory access level.
No support at the hardware, operating system, or programming-language level assumed.
Busy-Waiting: Example
A process (P0 or P1) wishing to execute its critical section first enters the igloo and examines the blackboard.
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 (P0), the process (P0) may proceed to the critical section.
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)
First Attempt pace of execution is dictated by lower process.
Second Attempt does not guarantee mutual exclusion.Third Attempt
dead lock.Fourth Attempt
mutual courtesy.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 1 Section turn
P0 P1P0 and P1 are wishing to execute its critical
section 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}; do {nothing};< critical section > <critical
section>turn := 1; turn := 0;.......... ........
First Attempt - Dekker’s Algorithm (3)
Problems of the First Attempt If one process fails ( global variable turn
would not change its number any more), the other process is permanently blocked.
The pace of execution is dictated by the slower of the two processes.If P0 used its critical section only once per hour, but P1 would like to use its critical section at a rate of 100 times per hour. P1 is forced to adopt the pace of P0 (P1 should wait the turn value has been changed).
Dekker’s Algorithm (4)
flag[0] flag[1] 1/0 1/0
P0 P1 critical section
P0 P1
flag[1] = 0 flag[1] = 1 flag[0] = 0 flag[0] = 1
flag[0] = 1 wait in while loop flag[0] = 1 wait in while loop
critical section critical section flag[0] = 0 flag[0] = 0
Second Attempt - Dekker’s Algorithm (5)Each process (P0 , P1) has its own
igloo(flag[0], flag[1]). Each process may examine the other’s
blackboard but cannot alter it.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.
The process then quickly goes to its own igloo, crawls in, and writes “true” on the blackboard.
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] while flag[0]
do {nothing}; do {nothing};
flag[0]:=true; flag[1]:=true;< critical section > <critical
section>flag[0]:=false; flag[1]:= false.......... ........
Second Attempt - Dekker’s Algorithm (7)
Problems of the Second AttemptIf 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.
The second attempt does not even guarantee mutual exclusion. (see next slide example)
Second Attempt - Dekker’s Algorithm (8)
Problems of the Second AttemptP0 executes the while statement and finds flag[1]
set to false.P1 executes the while statement and finds flag[0]
set to false.P0 sets flag[0] to true and enters its critical
section.P1 sets flag[1] to true and enters its critical
section.
Both processes are now in critical sections.The proposed solution is not independent of
relative process execution speeds.
Dekker’s Algorithm (9)
flag[0] flag[1] 1/0 1/0
P0 P1 critical section
P0 P1
flag[0] = 1 flag[0] = 1
flag[1] = 0 flag[1] = 1 flag[0] = 0 flag[0] = 1
wait in while loop wait in while loop
critical section critical section flag[0] = 0 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] while flag[0]
do {nothing}; do {nothing};
< critical section > <critical section>
flag[0]:=false; flag[1]:= false.......... ........
Third Attempt - Dekker’s Algorithm (11) Advantage of the Third Attempt
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
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.
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] flag[1] 1/0 1/0
P0 P1 critical section
P0 P1
flag[0] = 1 flag[0] = 1
flag[1] = 0 flag[1] = 1 flag[0] = 0 flag[0] = 1
set flag[0]=0 set flag[1]=0
critical section wait in while critical section wait in while
flag[0] = 0 flag[0]=1 flag[0] = 0 flag[1]=1
Fourth Attempt - Dekker’s Algorithm (14)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.
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
procedure P0;......
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, P0 goes critical section* flag[0]:=false; *P1 can go critical section *......
Fourth Attempt - Dekker’s Algorithm (15)
Forth Attempt - Dekker’s Algorithm (16)
Problems of the Forth Attempt - Mutual Courtesy
P0 sets flag[0] to true P1 sets flag[1] to trueP0 checks flag[1] P1 checks flag[0]P0 sets flag[0] to false P1 sets flag[1] to falseP0 sets flag[0] to true P1 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)
The array variable flag is used for observing the state of both processes.
The variable turn is used for indicating which process has the right to insist on entering its critical region.
There is now a “referee” igloo with a blackboard labeled “turn”.
Dekker’s Algorithm (18)
flag[0] turn flag[1] 1/0 1/0 1/0
P0 P1
flag[0] = 1 flag[1] = 0 flag[1] = 1
critical section turn = 0 turn = 1
check flog[1] set flag[0] = 0 until flag[1] = 0 if turn = 1 let P1 goes to critical section 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 P0;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 P0’s turn flag[0]:=false;
to check P1’s igloo while turn:=1 do{nothing}; avoid mutual courtesy flag[0]:=true
end; <critical section> *flag[1]=false, P0 goes critical part* turn:=1; *P1’s turn to check P0’s igloo * flag[0]:=false; *P1 can go critical section * <remainder>
foreverend;
procedure P1;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 P1’s turn flag[1]:=false;
to check P0’s igloo while turn:=0 do{nothing}; avoid mutual courtesy flag[1]:=true
end; <critical section> *flag[0]=false, P1 goes critical part* turn:=0; *P0’s turn to check P1’s igloo * flag[1]:=false; *P0 can go critical section * <remainder>
foreverend;
Dekker’s Algorithm (21)
......Begin
flag[0]:=false;flag[1]:=false;turn:=1;parbegin
p0; p1parend
end
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