Concurrent Programming (Critical Regions, Monitors, and Threads)

1. Concurrent Programming(Critical Regions, Monitors, and Threads) CSE 380 Lecture Note 6 Insup Lee CSE 380

2. 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) CSE 380

3. 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) CSE 380

4. 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 intregion a do -- access variable a -- • Compiler can generate code using P and V: • P(Sa) • -- access variable a -- • V(Sa) CSE 380

5. Critical Regions aren't perfect • Process 1: • region a do • region b do stmt1; • Process 2: • region b do • region a do stmt2; CSE 380

6. 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 CSE 380

7. The Producer-consumer problem • Var buffer: sharedrecord pool: array[0...n-1] of item; count, in, out: integer = 0; • Producer: • region buffer when count < ndobegin pool[in] := item_produced in : = in + 1 mod n count := count + 1end • Consumer: • region buffer when count > 0dobegin item_consumed := pool[out] out := out + 1 mod n count := count – 1end CSE 380

8. Brinch Hansen extension [1972] • region vdobegin S1await(B) S2end • synchronization conditions can be placed anywhere within the region (unlike original proposal) CSE 380

9. 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. CSE 380

10. fast q +-----+---------| |---------+ | | | | | | - - 1 process - entrance at a time - q - - | | | | | | +-----+---| |-------| |-----+ cond q cond q CSE 380

11. 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} CSE 380