Locking
Locking is a concurrency-control technique that restricts access to a shared resource or protected operation to prevent conflicting concurrent access.
Object-Oriented Software Design in C++
Mutual exclusion is a synchronization property that restricts access to a protected resource so that only one thread can enter the critical operation at a time.
- How it is used
- Protects shared memory, files, printers, and other resources in multithreaded applications.
- How deep it goes
- Explains critical regions, mutex lock-block-unlock behavior, scheduling variability, and deadlock risk, while deferring condition-variable synchronization.
- Examples
- Uses three C++ threads writing different strings character by character to a shared print stream.
- What you can do after
- Apply it via C++ mutexes to guard critical regions and diagnose interleaved output caused by unprotected shared resources.
Read how Object-Oriented Software Design in C++ explains locking →
Learn Go with Pocket-Sized Projects
Mutual exclusion is the property that prevents more than one execution context from accessing a protected resource at the same time.
- How it is used
- Protects shared cache maps, service repositories, and solver state when goroutines may access them concurrently.
- How deep it goes
- Works through lock placement, deferred unlocking, pointer safety, and a read-side mutation tradeoff; does not explain mutex internals.
- Examples
- Uses a generic cache, a locked repository insertion, and a solver’s shared solution flag.
- What you can do after
- Apply it via sync.Mutex to protect shared fields and use go test -race to look for data races.
Read how Learn Go with Pocket-Sized Projects explains locking →
Modern C, Third Edition
A mutex is a mutual-exclusion synchronization object that allows only one thread at a time to hold a protected critical section.
- How it is used
- Protects shared board data during input, accounting, drawing, and updates that cannot simply use atomic objects.
- How deep it goes
- Explains acquisition, release, visibility, condition waits, and deadlock-avoidance rules; defers extensive treatment of parallel-computing liveness.
- Examples
- Uses a shared game board, input and accounting threads, condition-wait loops, and a two-mutex deadlock scenario.
- What you can do after
- Apply it via C <threads.h> mutex calls to protect shared data, coordinate condition waits, and order multiple locks.
Software Design for Python Programmers
Mutual exclusion is a synchronization constraint that permits only one thread or execution path at a time to access a protected resource or critical operation.
- How it is used
- Protects shared resources in explicitly multithreaded applications from conflicting concurrent access.
- How deep it goes
- Explains critical regions, blocking acquisition, release, Python Lock usage, reader-writer coordination, and deadlock risks.
- Examples
- Uses interleaved multithreaded printing and a reader-writer meter simulation with technicians and loggers.
- What you can do after
- Operate/configure Python threading.Lock to guard critical regions and diagnose race conditions, blocking, deadlocks, and scheduling-sensitive output.
Read how Software Design for Python Programmers explains locking →
Latency
A mutex lock is an exclusive synchronization primitive that permits only one concurrent execution context to access a protected resource at a time.
- How it is used
- Protects shared resources from concurrent access while exposing contention as a source of tail latency.
- How deep it goes
- Defines critical sections, demonstrates Rust mutex use, and measures contention; stops short of implementing a mutex.
- Examples
- Uses a 100-thread shared counter, contention benchmarks, and a mutex-protected bounded queue.
- What you can do after
- Apply it via Rust std::sync::Mutex to protect shared data, then evaluate contention before choosing an alternative.
100 Go Mistakes and How to Avoid Them
A mutex is a synchronization primitive that provides mutual exclusion by allowing at most one execution to enter a protected section at a time.
- How it is used
- Protects shared mutable state accessed by goroutines, while reserving channels chiefly for communication and coordination.
- How deep it goes
- Defines mutual exclusion, traces a lost update, and diagnoses incomplete map locking and copied mutexes.
- Examples
- Uses competing increments, a balance cache backed by a map, and a counter whose value receiver copies its mutex.
- What you can do after
- Diagnose/debug with locking by extending protection across shared-data access and checking for inadvertently copied mutexes.
Read how 100 Go Mistakes and How to Avoid Them explains locking →
Java Persistence with Spring Data and Hibernate epub
Locking is a concurrency-control technique that restricts access to data while a transaction holds a lock on it.
- How it is used
- Controls concurrent database access within transactions, including explicit protection when JPA loads entities.
- How deep it goes
- Explains pessimistic lock modes, generated SQL, transaction lifetime, failure timing and deadlock mitigation, while leaving lock implementation to the database.
- Examples
- Uses JPA locking queries, dialect-specific SELECT clauses and two transactions updating rows in opposite orders.
- What you can do after
- Apply it via JPA pessimistic lock modes and diagnose deadlocks caused by conflicting update order.
Read how Java Persistence with Spring Data and Hibernate epub explains locking →
Modern C
Mutual exclusion is a synchronization property ensuring that at most one thread accesses a protected region at a time.
- How it is used
- Protects shared game-board data while input, accounting, update, and draw threads access it.
- How deep it goes
- Defines mutexes and critical sections, explains acquisition and linearizability, and shows guarded thread code without detailing mutex implementation.
- Examples
- Uses a shared game board and accounting, update, and draw thread functions with lock, wait, signal, and unlock calls.
- What you can do after
- Apply it via C `<threads.h>` mutex operations to guard critical sections and coordinate shared-state work with condition variables.
Grokking Concurrency
A lock is a synchronization mechanism that restricts access to a shared resource so that competing tasks cannot modify it simultaneously.
- How it is used
- Prevents race conditions when concurrent tasks access shared resources through critical sections.
- How deep it goes
- Explains mutex states and acquire()/release() through a Python bank-account implementation, while deferring processor-level synchronization details.
- Examples
- Uses a synchronized bank account and dining philosophers sharing chopsticks as mutexes.
- What you can do after
- Apply it via Python Lock to serialize updates to shared data and recognize blocking and lock-contention costs.
PostgreSQL Mistakes and How to Avoid Them
A database lock is a concurrency control mechanism that permits or prevents access to a database object by other transactions.
- How it is used
- Explains how PostgreSQL coordinates concurrent table and row access and why idle transactions become production performance hazards.
- How deep it goes
- Explains lock levels, conflicts, and a blocking sequence, but stops short of catalog-based lock diagnosis or exhaustive lock-mode reference.
- Examples
- Uses an idle SELECT transaction, ALTER TABLE, and a later SELECT to demonstrate cascading lock blockage.
- What you can do after
- Diagnose why ordinary-looking reads block schema changes and why later queries queue behind the blocked operation.
Read how PostgreSQL Mistakes and How to Avoid Them explains locking →
Advanced Algorithms and Data Structures
A lock is a synchronization primitive that coordinates access to shared resources by allowing mutually exclusive ownership.
- How it is used
- Coordinates concurrent cache access and protects database-backed updates from inconsistent reads and writes.
- How deep it goes
- Explains read/write compatibility, try-finally release, deadlock prevention, and latency trade-offs through cache implementations.
- Examples
- Uses Java LFU-cache get and set methods, lock-compatibility cases, and database cursor updates as concrete examples.
- What you can do after
- Apply it via read and write locks with guaranteed release around shared cache operations.
Read how Advanced Algorithms and Data Structures explains locking →
Elixir in Action, Third Edition
A cluster-wide lock is a distributed mutual-exclusion mechanism that prevents competing operations on different nodes from proceeding simultaneously.
- How it is used
- Coordinates cluster-wide critical sections and prevents competing processes on different nodes from operating simultaneously.
- How deep it goes
- Explains lock identity, acquisition, waiting, release, transactional wrapping, and registration internals without detailing broader failure handling.
- Examples
- Demonstrates competing :global.set_lock/1 calls across two nodes, explicit deletion, and :global.trans/2 around protected work.
- What you can do after
- Operate/configure cluster-wide locks with :global.set_lock/1, :global.del_lock/1, and :global.trans/2.
Go by Example
- How it is used
- Protects a shared in-memory link map used concurrently by HTTP-request goroutines.
- How deep it goes
- Explains mutex locking behavior and develops RWMutex read/write protection with deferred release.
- Examples
- Uses a Shortener service whose Shorten and Resolve methods guard an in-memory link map.
- What you can do after
- Apply it via sync.RWMutex to make shared map access safe for concurrent goroutines.
Go in Practice, Second Edition
- How it is used
- Protects shared data from inconsistent concurrent access by allowing goroutines to use a resource exclusively.
- How deep it goes
- Explains locking and unlocking, demonstrates a word-counter race, and shows a mutex-based implementation.
- Examples
- Uses a concurrent word counter that tallies files into a shared map and demonstrates race-detection output.
- What you can do after
- Apply sync.Mutex to protect shared data and use Go’s race detector to identify concurrent access.
ASP.NET Core in Action, 3e
Database locking is a concurrency-control technique that restricts simultaneous access to shared database state.
- How it is used
- Coordinates clustered background jobs so one application instance handles each trigger.
- How deep it goes
- Explains the operational purpose and database limitations but stops short of describing lock internals.
- Examples
- Uses Quartz.NET jobs and triggers, SQL Server persistence, a clustering configuration, and an EF Core schema migration.
- What you can do after
- Operate clustered Quartz.NET services that coordinate trigger handling through a shared database.
Go in Action, Second Edition
A lock is a synchronization mechanism that restricts concurrent access to a protected resource.
- How it is used
- Protects shared data when multiple goroutines concurrently read or modify a resource.
- How deep it goes
- Explains race conditions, exclusive and read locks, and an ArticleStore implementation, while deferring broader synchronization internals.
- Examples
- Demonstrates an ArticleStore, RSS feed fetchers, duplicate filtering, sorted results, read locks, write locks, and WaitGroup coordination.
- What you can do after
- Apply it via sync.Mutex or sync.RWMutex to protect shared data and maintain consistency across concurrent operations.
Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu
State locking is the coordination mechanism that prevents concurrent Terraform operations from modifying the same state simultaneously.
- How it is used
- Coordinates Terraform operations so concurrent processes cannot modify shared state simultaneously.
- How deep it goes
- Explains lock behavior, the unsafe override, speculative-plan exception, and backend-specific configuration requirements.
- Examples
- Uses simultaneous apply runs, the `-lock=false` flag, speculative plans, S3, and the local backend.
- What you can do after
- Operate/configure Terraform backends with locking and recognize when disabling locks is acceptable for non-mutating plans.
Read how Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu explains locking →
Learn Rust in a Month of Lunches
Mutual exclusion is a concurrency property that allows at most one thread to access a protected resource at a time.
- How it is used
- Protects shared mutable values when multiple threads may access them.
- How deep it goes
- Explains guards, scope-based release, drop(), deadlock, and try_lock(), but not broader synchronization design.
- Examples
- Uses integer mutation, scoped guards, explicit drop(), repeated increments, and a deliberately blocking second lock.
- What you can do after
- Apply it via Rust's std::sync::Mutex to guard shared updates and avoid indefinite waits with try_lock().
Read how Learn Rust in a Month of Lunches explains locking →
Related concepts
- race conditionaddresses · A race condition is a concurrency defect in which program behavior or results depend on the relative timing or ordering of interacting operations.
- condition variableused by · A condition variable is a synchronization object that allows threads to wait for a shared-state condition and be notified when it may have changed.
- data raceaddresses · A data race is a concurrent access to shared data in which at least one access is a write and the accesses are not adequately synchronized.
- shared resourceuses · A shared resource is data, an object, or another resource that multiple people, components, or execution contexts can access or use.
- cnd_timedwaitused by · cnd_timedwait is a C threads-library function that atomically releases a mutex while waiting on a condition variable, then reacquires it after notification or an absolute timeout.
- async/awaitcontrasts with · Async/await is language syntax for expressing asynchronous computations that suspend at awaited operations and resume when they can proceed without blocking the execution thread.
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.