Runtime & concurrency
Reveal answer and reasoning
The publication pattern writes data before a volatile ready flag and has the reader observe that flag before consuming the published data. The documented ordering of those operations supports reasoning about the one-shot handoff. It does not make several arbitrary updates indivisible, guarantee one total order for all program activity, or force every reader to observe a globally latest value immediately.
The portable companion performs the calls sequentially and therefore is not evidence of hardware contention. The desktop project adds bounded real producer and consumer behavior. A common wrong answer calls volatile a cache flush or a transaction around both fields, then uses one passing run without synchronization as proof it was unnecessary. Multiple writers, repeated generations, later mutation, and progress requirements need an explicit stronger protocol.
For long waits, choose an appropriate signal or async mechanism rather than making a bounded teaching spin into an unbounded production loop.
What a strong answer covers
- Ordering and visibility differ from compound atomicity.
- The sample is a one-shot publication protocol.
- Tests do not replace memory-order reasoning or progress policy.
Common pitfall
Explaining volatile as a universal cache flush, immediate freshness guarantee, or multi-field transaction.
Follow-up questions
- How would repeated snapshots change the state protocol?
- Why is a long busy wait a separate resource problem?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.