Senior · Concurrency
Happens-before, not wishful timing
Can another goroutine safely read a value after sleeping?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Time passing does not create a synchronization relationship. A send/receive, mutex unlock/lock or documented atomic operation can establish ordering; a sleep cannot.
The Go memory model defines the guarantees for correctly synchronized programs. Publishing a pointer before fully initializing the object can expose unsafe state without proper synchronization.
Use the smallest synchronization protocol that also documents ownership. An atomic flag only helps when the associated access obeys the memory model; replacing one field with an atomic does not automatically protect the whole object.
Common trap
A program that appears correct on your laptop can still contain a data race.
Try it
Publish a configuration snapshot to readers without mutating the published snapshot.
Worked solution
Fully construct an immutable snapshot, then publish it through a mutex or an atomic pointer/value with a consistent stored type. Replace with a new snapshot on updates. Never mutate an already published map concurrently.
Change the constraint
How do you handle a snapshot that contains mutable slices or nested maps?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.