Runtime & concurrency
Reveal answer and reasoning
Protect queue state and the producer-completed flag with one private monitor. A consumer checks whether an item exists, whether no further items can arrive, or whether the operation deadline expired before deciding to wait. Use a predicate loop, compute remaining time from a monotonic deadline after each wake, and change state plus notification under the same synchronization discipline.
Own every worker and give tests bounded joins and propagated failures. Test preexisting data, data arriving after waiting, empty successful completion, timeout, and any explicit cancellation wakeup contract. The wrong design waits unconditionally, resets an unlimited full timeout after every signal, or assumes Pulse stores an item for a future waiter. A channel may be a clearer abstraction when its completion and cancellation protocol matches the application, but using one still requires clear producer completion ownership rather than hiding lifecycle decisions behind a queue API.
What a strong answer covers
- Protect predicate and completion state together.
- Use remaining overall deadline rather than resetting it.
- Bound and await every owned worker.
Common pitfall
Implementing an unbounded wait or a reset-per-wake timeout while claiming an overall operation budget.
Follow-up questions
- How would cancellation wake the waiter safely?
- When would Channels simplify the protocol?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.