University of Pennsylvania
9/28/00
CSE 380
1
Concurrent Programming(Critical Regions, Monitors,and Threads)
CSE 380
Lecture Note 6
Insup Lee
University of Pennsylvania
9/28/00
CSE 380
2
Concurrent Programming
•An OS consists of a large number of programs that executeasynchronously and cooperate.
•Traditionally, these programs were written in assembly languagefor the following reasons:
–High-level languages (HLL) did not provide mechanisms forwriting machine-dependent code (such as device drivers).
–HLL did not provide the appropriate tools for writingconcurrent programs.
–HLL for concurrent programs were not efficient.
•HLL for OS must provide facilities for synchronization andmodularization.
•Modularization: describe the partitioning of a single large programinto a set of smaller modules. (1) Processes, (2) Procedures, (3)Abstract Data Types (a set of objects, a set of operations)
University of Pennsylvania
9/28/00
CSE 380
3
Motivating examples
P and V operations are better than shared variables but stillsusceptible 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)
University of Pennsylvania
9/28/00
CSE 380
4
Critical Regions
A higher-level programming language construct proposed in 1972 byBrinch 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)
University of Pennsylvania
9/28/00
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;
University of Pennsylvania
9/28/00
CSE 380
6
Conditional Critical Regions
Critical regions are basically a mutex
They are not easily adapted to general synchronizationproblems, i.e. those requiring a counting semaphore
Hoare, again in 1972, proposed conditional criticalregions:
region X when B do S
X will be accessed in mutual exclusion in S
process delayed until B becomes true
University of Pennsylvania
9/28/00
CSE 380
7
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
University of Pennsylvania
9/28/00
CSE 380
8
Brinch Hansen extension [1972]
region v do begin S1 await(B) S2 end
synchronization conditions can be placed anywhere withinthe region (unlike original proposal)
University of Pennsylvania
9/28/00
CSE 380
9
Monitors
•A monitor is a shared data object together with a set of operationsto manipulate it.
•To enforce mutual exclusion, at most one process may executeoperations 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.
University of Pennsylvania
9/28/00
CSE 380
10
fast q +-----+---------| |---------+ | | | | | | - - 1 process - entrance at a time - q - - | | | | | | +-----+---| |-------| |-----+ cond q cond q
University of Pennsylvania
9/28/00
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}