Cover of Learn Concurrent Programming with Go

What you will learn in Learn Concurrent Programming with Go

by James Cutajar

Read it on liveBook Get the book at manning.com

Chapter by chapter

Chapter 1: Stepping into concurrent programming

1.1 About concurrency · 1.2 Interacting with a concurrent world · 1.3 Increasing throughput · 1.4 Improving responsiveness · 1.5 Programming concurrency in Go · 1.5.1 Goroutines at a glance · 1.5.2 Modeling concurrency with CSP and primitives · 1.5.3 Building our own concurrency tools · 1.6 Scaling performance · 1.6.1 Amdahl’s law · 1.6.2 Gustafson’s law · 1.7 Summary

What you learn in chapter 1 →

Chapter 2: Dealing with threads

2.1 Multiprocessing in operating systems · 2.2 Abstracting concurrency with processes and threads · 2.2.1 Concurrency with processes · 2.2.2 Creating processes · 2.2.3 Using multiprocessing for common tasks · 2.2.4 Concurrency with threads · 2.2.5 A multithreaded application in practice · 2.2.6 Using multiple processes and threads together · 2.3 What’s so special about goroutines? · 2.3.1 Creating goroutines · 2.3.2 Implementing goroutines in the user space · 2.3.3 Scheduling goroutines · 2.4 Concurrency versus parallelism · 2.5 Exercises · 2.6 Summary

What you learn in chapter 2 →

Chapter 3: Thread communication using memory sharing

3.1 Sharing memory · 3.2 Memory sharing in practice · 3.2.1 Sharing a variable between goroutines · 3.2.2 Escape analysis · 3.2.3 Updating shared variables from multiple goroutines · 3.3 Race conditions · 3.3.1 Stingy and Spendy: Creating a race condition · 3.3.2 Yielding execution does not help with race conditions · 3.3.3 Proper synchronization and communication eliminate race conditions · 3.3.4 The Go race detector · 3.4 Exercises · 3.5 Summary

What you learn in chapter 3 →

Chapter 4: Synchronization with mutexes

4.1 Protecting critical sections with mutexes · 4.1.1 How do we use mutexes? · 4.1.2 Mutexes and sequential processing · 4.1.3 Non-blocking mutex locks · 4.2 Improving performance with readers–writer mutexes · 4.2.1 Go’s readers–writer mutex · 4.2.2 Building our own read-preferred readers–writer mutex · 4.3 Exercises · 4.4 Summary

What you learn in chapter 4 →

Chapter 5: Condition variables and semaphores

5.1 Condition variables · 5.1.1 Combining mutexes with condition variables · 5.1.2 Missing the signal · 5.1.3 Synchronizing multiple goroutines with waits and broadcasts · 5.1.4 Revisiting readers–writer locks using condition variables · 5.2 Counting semaphores · 5.2.1 What’s a semaphore? · 5.2.2 Building a semaphore · 5.2.3 Never miss a signal with semaphores · 5.3 Exercises · 5.4 Summary

What you learn in chapter 5 →

Chapter 6: Synchronizing with waitgroups and barriers

6.1 Waitgroups in Go · 6.1.1 Waiting for tasks to complete with waitgroups · 6.1.2 Creating a waitgroup type using semaphores · 6.1.3 Changing the size of our waitgroup while waiting · 6.1.4 Building a more flexible waitgroup · 6.2 Barriers · 6.2.1 What is a barrier? · 6.2.2 Implementing a barrier in Go · 6.2.3 Concurrent matrix multiplication using barriers · 6.3 Exercises · 6.4 Summary

What you learn in chapter 6 →

Chapter 7: Communication using message passing

7.1 Passing messages · 7.1.1 Passing messages with channels · 7.1.2 Buffering messages with channels · 7.1.3 Assigning a direction to channels · 7.1.4 Closing channels · 7.1.5 Receiving function results with channels · 7.2 Implementing channels · 7.2.1 Creating a channel with semaphores · 7.2.2 Implementing the Send() function in our channel · 7.2.3 Implementing the Receive() function in our channel · 7.3 Exercises · 7.4 Summary

What you learn in chapter 7 →

Chapter 8: Selecting channels

8.1 Combining multiple channels · 8.1.1 Reading from multiple channels · 8.1.2 Using select for non-blocking channel operations · 8.1.3 Performing concurrent computations on the default case · 8.1.4 Timing out on channels · 8.1.5 Writing to channels with select · 8.1.6 Disabling select cases with nil channels · 8.2 Choosing between message passing and memory sharing · 8.2.1 Balancing code simplicity · 8.2.2 Designing tightly versus loosely coupled systems · 8.2.3 Optimizing memory consumption · 8.2.4 Communicating efficiently · 8.3 Exercises · 8.4 Summary

What you learn in chapter 8 →

Chapter 9: Programming with channels

9.1 Communicating sequential processes · 9.1.1 Avoiding interference with immutability · 9.1.2 Concurrent programming with CSP · 9.2 Reusing common patterns with channels · 9.2.1 Quitting channels · 9.2.2 Pipelining with channels and goroutines · 9.2.3 Fanning in and out · 9.2.4 Flushing results on close · 9.2.5 Broadcasting to multiple goroutines · 9.2.6 Closing channels after a condition · 9.2.7 Adopting channels as first-class objects · 9.3 Exercises · 9.4 Summary

What you learn in chapter 9 →

Chapter 10: Concurrency patterns

10.1 Decomposing programs · 10.1.1 Task decomposition · 10.1.2 Data decomposition · 10.1.3 Thinking about granularity · 10.2 Concurrency implementation patterns · 10.2.1 Loop-level parallelism · 10.2.2 The fork/join pattern · 10.2.3 Using worker pools · 10.2.4 Pipelining · 10.2.5 Pipelining properties · 10.3 Exercises · 10.4 Summary

What you learn in chapter 10 →

Chapter 11: Avoiding deadlocks

11.1 Identifying deadlocks · 11.1.1 Picturing deadlocks with resource allocation graphs · 11.1.2 Deadlocking in a ledger · 11.2 Dealing with deadlocks · 11.2.1 Detecting deadlocks · 11.2.2 Avoiding deadlocks · 11.2.3 Preventing deadlocks · 11.3 Deadlocking with channels · 11.4 Exercises · 11.5 Summary

What you learn in chapter 11 →

Chapter 12: Atomics, spin locks, and futexes

12.1 Lock-free synchronization with atomic variables · 12.1.1 Sharing variables with atomic numbers · 12.1.2 Performance penalty when using atomics · 12.1.3 Counting using atomic numbers · 12.2 Implementing a mutex with spin locks · 12.2.1 Comparing and swapping · 12.2.2 Building a mutex · 12.3 Improving on spin locking · 12.3.1 Locking with futexes · 12.3.2 Reducing system calls · 12.3.3 Go’s mutex implementation · 12.4 Exercises · 12.5 Summary

What you learn in chapter 12 →

Concepts explained in this book

race conditionA race condition is a concurrency defect in which program behavior depends on the timing or interleaving of unsynchronized operations.
goroutineA goroutine is a lightweight Go execution construct that represents a concurrent activity managed by the Go runtime.
shared-memory interprocess communicationMemory sharing is a communication approach in which concurrent executions exchange information by accessing common memory.
channelA Go channel is a typed communication and synchronization mechanism through which goroutines send and receive values.
condition variableA condition variable is a synchronization mechanism that allows threads or goroutines to wait for a specified condition and be notified when it may hold.
concurrencyA programming technique for writing software in which multiple tasks or processes can make progress during overlapping periods of time.
atomicityAn atomic operation is an indivisible operation that cannot be interrupted during its execution.
rwlockA readers-writer lock is a synchronization lock that permits multiple simultaneous readers while granting writers exclusive access.
context switchingA context switch saves one task's execution state and restores another's so processor execution can move between tasks, threads, or goroutines.
critical regionA critical section is a region of code that accesses shared state and requires coordination to prevent conflicting concurrent access.
message passingMessage passing is a communication approach in which concurrent executions exchange information by sending and receiving messages.
BroadcastA broadcast pattern replicates each input message to every channel in a set of output channels.
select statementA select statement is a Go control-flow construct that waits for and chooses among channel communication operations.
waitWait is a condition-variable operation that suspends an execution until the condition variable is signaled or broadcast while coordinating the wait with an associated mutex.
barrierA barrier is a synchronization mechanism that suspends participating executions until all of them reach the same execution point, after which they resume and may participate again.
pipelineA pipeline is a sequence of processing stages connected so that the output of one stage becomes the input of the next.
sequential processingSequential execution is the execution of operations in an ordered flow without overlapping concurrent progress.
deadlockA deadlock is a state in which two or more executions wait indefinitely for conditions that can be satisfied only by one another.
SYS_futexA futex is an operating-system synchronization system call that allows user-space code to wait for and wake executions based on a shared memory value.
compare-and-exchange operationCompare-and-swap is an atomic operation that compares a memory location with an expected value and replaces it with a new value only when they match, returning whether the replacement occurred.
resource allocation graphA resource allocation graph is a directed graph whose nodes represent executions and resources and whose edges represent resource requests and assignments.
go keywordThe Go keyword go starts a function invocation as a goroutine without making the caller wait for its completion.
WaitGroupA waitgroup is a synchronization object that allows execution to wait until a counted set of concurrent operations has completed.
parallelismParallelism is the simultaneous execution of multiple computations, typically on multiple processing resources.
circular waitA circular wait is a dependency cycle in which each concurrent execution waits for a condition or resource held by another execution in the cycle.
semaphoreA synchronization mechanism that controls concurrent access to a resource through a counter of available permits.
spinlockA spin lock is a mutual-exclusion lock whose unsuccessful acquisition repeatedly retries while the execution remains active instead of blocking.
first-class objectA first-class object is a value that a programming language allows to be stored, passed as an argument, returned from a function, or otherwise handled like other ordinary values.
operating systemAn operating system is system software that manages computer hardware and provides services and abstractions for application programs.
monitorA synchronization pattern in which executions check a shared condition while holding a mutex, wait when it is false, and signal or broadcast when the state changes.
multithreadingMultithreading is a programming approach in which multiple threads execute concurrently within a single process or application.
fan-inA fan-in pattern merges values from multiple concurrent sources into a single stream.
multiprocessingAn operating-system capability in which multiple tasks are managed so that more than one can make progress on available processor resources.
time sharingA scheduling technique that lets multiple tasks share one processor by giving each task turns of execution.
WaitGroup Done methodA waitgroup Done operation decrements the count of outstanding operations tracked by a waitgroup.
write-preferring readers-writer lockA write-preferring readers-writer lock is a readers-writer synchronization lock that prioritizes waiting writers to prevent prolonged writer blocking.
hybrid threading systemA hybrid threading system combines user-level execution units with multiple kernel-level threads that the operating system schedules.
work stealingWork stealing is a scheduling technique in which an execution worker takes tasks from another worker's queue to improve utilization.
Go runtimeThe Go runtime is the standard execution environment that manages Go program services such as goroutine scheduling.
logical threadA user-level thread is a thread managed by a language runtime or user-space library rather than directly by the operating system kernel.
GoGo is a statically typed, compiled programming language designed for simplicity, readability, and efficient execution, including built-in support for concurrency.
deadlock detectionDeadlock detection is the computational identification of a state in which executions are indefinitely waiting on one another or on unavailable resources.
closed channelA closed channel is a Go channel marked as unable to accept further sends while still allowing pending or zero-valued receives.
scheduling algorithmAn algorithm that determines which task should be selected for execution from available tasks.
POSIX Threads APIPOSIX Threads is a standardized API and specification for creating, managing, and synchronizing threads.
starvationStarvation is a situation in which an execution is blocked from gaining access to a shared resource because other executions keep it unavailable for a long time or indefinitely.
local queueA local run queue is a scheduler queue associated with one kernel-level thread and containing goroutines assigned to that thread.
m:n threadingAn M:N threading model maps M user-level threads to N kernel-level threads.
rwmutexsync.RWMutex is Go's standard mutual-exclusion type that provides both exclusive locking and shared reader locking.
matrix-matrix multiplicationMatrix multiplication is the linear-algebra operation that computes a matrix product from weighted sums of rows and columns.
banker's algorithmThe banker's algorithm is a deadlock-avoidance algorithm that grants resource requests only when the resulting state can still complete all executions within their declared maximum resource demands.
arbitratorAn arbitrator is a coordination component that controls access to shared resources by suspending requests until the required resources are available.
deadlock avoidanceDeadlock avoidance is the dynamic allocation of resources or scheduling of executions so that the system does not enter a deadlocked state.
safe stateA safe state is a resource-allocation state from which there is an execution schedule allowing every execution to complete even if each requests its maximum resources.
unsafe stateAn unsafe state is a resource-allocation state for which no schedule is guaranteed to let all executions complete within their maximum resource demands.
communicating sequential processCommunicating sequential processes (CSP) is a formal concurrency model in which isolated sequential processes interact by exchanging messages through synchronized channels.
decompositionTask decomposition is the technique of dividing a computation into distinct units of work that can be assigned or coordinated independently.
heisenbugA Heisenbug is a software bug whose behavior disappears or changes when debugging or observation alters execution timing.
user-level schedulingUser-level scheduling is scheduling performed by a language runtime or user-space library rather than directly by the operating-system kernel.
write starvationA starvation condition in which a writer is indefinitely or excessively delayed because readers continuously hold a shared resource.
sync.CondThe Go standard-library condition-variable type that coordinates waiting and signaling through a sync.Locker.
parallel loopLoop-level parallelism is a pattern that executes independent loop iterations concurrently or in parallel.
Amdahl’s LawA performance model stating that the overall speedup from optimizing or parallelizing a system is limited by the fraction of execution that remains sequential.
futex_waitfutex_wait is a futex operation that suspends an execution when a memory address still contains an expected value.
futex_wakeFUTEX_WAKE is a Linux futex operation code requesting resumption of executions waiting on a memory address.
close functionclose is a Go built-in function that marks a channel as closed so that no further values can be sent to it.
speedupSpeedup is the ratio of a computation's execution time in a baseline configuration to its execution time in an improved or parallel configuration.
cycle detectionCycle detection is the identification of a closed path in a graph by tracking visited nodes or equivalent traversal state.
nil channelA nil channel is a Go channel value with no associated channel resource on which communication operations block indefinitely.
ReadLockReadLock is a function that acquires the read side of the book's readers-writer mutex implementation.
ReadUnlockReadUnlock is a function that releases the read side of the book's readers-writer mutex implementation.
WriteLockWriteLock is a function that acquires the exclusive write side of the book's readers-writer mutex implementation.
WriteUnlockWriteUnlock is a function that releases the exclusive write side of the book's readers-writer mutex implementation.
thread communicationThread communication is the exchange of information or coordination signals between concurrently executing threads.
fork-join modelFork/join is a concurrency pattern that performs parallel subtasks and then combines their results in a final join step.
channel capacityChannel capacity is the maximum number of messages a channel can hold before a send must wait for receiving capacity.
try_lockTryLock is a Go mutex operation that acquires an available mutex immediately and returns false immediately when the mutex is unavailable.
default caseA default case is the select branch that executes immediately when no other channel communication case is ready.
queueA queue is a data structure that stores elements in an ordered sequence for removal according to a queueing policy, typically first in, first out.
concurrency primitiveClassical concurrency primitives are low-level synchronization mechanisms traditionally used to coordinate concurrent execution.
fan-outA fan-out pattern distributes messages from one source among multiple concurrent consumers so that each message is processed by one consumer.
no preemptionNo preemption is a deadlock condition in which resources held by an execution cannot be forcibly taken away and must be released by that execution.
wait-for conditionThe wait-for condition is a deadlock condition in which an execution holding resources can request additional resources.
sync packagesync is a Go standard-library package that provides synchronization primitives and related concurrency utilities.
loop-carried dependenceA loop-carried dependence occurs when a step in one loop iteration depends on a step from another iteration of the same loop.
buffered channelA buffered channel is a Go channel with finite storage capacity that permits sends or receives to proceed without an immediate counterpart while capacity or queued values remain.
LoadInt32LoadInt32 is a Go sync/atomic function that atomically loads a signed 32-bit integer value.
permitA semaphore permit is a counted unit of availability that an acquisition can consume and a release can add.
nil channel patternA nil channel pattern disables a select case by assigning nil to its channel after that channel closes.
load balancingLoad balancing is the distribution of work across multiple workers or processing resources to avoid concentrating demand on one worker.
dynamic linear pipelineA dynamic linear pipeline is a one-directional processing chain that can grow by adding stages as the computation proceeds.
prime number pipeline algorithmThe prime number pipeline algorithm generates prime numbers by passing candidate integers through stages that filter multiples of previously found primes.
bus systemA system bus is a communication pathway that transfers requests and data between processors, caches, and main memory.
cache-coherent systemCache coherence is the coordination of cached copies so that processors observe consistent values for shared memory locations.
cache lineA cache line is a block-sized unit of memory storage that a cache transfers and tracks as a copy of main memory.
coherency wallThe coherency wall is a scalability limit caused by the increasing complexity, cost, and performance impact of maintaining cache coherence across many processor cores.
write-back with invalidationWrite-back with invalidation is a cache-coherence protocol that propagates an updated cached value and invalidates stale copies in other caches.
write-through cachingCache write-through is a cache update policy that immediately mirrors writes to the corresponding location in main memory.
runtime.Goschedruntime.Gosched is a Go runtime function that yields the processor so the scheduler can select another runnable goroutine.

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.