03. Sleep/Wakeup, Semaphores & Monitors

Spinlocks and hardware atomic instructions provide the fundamental building blocks of synchronization, but they suffer from a crippling operational drawback: busy waiting.

While a thread spins in a while loop waiting for a lock, it burns 100% of its CPU time slice doing zero productive work. If the thread holding the lock is blocked waiting for disk I/O, network packets, or timer events, spinning on the CPU achieves nothing.

To build scalable systems, operating systems introduce blocking synchronization primitives: mechanisms that transition waiting threads out of the CPU execution pipeline and into the BLOCKED queue until the required condition is fulfilled.

1. Sleep & Wakeup: The Lost Wakeup Hazard

In Module 02, we explored how hardware atomic instructions enable spinlocks. While spinlocks provide rapid mutual exclusion for tiny, nanosecond critical sections on multiprocessor systems, they suffer from a fatal operational defect: busy waiting.

A spinning thread burns 100% of its CPU time slice executing instructions that achieve zero computational work. If the thread holding the lock is descheduled, preempted, or waiting on a slow peripheral (such as an NVMe disk read, network packet, or user keystroke), all competing threads on other cores spin fruitlessly, driving system temperature and power consumption to maximum while stalling progress.

To build scalable operating systems, software requires blocking primitives: mechanisms that allow a thread to release its CPU execution core voluntarily, enter a suspended state (BLOCKED or WAITING), and sleep until another execution thread notifies it that the desired event or resource has become available.

The Primitive Sleep and Wakeup Abstraction

The earliest blocking synchronization models relied on a pair of paired operating system primitives:

• sleep(): An atomic system call that causes the invoking process to suspend execution. The kernel removes the process from the scheduler's READY runqueue, updates its state to BLOCKED, and context-switches to another runnable thread.
• wakeup(pid): A system call taking a target process identifier (PID) as an argument. The kernel locates the target process's Process Control Block (PCB) and transitions its state from BLOCKED back to READY, placing it back onto the scheduler's runqueue.

The Classical Bounded-Buffer Producer-Consumer Model

To evaluate sleep() and wakeup(), consider the canonical Producer-Consumer problem (also called the Bounded-Buffer problem). Two processes share a common fixed-size buffer of capacity N:

• The Producer generates data items and deposits them into the buffer.
• The Consumer extracts data items from the buffer and consumes them.
• A shared integer variable count tracks the number of items currently residing in the buffer (initialized to 0).

/* FLAWED: Producer-Consumer Implementation Using Primitive Sleep and Wakeup */
#define N 100                   /* Number of slots in the shared buffer */
volatile int count = 0;         /* Number of data items currently in buffer */

void producer(void) {
    while (true) {
        item_t item = produce_item(); /* Generate next data item */

        if (count == N) {
            sleep();            /* Buffer is full: producer sleeps */
        }

        insert_item(item);      /* Deposit item into buffer */
        count++;                /* Increment item counter */

        if (count == 1) {
            wakeup(consumer_pid); /* Was empty: wake up sleeping consumer */
        }
    }
}

void consumer(void) {
    while (true) {
        if (count == 0) {
            sleep();            /* Buffer is empty: consumer sleeps */
        }

        item_t item = remove_item(); /* Extract item from buffer */
        count--;                /* Decrement item counter */

        if (count == N - 1) {
            wakeup(producer_pid); /* Was full: wake up sleeping producer */
        }

        consume_item(item);     /* Process the data item */
    }
}

The Anatomy of the Lost Wakeup Defect

This intuitive code contains a fatal synchronization flaw known as the Lost Wakeup Problem. The defect arises because the high-level test of count and the execution of sleep() are not atomic.

Step-by-Step Breakdown of the Race Interleaving:

1. Evaluation (Consumer): The buffer is currently empty (count == 0). The Consumer executes if (count == 0). The condition evaluates to true. The Consumer prepares to execute sleep().
2. Preemptive Interruption: Immediately after the comparison but before the CPU can execute the system call trap instruction for sleep(), the local APIC hardware timer generates an interrupt. The OS kernel context-switches from the Consumer to the Producer.
3. Production & Signal (Producer): The Producer runs. It produces an item, inserts it into slot 0, and increments count from 0 to 1.
4. The Stateless Wakeup Call: The Producer tests if (count == 1). Finding it true, the Producer calls wakeup(consumer_pid).
5. The Silent Signal Loss: Inside the kernel, the dispatcher looks up the Consumer's process entry. Because the Consumer was interrupted before calling sleep(), the Consumer is not sleeping—it is in the READY state on the runqueue! A primitive wakeup signal has no memory buffer; because the process is not in the BLOCKED state, the wakeup signal is discarded by the kernel and permanently lost.
6. The Fatal Sleep (Consumer): The Consumer is rescheduled. Its program counter resumes exactly where it was paused: at the sleep() instruction. It executes sleep(), moving its PCB to the BLOCKED queue. The Consumer is now asleep, waiting for a wakeup signal that was already delivered and lost.
7. Complete System Deadlock: The Producer continues executing cycles, generating items and incrementing count. Because the Consumer is asleep, no items are ever removed. Eventually, the buffer fills completely (count == N). The Producer tests if (count == N), finds it true, and calls sleep().

Result: Total, unrecoverable deadlock. Both processes are permanently asleep, neither can run to wake the other, and no exception, crash log, or fault is raised by the operating system.

Windows Dispatcher Objects: Eliminating Lost Wakeups via Events

In the Windows NT kernel architecture, threads do not sleep via raw, uncoordinated signals. Instead, synchronization is mediated through Kernel Dispatcher Objects.

To solve the producer-consumer signaling problem cleanly, Windows introduces the Event Object (CreateEvent), which represents a persistent kernel state machine rather than an ephemeral pulse:

• Auto-Reset Events (SynchronizationEvent): Initialized via CreateEvent(NULL, FALSE, FALSE, NULL). When signaled via SetEvent(), the kernel wakes exactly one thread waiting in WaitForSingleObject() and automatically resets the event state back to nonsignaled. If no thread is currently waiting, the event remains in the signaled state until a thread arrives and consumes it, completely averting the lost wakeup defect!
• Manual-Reset Events (NotificationEvent): Initialized via CreateEvent(NULL, TRUE, FALSE, NULL). When signaled via SetEvent(), the event remains signaled until explicitly cleared via ResetEvent(), waking all currently and subsequently waiting threads (broadcasting).

/* Safe Win32 Producer-Consumer Signaling via Auto-Reset Event */
#include <windows.h>

HANDLE hEventItemReady;

void init_events(void) {
    /* Auto-reset event (bManualReset = FALSE), initially non-signaled */
    hEventItemReady = CreateEvent(NULL, FALSE, FALSE, NULL);
}

void consumer_worker(void) {
    /* Atomic check & sleep: if event is signaled, consumes signal without sleeping */
    DWORD wait_result = WaitForSingleObject(hEventItemReady, INFINITE);
    if (wait_result == WAIT_OBJECT_0) {
        consume_item(); /* Safe: event reset to 0 atomically */
    }
}

void producer_worker(void) {
    produce_item();
    SetEvent(hEventItemReady); /* Signal remembered even if consumer not yet waiting */
}

The Failed Wakeup-Waiting Bit Patch

An intuitive early attempt to patch this flaw was to equip each process control block with a wakeup waiting bit:

• When a wakeup() signal was sent to a process that was not yet asleep, the kernel set the target's wakeup waiting bit to 1.
• When a process called sleep(), the kernel checked this bit. If the bit was 1, the kernel cleared the bit to 0 and allowed the process to continue running without sleeping.

2. Dijkstra's Semaphores (1965)

In 1965, Dutch computer scientist Edsger W. Dijkstra introduced the Semaphore in his pioneering work on the THE multiprogramming system. The semaphore permanently resolved the lost wakeup problem by replacing stateless signaling pulses with an atomic integer variable coupled with a sleep queue.

A semaphore is not simply a flag; it is an abstract data type with historical memory. It maintains an integer counter that records wakeups sent in the past for consumption in the future.

The Fundamental Atomic Primitives: P() and V()

In Dijkstra's original Dutch notation, the two fundamental operations were named P and V:

• P() (from proberen, "to test"): Often called down() or wait(). Decrements the semaphore value and blocks the calling thread if resources are unavailable.
• V() (from verhogen, "to increment"): Often called up(), signal(), or post(). Increments the semaphore value and wakes a sleeping thread if any are queued.

Mathematical Models: Classical Non-Negative vs. Signed Model

Operating system literature and production kernels define the integer counter behavior using two mathematical conventions:

The Implementation Paradox: Spinlocks Inside Sleep Locks

Students frequently encounter a conceptual puzzle: "If semaphores exist to eliminate busy waiting, how do we make the semaphore's own down() and up() routines atomic without busy waiting?"

The answer reveals a fundamental engineering pattern in kernel design: we use a spinlock to implement a sleep lock.

/* Production Kernel Semaphore Implementation */
typedef struct {
    spinlock_t lock;            /* Hardware spinlock protecting this struct */
    int count;                  /* Resource permit counter */
    struct list_head wait_list; /* FIFO queue of sleeping task_struct PCBs */
} semaphore_t;

void down(semaphore_t *sem) {
    spin_lock(&sem->lock);      /* 1. Acquire spinlock: protect counter and list */

    sem->count--;
    if (sem->count < 0) {
        /* 2. Enqueue calling thread into semaphore wait list */
        enqueue_current_task(&sem->wait_list);
        set_current_task_state(TASK_UNINTERRUPTIBLE);

        spin_unlock(&sem->lock);/* 3. RELEASE spinlock BEFORE invoking scheduler! */
        schedule();             /* 4. Voluntary context switch: thread sleeps */
        return;
    }

    spin_unlock(&sem->lock);    /* Resource acquired immediately; release spinlock */
}

void up(semaphore_t *sem) {
    spin_lock(&sem->lock);      /* 1. Acquire spinlock */

    sem->count++;
    if (sem->count ≤ 0) {
        /* 2. Dequeue first sleeping thread from FIFO list */
        struct task_struct *task = dequeue_task(&sem->wait_list);
        wake_up_task(task);     /* 3. Transition PCB to TASK_RUNNING */
    }

    spin_unlock(&sem->lock);    /* 4. Release spinlock */
}

Taxonomy of Semaphore Use Cases

Depending on initial configuration, semaphores fulfill three distinct architectural roles:

1. Binary Semaphores (Mutexes)

• Initialization: Initialized to 1.
• Behavior: Constrained to values 1 (unlocked) and 0 (locked). Ensures that only one thread can execute within a critical section at any instant.
• Critical Architectural Distinction (Binary Semaphore vs. Mutex): In modern systems, a true Mutex has ownership semantics: only the thread that called lock() is legally allowed to call unlock(). If a thread attempts to unlock a mutex it does not own, the kernel throws an exception. Furthermore, mutexes support Priority Inheritance to eliminate priority inversion.
  In contrast, a semaphore has no concept of ownership: any thread (or even an asynchronous hardware interrupt service routine) can call up() to signal and release a binary semaphore.

2. Counting Semaphores (Resource Pool Management)

• Initialization: Initialized to N, where N > 1 represents the total number of identical units in a shared resource pool.
• Applications: Database connection pools (e.g., maximum 50 concurrent PostgreSQL connections), DMA buffer slots, or memory allocation pools. Each down() allocates a permit; each up() returns a permit to the pool. When all permits are exhausted, subsequent requesters block automatically.

3. Signaling & Rendezvous Semaphores

• Initialization: Initialized to 0.
• Applications: Enforcing strict sequential ordering between asynchronous execution flows. Thread B calls down() and blocks immediately. Thread A carries out hardware initialization or loads data from disk, and then executes up(). This guarantees that Thread B cannot execute its post-requisite code until Thread A has completed its pre-requisite code.

Windows Kernel Semaphores & Mutexes

In the Windows operating system, both semaphores and mutexes are implemented as first-class Kernel Executive Objects accessible via Win32 API handles.

1. Windows Counting Semaphores (CreateSemaphore)

A Windows semaphore object maintains a 32-bit signed integer count restricted between 0 and a specified lMaximumCount:

/* Win32 Counting Semaphore Creation */
HANDLE hSem = CreateSemaphore(
    NULL,           /* Default security attributes */
    3,              /* Initial count (e.g., 3 vacant buffer slots) */
    3,              /* Maximum count capacity */
    "Local\\BufferSem" /* Optional name for cross-process sharing */
);

/* P() / down() equivalent: */
WaitForSingleObject(hSem, INFINITE);

/* V() / up() equivalent: releases 1 permit and captures previous count */
LONG prev_count;
ReleaseSemaphore(hSem, 1, &prev_count);

2. Windows Mutexes & The Abandoned Mutex Safety Feature

A Windows Mutex (CreateMutex) is strictly a binary mutual exclusion primitive with ownership tracking. Only the thread that successfully acquired the mutex via a wait function can release it with ReleaseMutex().

Critically, Windows incorporates a vital kernel-level safety mechanism absent in raw POSIX semaphores: Automatic Abandoned Mutex Detection:

DWORD wait_result = WaitForSingleObject(hMutex, INFINITE);
if (wait_result == WAIT_ABANDONED) {
    /* The lock was acquired, BUT the previous owner died mid-critical section! */
    /* Data structure may be partially corrupted; thread must audit consistency */
}

3. Kernel Sleep Queues & Fast User-Mode Synchronization

In Section 2, we analyzed how operating system kernels implement semaphores and sleep locks using internal spinlocks to guard wait queues. However, that design introduces a major performance bottleneck for user-space applications: every lock acquisition and release requires a kernel system call.

A system call trap instruction (syscall on x86-64 Linux, syscall / sysenter on Windows, svc on ARM) forces the processor through an involuntary privilege boundary transition from Ring 3 (User Space) to Ring 0 (Kernel Mode). The CPU flushes pipeline queues, changes the stack pointer to the kernel stack, updates page-table permissions, and validates parameters. This sequence consumes 100 to 300 nanoseconds per invocation.

The Empirical Uncontended Invariant

Extensive benchmarking of production software (databases, web servers, GUI toolkits) reveals a universal concurrency profile:

Paying a 200 ns system call penalty millions of times per second just to set an uncontended integer flag in memory is an immense waste of CPU cycles. Conversely, relying purely on spinlocks in user space wastes entire scheduling quanta when a lock is contended.

To bridge this performance divide, modern operating systems implement hybrid user/kernel synchronization:

• Linux: The unified futex (Fast Userspace Mutex) architecture.
• Windows NT: The trio of CRITICAL_SECTION, SRWLOCK, and WaitOnAddress.

The Linux Futex Architecture

A Linux futex is an ordinary 32-bit integer allocated in user-space virtual memory. The fast-path executes an atomic Compare-and-Swap (cmpxchg) in Ring 3 (~5 ns). Only if contention occurs does the thread drop into Ring 0 via:

syscall(SYS_futex, uaddr, FUTEX_WAIT, val, timeout, NULL, 0);

The kernel verifies that *uaddr == val atomically under a bucket spinlock before putting the task to sleep on a kernel hash table (futex_queues), eliminating lost wakeups.

The Windows User-Mode Evolution: CRITICAL_SECTION, SRWLock, and WaitOnAddress

Windows pioneered user-mode hybrid locking and has developed three distinct generations of high-performance synchronization:

Deep Microarchitectural Comparison: Linux vs. Windows

Concrete Implementation: Building a Fast Mutex with Windows WaitOnAddress

We can construct an industrial-grade, pointer-sized mutex on Windows without allocating Win32 handles or kernel objects using WaitOnAddress:

/* Production Windows Fast Mutex Using WaitOnAddress (synchapi.h) */
#include <windows.h>
#include <synchapi.h>

typedef struct {
    volatile LONG state; /* 0 = Free, 1 = Held (no waiters), 2 = Held (waiters present) */
} win_fast_mutex_t;

void win_fast_mutex_lock(win_fast_mutex_t *m) {
    /* 1. FAST PATH: Optimistically attempt atomic CAS 0 -> 1 in user space */
    LONG prev = InterlockedCompareExchange(&m->state, 1, 0);
    if (prev == 0) {
        return; /* Lock acquired in Ring 3! ~5 nanoseconds, zero syscalls */
    }

    /* 2. SLOW PATH: Contention detected */
    while (true) {
        /* Announce that waiters exist (state = 2) */
        if (prev == 2 || InterlockedCompareExchange(&m->state, 2, 1) != 0) {
            /* Sleep in kernel if state is still 2 */
            LONG undesired = 2;
            WaitOnAddress(&m->state, &undesired, sizeof(LONG), INFINITE);
        }
        /* Try to acquire upon wakeup */
        prev = InterlockedExchange(&m->state, 2);
        if (prev == 0) break;
    }
}

void win_fast_mutex_unlock(win_fast_mutex_t *m) {
    /* Fast path: If state was 1, no waiters exist. Reset to 0 in user space */
    if (InterlockedExchange(&m->state, 0) == 2) {
        /* Waiters were present; wake up exactly one waiting thread */
        WakeByAddressSingle((PVOID)&m->state);
    }
}

4. Monitors & Condition Variables

While semaphores and futexes provide powerful low-level primitives for operating system kernels, building large-scale, correct multi-threaded applications using unstructured semaphores is notoriously error-prone.

Consider the fragility of semaphore code in production systems:

• Omission Defects: A developer who writes down(&mutex) but omits up(&mutex) due to an early return or uncaught exception leaves the critical region permanently locked, deadlocking the application.
• Inversion Hazards: Swapping the sequence of two semaphores (e.g., acquiring a resource lock before checking buffer bounds) introduces catastrophic circular wait deadlocks.
• Scattered Invariants: Semaphore operations are dispersed across disparate functions and files, making formal verification of program correctness nearly impossible.

To resolve these architectural weaknesses, C. A. R. Hoare (1974) and Per Brinch Hansen (1975) pioneered the Monitor: a high-level programming language construct that encapsulates shared variables, access procedures, and synchronization gates into a unified, compiler-enforced boundary.

The Anatomy of a Monitor

A monitor is an object-oriented or module-level abstraction consisting of:

1. Private Shared State: Internal variables (buffers, counters, queues) that can only be accessed by procedures defined inside the monitor. External threads cannot read or write them directly.
2. Public Interface Procedures: Methods that external threads call to interact with the shared data.
3. Compiler-Enforced Mutual Exclusion: The language compiler automatically injects synchronization guards at procedure entry and exit. At most one thread may be actively executing inside any procedure of the monitor at any given instant.

Condition Variables: Solving the In-Monitor Sleep Problem

Compiler-enforced mutual exclusion creates a critical synchronization dilemma:

The In-Monitor Sleep Dilemma: If Thread 1 enters a monitor method and discovers that a necessary condition is not met (e.g., the bounded buffer is full), it cannot simply execute a standard sleep() system call. If Thread 1 went to sleep while holding the monitor's mutual exclusion lock, no other thread could ever enter the monitor. A consumer could never enter to extract an item, and the producer would sleep forever, freezing the application permanently.

To resolve this, monitors introduce Condition Variables (e.g., cond_t in C/POSIX, Condition in Java/C#):

• wait(&cond, &mutex): Atomically releases the monitor lock and suspends the calling thread on the condition variable's wait queue. Because the monitor lock is released, other threads can now enter the monitor to mutate state. When the sleeping thread is eventually signaled and awakened, it automatically re-acquires the monitor lock before wait() returns to user code.
• signal(&cond): Wakes up exactly one thread waiting on the condition variable. If no threads are waiting, the signal is quietly discarded with zero side effects.
• broadcast(&cond): Wakes up all threads currently waiting on the condition variable.

Canonical Bounded-Buffer Monitor Implementation

Below is the classical bounded-buffer implemented via an explicit monitor pattern in C using POSIX threads:

/* Thread-Safe Bounded-Buffer Monitor using POSIX Threads */
#include <pthread.h>
#include <stdbool.h>

#define BUFFER_SIZE 100

typedef struct {
    int buffer[BUFFER_SIZE];
    int count;                  /* Number of populated slots */
    int head;                   /* Write index pointer */
    int tail;                   /* Read index pointer */
    pthread_mutex_t lock;       /* Monitor entry gatekeeper */
    pthread_cond_t not_full;    /* Condition: buffer has room for insert */
    pthread_cond_t not_empty;   /* Condition: buffer has item for removal */
} bounded_buffer_monitor_t;

void monitor_insert(bounded_buffer_monitor_t *m, int item) {
    pthread_mutex_lock(&m->lock); /* 1. Enter Monitor (Acquire Mutex) */

    /* 2. Wait while condition is not met (MESA INVARIANT: while loop!) */
    while (m->count == BUFFER_SIZE) {
        pthread_cond_wait(&m->not_full, &m->lock); /* Releases lock & sleeps */
    }

    /* 3. Mutate private state (Guaranteed Exclusive Access) */
    m->buffer[m->head] = item;
    m->head = (m->head + 1) % BUFFER_SIZE;
    m->count++;

    /* 4. Signal waiting consumers that buffer is no longer empty */
    pthread_cond_signal(&m->not_empty);

    pthread_mutex_unlock(&m->lock); /* 5. Exit Monitor (Release Mutex) */
}

int monitor_remove(bounded_buffer_monitor_t *m) {
    pthread_mutex_lock(&m->lock); /* 1. Enter Monitor */

    while (m->count == 0) {
        pthread_cond_wait(&m->not_empty, &m->lock);
    }

    int item = m->buffer[m->tail];
    m->tail = (m->tail + 1) % BUFFER_SIZE;
    m->count--;

    pthread_cond_signal(&m->not_full); /* Signal waiting producers */

    pthread_mutex_unlock(&m->lock); /* Exit Monitor */
    return item;
}

Signaling Semantics: Hoare vs. Mesa vs. Brinch Hansen

When a thread inside a monitor calls signal(&cond) and wakes a suspended thread, a fundamental concurrency question arises: Which thread is allowed to execute next? Both the signaling thread and the awakened thread now demand access to the monitor, but the monitor invariant permits only one thread inside!

This problem divided computer scientists into three distinct schools of monitor semantics:

if (count == N)
    wait(&cond);

while (count == N)
    wait(&cond);

Why You Must Always Use a WHILE Loop (Spurious Wakeups)

In production systems programming, replacing while (!condition) with if (!condition) around a condition wait is considered a critical bug. There are three distinct engineering reasons why threads must always re-check conditions in a loop:

1. Mesa Semantics (Intervening Threads): Under Mesa semantics, signaling only makes the waiter runnable. By the time the awakened thread is scheduled and regains the monitor lock, a third thread may have entered the monitor and consumed the available resource.
2. Broadcast Waking (Thundering Herd): If a thread calls pthread_cond_broadcast(), multiple sleeping threads wake up. The first thread to acquire the lock claims the available slot; all subsequent threads awaken to find the condition false once again.
3. Spurious Wakeups (Kernel Micro-architecture): Under POSIX specifications and operating system implementations (Linux, macOS, Windows), a condition variable wait can return successfully even if NO thread signaled the condition variable!
   Spurious wakeups occur due to low-level kernel implementation constraints: OS signals (such as SIGINT or SIGALRM) interrupting a sleep primitive, multi-core cache invalidation races in the futex hash table, or context switch preemption during wait queue rebalancing.

/* NEVER WRITE THIS (BUG): */
if (!condition_is_met) {
    pthread_cond_wait(&cond, &mutex);
}

/* ALWAYS WRITE THIS (CORRECT & SAFE): */
while (!condition_is_met) {
    pthread_cond_wait(&cond, &mutex);
}

Windows Native Condition Variables (CONDITION_VARIABLE)

In Windows Vista, Microsoft introduced native support for condition variables to match POSIX capabilities without requiring handle allocations:

• Allocation: Consumes only a single pointer (CONDITION_VARIABLE cv;). Initialized statically via CONDITION_VARIABLE_INIT or dynamically via InitializeConditionVariable(&cv).
• Dual Mutex Support: Unlike POSIX which binds condition variables strictly to pthread_mutex_t, Windows condition variables can atomically unlock and sleep over either a Critical Section or an SRW Lock:
  • SleepConditionVariableCS(&cv, &cs, dwMilliseconds): Releases Critical Section, sleeps, and re-acquires upon wake.
  • SleepConditionVariableSRW(&cv, &srw, dwMilliseconds, flags): Releases SRW lock (shared or exclusive), sleeps, and re-acquires.
• Signaling Primitives:
  • WakeConditionVariable(&cv): Equivalent to pthread_cond_signal (wakes one waiter).
  • WakeAllConditionVariable(&cv): Equivalent to pthread_cond_broadcast (wakes all waiters).

/* Windows Bounded-Buffer Monitor with SRWLock and CONDITION_VARIABLE */
#include <windows.h>
#include <stdbool.h>

#define BUFFER_CAPACITY 50

typedef struct {
    int buffer[BUFFER_CAPACITY];
    int count, head, tail;
    SRWLOCK lock;                       /* Fast user-mode lock */
    CONDITION_VARIABLE cv_not_full;     /* Condition: room for producer */
    CONDITION_VARIABLE cv_not_empty;    /* Condition: items for consumer */
} win_monitor_t;

void win_monitor_insert(win_monitor_t *m, int item) {
    AcquireSRWLockExclusive(&m->lock);

    /* MESA SEMANTICS INVARIANT: Mandatory while loop re-check */
    while (m->count == BUFFER_CAPACITY) {
        SleepConditionVariableSRW(&m->cv_not_full, &m->lock, INFINITE, 0);
    }

    m->buffer[m->head] = item;
    m->head = (m->head + 1) % BUFFER_CAPACITY;
    m->count++;

    WakeConditionVariable(&m->cv_not_empty); /* Wake one consumer */
    ReleaseSRWLockExclusive(&m->lock);
}

int win_monitor_remove(win_monitor_t *m) {
    AcquireSRWLockExclusive(&m->lock);

    while (m->count == 0) {
        SleepConditionVariableSRW(&m->cv_not_empty, &m->lock, INFINITE, 0);
    }

    int item = m->buffer[m->tail];
    m->tail = (m->tail + 1) % BUFFER_CAPACITY;
    m->count--;

    WakeConditionVariable(&m->cv_not_full); /* Wake one producer */
    ReleaseSRWLockExclusive(&m->lock);
    return item;
}

Windows condition variables strictly adhere to Mesa semantics (Signal-and-Continue). The thread calling WakeConditionVariable retains the SRW lock and continues executing; the awakened thread competes with incoming threads when re-acquiring the lock. Consequently, the while loop predicate guard is strictly mandatory on Windows.