concurrency: mutual exclusion and synchronization - chapter 5 (part 1) concurrency –basic...

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