1. University of Pennsylvania 9/28/00CSE 3801 Concurrent Programming (Critical Regions, Monitors, and Threads) CSE 380 Lecture Note 6 Insup Lee

2. University of Pennsylvania 9/28/00CSE 3802 Concurrent Programming An OS consists of a large number of programs that execute asynchronously and cooperate. Traditionally, these programs were written in assembly language for the following reasons: –High-level languages (HLL) did not provide mechanisms for writing machine-dependent code (such as device drivers). –HLL did not provide the appropriate tools for writing concurrent programs. –HLL for concurrent programs were not efficient. HLL for OS must provide facilities for synchronization and modularization. Modularization: describe the partitioning of a single large program into a set of smaller modules. (1) Processes, (2) Procedures, (3) Abstract Data Types (a set of objects, a set of operations)

3. University of Pennsylvania 9/28/00CSE 3803 Motivating examples P and V operations are better than shared variables but still susceptible to programming errors P(S) P(S). ==>... V(S) P(S) P(S1) P(S1).. P(S2) P(S2). ==>... V(S2) V(S1).. V(S1) V(S2)

4. University of Pennsylvania 9/28/00CSE 3804 Critical Regions A higher-level programming language construct proposed in 1972 by Brinch Hansen and Hoare.  if a variable is to be shared, it must be declared as such  access to shared variables only in mutual exclusion var a: shared int var b: shared int region a do -- access variable a -- Compiler can generate code using P and V: P(Sa) -- access variable a -- V(Sa)

5. University of Pennsylvania 9/28/00CSE 3805 Critical Regions aren't perfect Process 1: region a do region b do stmt1; Process 2: region b do region a do stmt2;

6. University of Pennsylvania 9/28/00CSE 3806 Conditional Critical Regions  Critical regions are basically a mutex  They are not easily adapted to general synchronization problems, i.e. those requiring a counting semaphore  Hoare, again in 1972, proposed conditional critical regions:  region X when B do S  X will be accessed in mutual exclusion in S  process delayed until B becomes true

7. University of Pennsylvania 9/28/00CSE 3807 The Producer-consumer problem Var buffer: shared record pool: array[0...n-1] of item; count, in, out: integer = 0; Producer: region buffer when count < n do begin pool[in] := item_produced in : = in + 1 mod n count := count + 1 end Consumer: region buffer when count > 0 do begin item_consumed := pool[out] out := out + 1 mod n count := count – 1 end

8. University of Pennsylvania 9/28/00CSE 3808 Brinch Hansen extension [1972] region v do begin S1 await(B) S2 end  synchronization conditions can be placed anywhere within the region (unlike original proposal)

9. University of Pennsylvania 9/28/00CSE 3809 Monitors A monitor is a shared data object together with a set of operations to manipulate it. To enforce mutual exclusion, at most one process may execute operations defined for the data object at any given time. All uses of shared variables are governed by monitors. –Support data abstraction (hide implementation details) –Only one process may execute a monitor's procedure at a time –data type “condition” for synchronization (can be waited or signaled within a monitor procedure) –Two operations on “condition” variables: wait: Forces the caller to be delayed. Exclusion released. Hidden Q of waiters. signal: One waiting process is resumed if there are waiters, and is not remembered.

10. University of Pennsylvania 9/28/00CSE 38010 fast q +-----+---------| |---------+ | | | | | | - - 1 process - entrance at a time - q - - | | | | | | +-----+---| |-------| |-----+ cond q cond q

11. University of Pennsylvania 9/28/00CSE 38011 Semaphore using monitor type semaphore = monitor var busy: boolean | nonbusy: condition procedure entry P begin if busy then nonbusy.wait fi busy := true end {P} procedure entry V begin busy := false nonbusy.signal end {V} begin busy := false end {monitor}