Monitor

A monitor groups protected state with its operations and controls entry so one execution agent runs the relevant protected code at a time. Clients use those operations instead of modifying internal fields arbitrarily.

The Mesa design distinguishes entry and internal procedures and also allows module procedures that do not need the monitor lock. Synchronization boundaries follow shared-state needs rather than forcing every computation in a module to retain the lock.

References: [1]

Holding the lock does not make a resource available. An allocator with insufficient space waits on a condition and releases the monitor lock so another agent can return resources, then reacquires it and checks the request again.

Monitor operations also maintain invariants. Temporary intermediate states must be repaired before returning or waiting so another entrant can rely on the protected constraints. Automatic locking does not determine those constraints for the programmer.

References: [1]

The Mesa paper contrasts Hoare’s immediate handoff with Mesa notification, where a waiter competes to reenter later and cannot assume the signaled condition was reserved for it. The name “monitor” alone does not identify the wakeup semantics.

Monitors do not automatically eliminate deadlock. Cyclic calls or a condition whose producer is blocked by an outer lock can still prevent progress. Nesting, resource order and condition protocols must be designed together.

References: [1]