What Are Atomic Operations in an Operating System?
Learn what atomic operations are, why plain increments race, and how CAS underpins mutexes, with OS interview questions answered.
Expected Interview Answer
An atomic operation is one that executes as a single, indivisible step from the perspective of every other thread or CPU core, so no concurrent operation can ever observe it half-completed, which is what makes it safe to use for shared-state updates without a lock.
Ordinary operations like incrementing a shared counter (counter++) actually compile into multiple steps — read the value, add one, write it back — and if two threads interleave those steps, one increment can be lost entirely, a classic race condition. Atomic operations, provided either by dedicated CPU instructions (compare-and-swap, fetch-and-add, test-and-set) or by the language’s atomic types, guarantee the hardware performs the read-modify-write as one uninterruptible unit, using the memory bus’s lock signal or cache-coherence protocol to block any other core from touching that location mid-operation. Atomics are the foundation everything else in concurrency is built on: mutexes, semaphores, and lock-free data structures are all implemented using atomic instructions underneath, because you need at least one truly indivisible primitive to bootstrap any higher-level synchronization. The tradeoff is scope — atomics only protect a single memory location per instruction, so multi-step invariants across several variables still need a lock or a carefully designed lock-free algorithm built from a sequence of atomics.
- Prevents lost updates and race conditions on shared counters/flags
- Forms the hardware foundation mutexes and semaphores are built on
- Enables lock-free data structures without kernel involvement
- Explains why plain increments on shared variables are unsafe
AI Mentor Explanation
An atomic operation is like a single indivisible umpire signal — raising the six-runs signal happens in one motion that nobody can interrupt or half-perform, unlike a scorer manually reading the total, adding runs, and writing it back across three separate steps where another scorer could interleave and lose an update. Because the signal is one uninterruptible action, two umpires can never produce a half-finished or conflicting signal at the same instant. That single-step, unsplittable guarantee is exactly what makes an operation atomic.
Step-by-Step Explanation
Step 1
Non-atomic hazard
A plain increment like counter++ actually decomposes into read, add, and write as three separate machine steps.
Step 2
Interleaving risk
If two threads interleave those three steps, one thread's write can be silently overwritten, losing an update.
Step 3
Atomic instruction
A dedicated hardware instruction (fetch-and-add, CAS, test-and-set) performs read-modify-write as one indivisible step using the bus lock or cache-coherence protocol.
Step 4
Higher-level primitives built on it
Mutexes, semaphores, and lock-free structures all use these atomic instructions as their foundational building block.
What Interviewer Expects
- A precise definition of atomicity as indivisibility observable by other threads
- A concrete example of why a plain increment on shared data is unsafe
- Naming at least one real atomic instruction (CAS, fetch-and-add, test-and-set)
- Understanding that atomics are the foundation for mutexes and lock-free structures
Common Mistakes
- Assuming counter++ is already atomic in most languages by default
- Confusing atomicity with thread safety of an entire multi-step algorithm
- Not knowing any actual atomic CPU instruction by name
- Thinking atomics eliminate the need for locks in all situations
Best Answer (HR Friendly)
“An atomic operation is one that happens as a single, uninterruptible step, so no other thread can ever catch it half-done. This matters because something as simple as incrementing a shared counter is actually three separate steps under the hood, and without atomicity, two threads doing that at the same time can silently lose an update. Atomic operations are the basic building block that locks and other synchronization tools are built on top of.”
Code Example
#include <stdatomic.h>
int unsafe_counter = 0;
atomic_int safe_counter = 0;
/* UNSAFE: read, add, write are three separate steps -- can race */
void unsafe_increment(void) {
unsafe_counter = unsafe_counter + 1;
}
/* SAFE: fetch-and-add executes as one indivisible hardware step */
void safe_increment(void) {
atomic_fetch_add(&safe_counter, 1);
}Follow-up Questions
- Why is counter++ not atomic in most compiled languages?
- What is the difference between fetch-and-add and compare-and-swap?
- How does the CPU enforce atomicity across multiple cores?
- Can atomic operations replace mutexes entirely?
MCQ Practice
1. What makes an operation atomic?
Atomicity means the operation is indivisible from the perspective of other threads or cores — it either fully happens or has not happened yet, with no in-between state visible.
2. Why is a plain counter++ on shared data unsafe without atomics?
The increment is really three machine steps; if two threads interleave them, one thread's update can be silently lost.
3. What are mutexes and semaphores typically built from?
Higher-level synchronization primitives use atomic hardware instructions as the indivisible foundation to safely coordinate their internal state.
Flash Cards
What is an atomic operation? — An operation that executes as one indivisible step, never observable half-done by other threads.
Why is counter++ unsafe on shared data? — It decomposes into read-add-write steps that can interleave and lose updates between threads.
Name two atomic CPU instructions. — Compare-and-swap (CAS) and fetch-and-add (also test-and-set).
What is built on top of atomic operations? — Mutexes, semaphores, and lock-free data structures.