Monitor

Giving credit where it is due:

The lecture notes are borrowed from Dr. I-Ling Yen at University of Texas at Dallas I have modified them and added new slides

Problems with Semaphores

Correct use of semaphore operations may not be easy, since they may be scattered throughout a program:

Monitors
A high-level abstraction that provides equivalent functionality to that of semaphores and that is easier to control

The monitor construct has been implemented in a number of programming languages and as a program library
A programmer does not need to manually write the entire synchronization code

Monitors
monitor monitor-name { // shared variables declarations procedure P1 () { . } procedure Pn () {} Initialization code (.) { } }

Monitor
Protect shared objects within an abstraction
Provide encapsulation Accesses to a shared object is confined within a monitor

Provide mutual exclusive accesses

No two process can be active at the same time within a monitor monitor
Monitor already provides lock box and corresponding control mechanism

Shared Device Program with Monitor

N devices in the system
Use any of them as long as it is free monitor mutex_devices: free: array [0..N1] of boolean; -- initialized to true int acquire () { for i := 0 to N1 do if (free[i]) then { free[i] := false; return (i); } else return (1); } void release (index: integer) { free[index] := true; }

Synchronization within a Hoare-style Monitor

Monitor guarantees mutual exclusive accesses Monitor guarantees mutual exclusive accesses May still need synchronization May still need synchronization E.g., also device problem Monitorsharedprovides condition variables
wait for conditional wait and support synchronization To achievedevice to become available E.g., bounded buffer condition Associated with each problem variable

wait for buffer to A condition queuebecome full/empty The wait and signal functions

If wait inside a monitor

Same as wait inside a lockbox protected by a semaphore (mutex) Has potential of deadlock Monitor provides mechanism to counter it

Synchronization within a Hoare-style Monitor

condition queue

monitor
x

y
condition variable

Bounded Buffer Problem with a Hoarestyle Monitor

monitor bounded_buffer buffer: array [0..n-1] of item; in, out, counter: integer := 0; empty, full: condition;

function deposit (item) { if (counter = n) then full.wait; buffer[in] := item; in := (in+1) % n; counter := counter + 1; empty.signal; }

function remove (&item) { if (counter = 0) then empty.wait; item := buffer[out]; out := (out+1) % n; counter := counter 1; full.signal; }

Bounded Buffer Problem with a Hoarestyle Monitor

Producer process: repeat produce item deposit (item); until false; Consumer process: repeat remove (item); consume item; until false;

Bounded Buffer Problem with a Hoarestyle Monitor (Signal-and-Wait Discipline)

condition queue

monitor full

function deposit (item) { if (counter = n) then full.wait; buffer[in] := item;

in := (in+1) % n;

empty

counter := counter + 1; empty.signal; } function remove (&item) { if (counter = 0) then empty.wait; item := buffer[out];
out := (out+1) % n;

counter := counter 1; full.signal; }

Bounded Buffer Problem with a Hoarestyle Monitor (Signal-and-Wait Discipline)

condition queue

monitor full

empty

function fun1 () { empty.signal; } function fun2 () { empty.wait; }

A process signals and then must be blocked; signal-and-wait Process scheduling associated with a signal must be perfectly reliable

Bounded Buffer Problem with a Hoarestyle Monitor (Signal-and-Wait Discipline)

condition queue

monitor full

function deposit (item) { if (counter = n) then full.wait; buffer[in] := item;

in := (in+1) % n;

empty

counter := counter + 1; empty.signal; } function remove (&item) { if (counter = 0) then empty.wait; item := buffer[out];
out := (out+1) % n;

counter := counter 1; full.signal; }

Bounded Buffer Problem with a Mesa Monitor (Signal-and-Continue Discipline)

monitor bounded_buffer buffer: array [0..n-1] of item; in, out, counter: integer := 0; empty, full: condition;

function deposit (item) { while (counter = n) then full.wait; buffer[in] := item; in := (in+1) % n; counter := counter + 1; empty.notify; }

function remove (&item) { while (counter = 0) then empty.wait; item := buffer[out]; out := (out+1) % n; counter := counter 1; full. notify; }

Bounded Buffer Problem with a Mesa Monitor (Signal-and-Continue Discipline)

condition queue

monitor full

empty
watchdog timer

function deposit (item) { while (counter = n) then full.wait; buffer[in] := item;

in := (in+1) % n;

counter := counter + 1; empty.notify; } function remove (&item) { while (counter = 0) then empty.wait; item := buffer[out];
out := (out+1) % n;

counter := counter 1; full.notify; }

Monitor
Monitor provides encapsulation
Accesses to a shared object is confined within a monitor Easier to debug the code
E.g., bounded buffer problem, deposit & remove functions

What should be encapsulated? Too much reduce concurrency

Some part of the code that can be executed concurrently, if encapsulated in the monitor, can cause reduced concurrency