1. University of Pennsylvania 9/19/00CSE 3801 Concurrent Processes CSE 380 Lecture Note 4 Insup Lee

2. University of Pennsylvania 9/19/00CSE 3802 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.

3. University of Pennsylvania 9/19/00CSE 3803 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

4. University of Pennsylvania 9/19/00CSE 3804 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?

5. University of Pennsylvania 9/19/00CSE 3805 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

6. University of Pennsylvania 9/19/00CSE 3806 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

7. University of Pennsylvania 9/19/00CSE 3807 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. University of Pennsylvania 9/19/00CSE 3808 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. University of Pennsylvania 9/19/00CSE 3809 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.

10. University of Pennsylvania 9/19/00CSE 38010 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)

11. University of Pennsylvania 9/19/00CSE 38011 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: 1Mutual Exclusion 2Progress 3Bounded waiting (no starvation)

12. University of Pennsylvania 9/19/00CSE 38012 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. University of Pennsylvania 9/19/00CSE 38013 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)

14. University of Pennsylvania 9/19/00CSE 38014 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

15. University of Pennsylvania 9/19/00CSE 38015 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. University of Pennsylvania 9/19/00CSE 38016 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. University of Pennsylvania 9/19/00CSE 38017 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

18. University of Pennsylvania 9/19/00CSE 38018 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

19. University of Pennsylvania 9/19/00CSE 38019 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

20. University of Pennsylvania 9/19/00CSE 38020 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

21. University of Pennsylvania 9/19/00CSE 38021 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 and flag[2] = false. Similarly for process 2. Therefore,... Case 2. mutual blocking cannot occur. 1Only process 1 wants to enter CS i.e., flag[1]=true and flag[2]=false Then, process 1 enters CS regardless of turn

22. University of Pennsylvania 9/19/00CSE 38022 Correctness (cont.) 2Both processes 1 and 2 want to enter CS and turn=1 i.e., flag[1]=true and flag[2]=true and turn=1 Process 1 loops for flag[2] to set to false Process 2 changes flag[2] to false since turn=1 Process 2 then loops So, process 1 eventually enters CS 3Only process 2 wants to enter CS 4Both 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. University of Pennsylvania 9/19/00CSE 38023 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.