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>
mutex.wait()
hydrogen += 1
if hydrogen >= 2 and oxygen >= 1:
hydroQueue.signal()
hydroQueue.signal()
hydrogen -= 2
oxyQueue.signal()
oxygen -= 1
else
mutex.signal() 11
hydroQueue.wait()
bond()
Correct use of semaphore operations may not be easy, since they may be scattered throughout a program:
<Oxygen>
mutex.wait()
oxygen += 1
if hydrogen >= 2:
hydroQueue.signal()
hydroQueue.signal()
hydrogen -= 2
oxyQueue.signal()
oxygen -= 1
else
mutex.signal() 11
oxyQueue.wait()
bond()
mutex.signal()

3. 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
Signal(mutex)
Critical section
Wait(mutex)

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. Figure 6.17 Monitor Structured “OO type” programming construct
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.
Monitor: <monitor name> {
// shared variable declaration
function P1(){
do this() }
function P2(){
do that();
Figure 6.17

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] of boolean; -- initialized to true
int acquire ()
{ for i := 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).
Should B leave the monitor and be put back on the service queue.
Should B be allowed to execute to completion. If so Should C or A be allowed In after B exits?
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;
function deposit (item) function remove (&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:
repeat     produce item     deposit (item); until false;
Consumer process: repeat     remove (item);     consume item; until false;

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

15. Hoare-style Monitor (Signal-and-Wait Discipline)
condition queue x y
function fun1 () {  …
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

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
monitor
condition queue
full
empty
function deposit (item) { 
if (counter = n) then
full.wait;
    buffer[in] := item;
counter := counter + 1;
    empty.signal;
in := (in+1) % n; }
function remove (&item) {
  if (counter = 0) then
empty.wait;
    item := buffer[out];
 counter := counter – 1;
    full.signal;
out := (out+1) % n;}
empty.notify;
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;
function deposit (item) function remove (&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)
condition queue
full
empty
function deposit (item) { 
while (counter = n) then
full.wait;
    buffer[in] := item;
counter := counter + 1;
    empty.notify;
in := (in+1) % n; }
function remove (&item) {
  while (counter = 0) then
empty.wait;
    item := buffer[out];
counter := counter – 1;
    full.notify;
out := (out+1) % n;}
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