Ln4 Concur

7/27/2019 Ln4 Concur

1/23

University ofPennsylvania

9/19/00 CSE 380 1

Concurrent Processes

CSE 380

Lecture Note 4

Insup Lee


2/23


9/19/00 CSE 380 2

Concurrent Processes

Implementing a multiprogramming OS requires programming toaccommodate a number of simultaneously executing processes

Multiple-process paradigm also useful for applications (e.g.,

parallel processing, background processing)

Two kinds of parallelism in today's computer systems: Pseudo-parallelism - one CPU supports multiple processes

True parallelism - processes run on multiple CPUs

Two kinds of communication paradigms:

Shared-variable model

Message-passing model

Most systems incorporate a mixture of the two.


3/23


9/19/00 CSE 380 3

Basic Issues in Concurrent Programming

Programming concurrent processes is difficult anderror-prone bugs are often not reproducible sincethey are timing dependent (known as race condition)

Cooperating concurrent processes need to be

synchronized and/or coordinated to accomplish theirtask.

Basic actions: they are the indivisible (or atomic)actions of a process

Interleaving: other processes may execute anarbitrary number of actions between any twoindivisible actions of one process


4/23


9/19/00 CSE 380 4

Example: Shared variable problem

Two processes are each reading characters typed at theirrespective terminals

Want to keep a running count of total number of characters

typed on both terminals

A Shared variable V is introduced; each time a character is

typed, a process uses the code:V := V + 1;

to update the count. During testing it is observed that the count

recorded in V is less than the actual number of characters typed.

What happened?


5/23


9/19/00 CSE 380 5

Example (contd)

The programmer failed to realize that the assignment was notexecuted as a single indivisible action, but rather as the

following sequence of instructions:

MOVE V, r0

INCR r0

MOVE r0, V


6/23


9/19/00 CSE 380 6

The Producer/Consumer Problem

from time to time, the producer places an item in the buffer

the consumer removes an item from the buffer

careful synchronization required

the consumer must wait if the buffer empty

the producer must wait if the buffer full

typical solution would involve a shared variable count (recallprevious example)

also known as the Bounded Buffer problem

Example: in UNIX shell

myfile.t | eqn | troff

producer

process

consumer

process

P

buffer

C


7/23


9/19/00 CSE 380 7

Push and Pop example

struct stacknode {int data;

struct stacknode *nextptr;

};

typedef struct stacknode STACKNODE;

typedef STACKNODE *STACKNODEPTR;

void push (STACKNODEPTR *topptr, int info)

{

STACKNODEPTR newptr;

newptr = malloc (sizeof (STACKNODE));newptr->date = info; /* Push 1 */

newptr->nextptr = *topptr; /* Push 2 */

*topptr = newptr; /* Push 3 */

}


8/23


9/19/00 CSE 380 8

Pop

int pop (STACKNODEPTR *topptr){

STACKNODEPTR tempptr;

int popvalue;

tempptr = *topptr; /* Pop 1 */

popvalue = (*topptr)->data; /* Pop 2 */

*topptr = (*topptr)->nextptr; /* Pop 3 */

free(tempptr);

return popvalue;

}


9/23


9/19/00 CSE 380 9

The Mutual Exclusion Problem

The previous examples are typical of kind of problem that arises

in operating system programming.

Occurs when more than one process has simultaneous accessto shared data, whose values are supposed to obey someintegrity constraint.

Other examples: airline reservation system, bank transaction

system

Problem generally solved by making access to shared variablesmutually exclusive: at most one process can access sharedvariables at a time

The period of time when one process has exclusive access to

the data is called a critical section.

A process may assume integrity constraint (or data invariant)holds at beginning of critical section and must guarantee that itholds at end.


10/23


9/19/00 CSE 380 10

Definitions

Deadlock. A situation in which each process in a cycle iswaiting for resources held by the next process in the cycle.

Livelock. A situation in which the algorithm that decides

whether to block an activity fails to reach a decision and

continues to use computational resources.

Starvation. A situation in which a process continue to be

denied a resource that it needs, even though the resource is

being granted to other processes.

Safety Property: bad things will not happen. (e.g., no deadlock)

Liveness Property: good things will eventually happen. (e.g.,no livelock, no starvation)


11/23


9/19/00 CSE 380 11

The Critical Section Problem

Definition. A critical section is a sequence of activities (orstatements) in a process during which a mutually excluded

resource(s) (either hardware or software) must be accessed.

The critical section problem is to ensure that two concurrent

activities do not access shared data at the same time.

A solution to the mutual exclusion problem must satisfy the

following three requirements:

1 Mutual Exclusion

2 Progress

3 Bounded waiting (no starvation)


12/23


9/19/00 CSE 380 12

Methods for Mutual Exclusion

1. disable interrupts (hardware solution)

2. switch variables (assume atomic read and write)

3. locks (hardware solution)

4. semaphores (software solution)

5. critical regions and conditional critical sections (language

solution)

6. Hoare's monitor

7. Ada rendezvous


13/23


9/19/00 CSE 380 13

Disable Interrupts

process A process B... ...

disable interrupts disable interrupts

CS CS

enable interrupts enable interrupts

prevents scheduling during CS

may hinder real-time response (use different priority levels)

All CS's exclude each other even if they do not access thesame variables

This is sometimes necessary (to prevent further interrupts

during interrupt handling)


14/23


9/19/00 CSE 380 14

Switch Variables

switch := A

process A process B

repeat repeat

... ...

while switch A do while switch B doskip; skip;

/* CS */ /* CS */

switch := B switch := A

1. busy waiting2. danger of long blockage since A and B strictly alternates

3. different CS's can be implemented using different switchvariables


15/23


9/19/00 CSE 380 15

Shared Variable Solutions

Two processes with shared variables/* initialization section */

Process P[i: 1..2]

do forever

/* entry code *//* critical section */

/* exit code */

/* non-critical section */end


16/23


9/19/00 CSE 380 16

1st Attempt

1. turn := 1;

2. Process P[1]

3. do forever

4. while turn != 1 do no-op end

5. /* critical section */

6. turn := 2;

7. /* non-critical section *

8. end


17/23


9/19/00 CSE 380 17

2nd Attempt

1. flag[i: 1..2] := {false, false}

2. Process P[1]

3. do forever

4. while flag[2] do no-op end

5. flag[1] := true;


7. flag[1] := false;

8. /* non-critical section */

9. end


18/23


9/19/00 CSE 380 18

3rd Attempt

1. flag[i:1..2] := {false, false}

2. Process P[1]

3. do forever

4. flag[1] := true;





9. end


19/23


9/19/00 CSE 380 19

4th Attempt

1. flag[i:1..2] := {false, false}2. Process P[1]

3. do forever

4. flag[1] := true;

5. while flag[2] do



8. flag[1] := true;

9. end




13. end


20/23


9/19/00 CSE 380 20

Dekkers Algorithm

1. Flag[i:1..2] := {false, false}

2. turn := 1;3. Process P[1]

4. do forever

5. flag[1] := true;

6. while flag[2] do

7. if turn = 2 then

8. flag[1] := false

9. while turn = 2 do no-op end

10. flag[1] := true;

11. end

12. end

13. /* critical section */14. turn := 2;



17. end


21/23


9/19/00 CSE 380 21

Correctness of Dekker's Algorithm

Case 1. mutual exclusion is preserved.

Process 1 decides to enter CS only if flag[1] = true.

Only process 1 can change flag[1]

Process 1 inspects flag[2] only while flag[1] = true

Thus, process 1 enters CS only if flag[1] = true andflag[2] = false.

Similarly for process 2.

Therefore, ...

Case 2. mutual blocking cannot occur.

1 Only process 1 wants to enter CS

i.e., flag[1]=true and flag[2]=false

Then, process 1 enters CS regardless of turn


22/23


9/19/00 CSE 380 22

Correctness (cont.)

2 Both processes 1 and 2 want to enter CS and turn=1

i.e., flag[1]=true and flag[2]=true and turn=1Process 1 loops for flag[2] to set to falseProcess 2 changes flag[2] to false since turn=1Process 2 then loopsSo, process 1 eventually enters CS

3 Only process 2 wants to enter CS

4 Both processes 1 and 2 want to enter CS and turn=2

Properties:

Complex and unclear

Mutual exclusion is preserved

Mutual blocking cannot occur Can be extended for n processes

Starvation impossible

Busy waiting


23/23


9/19/00 CSE 380 23

Shared Variable Solutions - Discussion

Code depicted is for process P1; symmetric forP2.

Attempt 1: mutex O.K. (Why ?)

but not liveness (What ifP2decides to no longer

enter its critical section ?!)

Attempt 2: mutex not guaranteed(P1 and P2can both find flags false if they

happen to run at same speed)

Attempt 3: mutex, but both P1, P2may find flags true

Attempt 4: again, no progress possible

Dekker's alg: mutex, liveness and bounded waiting!

Note: unlike in attempt 1, "turn" is used only

to break ties.

Documents

Ln4 Concur