1. Chapter 71 Monitors (7.7)  A high-level-language object-oriented concept that attempts to simplify the programming of synchronization problems  A synchronization construct that allows the safe sharing of an abstract data type among concurrent processes  Found in many concurrent programming languages  Not standardized: each language has own ‘dialect’

2. Chapter 72 Monitor  A software module containing: one or more procedures an initialization sequence data variables  Characteristics: data variables accessible only by monitor’s procedures a process enters the monitor by invoking one of its procedures only one process can be be active in the monitor at any given time  Guarantees mutual exclusion

3. Chapter 73 monitor monitor-name { shared variable declarations procedure body P1 (…) {... } procedure body P2 (…) {... } procedure body Pn (…) {... } { initialization code }

4. Chapter 74 Schematic View of a Monitor

5. Chapter 75 Monitor  Because the monitor ensures mutual exclusion no need to program this constraint explicitly  Simply place shared data in the monitor The monitor locks the shared data on process entry, assuring sequential use.  Critical sections placed inside a monitor, have a “wall” around them, with only one process allowed in at a time  Also supports process synchronization by using condition concept

6. Chapter 76 Monitors  To allow a process to wait within the monitor, a condition variable must be declared, as condition x, y;  Condition variable can only be used with the operations wait and signal. The operation x.wait(); means that the process invoking this operation is suspended until another process invokes x.signal(); The x.signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect.

7. Chapter 77 Monitor With Condition Variables

8. Chapter 78 Producer/Consumer Example  Two processes (outside monitor BoundedBuffer): Producer Consumer  Synchronization confined to the monitor  append() and take() are inside the monitor, and are the only means to access the buffer  If these procedures are correct, synchronization will be correct for all participating processes  Easy to generalize to n processes. Producer() while (T){ produce item; BoundedBuffer. append(item); } Consumer(){ while(T) BoundedBuffer. take(&item); consume item; }

9. Chapter 79 Monitor for Producer/Consumer  Monitor holds the buffer: buffer: array[0..n-1] of items;  Two condition variables: notfull: notfull.signal() means “buffer not full” notempty: notempty.signal() means “buffer not empty”  Needs buffer pointers and counts: nextin: points to next item to be appended nextout: points to next item to be taken count: the number of items in buffer

10. Monitor for Producer/Consumer Problem Monitor BoundedBuffer ; char buffer[N]; int nextin, nextout, count; condition notfull, notempty; //buf state nextin = nextout = count = 0; void take(char* item){ if (count==0) notempty.wait(); *item = buffer[nextout]; nextout = (nextout +1)% N; count--; notfull.signal(); } void append(char item){ if (count==N) notfull.wait(); buffer[nextin]= item; nextin = (nextin + 1) % N; count++; notempty.signal(); }

11. Chapter 711 Monitor for Reader/Writers

12. Chapter 712 Monitor for Reader/Writers  Synchronizes access if all processes follow.  If some don’t go through monitor and database is accessed directly, it all falls apart.  Still doesn’t guard against starvation of writers. How to modify to guard against writer starvation?