Monitor

1. 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

2. Problems with Semaphores mutex = Semaphore(1) oxygen = 0 hydrogen = 0 oxyQueue = Semaphore(0) hydroQueue = Semaphore(0) <Hydrogen> 1 mutex.wait() 2 hydrogen += 1 3 if hydrogen >= 2 and oxygen >= 1: 4 hydroQueue.signal() 5 hydroQueue.signal() 6 hydrogen -= 2 7 oxyQueue.signal() 8 oxygen -= 1 9 else 10 mutex.signal() 11 12 hydroQueue.wait() 13 bond() • Correct use of semaphore operations may not be easy, since they may be scattered throughout a program: <Oxygen> 1 mutex.wait() 2 oxygen += 1 3 if hydrogen >= 2: 4 hydroQueue.signal() 5 hydroQueue.signal() 6 hydrogen -= 2 7 oxyQueue.signal() 8 oxygen -= 1 9 else 10 mutex.signal() 11 12 oxyQueue.wait() 13 bond() 14 mutex.signal()

3. Signal(mutex) Critical section Wait(mutex) Wait(mutex) Critical section Wait(mutex) Semaphore Pitfalls • Easy to misuse signal or wait. • Easy to signal or wait on wrong semaphore • Possible to misidentify or not protect all critical sections • Easy to forget to use or correctly acquire and release

4. Monitor • 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

5. Monitor • Only one thread can execute within the monitor at any time. • Any other thread will be queued in the service queue for that monitor. • You get mutual exclusion for free. • Structured “OO type” programming construct Monitor: <monitor name> { // shared variable declaration function P1(){ do this() } function P2(){ do that(); } }

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

7. 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..N–1] ofboolean; -- initialized to true int acquire () { fori := 0 to N–1 do if (free[i]) then { free[i] := false; return (i); } return (–1); } void release (index: integer) { free[index] := true; }

8. Synchronization within a Monitor • Monitor guarantees mutual exclusive accesses • May still need synchronization • E.g., shared device problem • wait for device to become available • E.g., producer and consumer problem • wait for buffer/item to become available • Monitor guarantees mutual exclusive accesses • May still need synchronization • Monitor also provides condition variables • To achieve conditional wait and support synchronization • Associated with each condition variable • A condition queue • 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

9. Monitor Signaling Disciplines Consider the following scenario: • Thread A is in monitor and executes wait(x). This causes it to leave the monitor and be queued in queue x. • Thread B enters the monitor and begins executing monitor code. • Thread C then calls a method in the monitor and is queued on the service queue. • Then process B executes signal(x). • Now we have one process executing monitor code (process B) and two processes wishing to enter the monitor (process A that was on the condition queue, x, and process C on the service queue). What happens next? • Should process B leave the monitor be put back on the service queue? • Should B be allowed to execute to completion? If so, who should be allowed in after B exits, C or A?

10. Monitor Signaling Disciplines Signal and Wait • A process executing a signal hands over access to the monitor immediately to the signaled process (which has priority over service queue processes). When the signaled process completes its monitor method and exits the monitor, the signaler resumes its execution within the monitor (with priority over service queue processes).

11. Synchronization within a Hoare-style Monitor (Signal-and-Wait Discipline) condition queue monitor x y condition variable

12. Producer and Consumer Problem with a Hoare-style Monitor monitor bounded_buffer buffer: array [0..n-1] of item; in, out, counter: integer := 0; empty, full: condition; functiondeposit (item) functionremove (&item) {  if (counter = n) then {  if (counter = 0) then full.wait; empty.wait;     buffer[in] := item;  item := buffer[out]; counter := counter + 1;       counter := counter – 1; empty.signal; full.signal; in := (in+1) % n;      out := (out+1) % n; } }

13. Producer and Consumer Problem with a Hoare-style Monitor Producer process: repeatproduce item    deposit (item); untilfalse; Consumer process: repeat    remove (item);     consume item; untilfalse;

14. Producer and Consumer Problem with a Hoare-style Monitor condition queue monitor x y

15. Hoare-style Monitor (Signal-and-Wait Discipline) functionfun1 () {  … y.signal;     …} function fun2 () { …     y.wait; …} • A process signals and then must be blocked; signal-and-wait • Process scheduling associated with a signal must be perfectly reliable condition queue monitor x y

16. Monitor Signaling Disciplines Signal and Continue • A process executing the signal is not required to leave the monitor, it continues executing until the completion of the method which it is executing. • Thus it cannot be guaranteed that the condition leading to the signal is still true when the signaled process resumes execution in the monitor---- • The signaling process may change variables before exiting the monitor; • Another process may enter the monitor before the signaled process and change variables (and thus invalidate the condition).

17. Signal-and-Wait Signal-and-Continue functiondeposit (item) {  if (counter = n) then full.wait;     buffer[in] := item; counter := counter + 1;     empty.signal; in := (in+1) % n; } functionremove (&item) { if (counter = 0) then empty.wait;     item := buffer[out];  counter := counter – 1;     full.signal; out := (out+1) % n;} condition queue monitor full empty.notify; empty full.notify;

18. Producer and Consumer 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; functiondeposit (item) functionremove (&item) {  while (counter = n) then {  while (counter = 0) then full.wait; empty.wait;     buffer[in] := item;  item := buffer[out]; counter := counter + 1;       counter := counter – 1; empty.notify; full.notify; in := (in+1) % n;      out := (out+1) % n; } }

19. Producer and Consumer Problem with a Mesa Monitor (Signal-and-Continue Discipline) functiondeposit (item) {  while (counter = n) then full.wait;     buffer[in] := item; counter := counter + 1;     empty.notify; in := (in+1) % n; } functionremove (&item) { while (counter = 0) then empty.wait;     item := buffer[out]; counter := counter – 1;     full.notify; out := (out+1) % n;} condition queue monitor full empty watchdog timer

20. Monitor • Monitor provides encapsulation • Accesses to a shared object is confined within a monitor • Easier to debug the code • E.g., producer and consumer 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

21. Announcement • Reading assignment this week • Chapter 7 Deadlock