Ошибка	Последствие
Скопировать структуру с `sync.Mutex` после первого использования	Копируется состояние блокировки; `go vet` ловит это, но не всегда читают вывод
Считать `sync.Mutex` реентерабельным	Повторный `Lock` на своём мьютексе в той же goroutine — deadlock
Вызвать `Add` внутри уже запущенной goroutine	Гонка с `Wait`; счётчик может ещё не учитывать goroutine
Передать `WaitGroup` по значению в goroutine	`Done` обновляет копию; `Wait` блокируется навсегда
Увести счётчик `WaitGroup` ниже нуля лишним `Done`	panic — программа падает
Смешать атомарный и обычный доступ к одной переменной	Гонка данных остаётся; неопределённое поведение
Защищать атомиками многошаговый инвариант	Атомик покрывает лишь одно слово; промежуточное состояние видно другим goroutine
Брать `RWMutex` по умолчанию	При низкой конкуренции он медленнее обычного `sync.Mutex`
Считать, что записи видны между goroutine без ребра синхронизации	Несвежие чтения или гонка — модель памяти не даёт порядка без `happens-before`
Полагать, что выровненный `MOV` атомарен между ядрами сам по себе	Без `LOCK`-префикса и барьера другие ядра не увидят результат согласованно

advanced

Go Synchronization Primitives — Cheap, but Unforgiving

Mutex, RWMutex, WaitGroup, Once, the sync/atomic package, the CPU-level implementation of atomics, and the Go memory model with its happens-before rules.

go-sync

Practice: 15 questions · 1 task →

Sections

Contents

Detailed explanation

Go Synchronization Primitives — Cheap, but Unforgiving

"Do not communicate by sharing memory; share memory by communicating" is the famous Go advice, but it does not make the standard library's mutexes and atomics pointless. A channel is an excellent tool for transferring ownership of data, but guarding a counter or a cache in a hot loop is cheaper with a plain sync.Mutex or a single atomic operation. A serious Go developer commands both styles and knows when each fits.

The hard part of the sync package is not the API — Lock/Unlock, Add/Done/Wait, Do look trivial. The hard part is that these primitives are unforgiving. A struct holding a mutex, copied after first use, silently copies lock state. A WaitGroup counter driven below zero crashes the program with a panic. Mixed atomic and plain access to the same variable stays a data race — undefined behaviour that no exception catches. And underneath it all sits the Go memory model: without an explicit happens-before edge, one goroutine is not obliged to see another's writes at all. This topic dissects synchronization layer by layer — from the internals of a mutex to the rules of write visibility.

Topic Map

sync.Mutex — mutual exclusion, the zero value as a ready mutex, non-reentrancy, and the starvation mode that ensures fairness.
sync.WaitGroup — waiting for a set of goroutines, the Add/Done/Wait contract, and why Add must precede the goroutine launch.
The sync/atomic package — lock-free operations on a single machine word and the typed atomic.Int64/atomic.Value wrappers.
CPU-level atomics — the LOCK prefix on x86, the load-linked/store-conditional pair on ARM, and memory fences.
sync.RWMutex — many readers OR one writer, the win on read-heavy workloads, and writer-starvation protection.
sync.Once — the one-time-execution guarantee via an atomic fast path and a mutex-guarded slow path.
The Go memory model — happens-before rules, the synchronization edges of channels and mutexes, and the absence of ordering without them.
Atomics vs mutex — when one indivisible operation is enough and when you need a full critical section.

Common Mistakes and Traps

Mistake	Consequence
Copying a struct holding a `sync.Mutex` after first use	Lock state is copied; `go vet` catches it, but the output is not always read
Treating `sync.Mutex` as reentrant	Re-`Lock` of your own mutex on the same goroutine — deadlock
Calling `Add` inside an already started goroutine	Race with `Wait`; the counter may not yet count the goroutine
Passing a `WaitGroup` by value to a goroutine	`Done` updates a copy; `Wait` blocks forever
Driving the `WaitGroup` counter below zero with an extra `Done`	panic — the program crashes
Mixing atomic and plain access to the same variable	The data race remains; undefined behaviour
Guarding a multi-step invariant with atomics	An atomic covers only one word; the intermediate state is visible to other goroutines
Reaching for `RWMutex` by default	Under low contention it is slower than a plain `sync.Mutex`
Assuming writes are visible across goroutines without a synchronization edge	Stale reads or a race — the memory model gives no ordering without `happens-before`
Believing an aligned `MOV` is atomic across cores by itself	Without the `LOCK` prefix and a fence, other cores will not see the result consistently

Interview Relevance

Synchronization is a mandatory topic in any serious Go interview. A candidate usually knows channels; the sync package and the memory model separate someone who can reason about the correctness of concurrent code from someone who memorised go func(){}().

What interviewers check:

What sync.Mutex provides, why it must not be copied, and why it is not reentrant.
The Add/Done/Wait contract and why Add must run before the goroutine launch.
What sync/atomic provides and why an atomic guards only a single machine word.
How an atomic operation is implemented at the CPU level — the LOCK prefix, LL/SC, memory fences.
When sync.RWMutex beats sync.Mutex and what it costs.
How sync.Once guarantees a single run and why it needs both an atomic and a mutex.
What happens-before is and which synchronization edges establish it.

A typical wrong answer: "atomics are just a fast mutex, you can guard anything with them." That triggers a discussion that an atomic indivisibly updates exactly one word, while consistency across several values or a multi-step critical section needs a sync.Mutex.

Why it matters

Channels are not the only way to synchronise in Go, and on a hot path they lose to a mutex or an atomic. But these primitives are unforgiving — a copied mutex, a data race, a wrong assumption about write visibility between goroutines turn not into an exception but into undefined behaviour that reproduces only in production.

Ошибка	Последствие
Скопировать структуру с `sync.Mutex` после первого использования	Копируется состояние блокировки; `go vet` ловит это, но не всегда читают вывод
Считать `sync.Mutex` реентерабельным	Повторный `Lock` на своём мьютексе в той же goroutine — deadlock
Вызвать `Add` внутри уже запущенной goroutine	Гонка с `Wait`; счётчик может ещё не учитывать goroutine
Передать `WaitGroup` по значению в goroutine	`Done` обновляет копию; `Wait` блокируется навсегда
Увести счётчик `WaitGroup` ниже нуля лишним `Done`	panic — программа падает
Смешать атомарный и обычный доступ к одной переменной	Гонка данных остаётся; неопределённое поведение
Защищать атомиками многошаговый инвариант	Атомик покрывает лишь одно слово; промежуточное состояние видно другим goroutine
Брать `RWMutex` по умолчанию	При низкой конкуренции он медленнее обычного `sync.Mutex`
Считать, что записи видны между goroutine без ребра синхронизации	Несвежие чтения или гонка — модель памяти не даёт порядка без `happens-before`
Полагать, что выровненный `MOV` атомарен между ядрами сам по себе	Без `LOCK`-префикса и барьера другие ядра не увидят результат согласованно

advanced

Go Synchronization Primitives — Cheap, but Unforgiving

Mutex, RWMutex, WaitGroup, Once, the sync/atomic package, the CPU-level implementation of atomics, and the Go memory model with its happens-before rules.

go-sync

Practice: 15 questions · 1 task →

Sections

Contents

Detailed explanation

Go Synchronization Primitives — Cheap, but Unforgiving

Topic Map

sync.Mutex — mutual exclusion, the zero value as a ready mutex, non-reentrancy, and the starvation mode that ensures fairness.
sync.WaitGroup — waiting for a set of goroutines, the Add/Done/Wait contract, and why Add must precede the goroutine launch.
The sync/atomic package — lock-free operations on a single machine word and the typed atomic.Int64/atomic.Value wrappers.
CPU-level atomics — the LOCK prefix on x86, the load-linked/store-conditional pair on ARM, and memory fences.
sync.RWMutex — many readers OR one writer, the win on read-heavy workloads, and writer-starvation protection.
sync.Once — the one-time-execution guarantee via an atomic fast path and a mutex-guarded slow path.
The Go memory model — happens-before rules, the synchronization edges of channels and mutexes, and the absence of ordering without them.
Atomics vs mutex — when one indivisible operation is enough and when you need a full critical section.

Common Mistakes and Traps

Mistake	Consequence
Copying a struct holding a `sync.Mutex` after first use	Lock state is copied; `go vet` catches it, but the output is not always read
Treating `sync.Mutex` as reentrant	Re-`Lock` of your own mutex on the same goroutine — deadlock
Calling `Add` inside an already started goroutine	Race with `Wait`; the counter may not yet count the goroutine
Passing a `WaitGroup` by value to a goroutine	`Done` updates a copy; `Wait` blocks forever
Driving the `WaitGroup` counter below zero with an extra `Done`	panic — the program crashes
Mixing atomic and plain access to the same variable	The data race remains; undefined behaviour
Guarding a multi-step invariant with atomics	An atomic covers only one word; the intermediate state is visible to other goroutines
Reaching for `RWMutex` by default	Under low contention it is slower than a plain `sync.Mutex`
Assuming writes are visible across goroutines without a synchronization edge	Stale reads or a race — the memory model gives no ordering without `happens-before`
Believing an aligned `MOV` is atomic across cores by itself	Without the `LOCK` prefix and a fence, other cores will not see the result consistently

Interview Relevance

What interviewers check:

What sync.Mutex provides, why it must not be copied, and why it is not reentrant.
The Add/Done/Wait contract and why Add must run before the goroutine launch.
What sync/atomic provides and why an atomic guards only a single machine word.
How an atomic operation is implemented at the CPU level — the LOCK prefix, LL/SC, memory fences.
When sync.RWMutex beats sync.Mutex and what it costs.
How sync.Once guarantees a single run and why it needs both an atomic and a mutex.
What happens-before is and which synchronization edges establish it.

Why it matters

Примитивы синхронизации Go — дёшево, но не прощают ошибок

Примитивы синхронизации Go — дёшево, но не прощают ошибок

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Go Synchronization Primitives — Cheap, but Unforgiving

Go Synchronization Primitives — Cheap, but Unforgiving

Topic Map

Common Mistakes and Traps

Interview Relevance

Примитивы синхронизации Go — дёшево, но не прощают ошибок

Примитивы синхронизации Go — дёшево, но не прощают ошибок

Карта темы

Частые ошибки и ловушки

Значение для собеседований

Go Synchronization Primitives — Cheap, but Unforgiving

Go Synchronization Primitives — Cheap, but Unforgiving

Topic Map

Common Mistakes and Traps

Interview Relevance