監視器 (程序同步化)

东尼·霍尔与泊·派克·汉森最早提出的是阻塞式条件变量. 发出通知(signaling)的线程必须等待被通知(signaled)的线程放弃占用管程（或者离开管程，或者等待某个条件变量）。使用阻塞式条件变量的管程被称为霍尔风格(Hoare-style)管程或通知且急迫等待(signal-and-urgent-wait)管程.

霍尔风格管程，有两个条件变量a与b. 根据Buhr et al.

设每个管程对象有两个线程队列

• e是入口队列
• s是已经发出通知的线程队列.

设对于每个条件变量${\displaystyle c}$, 有一个线程队列

• ${\displaystyle c}$.q, 所有等待${\displaystyle c}$的线程的队列

这些队列会公平(fair)调度，甚至实现为先进先出.

各个环节实现如下 (规定各个环节彼此是互斥的. 因此restart一个线程，并不会立即执行，直到当前环节完成)

 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 ${\displaystyle c}$ :
    add this thread to ${\displaystyle c}$.q
    schedule
    block this thread

 signal ${\displaystyle c}$ :
    if there is a thread waiting on ${\displaystyle c}$.q
        select and remove one such thread t from ${\displaystyle c}$.q
        (t is called "the signaled thread")
        add this thread to s
        restart t
        (so t will occupy the monitor next)
        block this thread

  schedule :
    if there is a thread on s
      select and remove one thread from s and restart it
      (this thread will occupy the monitor next)
    else if there is a thread on e
      select and remove one thread from e and restart it
      (this thread will occupy the monitor next)
    else
      unlock the monitor
      (the monitor will become unoccupied)

schedule子程序选择下一个线程占用管程，如果没有候选的线程则解锁管程.

发出通知的线程转入等待，但会比在线程入口的队列有更高优先权被调度，这称为"通知且急迫等待"。另一种方案是"通知且等待"，不设s队列，发出通知的线程进入e队列等待.

某些实现提供了signal and return操作.

 signal ${\displaystyle c}$ and return :
    if there is a thread waiting on ${\displaystyle c}$.q
        select and remove one such thread t from ${\displaystyle c}$.q
        (t is called "the signaled thread")
        restart t
        (so t will occupy the monitor next)
    else
        schedule
    return from the method

如果在每个signal ${\displaystyle c}$的开始处，${\displaystyle P_{c}}$为真, 那么在wait ${\displaystyle c}$的结尾处${\displaystyle P_{c}}$也应为真。 这可由契约式设计来表达. 在这些契约中, ${\displaystyle I}$是管程的不变量.

 enter the monitor:
    postcondition ${\displaystyle I}$

 leave the monitor:
    precondition ${\displaystyle I}$

 wait ${\displaystyle c}$ :
    precondition ${\displaystyle I}$
    modifies the state of the monitor
    postcondition ${\displaystyle P_{c}}$ and ${\displaystyle I}$

 signal ${\displaystyle c}$ :
    precondition ${\displaystyle P_{c}}$ and ${\displaystyle I}$
    modifies the state of the monitor
    postcondition ${\displaystyle I}$

 signal ${\displaystyle c}$ and return :
    precondition ${\displaystyle P_{c}}$ and ${\displaystyle I}$

在上述契约中，设定${\displaystyle I}$ and ${\displaystyle P_{c}}$不依赖于任何队列长度.

如果可以查询条件变量所关联的队列上处于等待的线程的数量，可以使用更为复杂的契约。例如，一个有用的契约对，无需不变量就允许管程的占用被传递

 wait ${\displaystyle c}$ :
    precondition ${\displaystyle I}$
    modifies the state of the monitor
    postcondition ${\displaystyle P_{c}}$

 signal ${\displaystyle c}$
    precondition (not empty(${\displaystyle c}$) and ${\displaystyle P_{c}}$) or (empty(${\displaystyle c}$) and ${\displaystyle I}$)
    modifies the state of the monitor
    postcondition ${\displaystyle I}$

参见 Howard[3] and Buhr et al.,[4]有更多信息。

特别需要注意，断言${\displaystyle P_{c}}$完全是由编程者负责，编程者需要在头脑中保持对断言有一致的(consistent)定义。

下例是用阻塞式管程实现一个有界的、线程安全的栈. 即多线程并发访问这个栈时，在任意时刻最多只有一个线程执行push或pop操作。

monitor class SharedStack {
  private const capacity := 10
  private int[capacity] A
  private int size := 0
  invariant 0 <= size and size <= capacity
  private BlockingCondition theStackIsNotEmpty /* associated with 0 < size and size <= capacity */
  private BlockingCondition theStackIsNotFull /* associated with 0 <= size and size < capacity */

  public method push(int value)
  {
    if size = capacity then wait theStackIsNotFull
    assert 0 <= size and size < capacity
    A[size] := value ; size := size + 1
    assert 0 < size and size <= capacity
    signal theStackIsNotEmpty and return
  }

  public method int pop()
  {
    if size = 0 then wait theStackIsNotEmpty
    assert 0 < size and size <= capacity
    size := size - 1 ;
    assert 0 <= size and size < capacity
    signal theStackIsNotFull  and return A[size]
  }
}

非阻塞式条件变量 (也称作"Mesa风格"条件变量或"通知且继续"(signal and continue)条件变量), 发出通知的线程并不会失去管程的占用权. 被通知的线程将会被移入管程入口的e队列. 不需要s队列。pthread中的条件变量就是这种非阻塞式：要先显式获得互斥加锁（pthread_mutex_lock），调用pthread_cond_wait时隐式对互斥锁解锁并进入阻塞睡眠，被唤醒后还要再显式获得互斥加锁。

Mesa风格的管程，有两个条件变量a与b

非阻塞式条件变量经常把signal操作称作notify — . 也常用notify all操作把该条件变量关联的队列上所有的线程移入e队列.

各种操作定义如下. (规定各种操作都是互斥的，线程被restart并不会立即执行，直到发起的操作完成)

 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 ${\displaystyle c}$ :
    add this thread to ${\displaystyle c}$.q
    schedule
    block this thread

 notify ${\displaystyle c}$ :
    if there is a thread waiting on ${\displaystyle c}$.q
        select and remove one thread t from ${\displaystyle c}$.q
        (t is called "the notified thread")
        move t to e

 notify all ${\displaystyle c}$ :
    move all threads waiting on ${\displaystyle 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

一个变种实现，把被通知的(notified)线程移入队列w, 具有比e更高的优先级. 参见 Howard[3] and Buhr et al.[4]。

可以把断言${\displaystyle P_{c}}$关联于条件变量${\displaystyle c}$，因而${\displaystyle P_{c}}$wait ${\displaystyle c}$返回时期望为真. 但是，这必须确保发出通知的线程结束到被通知的线程恢复执行这一时间段内，${\displaystyle P_{c}}$保持为真. 这一时间段内可能会有其它线程占用过管程。因此通常必须把每个wait操作用一个循环包裹起来：

  while not( ${\displaystyle P}$ ) do wait c

其中${\displaystyle P}$是一个条件，强于${\displaystyle P_{c}}$. 操作notify ${\displaystyle c}$与notify all ${\displaystyle c}$被视为"提示"(hints)某个等待队列的${\displaystyle P}$可能为真. 上述循环的每一次迭代，表示失去了一次通知。

一个银行账户的例子，取款线程将等待资金已经完成注入账户之后再执行。

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

在这个例子中，被等待的条件是取款金额大于存款余额，存款线程不可能知道取款金额，因此存款线程发出的通知的意涵是提示所有等待中的取款线程检查它自身的断言是否为真。

Java风格管程

Java程序设计语言中，每个对象都可以作为一个管程。需要互斥使用的方法必须明确标示关键字synchronized。 代码块也可以标示关键字synchronized。

不使用明确的条件变量, Java的这种管程在入口队列之外，使用单独的条件等待队列. 所有等待的线程进入这个队列，所有的notify与notify all操作也施加于这个队列。这种方法已经被其它程序设计语言使用，如C#。

另一种实现方法是忽略signal操作。当一个线程交出管程占用权(returning或者waiting)，所有处于等待状态的线程的断言都被检查，直到发现某个线程的断言为真。在这种系统中，不需要条件变量，但是断言必须明确编码。 wait操作的契约：

 wait ${\displaystyle P}$:
    precondition ${\displaystyle I}$
    modifies the state of the monitor
    postcondition ${\displaystyle P}$ and ${\displaystyle I}$

pthread中，条件变量实际上是一个阻塞线程处于睡眠状态的线程队列。每个条件变量都必须与一个（且建议只能是一个）互斥锁配套使用。一个线程首先获得互斥锁，然后检查或者修改“条件”；如果条件不成立，则调用pthread_cond_wait()，依次实施3个操作：

1. 对当前互斥锁解锁（以便其它线程可以访问或者修改“条件”）
2. 把线程自身阻塞挂起到互斥锁的线程队列中
3. 被其它线程的信号从互斥锁的线程队列唤醒后，对当前配套的互斥锁申请加锁，如果加锁未能成功，则阻塞挂起到当前互斥锁上。pthread_cond_wait() 函数将不返回直到线程获得配套的互斥锁。

线程离开“条件”的临界区时，必须对当前互斥锁执行解锁。

从Windows Vista开始，Windows Thread用critical section与条件变量配合，二者均为用户态同步对象，不能跨进程使用。使用API函数InitializeConditionVariable创建条件变量；函数SleepConditionVariableCS用于释放临界区并阻塞在条件变量上；函数WakeConditionVariable或 WakeAllConditionVariable唤醒挂在条件变量上的线程。

也可配套使用读写锁（Slim Reader/Writer (SRW) Locks）。

假唤醒是POSIX Threads与Windows API使用条件变量时可能发生的复杂情形。一个挂在条件变量上的线程被signaled，正在等待的条件仍有可能不成立。假唤醒（Spurious wakeup）是指即使没有线程signaled该条件变量，挂在该条件变量上的线程却被唤醒。[5]因此，应该用while循环包围条件变量等待操作：

/* In any waiting thread: */
while(!buf->full)
	wait(&buf->cond, &buf->lock);

/* In any other thread: */
if(buf->n >= buf->size){
	buf->full = 1;
	signal(&buf->cond);
}

被偷走的唤醒是POSIX Threads与Windows API使用条件变量时，线程调用g_cond_signal时，另一个线程已经获取了mutex使得期望的条件不再满足，因此被唤醒的线程面临着条件不成立。[6][7]因此，应该用while循环包围条件变量等待操作.