{
  "id": 8192725,
  "title": "Concurrency Programming (1): Start with the Hardware — From count++ to Atomicity, Visibility, and Ordering",
  "url": "https://urgent.news/2026/09/18/concurrency-programming-1-start-with-the-hardware-from-count-to",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-18T06:37:56.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/thinkerqaq/concurrency-programming-1-start-with-the-hardware-from-count-to-atomicity-visibility-and-1a0o"
  },
  "original_language": "en",
  "account": "Concurrency Programming (1): Start with the Hardware — From count++ to Atomicity, Visibility, and Ordering\n\nThe von Neumann architecture treats programs and data as the same thing. A computer is divided into a control unit, arithmetic unit, memory, and input/output devices. The CPU contains a program counter, instruction register, and general-purpose registers. The CPU fetches instructions, decodes them, and executes them, continually looping through these steps.\n\nThe expression count++ can be broken down into three machine-level operations: loading the value of count into a register, incrementing the value inside the CPU, and storing the result back to memory. These operations are not performed atomically, meaning that another operation could interrupt and observe an intermediate state, leading to lost updates.\n\nModern processors use caches to speed up access to data. Data is loaded into smaller, faster cache levels before being stored in main memory. This optimization does not make count++ a safe concurrent operation, as separate operations can still be executed out of order.\n\nWith multiple cores, two threads may execute in parallel, leading to the problem of visibility. If two cores read the same value of count, the updates made by one core may not be immediately visible to the other core. This introduces the problem of visibility, where the question arises of when other cores can observe the new value after a core has written to it.\n\nFinally, the order of multiple memory operations becomes important. If Thread A writes to count and then Thread B reads ready and sets it to true, the order of these operations should be preserved so that Thread B can only see the updated values if it has already observed ready being set to true. This introduces the problem of memory ordering, which ensures that the sequence of memory operations is maintained across cores.",
  "summary": "Table of Contents 1. Start with the von Neumann Architecture 2. What Does count++ Become? 3. Why Do We Need Caches? 4. Concurrency on One Core: Why Can count++ Lose an Update? 5. From One Core to Multiple Cores: Visibility 6. What About the Order of Multiple Memory Operations? 6.1 Store Buffer 6.2 Out-of-Order Execution 6.3 Store Buffer vs Out-of-Order Execution 7. We Have Actually Encountered…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}