Runtime & concurrency
Reveal answer and reasoning
A monitor notification is a prompt to reconsider protected state, not durable queue data or a reservation. The caller must own the monitor, check the predicate, and use Wait to release it while waiting. When resumed, it reacquires the monitor before continuing and should recheck the predicate in a loop. Another participant may have changed the state before the waiter can proceed.
The producer changes the queue and pulses under the same monitor. If data is already available, the consumer should not require a remembered pulse. A common wrong answer waits unconditionally and assumes an earlier Pulse will be stored for it, or replaces the predicate loop with a one-time notification check. Completion, cancellation, and an overall deadline are additional state and ownership decisions.
The portable companion models only predicate transitions; the external project is where real Wait/Pulse and owned-thread behavior are exercised.
What a strong answer covers
- The predicate is durable state; Pulse is not stored data.
- Wait releases and then reacquires the monitor.
- Recheck under the same synchronization discipline.
Common pitfall
Treating a pulse as a remembered message or an exclusive reservation of the desired condition.
Follow-up questions
- How would producer completion affect an empty wait?
- Why is a fresh timeout per wake different from one operation deadline?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.