Concurrent Programming (Critical Regions, Monitors, and Threads) - PowerPoint PPT Presentation

View by Category
About This Presentation

Concurrent Programming (Critical Regions, Monitors, and Threads)


(Critical Regions, Monitors, and Threads) CSE 380 ... Critical Regions ... Hoare, again in 1972, proposed conditional critical regions: region X when B do S ... – PowerPoint PPT presentation

Number of Views:121
Avg rating:3.0/5.0
Slides: 12
Provided by: insu5
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Concurrent Programming (Critical Regions, Monitors, and Threads)

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

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

Motivating examples
  • P and V operations are better than shared
    variables but still susceptible to programming
  • P(S) P(S) . gt
    . . . V(S)
  • P(S1) P(S1) .
    . P(S2) P(S2) .
    gt . . . V(S2)
    V(S1) .
    . V(S1) V(S2)

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
  • 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)

Critical Regions aren't perfect
  • Process 1
  • region a do
  • region b do stmt1
  • Process 2
  • region b do
  • region a do stmt2

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

The Producer-consumer problem
  • Var buffer shared record pool
    array0...n-1 of item count, in,
    out integer 0
  • Producer
  • region buffer when count lt n do begin
    poolin item_produced in in 1 mod
    n count count 1 end
  • Consumer
  • region buffer when count gt 0 do begin
    item_consumed poolout out out 1
    mod n count count 1 end

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)

  • 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
  • Support data abstraction (hide implementation
  • 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.

  • fast q -------------- ---------

    - - 1 process -
    entrance at a time - q -
    -------- -------
    ----- cond q cond q

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