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’

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

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

Chapter 74 Schematic View of a Monitor

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

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.

Chapter 77 Monitor With Condition Variables

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; }

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

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(); }

Chapter 711 Monitor for Reader/Writers

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?