9/19/00 CSE 380 1

University of Pennsylvania

Concurrent Processes

CSE 380

Lecture Note 4

Insup Lee

9/19/00 CSE 380 2

University of Pennsylvania

Concurrent Processes

• Implementing a multiprogramming OS requires programming to accommodate 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.

9/19/00 CSE 380 3

University of Pennsylvania

Basic Issues in Concurrent Programming

• Programming concurrent processes is difficult and error-prone bugs are often not reproducible since they are timing dependent (known as race condition)

• Cooperating concurrent processes need to be synchronized and/or coordinated to accomplish their task.

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

• Interleaving: other processes may execute an arbitrary number of actions between any two indivisible actions of one process

9/19/00 CSE 380 4

University of Pennsylvania

Example: Shared variable problem

– Two processes are each reading characters typed at their respective 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?

9/19/00 CSE 380 5

University of Pennsylvania

Example (cont’d)

• The programmer failed to realize that the assignment was not executed as a single indivisible action, but rather as the following sequence of instructions:

MOVE V, r0 INCR r0 MOVE r0, V

9/19/00 CSE 380 6

University of Pennsylvania

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 (recall

previous example) also known as the Bounded Buffer problem Example: in UNIX shell

myfile.t | eqn | troff

producer

process

consumer

process

P

buffer

C

9/19/00 CSE 380 7

University of Pennsylvania

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 */ }

9/19/00 CSE 380 8

University of Pennsylvania

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/19/00 CSE 380 9

University of Pennsylvania

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 access to shared data, whose values are supposed to obey some integrity constraint.

• Other examples: airline reservation system, bank transaction system

• Problem generally solved by making access to shared variables mutually exclusive: at most one process can access shared variables 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 it holds at end.

9/19/00 CSE 380 10

University of Pennsylvania

Definitions

Deadlock. A situation in which each process in a cycle is waiting 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)

9/19/00 CSE 380 11

University of Pennsylvania

The Critical Section Problem

Definition. A critical section is a sequence of activities (or statements) 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)

9/19/00 CSE 380 12

University of Pennsylvania

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

9/19/00 CSE 380 13

University of Pennsylvania

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 the same variables

• This is sometimes necessary (to prevent further interrupts during interrupt handling)

9/19/00 CSE 380 14

University of Pennsylvania

Switch Variables

switch := A

process A process B repeat repeat ... ... while switch <> A do while switch <> B do skip; skip; /* CS */ /* CS */ switch := B switch := A

1. busy waiting

2. danger of long blockage since A and B strictly alternates

3. different CS's can be implemented using different switch variables

9/19/00 CSE 380 15

University of Pennsylvania

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

9/19/00 CSE 380 16

University of Pennsylvania

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

9/19/00 CSE 380 17

University of Pennsylvania

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;

6. /* critical section */

7. flag[1] := false;

8. /* non-critical section */

9. end

9/19/00 CSE 380 18

University of Pennsylvania

3rd Attempt

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

2. Process P[1]

3. do forever

4. flag[1] := true;

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

6. /* critical section */

7. flag[1] := false;

8. /* non-critical section */

9. end

9/19/00 CSE 380 19

University of Pennsylvania

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 6. flag[1] := false; 7. while flag[2] do no-op end 8. flag[1] := true; 9. end 10. /* critical section */ 11. flag[1] := false; 12. /* non-critical section */ 13. end

9/19/00 CSE 380 20

University of Pennsylvania

Dekker’s 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; 15. flag[1] := false; 16. /* non-critical section */ 17. end

9/19/00 CSE 380 21

University of Pennsylvania

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] = trueThus, process 1 enters CS only if flag[1] = true and flag[2] = false.

Similarly for process 2.

Therefore, ...

Case 2. mutual blocking cannot occur.

1 Only process 1 wants to enter CSi.e., flag[1]=true and flag[2]=falseThen, process 1 enters CS regardless of turn

9/19/00 CSE 380 22

University of Pennsylvania

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

9/19/00 CSE 380 23

University of Pennsylvania

Shared Variable Solutions - Discussion

Code depicted is for process P1; symmetric for P2.

Attempt 1: mutex O.K. (Why ?)but not liveness (What if P2 decides to no longer enter its critical section ?!)

Attempt 2: mutex not guaranteed(P1 and P2 can both find flags false if they happen to run at same speed)

Attempt 3: mutex, but both P1, P2 may 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.