A tick goroutine writes Player fields through a *Player while another does snap := *p — is that safe?

## What `snap := *p` compiles to A struct copy in Go is not a single machine instruction and is not guaranteed to be atomic at any size beyond a single word. `snap := *p` for a `Player{X, Y int; Name string}` becomes several loads from the pointed-to memory and several stores into `snap`. If another goroutine is writing those same fields concurrently, the loads and stores interleave arbitrarily. The visible failure is a **torn value**: a snapshot whose `X` comes from the update the tick goroutine just finished and whose `Y` is still the previous tick's. No individual field is corrupt; the *combination* never existed in the program's history. In a game-server tick loop that shows up as an entity that appears to have teleported diagonally, or a position that fails an invariant check that the writer never violated. Go's memory model does not rescue you. It defines what a correctly synchronised program observes and states that a program with a data race is faulty; for races it offers only limited guarantees on word-sized accesses, and none at all for a multi-word struct copy. Nothing in the language promises the copy is a snapshot. ## Confirming it: the race detector Build or run with `-race` — `go test -race ./...`, `go run -race .`, or `go build -race` for a canary binary. The detector instruments memory accesses and maintains happens-before information at run time; when two goroutines touch the same address without an ordering between them and at least one writes, it prints a report naming the reading goroutine's stack, the writing goroutine's stack, and where each goroutine was created. Two properties matter for how you use it: - It is a **dynamic** tool. It finds races on the interleavings that actually occurred during that run. A clean run over a code path you never exercised proves nothing, which is why teams run their whole test suite under `-race` in CI rather than spot-checking. - It costs roughly an order of magnitude in memory and several times the CPU, so it is a test and staging tool, not a production build — though a single `-race` canary instance is a legitimate tactic for a race you cannot reproduce locally. If the race is in the tick loop's hot path, this is also where the "make it faster without changing behaviour" instinct gets people into trouble: removing a lock because a profile blamed it, on the argument that "the reader only reads a copy", is exactly the change this question is about. ## Fix one: synchronise The boring, correct answer is a mutex owned by the entity or by the world: ```go mu.RLock() snap := *p mu.RUnlock() ``` with the tick goroutine taking `mu.Lock()` around its writes. A `sync.RWMutex` lets many readers copy concurrently, which fits a tick loop with one writer and several readers — but `RWMutex` has more overhead per operation than a plain `Mutex` and only pays off when read critical sections are long enough or contended enough to matter. Measure rather than assume. ## Fix two: publish immutable snapshots The lock-free shape that suits a single-writer tick loop is copy-on-write publication. The tick goroutine builds the next state privately, then swaps in a pointer to it: ```go var cur atomic.Pointer[Player] // tick goroutine, the only writer next := *cur.Load() next.X, next.Y = nx, ny cur.Store(&next) // any reader snap := *cur.Load() ``` The crucial discipline is that **a published `Player` is never mutated again**. Readers only ever dereference a pointer to a frozen struct, and the atomic pointer load/store provides the ordering, so there is no race and readers never block. The cost is one allocation per tick per entity and slightly staler reads. Note also what `atomic.Pointer` does *not* do: it makes the pointer swap atomic, not the struct. Storing a pointer and then editing the struct behind it puts the race straight back. A third shape, and often the most Go-ish, is to stop sharing: let the tick goroutine own the entities outright and answer queries over a channel, so no other goroutine holds a `*Player` at all. That trades throughput for a design where the race cannot be written. ## The reasoning to demonstrate The misconception being tested is that value semantics are a synchronisation mechanism. They are not. Copying gives you an *isolated* value once you have it; it says nothing about whether the memory you read was stable while you read it. The rule to state out loud is: **the copy protects you from future writes by others, never from concurrent ones.** Any time a pointer to mutable state crosses a goroutine boundary, something — a mutex, a channel handoff, or an atomic publication of immutable data — has to establish the ordering.