Monitors in OS Synchronization

Introduction

A monitor is a high-level synchronization construct used to organize safe access to shared data. It combines shared state, procedures, mutual exclusion, and condition-variable based waiting in one protected structure.

The main idea is that shared data should not be touched directly from outside. Threads should access it only through monitor procedures, where synchronization rules are built into the design.

Why Monitors Are Needed

Manual synchronization can become difficult when lock and unlock calls are spread across many parts of a program. A programmer may forget to unlock, access shared state without the correct lock, or protect the wrong region of code.

A monitor reduces this risk by keeping the shared data and the procedures that use it together. Instead of asking every caller to remember the locking details, the monitor makes controlled access the normal path.

This makes synchronization easier to reason about than scattered semaphore or lock usage.

Monitor Definition

A monitor is a structured synchronization abstraction that contains:

• Shared data: The protected state that should not be accessed directly.

• Procedures or methods: Controlled functions that read or update the shared data.

• Implicit mutual exclusion: At most one thread executes monitor code at a time.

• Condition variables: Waiting points used when the shared state is not ready.

The word “implicit” means the mutual exclusion behavior is part of the monitor abstraction. The programmer does not manually place lock and unlock calls around every outside access.

How a Monitor Works

Only one thread can be active inside a monitor at a time. Other threads trying to enter monitor procedures must wait until the monitor becomes available.

The basic flow is:

• Enter monitor procedure: A thread calls a controlled procedure.

• Get exclusive access: The monitor allows only one active thread inside.

• Check or update state: The thread safely reads or changes shared data.

• Wait if needed: If the required state is not ready, the thread waits on a condition variable.

• Signal after state change: Another thread can later update the state and signal a waiter.

This structure keeps shared data access disciplined. Threads use monitor procedures instead of directly touching the internal state.

Condition Variables Inside Monitors

A thread may enter a monitor and still be unable to continue. For example, a consumer may enter a bounded-buffer monitor and find that the buffer is empty.

In that case, the thread waits on a condition variable. Waiting releases monitor access according to the monitor’s rules, so another thread can enter and change the state.

For example, a producer may later add an item and signal the condition variable. The waiting consumer wakes, regains monitor access, rechecks the condition, and continues only if the state is now suitable.

The monitor protects the state. The condition variable handles sleeping and waking.

Monitor vs Semaphore

Semaphores and monitors both support synchronization, but they work at different levels.

A semaphore focuses on counting or signaling. A monitor focuses on structure: protected state plus safe procedures.

Hoare-Style and Mesa-Style Monitors

Monitor behavior can be described using two common signaling styles.

In Hoare-style semantics, a signal hands control directly to the waiting thread. In Mesa-style semantics, the signal only wakes the waiter, and another thread may run before that waiter resumes.

Mesa-style behavior is common in practical systems. Because the shared state may change before the awakened thread runs, the waiter should recheck the condition after waking.

Summary

A monitor packages shared data, controlled procedures, mutual exclusion, and condition-variable waiting into one protected structure. It helps reduce scattered locking mistakes by making safe access part of the abstraction.

Semaphores focus on counting and signaling, while monitors focus on encapsulation and controlled access. The clean memory line is: a monitor means protected state plus monitor procedures plus condition variables for waiting.