Atomicity
Atomicity is the property that an operation or group of operations takes effect as an indivisible, all-or-nothing unit, without observable partial effects.
Learn Concurrent Programming with Go
An atomic operation is an indivisible operation that cannot be interrupted during its execution.
- How it is used
- Protects concurrent reads and updates of a shared single variable from race conditions.
- How deep it goes
- Defines indivisible operations, traces a race, and demonstrates Go atomic updates, while deferring multi-variable protection to mutexes.
- Examples
- Uses a shared bank balance, a concurrent letter-frequency counter, and multi-flight booking to contrast suitable and unsuitable cases.
- What you can do after
- Apply it via Go's sync/atomic package for single-variable additions, loads, stores, swaps, and compare-and-swap operations.
Read how Learn Concurrent Programming with Go explains atomicity →
API Design Patterns
Atomicity is the property of treating a multi-step operation as an indivisible unit whose effects are either all applied or all undone.
- How it is used
- Uses all-or-nothing semantics to keep multi-resource API changes, list updates, and data copies consistent.
- How deep it goes
- Defines indivisibility and applies it to lists, batch methods, singleton sub-resources, and copy consistency, without specifying a universal transaction protocol.
- Examples
- Demonstrates whole-list replacement, BatchGetMessages failures, ChatRoom logging configuration, and point-in-time resource copying.
- What you can do after
- Build API operations that either apply all intended effects or return one complete failure, while documenting unavoidable consistency limits.
Think Distributed Systems
Failure atomicity is the property that an operation either completes as an indivisible unit or exposes no partial effect when execution fails.
- How it is used
- Uses atomicity to reason about transactions, crashes, partial executions, and coordinated decisions across distributed components.
- How deep it goes
- Defines all-or-nothing behavior, models crash prefixes, distinguishes concurrency from failure atomicity, and specifies distributed safety and liveness.
- Examples
- Uses signup payment, one-resource money transfer, two-resource money transfer, and process traces that crash after zero or more steps.
- What you can do after
- Evaluate whether operations expose partial effects and reason about commit or abort guarantees under crashes and distributed coordination.
Latency
Atomicity is the transaction property that requires all of a transaction's operations to take effect or none of them to take effect.
- How it is used
- Frames atomicity as the all-or-nothing guarantee of a database transaction within ACID.
- How deep it goes
- Defines all-or-nothing transaction behavior but does not explain its recovery or implementation mechanisms.
- Examples
- Uses ACID properties and isolation-level trade-offs as context, without a worked all-or-nothing transaction example.
- What you can do after
- Evaluate/understand whether an all-or-nothing transaction guarantee is being confused with isolation or durability.
100 SQL Server Mistakes and How to Avoid Them
Atomicity is the transaction property that makes all of a transaction's operations succeed or fail as one unit.
- How it is used
- Uses atomicity to keep multi-statement database updates together when stored procedures or queries succeed or fail.
- How deep it goes
- Defines all-or-nothing behavior, demonstrates open-transaction failures, and defers broader transaction nuances to isolation and durability.
- Examples
- Demonstrates sales-order insertion, invalid tables, foreign-key violations, @@TRANCOUNT checks, and TRY...CATCH procedures.
- What you can do after
- Diagnose unfinished transactions with @@TRANCOUNT and implement rollback-aware TRY...CATCH handling around multi-statement updates.
Read how 100 SQL Server Mistakes and How to Avoid Them explains atomicity →
100 Java Mistakes and How to Avoid Them
An atomic request is an operation that observes or updates its target as one indivisible action without an intervening state change.
- How it is used
- Prevents check-then-act errors when filesystem state, time, weak references, or shared collections can change between requests.
- How deep it goes
- Explains concrete races and replaces split calls with bounded reads, Queue.poll, ConcurrentMap methods, and AtomicInteger.updateAndGet.
- Examples
- Contrasts file-size checks with bounded stream reads, isEmpty-plus-remove with poll, map counting with merge, and get-set with updateAndGet.
- What you can do after
- Apply it via Java filesystem, Queue, ConcurrentMap, and AtomicInteger APIs to avoid races caused by split observations and updates.
Read how 100 Java Mistakes and How to Avoid Them explains atomicity →
MongoDB 8.0 in Action, Third Edition
Atomicity is a transaction property in which an operation completes entirely or has no effect.
- How it is used
- Preserves database integrity by preventing partial single-document operations and coordinating changes that must succeed together.
- How deep it goes
- Explains single-document behavior, multidocument scope, WiredTiger storage, and optimistic conflict handling, but not recovery implementation in detail.
- Examples
- Uses travel booking, single-document failure, and a Node.js account-and-customer transaction to demonstrate all-or-nothing behavior.
- What you can do after
- Apply it via MongoDB single-document operations or the Node.js withTransaction Callback API to coordinate reliable updates.
Read how MongoDB 8.0 in Action, Third Edition explains atomicity →
Functional Design and Architecture: Examples in Haskell
Atomicity is the property that a transaction's operations take effect as one indivisible unit.
- How it is used
- Uses atomicity to make shared-state transactions thread-safe in concurrent application logic.
- How deep it goes
- Explains atomic transactions, composition, rollback through retry, and execution with atomically, but leaves subtle usage concerns largely undeveloped.
- Examples
- Demonstrates atomicity with TQueues, meteor reporting, transaction composition, and the dining philosophers problem.
- What you can do after
- Apply it via Haskell’s STM library to build, compose, retry, and atomically execute thread-safe state updates.
Read how Functional Design and Architecture: Examples in Haskell explains atomicity →
100 Go Mistakes and How to Avoid Them
An atomic operation is an indivisible operation that cannot be interrupted by competing accesses to the same data.
- How it is used
- Prevents data races during concurrent updates by making a shared operation indivisible.
- How deep it goes
- Explains interleaved increments, demonstrates sync/atomic, and contrasts mutexes and channels; it omits atomic.Value.
- Examples
- Uses competing i++ operations, an atomic int64 increment, a mutex-protected increment, and channel-based increment notifications.
- What you can do after
- Apply it via sync/atomic to make supported numeric updates deterministic across goroutines.
Read how 100 Go Mistakes and How to Avoid Them explains atomicity →
Advanced Algorithms and Data Structures
An atomic operation is an operation that appears indivisible to concurrent observers, with no visible intermediate state.
- How it is used
- Prevents race conditions while mutable cache methods execute concurrently.
- How deep it goes
- Explains intermediate-state interference, lock-based isolation, lock scope, and deadlock risk without developing synchronization comprehensively.
- Examples
- Uses an LFU cache set operation, competing threads with one free slot, synchronized cache locking, and Java concurrent collections.
- What you can do after
- Build it from scratch by enclosing dependent cache mutations in a write lock and releasing it reliably.
Read how Advanced Algorithms and Data Structures explains atomicity →
Data Pipelines with Apache Airflow, Second Edition
An atomic transaction is an indivisible database transaction whose operations either all take effect or have no effect.
- How it is used
- Designs Airflow tasks that report accurate outcomes during retries, failures, backfills, and reruns.
- How deep it goes
- Defines all-or-nothing behavior, demonstrates task decomposition, and applies transactions without detailing database isolation internals.
- Examples
- Uses user statistics and email delivery, API authentication, and pandas database replacement as concrete cases.
- What you can do after
- Apply it via Airflow by separating independent work and wrapping related database changes in transactions.
Read how Data Pipelines with Apache Airflow, Second Edition explains atomicity →
Grokking Concurrency
Atomicity is the property that an operation occurs as one indivisible action, either completing entirely or not taking effect.
- How it is used
- Prevents concurrent tasks from observing partial updates to shared primitive data.
- How deep it goes
- Explains all-or-nothing hardware execution and software support, but defers detailed implementation of atomic data structures.
- Examples
- Uses a counter increment and an assembly instruction adding one to a memory location.
- What you can do after
- Apply atomic data structures when supported, and substitute locks or message passing when atomicity is unavailable.
Learn Rust in a Month of Lunches
An atomic operation is an indivisible computer operation that appears to other threads as either fully completed or not performed.
- How it is used
- Uses atomicity to explain why Arc and Mutex are needed when threads access shared data.
- How deep it goes
- Defines indivisibility and demonstrates lost updates, but defers processor-level implementation details.
- Examples
- Uses concurrent counter increments and an Arc-wrapped Mutex to demonstrate lost and preserved updates.
- What you can do after
- Apply atomicity via Arc and Mutex when multiple threads update shared data.
Read how Learn Rust in a Month of Lunches explains atomicity →
Related concepts
- ACIDpart of · ACID is the set of database transaction properties—atomicity, consistency, isolation, and durability—that characterize reliable transactional behavior.
- compare-and-exchange operationincludes · A compare-and-exchange operation atomically replaces a value with a desired value only if the current value matches an expected value.
- read-modify-write operationincludes · An operation that reads a value from a location, computes or selects an update, and writes the resulting value back to that location.
- atomic operationincludes · An atomic operation accesses or updates shared state as an indivisible action with respect to concurrent operations.
- lockingalternative to · Locking is a synchronization technique that restricts concurrent access to shared resources or protected operations.
- batchingimplemented by · Batching is the grouping of multiple data items, requests, or operations so they can be processed together as a unit.
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.