{"title":"Atomic Operations","description":null,"content":"# Atomic Operations\n\nIncrementing a counter seems trivial. Just add one, right?\n\nBut `count++` is actually three operations: read the value, add one, write the result back. If two threads run this \"simultaneously,\" you get corrupted data.\n\n**Atomic operations** solve this by executing as a single, indivisible unit. No thread can observe the operation in a half-completed state.\n\nIn this article, we'll explore:\n\n- What makes an operation atomic\n- Why non-atomic operations fail in concurrent code\n- How atomic operations work at the hardware level\n- Compare-and-Swap (CAS) and lock-free programming\n- When to use atomic operations vs locks\n\n---\n\nIf you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](https://blog.algomaster.io/subscribe)\n\n---\n\n## 1. What is an Atomic Operation?\n\nAn **atomic operation** is an operation that completes in a single step from the perspective of other threads. It cannot be interrupted, and other threads cannot see it in a partially completed state.\n\nThe word \"atomic\" comes from the Greek word \"atomos,\" meaning indivisible.\n\n\n```mermaid\nflowchart LR\n subgraph NonAtomic[\"Non-Atomic: count++\"]\n R[\"1. Read\"]\n A[\"2. Add\"]\n W[\"3. Write\"]\n R --> A --> W\n end\n\n subgraph Atomic[\"Atomic: incrementAndGet()\"]\n Single[\"Read + Add + Write
(Single indivisible operation)\"]\n end\n\n style NonAtomic fill:#ff8787,stroke:#000,color:#000\n style Atomic fill:#69db7c,stroke:#000,color:#000\n style R fill:#00ceff,stroke:#000,color:#000\n style A fill:#ffa94d,stroke:#000,color:#000\n style W fill:#9775fa,stroke:#000,color:#000\n style Single fill:#00ceff,stroke:#000,color:#000\n```\n\n\n### Types of Atomic Operations\n\n\n| ##### Type | ##### Description | ##### Example |\n| --- | --- | --- |\n| **Atomic Read** | Reading a value in one step | Reading a 32-bit integer |\n| **Atomic Write** | Writing a value in one step | Writing a 32-bit integer |\n| **Atomic Read-Modify-Write** | Read, modify, and write as one operation | Increment, compare-and-swap |\n\n\nSimple reads and writes of primitive types are often atomic on modern hardware. The challenge is **read-modify-write** operations like increment, which require multiple steps.\n\n---\n\n## 2. The Problem with Non-Atomic Operations\n\nConsider a counter shared between two threads:\n\n\n```java\npublic class Counter {\n private int count = 0;\n\n public void increment() {\n count++;\n }\n}\n```\n\n\nThe `count++` operation compiles to something like this:\n\n\n```shell\n1. Load count from memory into register\n2. Add 1 to register\n3. Store register value back to memory\n```\n\n\nWhen two threads execute this concurrently, their operations can interleave:\n\n\n```mermaid\nsequenceDiagram\n participant T1 as Thread 1\n participant Mem as Memory (count)\n participant T2 as Thread 2\n\n Note over Mem: count = 0\n\n T1->>Mem: Read count (gets 0)\n T2->>Mem: Read count (gets 0)\n T1->>T1: Add 1 (result = 1)\n T2->>T2: Add 1 (result = 1)\n T1->>Mem: Write 1\n T2->>Mem: Write 1\n\n Note over Mem: count = 1 (should be 2)\n```\n\n\nBoth threads read 0, both compute 1, both write 1. One increment is lost. This is called a **lost update** or **race condition**.\n\n---\n\n## 3. How Atomic Operations Work\n\nModern CPUs provide special instructions that perform read-modify-write operations atomically. These instructions lock the memory bus for the duration of the operation, preventing other cores from accessing that memory location.\n\n### Hardware Support\n\nMost processors support these atomic instructions:\n\n\n| ##### Instruction | ##### Description |\n| --- | --- |\n| **Test-and-Set** | Read a value and set it to 1 atomically |\n| **Fetch-and-Add** | Read a value and add to it atomically |\n| **Compare-and-Swap (CAS)** | Compare value with expected, swap if match |\n| **Load-Link/Store-Conditional** | Alternative to CAS on some architectures |\n\n\n\n```mermaid\nflowchart TB\n subgraph CPU[\"CPU Atomic Instruction\"]\n Lock[\"Lock memory bus\"]\n Read[\"Read value\"]\n Modify[\"Modify value\"]\n Write[\"Write value\"]\n Unlock[\"Unlock memory bus\"]\n end\n\n Lock --> Read --> Modify --> Write --> Unlock\n\n Other[\"Other CPU cores\"]\n Other -.->|\"Blocked during operation\"| Lock\n\n style CPU fill:#00ceff,stroke:#000,color:#000\n style Lock fill:#ff8787,stroke:#000,color:#000\n style Read fill:#69db7c,stroke:#000,color:#000\n style Modify fill:#ffa94d,stroke:#000,color:#000\n style Write fill:#69db7c,stroke:#000,color:#000\n style Unlock fill:#9775fa,stroke:#000,color:#000\n style Other fill:#38d9a9,stroke:#000,color:#000\n```\n\n\n### Memory Barriers\n\nAtomic operations also include **memory barriers** (or fences) that prevent the CPU and compiler from reordering instructions around them. This ensures that changes made before an atomic operation are visible to other threads that observe the atomic operation.\n\n---\n\n## 4. Compare-and-Swap (CAS)\n\n**Compare-and-Swap (CAS)** is the foundation of most atomic operations. It atomically:\n\n1. Compares the current value with an expected value\n2. If they match, updates to a new value\n3. Returns whether the update succeeded\n\n\n```mermaid\nflowchart TD\n Start[\"CAS(expected, new)\"]\n Read[\"Read current value\"]\n Compare{\"current == expected?\"}\n Swap[\"Write new value\"]\n Success[\"Return true\"]\n Fail[\"Return false\"]\n\n Start --> Read\n Read --> Compare\n Compare -->|\"Yes\"| Swap\n Swap --> Success\n Compare -->|\"No\"| Fail\n\n style Start fill:#00ceff,stroke:#000,color:#000\n style Read fill:#ffa94d,stroke:#000,color:#000\n style Compare fill:#9775fa,stroke:#000,color:#000\n style Swap fill:#69db7c,stroke:#000,color:#000\n style Success fill:#69db7c,stroke:#000,color:#000\n style Fail fill:#ff8787,stroke:#000,color:#000\n```\n\n\n### CAS Pseudocode\n\n\n```shell\nfunction compareAndSwap(address, expected, new):\n atomic:\n current = *address\n if current == expected:\n *address = new\n return true\n return false\n```\n\n\n### Implementing Increment with CAS\n\nUsing CAS, we can implement a thread-safe increment without locks:\n\n\n```java\npublic void increment() {\n int current;\n int next;\n do {\n current = count.get(); // Read current value\n next = current + 1; // Compute new value\n } while (!count.compareAndSet(current, next)); // Try to update\n}\n```\n\n\nIf another thread modified `count` between the read and the CAS, the CAS fails, and we retry. This is called a **CAS loop** or **spin**.\n\n\n```mermaid\nflowchart TD\n Start[\"Start increment\"]\n Read[\"Read current value\"]\n Compute[\"Compute new = current + 1\"]\n CAS{\"CAS(current, new)\"}\n Done[\"Done\"]\n Retry[\"Another thread
modified value\"]\n\n Start --> Read\n Read --> Compute\n Compute --> CAS\n CAS -->|\"Success\"| Done\n CAS -->|\"Fail\"| Retry\n Retry --> Read\n\n style Start fill:#00ceff,stroke:#000,color:#000\n style Read fill:#ffa94d,stroke:#000,color:#000\n style Compute fill:#69db7c,stroke:#000,color:#000\n style CAS fill:#9775fa,stroke:#000,color:#000\n style Done fill:#69db7c,stroke:#000,color:#000\n style Retry fill:#ff8787,stroke:#000,color:#000\n```\n\n\n---\n\n## 5. Atomic Variables\n\nMost programming languages provide atomic variable classes that wrap primitive types and provide atomic operations.\n\n### Common Atomic Classes\n\n\n| ##### Class | ##### Description |\n| --- | --- |\n| AtomicInteger | Atomic int with increment, add, CAS |\n| AtomicLong | Atomic long with same operations |\n| AtomicBoolean | Atomic boolean with get, set, CAS |\n| AtomicReference | Atomic object reference |\n\n\n### Basic Usage\n\n\n```java\nimport java.util.concurrent.atomic.AtomicInteger;\n\npublic class Counter {\n private AtomicInteger count = new AtomicInteger(0);\n\n public void increment() {\n count.incrementAndGet(); // Atomic increment\n }\n\n public int get() {\n return count.get(); // Atomic read\n }\n}\n```\n\n\n### Common Atomic Operations\n\n\n| ##### Operation | ##### Description |\n| --- | --- |\n| `get()` | Read the current value |\n| `set(value)` | Write a value |\n| `getAndSet(value)` | Read current, set new, return old |\n| `compareAndSet(expect, update)` | CAS operation |\n| `incrementAndGet()` | Increment and return new value |\n| `getAndIncrement()` | Return current and then increment |\n| `addAndGet(delta)` | Add delta and return new value |\n| `getAndAdd(delta)` | Return current and then add delta |\n\n\n---\n\n## 6. Atomic Operations vs Locks\n\nAtomic operations and locks both solve concurrency problems, but they work differently.\n\n\n```mermaid\nflowchart LR\n subgraph Locks[\"Lock-Based\"]\n L1[\"Acquire lock\"]\n L2[\"Execute critical section\"]\n L3[\"Release lock\"]\n L1 --> L2 --> L3\n end\n\n subgraph Atomic[\"Lock-Free (Atomic)\"]\n A1[\"Read value\"]\n A2[\"Compute new value\"]\n A3[\"CAS\"]\n A4{\"Success?\"}\n A1 --> A2 --> A3 --> A4\n A4 -->|\"No\"| A1\n end\n\n style Locks fill:#ffa94d,stroke:#000,color:#000\n style Atomic fill:#00ceff,stroke:#000,color:#000\n```\n\n\n### Comparison\n\n\n| ##### Aspect | ##### Locks | ##### Atomic Operations |\n| --- | --- | --- |\n| **Mechanism** | Block threads | Retry on conflict |\n| **Blocking** | Yes | No (lock-free) |\n| **Deadlock risk** | Yes | No |\n| **Performance (low contention)** | Good | Better |\n| **Performance (high contention)** | Better | Can degrade (spinning) |\n| **Complexity** | Simple | Can be complex |\n| **Scope** | Any code block | Single variable |\n\n\n### When to Use Each\n\n**Use atomic operations when:**\n\n- Operating on a single variable\n- Operations are simple (increment, compare-and-set)\n- Contention is low to moderate\n- You need lock-free guarantees\n\n**Use locks when:**\n\n- Operating on multiple variables together\n- Operations are complex\n- You need to hold the lock for longer operations\n- High contention makes spinning wasteful\n\n---\n\n## 7. The ABA Problem\n\nCAS has a subtle issue called the **ABA problem**. It occurs when a value changes from A to B and back to A between a thread's read and CAS.\n\n\n```mermaid\nsequenceDiagram\n participant T1 as Thread 1\n participant Mem as Memory\n participant T2 as Thread 2\n\n Note over Mem: value = A\n\n T1->>Mem: Read A\n T1->>T1: Prepare to CAS(A, C)\n\n Note over T1: Thread 1 paused\n\n T2->>Mem: Read A\n T2->>Mem: CAS(A, B) - Success\n Note over Mem: value = B\n T2->>Mem: CAS(B, A) - Success\n Note over Mem: value = A (back to A)\n\n Note over T1: Thread 1 resumes\n\n T1->>Mem: CAS(A, C) - Success!\n Note over Mem: Thread 1 thinks nothing
changed, but B happened\n```\n\n\nThread 1 sees value A, prepares to change it to C. While paused, Thread 2 changes A to B, then back to A. Thread 1 resumes, sees A (expected), and CAS succeeds. But the value was modified in between.\n\n### Why ABA Matters\n\nFor simple counters, ABA is usually harmless. But for data structures like lock-free stacks or queues, ABA can cause serious bugs:\n\n\n```shell\nScenario: Lock-free stack pop\n\n1. Thread 1 reads top = Node A (points to Node B)\n2. Thread 1 prepares CAS to make B the new top\n3. Thread 2 pops A, pops B, pushes new C, pushes A back\n4. Stack: A -> C (B is gone, A now points to C)\n5. Thread 1's CAS succeeds (top is still A)\n6. Thread 1 sets top = B (which is no longer in stack!)\n7. Stack is now corrupted\n```\n\n\n### Solutions to ABA\n\n**1. Version numbers (Stamped references)**\n\nPair the value with a version number that increments on every update:\n\n\n```java\nAtomicStampedReference head = new AtomicStampedReference<>(null, 0);\n\nint[] stampHolder = new int[1];\nNode current = head.get(stampHolder);\nint stamp = stampHolder[0];\n\n// CAS checks both value AND stamp\nhead.compareAndSet(current, newNode, stamp, stamp + 1);\n```\n\n\n**2. Hazard pointers**\n\nKeep track of which pointers are being accessed by threads. Only reclaim memory when no thread is accessing it.\n\n**3. Garbage collection**\n\nIn languages with GC, memory is not reused immediately, reducing (but not eliminating) ABA risk.\n\n---\n\n## 8. Lock-Free Data Structures\n\nAtomic operations enable **lock-free** data structures that provide progress guarantees without locks.\n\n### Lock-Free Stack Example\n\n\n```java\npublic class LockFreeStack {\n private AtomicReference> top = new AtomicReference<>(null);\n\n public void push(T value) {\n Node newNode = new Node<>(value);\n Node current;\n do {\n current = top.get();\n newNode.next = current;\n } while (!top.compareAndSet(current, newNode));\n }\n\n public T pop() {\n Node current;\n Node next;\n do {\n current = top.get();\n if (current == null) return null;\n next = current.next;\n } while (!top.compareAndSet(current, next));\n return current.value;\n }\n\n private static class Node {\n T value;\n Node next;\n Node(T value) { this.value = value; }\n }\n}\n```\n\n\n\n```mermaid\nflowchart TB\n subgraph Push[\"Push Operation\"]\n P1[\"Create new node\"]\n P2[\"Read current top\"]\n P3[\"Point new.next to current\"]\n P4[\"CAS top to new node\"]\n P5{\"Success?\"}\n P1 --> P2 --> P3 --> P4 --> P5\n P5 -->|\"No\"| P2\n end\n\n subgraph Pop[\"Pop Operation\"]\n O1[\"Read current top\"]\n O2[\"Get next node\"]\n O3[\"CAS top to next\"]\n O4{\"Success?\"}\n O1 --> O2 --> O3 --> O4\n O4 -->|\"No\"| O1\n end\n\n style Push fill:#69db7c,stroke:#000,color:#000\n style Pop fill:#00ceff,stroke:#000,color:#000\n```\n\n\n### Progress Guarantees\n\n\n| ##### Guarantee | ##### Definition |\n| --- | --- |\n| **Wait-free** | Every operation completes in bounded steps |\n| **Lock-free** | At least one thread makes progress |\n| **Obstruction-free** | A thread makes progress if run alone |\n| **Blocking** | Threads can be blocked indefinitely |\n\n\nAtomic CAS loops are typically **lock-free** but not wait-free. At least one thread always succeeds, but individual threads might retry many times.\n\n---\n\n## 9. Memory Ordering and Visibility\n\nAtomic operations provide more than atomicity. They also control **memory visibility** and **ordering**.\n\n### The Visibility Problem\n\nWithout proper synchronization, one thread's writes might not be visible to another thread due to:\n\n- CPU caches holding different values\n- Compiler reordering instructions\n- CPU out-of-order execution\n\n\n```mermaid\nflowchart TB\n subgraph T1[\"Thread 1 (CPU 1)\"]\n C1[\"CPU Cache
x = 1\"]\n end\n\n subgraph T2[\"Thread 2 (CPU 2)\"]\n C2[\"CPU Cache
x = 0 (stale)\"]\n end\n\n Mem[\"Main Memory
x = 1\"]\n\n T1 -->|\"wrote\"| Mem\n Mem -.->|\"not synced\"| T2\n\n style T1 fill:#00ceff,stroke:#000,color:#000\n style T2 fill:#ffa94d,stroke:#000,color:#000\n style Mem fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Memory Ordering Modes\n\nDifferent languages offer different memory ordering options:\n\n\n| ##### Mode | ##### Guarantee | ##### Performance |\n| --- | --- | --- |\n| **Relaxed** | Only atomicity, no ordering | Fastest |\n| **Acquire** | Reads after this see writes before release | Medium |\n| **Release** | Writes before this are visible after acquire | Medium |\n| **Sequential Consistency** | Total global ordering | Slowest |\n\n\nMost atomic classes use **sequential consistency** by default, providing the strongest guarantees.\n\n---\n\n## 10. Common Patterns\n\n### Pattern 1: Atomic Counter\n\n\n```java\nAtomicLong requestCount = new AtomicLong(0);\n\npublic void handleRequest() {\n requestCount.incrementAndGet();\n // Process request\n}\n```\n\n\n### Pattern 2: Atomic Flag\n\n\n```java\nAtomicBoolean shutdown = new AtomicBoolean(false);\n\npublic void shutdown() {\n if (shutdown.compareAndSet(false, true)) {\n // Only one thread executes cleanup\n cleanup();\n }\n}\n```\n\n\n### Pattern 3: Lazy Initialization\n\n\n```java\nAtomicReference instance = new AtomicReference<>();\n\npublic ExpensiveObject getInstance() {\n ExpensiveObject current = instance.get();\n if (current != null) return current;\n\n ExpensiveObject newInstance = new ExpensiveObject();\n if (instance.compareAndSet(null, newInstance)) {\n return newInstance;\n }\n return instance.get(); // Another thread won\n}\n```\n\n\n### Pattern 4: Atomic Update\n\n\n```java\nAtomicInteger max = new AtomicInteger(Integer.MIN_VALUE);\n\npublic void updateMax(int value) {\n int current;\n do {\n current = max.get();\n if (value <= current) return; // No update needed\n } while (!max.compareAndSet(current, value));\n}\n```\n\n\n---\n\n## 11. Common Pitfalls\n\n### Pitfall 1: Assuming All Operations Are Atomic\n\n\n```java\n// Bad: Two atomic operations are not atomic together\nif (counter.get() < MAX) {\n counter.increment(); // Race condition between check and increment\n}\n\n// Good: Use atomic update methods\ncounter.updateAndGet(v -> v < MAX ? v + 1 : v);\n```\n\n\n### Pitfall 2: Excessive Spinning Under High Contention\n\n\n```java\n// Many threads competing = lots of failed CAS = wasted CPU\nAtomicLong counter = new AtomicLong();\n// 100 threads all incrementing rapidly\n\n// Better: Use LongAdder for high-contention counters\nLongAdder adder = new LongAdder();\nadder.increment();\nlong sum = adder.sum();\n```\n\n\n### Pitfall 3: Ignoring the ABA Problem\n\n\n```java\n// Bad: Simple CAS on pointer-based structures\nAtomicReference head;\n// ABA can corrupt the structure\n\n// Good: Use stamped references\nAtomicStampedReference head;\n```\n\n\n### Pitfall 4: Using Atomic Variables for Compound Operations\n\n\n```java\n// Bad: Separate atomic variables don't give atomic compound operation\nAtomicInteger balance = new AtomicInteger(100);\nAtomicInteger transactions = new AtomicInteger(0);\n\n// This is NOT atomic together\nbalance.addAndGet(-50);\ntransactions.incrementAndGet();\n\n// Good: Use locks for compound operations, or design differently\n```\n\n\n---\n\n## 12. Performance Considerations\n\n### When Atomics Excel\n\n- Low to moderate contention\n- Simple operations (increment, CAS)\n- Hot paths where lock overhead matters\n- When lock-free guarantees are needed\n\n### When Atomics Struggle\n\n- High contention (many threads competing)\n- Complex operations requiring multiple variables\n- Long-running operations\n\n### Specialized High-Performance Classes\n\nFor high-contention scenarios, use specialized classes:\n\n\n| ##### Class | ##### Use Case |\n| --- | --- |\n| LongAdder | High-contention counter (better than AtomicLong) |\n| LongAccumulator | High-contention accumulation with custom function |\n| DoubleAdder | High-contention double counter |\n\n\n\n```java\n// AtomicLong: all threads compete on single variable\nAtomicLong atomicCounter = new AtomicLong();\n\n// LongAdder: threads update separate cells, sum on read\nLongAdder adder = new LongAdder();\nadder.increment();\nlong total = adder.sum(); // Aggregates all cells\n```\n\n\n\n```mermaid\nflowchart LR\n subgraph AtomicLong[\"AtomicLong\"]\n Single[\"Single Value\"]\n T1a[\"Thread 1\"] --> Single\n T2a[\"Thread 2\"] --> Single\n T3a[\"Thread 3\"] --> Single\n end\n\n subgraph LongAdder[\"LongAdder\"]\n Cell1[\"Cell 1\"]\n Cell2[\"Cell 2\"]\n Cell3[\"Cell 3\"]\n T1b[\"Thread 1\"] --> Cell1\n T2b[\"Thread 2\"] --> Cell2\n T3b[\"Thread 3\"] --> Cell3\n end\n\n style AtomicLong fill:#ff8787,stroke:#000,color:#000\n style LongAdder fill:#69db7c,stroke:#000,color:#000\n style Single fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n---\n\n## 13. Summary\n\n**Atomic operations** provide thread-safe access to shared variables without locks. They are the building blocks of lock-free concurrent programming.\n\n\n```mermaid\nflowchart TD\n Problem[\"Problem: Race Conditions\"]\n Solution[\"Solution: Atomic Operations\"]\n\n Hardware[\"Hardware Support
(CAS, Memory Barriers)\"]\n AtomicVars[\"Atomic Variables
(AtomicInteger, etc.)\"]\n LockFree[\"Lock-Free Data Structures\"]\n\n Problem --> Solution\n Solution --> Hardware\n Solution --> AtomicVars\n Solution --> LockFree\n\n style Problem fill:#ff8787,stroke:#000,color:#000\n style Solution fill:#69db7c,stroke:#000,color:#000\n style Hardware fill:#00ceff,stroke:#000,color:#000\n style AtomicVars fill:#ffa94d,stroke:#000,color:#000\n style LockFree fill:#9775fa,stroke:#000,color:#000\n```\n\n\n### Key Concepts\n\n\n| ##### Concept | ##### Description |\n| --- | --- |\n| Atomic Operation | Indivisible operation, no partial state visible |\n| Compare-and-Swap | Compare expected, swap if match, return success |\n| CAS Loop | Retry CAS until success |\n| ABA Problem | Value changes A->B->A, CAS succeeds incorrectly |\n| Lock-Free | At least one thread always makes progress |\n\n\n### When to Use\n\n\n| ##### Scenario | ##### Recommendation |\n| --- | --- |\n| Simple counter | AtomicInteger/AtomicLong |\n| High-contention counter | LongAdder |\n| Boolean flag | AtomicBoolean |\n| Object reference | AtomicReference |\n| Multiple variables | Use locks instead |\n| Complex operations | Use locks instead |\n\n\n### Best Practices\n\n1. Use atomic variables for single-variable operations\n2. Prefer higher-level constructs (LongAdder) for high contention\n3. Watch out for ABA problem in pointer-based structures\n4. Use locks when operations span multiple variables\n5. Understand memory ordering guarantees\n6. Profile before optimizing with atomics\n\nAtomic operations are a powerful tool for building efficient concurrent code. Master them, and you can write lock-free algorithms that scale better under contention while avoiding deadlocks entirely.\n\n---\n\nThank you for reading!\n\nIf you found it valuable, hit a like and consider subscribing for more such content every week.\n\nIf you have any questions or suggestions, leave a comment.\n\nThis post is public so feel free to share it.\n\n[Share](https://blog.algomaster.io/)\n\n---\n\n**P.S.** If you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](https://blog.algomaster.io/subscribe)\n\n**There are [group discounts](https://blog.algomaster.io/subscribe?group=true), [gift options](https://blog.algomaster.io/subscribe?gift=true), and [referral bonuses](https://blog.algomaster.io/leaderboard) available.**\n\n---\n\nCheckout my **[Youtube channel](https://www.youtube.com/@ashishps_1/videos)** for more in-depth content.\n\nFollow me on **[LinkedIn](https://www.linkedin.com/in/ashishps1/)** and **[X](https://twitter.com/ashishps_1)** to stay updated.\n\nCheckout my **[GitHub repositories](https://github.com/ashishps1)** for free interview preparation resources.\n\nI hope you have a lovely day!\n\nSee you soon, Ashish\n\n---\n\n## References\n\n- [Java Concurrency in Practice (Brian Goetz)](https://jcip.net/) - Chapter 15: Atomic Variables and Nonblocking Synchronization\n- [The Art of Multiprocessor Programming (Herlihy & Shavit)](https://www.elsevier.com/books/the-art-of-multiprocessor-programming/herlihy/978-0-12-415950-1) - Comprehensive coverage of lock-free algorithms\n- [Java Atomic Package Documentation](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html)\n- [Memory Barriers: a Hardware View for Software Hackers](http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf) - Deep dive into memory ordering\n\n---\n\n## Images Needed\n\n[IMAGE 1: Atomic vs Non-Atomic Operation] \n\n[IMAGE 2: Compare-and-Swap Flow] \n\n[IMAGE 3: CAS Loop Retry] \n\n[IMAGE 4: ABA Problem Timeline] \n\n[IMAGE 5: Lock-Free Stack Push/Pop] \n\n[IMAGE 6: AtomicLong vs LongAdder] ","pageType":"lld-interviews"}

Atomic Operations

Ashish Pratap Singh

Get Premium