Graceful close and linearization
What this concept is
A concurrent operation can be reasoned about as taking effect at a particular point while holding the lock. In this queue, append accepts a put, removal completes a get, and setting closed commits close. These points order operations that overlap in wall-clock time.
Why it matters here
“Close the queue” is ambiguous without a drain rule and a policy for blocked producers. This lab forbids new accepted work after close, preserves already accepted items, wakes all waiters, and reports Closed only when a get finds no remaining item.
Concrete example
The queue contains a,b and producer P waits to add c. Close obtains the lock, sets closed and wakes everyone. P reacquires the lock and raises Closed; a and b remain available for consumers. After both are removed, every subsequent get raises Closed. If P had appended before close instead, c would be accepted and included in the drain.
Common confusion / misconception
A return log is not the linearization order: a thread can be descheduled after it removes an item and log later than another consumer. FIFO means removal follows append order, not that consumers finish processing in that order. None is valid payload here; it is not a hidden shutdown signal.
How to use it
Draw open/closed state separately from empty/nonempty state. Make close idempotent. Wake blocked producers as well as consumers. A coordinator that wants every producer item accepted must join producers before closing, while consumers continue draining concurrently.
Check yourself
Does exactly-once removal guarantee exactly-once payment processing? No. A consumer may crash after removal or repeat a side effect. The queue has no acknowledgement, durability or retry protocol. What evidence would those stronger claims need?
Mini drill or application
Trace both orders of an overlapping put and close. Then trace two close calls and three empty consumers. State why waking only one consumer on closure can strand the others even though no data race corrupts state.
Read this only if stuck
Return to critical sections in OSTEP locks and mark the one state change where each operation takes effect.