Mastering Go Concurrency: From Basics to Advanced Patterns

Chapter 1: Entering Concurrency

Concurrency groups instructions into independent tasks and defines boundaries and synchronization points; parallelism is the simultaneous execution of those tasks, a subset of concurrency. Go was designed for high‑performance concurrency, using lightweight goroutine as the basic execution unit managed by the runtime.

Go offers two concurrency models: the Communicating Sequential Processes (CSP) model, which relies on message passing, and the traditional shared‑memory model that uses mutexes and condition variables for synchronization.

Chapter 2: Handling Threads

Operating systems split a job into stages such as ready, running, and I/O‑waiting. Green threads are user‑level threads, but Go's goroutines can fully exploit multi‑core CPUs. Concurrency plans how to do many things at once, while parallelism actually runs them simultaneously. Even on a single processor, frequent context switches can simulate parallel execution.

Chapter 3: Memory‑Shared Thread Communication

Race conditions occur when multiple goroutines access shared resources without a deterministic execution order.

Atomic operations are indivisible actions that prevent race conditions.

To avoid races, developers must synchronize and communicate, using tools such as mutex and condition variables.

Go's race detector helps locate race conditions in code.

Chapter 4: Synchronizing with Mutexes

A Mutex allows only one goroutine to enter a critical section.

The sync package provides the Mutex type with Lock() and Unlock() methods.

If several goroutines try to lock simultaneously, only one succeeds; the others block until the lock is released. TryLock() attempts to acquire the lock and returns false immediately if it is unavailable, avoiding blocking.

A RWMutex permits multiple readers but only one writer.

Read‑preferring RWMutexes can cause writer starvation , where a writer never obtains the lock.

Chapter 5: Condition Variables and Semaphores

A Condition Variable adds waiting capabilities on top of a mutex, allowing a goroutine to wait for a specific condition. Wait() atomically releases the mutex and suspends the goroutine; Signal() or Broadcast() wakes waiting goroutines.

If Signal() or Broadcast() is called with no waiting goroutine, the signal is lost.

Using a condition variable, one can implement a write‑preferring lock to avoid writer starvation.

A Semaphore limits the number of goroutines that may enter a critical section simultaneously; a binary semaphore (value = 1) behaves like a mutex.

Chapter 6: WaitGroup and Barrier Synchronization

Add(delta int)

increments a WaitGroup counter; Done() decrements it; Wait() blocks until the counter reaches zero.

A WaitGroup is used to wait for a set of tasks to finish; it can be implemented with semaphores or condition variables.

A Barrier forces multiple goroutines to rendezvous at a common point before any can proceed; it can be built using a condition variable.

Chapter 7: Message‑Passing Communication

A Channel is a pipe for goroutine communication, available as unbuffered or buffered.

Create an unbuffered channel with make(chan T) and a buffered one with make(chan T, capacity).

The <- operator sends (left side) or receives (right side) values.

Unbuffered sends block until a receiver is ready; buffered channels allow sends until the buffer is full.

Direction‑restricted channels: chan<- int (send‑only) and <-chan int (receive‑only).

Closing a channel with close(channel) prevents further sends; receives from a closed channel yield the zero value of the element type.

Iterating with for range reads until the channel is closed.

Internally, a channel behaves like a fixed‑size queue and must be protected by a mutex when shared data structures are accessed.

Semaphores can be used to block senders when the buffer is full or block receivers when it is empty.

Chapter 8: Selecting Channels

The select statement lets a goroutine wait on multiple channel operations.

When several case clauses are ready, select chooses one at random.

Using a default case makes the operation non‑blocking.

A default case can also be used to broadcast a stop signal in concurrent calculations.

Setting a channel to nil disables its case in a select, enabling dynamic addition/removal of communication sources.

Combining multiple channels into a single stream via select implements the fan‑in pattern.

Message‑passing is generally easier to understand and yields more concise code than shared memory, though in some cases shared memory can be faster.

Chapter 9: Common Channel Patterns

Sentinel values (or poison‑pill messages) signal termination.

The fan‑out pattern distributes a single computation's output to many goroutines.

Dynamic fan‑in can be built with select and dynamic channels.

Helper functions like CreateAll() and CloseAll() simplify management of dynamic channels.

Chapter 10: Concurrency Patterns

Channels can drive concurrent computation in each loop iteration.

Combining channels with select creates a non‑blocking worker pool, preventing client blockage when the pool is full.

Channels together with mapping functions enable reusable pipeline patterns.

Chapter 11: Avoiding Deadlocks

A deadlock occurs when two or more goroutines wait indefinitely for each other’s resources.

The Resource Allocation Graph visualizes resource requests and allocations.

Four conditions must hold for a deadlock: mutual exclusion, hold‑and‑wait, no preemption, and circular wait.

Deadlock detection and prevention techniques (e.g., the Banker’s algorithm) can be applied.

An Arbitrator can control resource allocation to break circular wait cycles.

Using select can avoid circular waits between channels.

Chapter 12: Atomic Operations, Spin Locks, and Futexes

Atomic variables provide indivisible read/write/compare‑and‑swap operations for basic types.

They can implement counters and lightweight mutexes.

The CompareAndSwap function atomically compares a value and swaps it if it matches.

A spin lock repeatedly checks a lock variable in user space until it acquires the lock.

A futex (fast userspace mutex) is a kernel call that puts a thread to sleep only when contention occurs, reducing CPU usage.

Go’s sync.mutex combines atomic ops, spin locks, and futexes for high performance. sync.mutex operates in two modes—normal and starvation—chosen based on runtime conditions.