Editing Monitor (synchronization) (section)

===Nonblocking condition variables===
With ''nonblocking condition variables'' (also called ''"Mesa style"'' condition variables or ''"signal and continue"'' condition variables), signaling does not cause the signaling thread to lose occupancy of the monitor. Instead the signaled threads are moved to the <code>e</code> queue. There is no need for the <code>s</code> queue.

[[File:Monitor (synchronization)-Mesa.png|thumb|200px|right|A Mesa style monitor with two condition variables <code>a</code> and <code>b</code>]]

With nonblocking condition variables, the '''signal''' operation is often called '''notify''' &mdash; a terminology we will follow here. It is also common to provide a '''notify all''' operation that moves all threads waiting on a condition variable to the <code>e</code> queue.

The meaning of various operations are given here. (We assume that each operation runs in mutual exclusion to the others; thus restarted threads do not begin executing until the operation is complete.)

 enter the monitor:
     enter the method
     '''if''' the monitor is locked
         add this thread to e
         block this thread
     '''else'''
         lock the monitor
 
 leave the monitor:
     schedule
     '''return''' from the method
 
 '''wait''' {{mvar|c}}:
     add this thread to {{mvar|c}}.q
     schedule
     block this thread
 
 '''notify''' {{mvar|c}}:
     if there is a thread waiting on {{mvar|c}}.q
         select and remove one thread t from {{mvar|c}}.q
         (t is called "the notified thread")
         move t to e
 
 '''notify all''' {{mvar|c}}:
     move all threads waiting on {{mvar|c}}.q to e
 
 schedule :
     '''if''' there is a thread on e
         select and remove one thread from e and restart it
     '''else'''
         unlock the monitor

As a variation on this scheme, the notified thread may be moved to a queue called <code>w</code>, which has priority over <code>e</code>. See Howard<ref name="1976_Howard"/> and Buhr ''et al.''<ref name="1995_Buhr-Fortier-Coffin"/> for further discussion.

It is possible to associate an assertion {{mvar|P<sub>c</sub>}} with each condition variable {{mvar|c}} such that {{mvar|P<sub>c</sub>}} is sure to be true upon return from <code>'''wait''' {{mvar|c}}</code>. However, one must
ensure that {{mvar|P<sub>c</sub>}} is preserved from the time the '''notify'''ing thread gives up occupancy until the notified thread is selected to re-enter the monitor. Between these times there could be activity by other occupants. Thus it is common for {{mvar|P<sub>c</sub>}} to simply be ''true''.

For this reason, it is usually necessary to enclose each '''wait''' operation in a loop like this

 '''while''' '''not''' ( {{mvar|P}} ) '''do'''
     '''wait''' c

where {{mvar|P}} is some condition stronger than {{mvar|P<sub>c</sub>}}. The operations <code>'''notify''' {{mvar|c}}</code> and <code>'''notify all''' {{mvar|c}}</code> are treated as "hints" that {{mvar|P}} may be true for some waiting thread.
Every iteration of such a loop past the first represents a lost notification; thus with nonblocking monitors, one must be careful to ensure that too many notifications cannot be lost.

As an example of "hinting," consider a bank account in which a withdrawing thread will wait until the account has sufficient funds before proceeding

 '''monitor class''' ''Account'' {
     '''private''' ''int'' balance := 0
     '''invariant''' balance >= 0
     '''private''' ''NonblockingCondition'' balanceMayBeBigEnough
 
     '''public method''' withdraw(''int'' amount)
         '''precondition''' amount >= 0
     {
         '''while''' balance < amount '''do''' '''wait''' balanceMayBeBigEnough
         '''assert''' balance >= amount
         balance := balance - amount
     }
 
     '''public method''' deposit(''int'' amount)
         '''precondition''' amount >= 0
     {
         balance := balance + amount
         '''notify all''' balanceMayBeBigEnough
     }
 }

In this example, the condition being waited for is a function of the amount to be withdrawn, so it is impossible for a depositing thread to ''know'' that it made such a condition true. It makes sense in this case to allow each waiting thread into the monitor (one at a time) to check if its assertion is true.