Stage 3 · Build

Concurrency in Depth

sync Primitives

Mutex, RWMutex, Cond, Once, Pool, atomic, and when channels are the wrong tool.

8 min readGo for SREBuild

sync.Mutex

Mutex protects shared state from concurrent access. Lock before accessing shared data, unlock after. Use defer for unlock to prevent forgotten unlocks.

Gomutex-usage.go

30 linesLn 1, Col 1Go

defer mu.Unlock() ensures the mutex is always released, even on panic. Keep critical sections small — lock, do minimal work, unlock. Mutexes are for protecting shared state, not for coordinating goroutines.

sync.RWMutex

RWMutex allows multiple concurrent readers or one exclusive writer. Use it when reads are frequent and writes are rare.

Gorwmutex-pattern.go

29 linesLn 1, Col 1Go

RLock allows multiple concurrent readers. Lock is exclusive — no readers or other writers. RWMutex is more efficient than Mutex when reads dominate. The snapshot pattern copies data under the lock to avoid holding it during iteration.

sync.Once

Once ensures a function is executed exactly once, even across multiple goroutines. It is used for lazy initialization of singletons, configuration loading, and connection setup.

Gosync.once-patterns.go

39 linesLn 1, Col 1Go

Once.Do guarantees the function runs exactly once. Subsequent calls are no-ops. The function is executed synchronously — callers block until it completes. If the function panics, subsequent calls will execute it again.

sync.Pool

Pool is a temporary object cache. It reduces garbage collection pressure by reusing objects. Each P (processor) has a private pool and a shared pool.

Gosync.pool-usage.go

40 linesLn 1, Col 1Go

Pool.Get returns an object from the pool or creates a new one. Pool.Put returns an object to the pool. Objects in the pool may be garbage collected at any time — Pool is a cache, not a guaranteed store. Use it for hot-path allocations.

atomic Operations

atomic operations provide lock-free synchronization for simple types. They are faster than mutex for single-value updates: counters, flags, and pointers.

Goatomic-operations.go

49 linesLn 1, Col 1Go

atomic.AddInt64 atomically increments. atomic.LoadInt64 reads without races. atomic.StoreInt64 writes without races. CompareAndSwap atomically compares and swaps — the building block for lock-free algorithms.

Channels vs sync

Channels and mutexes serve different purposes. Choose based on the problem, not habit.

Use Channels When	Use sync When
Communicating data between goroutines	Protecting shared state
Coordinating goroutine lifecycle	Simple counters and flags
Implementing pipelines	Read-heavy concurrent access
Signaling events	Single-process in-memory state

Godecision-examples.go

37 linesLn 1, Col 1Go

Channels are for communication. Mutexes are for protection. If you are passing data, use channels. If you are protecting a map or counter, use a mutex. Do not use channels to protect shared state — it is slower and more complex.

Start with mutex, graduate to channels

Mutexes are simpler to reason about. Start with a mutex for shared state. If you find yourself passing data between goroutines, switch to channels. Do not prematurely optimize with atomic operations unless profiling shows a bottleneck.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.