# Concurrent Programming A programming discipline involving processes and threads as execution units. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Python 3.14 free-threaded build is now available in RHEL DevFeed: [Python 3.14 free-threaded build is now available in RHEL]() Original publisher: [Read original article]() Author: Lumír Balhar Published: 2026-09-14T13:01:41Z Content type: release Language: en Sources: [Red Hat](), [Red Hat Developer]() Topics: [Python 3.14](), [Python](), [Concurrency](), [Linux](), [Concurrent Programming](), [cpu]() Tags: [cpu](), [developer-tools](), [developers](), [linux](), [performance](), [programming-languages-frameworks](), [python](), [python-3-14](), [red-hat](), [release](), [rhel](), [thread](), [upstream-release]() ### AI overview Red Hat Enterprise Linux 9.8 and 10.2 now provide a free-threaded Python 3.14 build through the Red Hat CodeReady Linux Builder repositories. With the GIL disabled, CPU-bound Python threads can execute in parallel across multiple CPU cores within a single process. The article explains expected performance benefits, installation, verification, and possible thread-safety issues in existing code. ### Source excerpt Developers on Red Hat Enterprise Linux 9.8 and 10.2 can now test full parallel CPU execution in Python using the new free-threaded Python 3.14 build. In addition to the regular Python 3.14 interpreter, we also provide the free-threaded variant in the Red Hat CodeReady Linux Builder repositories. Python 3.14 is the first upstream release where the free-threaded build is officially supported rather than experimental. The post Python 3.14 free-threaded build is now available in RHEL appeared first on Red Hat Developer. ## Back to the Basics. Threads. DevFeed: [Back to the Basics. Threads.]() Original publisher: [Read original article]() Author: Daniel Beach Published: 2026-09-14T12:19:11Z Content type: tutorial Language: en Sources: [Data Engineering Central]() Topics: [Concurrency](), [Rust](), [Concurrent Programming](), [Programming](), [Python]() Tags: [concurrency](), [programming](), [python](), [rust](), [threads]() ### AI overview An introductory, applied discussion of threads and concurrency, focusing on Rust and briefly recalling Python ProcessPools for parallel data and file processing. ### Source excerpt staying grounded in an agentic world ## Speeding Up Azure Durable Functions with Fan-Out/Fan-In and a Higher Concurrency Limit DevFeed: [Speeding Up Azure Durable Functions with Fan-Out/Fan-In and a Higher Concurrency Limit]() Original publisher: [Read original article]() Author: Michael Li Published: 2026-09-14T12:00:32Z Content type: tutorial Language: en Sources: [Atomic Object]() Topics: [Azure](), [Concurrent Programming](), [Code]() Tags: [apis](), [azure](), [azure-functions](), [batch](), [concurrency](), [development-practices](), [file](), [storage]() ### AI overview An Azure Durable Functions batch job was accelerated by combining fan-out/fan-in orchestration with a higher function-host concurrency limit. Together, the changes reduced a representative run from about 710 seconds to about 240 seconds. ### Source excerpt For one of our projects, we run a nightly job that generates a batch of files. It's a long process: pulling records from an upstream system, calling several APIs to gather info about each one, generating a file per record, and writing the results back to storage. For a small batch, this works fine, but [...] The post 2 Changes Made Our Azure Durable Functions 3X Faster appeared first on Atomic Spin. ## Scaling real-time AI agents with session-aware load balancing DevFeed: [Scaling real-time AI agents with session-aware load balancing]() Original publisher: [Read original article]() Author: Simerus Mahesh Published: 2026-09-12T11:04:33.891311Z Content type: article Language: en Sources: [Google Developers Blog]() Topics: [real-time](), [Artificial Intelligence](), [Streaming](), [Server](), [gRPC](), [WebSocket](), [cpu](), [Concurrent Programming]() Tags: [ai-agents](), [concurrent](), [cpu](), [real-time](), [routing](), [server](), [streaming]() ### AI overview This article explains why real-time AI agents require session-aware load balancing. Long-lived, stateful bidirectional streams make request rates and CPU utilization insufficient measures of backend capacity. The proposed approach tracks active sessions at the application level and combines session counts with CPU metrics to distribute traffic and avoid bottlenecks. ### Source excerpt Real-time AI agents break traditional request-response load balancing paradigms because they rely on long-lived, stateful bidirectional streams that obscure true server capacity. To solve this, developers must implement application-level session tracking directly within the runtime to accurately measure the committed concurrent workload of active conversations. By feeding these precise session counts alongside standard CPU utilization metrics into a hybrid routing algorithm, infrastructure can effectively distribute stateful AI traffic and prevent individual backend bottlenecks. ## A Bootiful Podcast: Netflix's Paul Bakker DevFeed: [A Bootiful Podcast: Netflix's Paul Bakker]() Original publisher: [Read original article]() Author: joshlong Published: 2026-09-10T00:00:00Z Content type: article Language: en Sources: [Spring]() Topics: [Concurrency](), [Concurrent Programming](), [Tooling]() Tags: [ai](), [batch](), [boot](), [cloud](), [complexity](), [concurrency](), [event-driven](), [java](), [microservices](), [netflix](), [podcast](), [reactive](), [serverless](), [spring](), [tooling](), [web-applications]() ### AI overview A podcast interview with Netflix's Paul Bakker on scaling Java, adopting newer JDKs to reduce costs, and using virtual threads and structured concurrency instead of reactive complexity. It also previews AI-powered tooling and Project Valhalla's future. ### Source excerpt Hi, Spring fans! This week's interview is a must-watch if you care about where Java is headed next. This week, I talk to Netflix's Paull Bakker! We dig into Netflix's real-world playbook for scaling Java, cutting costs with newer JDKs, and replacing reactive complexity with virtual threads and structured concurrency. Plus, there's a sneak peek at the exciting future of Java, from AI-powered tooling to the upcoming Valhalla era. ## A quick overview of atomics in C DevFeed: [A quick overview of atomics in C]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-09-09T20:41:53Z Content type: tutorial Language: en Sources: [Daniel Lemire]() Topics: [C](), [Concurrency](), [Concurrent Programming](), [Programming]() Tags: [atomics](), [c](), [join](), [ordering](), [posix](), [programming-language](), [systems](), [thread](), [threads]() ### AI overview This tutorial introduces atomics in C, explaining data races on shared non-atomic variables, atomic accesses, instruction reordering, and memory-ordering models including relaxed, release, and acquire semantics. It also discusses C11 threads and platform support limitations. ### Source excerpt If you write in C, by default, you use a single thread. Extra cores do not help until you create more threads. However, if you include the header , you can pass a function to thrd_create, and wait for it with thrd_join. #include #include int worker(void *arg) { printf("hello from thread %d\n", *(int ... Continue reading A quick overview of atomics in C ## Redesigning Kubernetes Workqueues and Resyncs to Reduce Thundering Herd Effects DevFeed: [Redesigning Kubernetes Workqueues and Resyncs to Reduce Thundering Herd Effects]() Original publisher: [Read original article]() Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Kubernetes](), [systems](), [Concurrent Programming](), [Latency](), [Maintainers]() Tags: [architecture](), [concurrent](), [defense-in-depth](), [failover](), [goroutines](), [kubernetes](), [latency](), [maintainers](), [reconciliation](), [thundering-herd]() ### AI overview This article explains how Kubernetes controllers can experience thundering herd effects when restarts, leader failovers, or periodic resyncs cause many keys to enter an in-memory workqueue at once. It describes the queue and informer behavior behind the problem and introduces Chainguard's redesign of workqueues and resyncs to improve reconciliation under these conditions. ### Source excerpt The thundering herd is an architecture problem. See how Chainguard redesigned workqueues and resyncs to keep reconciliation running smoothly. ## Async Programming in Python: From Generators to asyncio DevFeed: [Async Programming in Python: From Generators to asyncio]() Original publisher: [Read original article]() Author: Doug Farrell Published: 2026-08-31T14:00:00Z Content type: tutorial Language: en Sources: [Real Python]() Topics: [Python](), [Programming](), [Concurrent Programming](), [IO](), [Code](), [Python 3.14]() Tags: [automation](), [batch](), [code](), [learning](), [programming](), [python](), [tutorial]() ### AI overview A tutorial on Python asynchronous programming, explaining how event loops, coroutines, async and await enable a single-threaded program to handle slow I/O without blocking. It progresses from synchronous code and generators to concurrent task execution with asyncio, using examples compatible with Python 3.11 and later. ### Source excerpt Learn how Python async programming works. Write async functions with async and await, and run slow I/O operations concurrently with asyncio. ## Concurrent Servers: Part 8 - Go DevFeed: [Concurrent Servers: Part 8 - Go]() Original publisher: [Read original article]() Author: Eli Bendersky Published: 2026-08-22T14:52:00Z Content type: tutorial Language: en Sources: [Eli Bendersky]() Topics: [Go Language](), [Concurrency](), [Server](), [Concurrent Programming](), [Network]() Tags: [capacity](), [concurrency](), [concurrent](), [go](), [goroutines](), [misc](), [network-programming](), [servers](), [threads]() ### AI overview Part 8 of a series on concurrent network servers explains how Go implements sequential and concurrent servers. It demonstrates serving each client with a lightweight goroutine and discusses why concurrency may still need to be limited, including when tasks compete for finite CPU capacity. ### Source excerpt This is part 8 in a series of posts on writing concurrent network servers. In this part, we'll switch to Go and see how it tackles the challenges described earlier in the series. All posts in the series: Part 1 - Introduction Part 2 - Threads Part 3 - Event-driven Part 4 - libuv ... ## Tips for Saving Game Data in Godot DevFeed: [Tips for Saving Game Data in Godot]() Original publisher: [Read original article]() Published: 2026-08-21T00:00:00Z Content type: tutorial Language: en Sources: [Robin Ward]() Topics: [Godot](), [saving](), [Concurrent Programming](), [data](), [JSON](), [Hardware](), [Testing]() Tags: [bug](), [code](), [disk-space](), [game](), [games](), [json](), [mutex](), [os](), [saving](), [testing](), [thread](), [tips]() ### AI overview This tutorial describes a save-data approach for Godot games, based on experience shipping two games. It compares custom binary and JSON formats, recommends frequent debounced saves on a separate thread, checks available disk space, and discusses temporary-file replacement to reduce corrupted save-game reports. ### Source excerpt Saving game data is easy. Making your save code survive every kind of hardware failure is not. A lot of these issues will never show up during testing, but if your game reaches a wide audience with many different kinds of hard drives in different states of degradation, you will start to get bug reports about save games not working. I decided to write up my approach, learned over the course of shipping two Godot games, that has reduced our corrupted save game bug reports to virtually nothing. ## Concurrent Servers: Part 7 - Rust DevFeed: [Concurrent Servers: Part 7 - Rust]() Original publisher: [Read original article]() Author: Eli Bendersky Published: 2026-08-15T16:41:00Z Content type: tutorial Language: en Sources: [Eli Bendersky]() Topics: [Rust](), [Concurrent Programming](), [Network](), [Server](), [Programming]() Tags: [concurrency](), [concurrent](), [misc](), [network](), [network-programming](), [programming](), [programming-language](), [rust](), [servers](), [threads]() ### AI overview Part 7 of a series on concurrent network servers explains how to implement the series' state-machine protocol in Rust. It covers a sequential server, one thread per client, and a fixed thread pool. ### Source excerpt This is part 7 in a series of posts on writing concurrent network servers. In this part, we discuss how the challenges described in earlier parts are tackled in the Rust programming language. All posts in the series: Part 1 - Introduction Part 2 - Threads Part 3 - Event-driven Part 4 - libuv ... ## Sendable and @Sendable closures explained with code examples DevFeed: [Sendable and @Sendable closures explained with code examples]() Original publisher: [Read original article]() Author: Antoine van der Lee Published: 2026-08-09T11:53:15Z Content type: article Language: en Sources: [SwiftLee]() Topics: [Swift](), [Concurrency](), [Concurrent Programming](), [Code](), [async/await]() Tags: [code](), [concurrency](), [examples](), [swift]() ### AI overview This article explains Swift's Sendable protocol and the @Sendable closure attribute. It describes how the compiler checks whether values can safely cross concurrency domains such as actors, tasks, and threads, including examples involving value types, classes, generics, and enums with associated values. ### Source excerpt Sendable is a protocol in Swift that indicates a type is safe to share across concurrency domains like actors, tasks, and threads. When a type conforms to Sendable, the compiler verifies at compile time that passing it around can't introduce data races. Together with the @Sendable attribute for closures, it's one of the core building ... -> The post Sendable and @Sendable closures explained with code examples appeared first on SwiftLee. ## The Real Python Podcast - Episode #303: Free-Threaded Python's History & uv in Production DevFeed: [The Real Python Podcast - Episode #303: Free-Threaded Python's History & uv in Production]() Original publisher: [Read original article]() Author: Real Python Published: 2026-07-17T12:00:00Z Content type: article Language: en Sources: [Real Python]() Topics: [Python](), [Concurrent Programming](), [Concurrency](), [Wagtail](), [Django](), [Compiler](), [GitHub Copilot CLI](), [Model Context Protocol]() Tags: [article](), [cli](), [github-copilot](), [github-copilot-cli](), [locks](), [mcp](), [podcast](), [production](), [python](), [techniques]() ### AI overview This podcast episode discusses the history of attempts to remove Python's Global Interpreter Lock, the current free-threaded Python approach, and the challenges of running multiple tasks concurrently within one process. It also covers Python community news and projects, including JIT compiler work, GitHub Copilot CLI, MCP server testing, uv in production, Wagtail with Django, Python code quality, and thread-safety techniques. ### Source excerpt How many attempts have been made to remove Python's Global Interpreter Lock (GIL)? How do they compare to the current approach? Christopher Trudeau is back on the show this week with another batch of PyCoder's Weekly articles and projects. ## Crystal 1.21.0 is released! DevFeed: [Crystal 1.21.0 is released!]() Original publisher: [Read original article]() Author: Johannes Müller Published: 2026-07-16T00:00:00Z Content type: release Language: en Sources: [Crystal]() Topics: [Crystal](), [releases](), [Concurrency](), [Concurrent Programming]() Tags: [bug-fixes](), [changelog](), [new-features](), [release]() ### AI overview Crystal 1.21.0 introduces execution contexts enabled by default, string array literals with interpolation, split manpages infrastructure, and other language, compiler, and standard-library changes. The release includes bug fixes and 161 changes from 21 contributors. ### Source excerpt We are announcing a new Crystal release 1.21.0 with several new features and bug fixes. ## Test & Set DevFeed: [Test & Set]() Original publisher: [Read original article]() Author: Jesse Wilson Published: 2026-07-13T22:22:27Z Content type: tutorial Language: en Sources: [Public Object]() Topics: [Concurrency](), [Concurrent Programming](), [Code](), [function](), [business logic]() Tags: [business-logic](), [code](), [concurrency](), [flaky-tests](), [function](), [programming](), [tests](), [threads]() ### AI overview An article about managing concurrency in threaded programs. It discusses the limits of simple and stress tests, describes a trusted concurrency pattern, and presents a helper function that separates business logic from concurrency logic while retrying after a lost race. ### Source excerpt Working with threads always feels hazardous to me. Non-determinism limits how much we can exercise with simple tests. Stress tests can shake out some bugs, but they're slow and potentially flaky. I don't like flaky tests. So I have a few concurrency patterns that I trust, and I ## Releasing Execution Contexts DevFeed: [Releasing Execution Contexts]() Original publisher: [Read original article]() Author: Julien Portalier Published: 2026-07-12T00:00:00Z Content type: release Language: en Sources: [Crystal]() Topics: [Crystal](), [Concurrency](), [Concurrent Programming](), [context](), [cpu]() Tags: [concurrent](), [cpu](), [kotlin](), [main-thread](), [multithreading](), [parallelism](), [threads]() ### AI overview Crystal is introducing Execution Contexts, an interface for orchestrating fibers across one or more threads. The article describes concurrent and parallel contexts, configurable parallelism, and execution across CPU cores while preserving a single-threaded default. ### Source excerpt Two and a half years ago, with the invaluable support from 84codes, we re-examined the multithreading model inherited from Crystal 0.28 (preview MT). ## Deadlocks and downtime DevFeed: [Deadlocks and downtime]() Original publisher: [Read original article]() Author: Simeon Griggs Published: 2026-07-08T00:00:00Z Content type: tutorial Language: en Sources: [Blog -- PlanetScale]() Topics: [Database](), [Deadlock](), [Transactions](), [Concurrency](), [Concurrent Programming]() Tags: [database](), [deadlock](), [engineering](), [errors](), [how-to](), [learn](), [postgres](), [reduce](), [transactions]() ### AI overview This article explains how Postgres deadlocks arise when concurrent transactions hold locks that each other needs, and how those deadlocks can escalate into database downtime. It examines the effects of high query volume and immediate retry loops, then recommends consistent row-update ordering, smaller transactions, and late locking to reduce the risk. ### Source excerpt Deadlocks happen when transactions block each other. Learn how they escalate into downtime, how to reduce them through better queries and retry logic, and how Traffic Control can protect your database from your application. ## How we scale PgBouncer in ClickHouse Managed Postgres DevFeed: [How we scale PgBouncer in ClickHouse Managed Postgres]() Original publisher: [Read original article]() Author: Kaushik Iska Published: 2026-07-01T15:40:41Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Processes](), [Process](), [cpu](), [Amazon EC2](), [Concurrent Programming](), [benchmarking](), [Server]() Tags: [aws](), [benchmarks](), [clickhouse](), [cpu](), [hardware](), [process](), [processes](), [server](), [transactions]() ### AI overview ClickHouse Managed Postgres scales PgBouncer connection pooling by running a peered fleet of processes across available CPU cores. Benchmarks on identical AWS EC2 setups show the 16-process fleet reaching roughly 336,000 transactions per second, about four times the single-process result. ### Source excerpt PgBouncer is single-threaded, so a single process caps out at one CPU core no matter the box size. See how ClickHouse Managed Postgres runs a peered fleet of PgBouncer processes with so_reuseport to scale pooling across every core -- with benchmarks showin ## Logic for Programmers extra credits DevFeed: [Logic for Programmers extra credits]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-06-02T14:48:48Z Content type: article Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Math and Logic](), [Concurrent Programming]() Tags: [book](), [concurrent](), [math](), [writing]() ### AI overview The author announces four supplementary pieces for Logic for Programmers covering concurrent-process orderings, first-order logic and sets of functions, Liskov's history rule in subtyping, and orders on sets. The supplements contain roughly 2,000-3,000 words of math content and may be less polished than the book. ### Source excerpt So I said there wasn't a proper newsletter this week, since I'm in Budapest prepping for a conference. But I still got a thing for y'all. There's a lot of interesting topics I wanted to cover for Logic for Programmers, but the book is dense enough as it is and many of these were too tangential or technical to fit in well. So I've been writing some supplements and uploading them here. I've got four so far: How we compute the number of orderings of multiple concurrent processes How first-order logic can quantify over "a set of functions", what a "set of functions" looks like, and how functions can be defined in terms of sets (plus a bit on currying and type theory) Barbara Liskov's "history rule" in subtyping Total and partial orders on sets. Now I'm going to caveat that these were written off the cuff and haven't gone through the obsessive editing of the book itself, so they may be rough and there might be errors in them. Still, it's like 2-3000 words of math content, so hopefully covers not having a proper newsletter this time. Seeya next week! ## Diagnosing a Deadlock in Trino's Hudi Connector That Stalled Blinkit's Inventory Pipeline DevFeed: [Diagnosing a Deadlock in Trino's Hudi Connector That Stalled Blinkit's Inventory Pipeline]() Original publisher: [Read original article]() Author: Ratul Dawar Published: 2026-05-29T09:26:27Z Content type: article Language: en Sources: [Grofers]() Topics: [Deadlock](), [Concurrent Programming](), [Amazon S3]() Tags: [apache-hudi](), [big-data](), [blinkit](), [bug](), [deadlock](), [open-source](), [s3](), [thread](), [trino](), [trinos](), [yield]() ### AI overview Blinkit describes how a deadlock in Trino's Hudi connector stalled inventory replenishment queries without errors or resource saturation. The issue involved one thread pool handling both file-split production and signalling; the reported fix used cooperative scheduling and was contributed upstream. ### Source excerpt A silent deadlock in our query engine was stalling inventory replenishment jobs with no error, no crash -- just infinite waiting. This is the story of how we found it, traced it to an open-source bug, and fixed it upstream. TL;DRTrino's Hudi connector used a single thread pool for both producing file splits and signalling when there was room for more. Under load, every thread ended up waiting for a signal that had no thread left to run it. The fix was to switch the producer side to a cooperative scheduling pattern: yield the thread when the buffer is full, and resume when space opens. Our inventory replenishment pipeline was frozen. CPU was idle. Memory was fine. There were no errors anywhere. Queries just... stopped moving. The first signal was a long queue on one of our analytics clusters. Queries were piling up. Inventory replenishment jobs -- the jobs that decide how much stock every warehouse and store needs to hold -- were delayed. Blinkit's supply chain was being impacted. Dashboards were turning amber, but nothing was crashing. That was the unsettling part. Investigation: Resources Doing Nothing The affected cluster runs analytical workloads on Trino, reading data stored in Apache Hudi tables on S3. The natural first instinct in a queue build-up is to look at resource saturation -- a CPU spike, memory pressure, network bottleneck. There was none of that. The cluster was sitting largely idle, with CPU barely above baseline and heap usage well within limits. Every new query touching a Hudi table joined the queue and stayed there indefinitely. Queries that were already mid-execution completed fine. Only freshly submitted ones were affected. And crucially, there were no errors. No timeouts, no exceptions in the logs -- just silence and a growing backlog. A thread dump -- a snapshot of what every thread in the process is doing right now -- was our next move. It showed dozens of producer threads all stuck in the same parked state, waiting on the exact same internal signal. ## Concurrent, atomic MSI hash tables DevFeed: [Concurrent, atomic MSI hash tables]() Original publisher: [Read original article]() Published: 2026-05-06T02:01:17Z Content type: tutorial Language: en Sources: [Chris Wellons]() Topics: [Concurrency](), [Concurrent Programming](), [Code](), [gcc](), [Processes]() Tags: [article](), [c](), [code](), [concurrency](), [concurrent](), [gcc](), [processes](), [thread]() ### AI overview This article explains how to add atomic operations to Mask-Step-Index (MSI) hash tables so they can be accessed concurrently without data races. It covers single-producer and multiple-consumer designs, relaxed atomics, and acquire-release synchronization when published objects must be safely observed. ### Source excerpt Readers will be familiar with Mask-Step-Index (MSI) hash tables, a technique for building fast, open-addressed hash tables in a dozen lines of code. If multiple threads or processes access an MSI table with at least one still inserting elements, care must be taken to avoid data races. This article will show how to add atomic operations to MSI tables in order to support different concurrency constraints. Let's begin with the simplest case: An integer hash set, no deletions, only one insert thread (single producer), and consumers do not care about insert order. That is, the producer inserts A then B, but consumers may observe B in the table before A. Suppose this is the hash table in the single-threaded case: int32_t *lookup(int32_t key, int32_t *table, int exp) { uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32; uint32_t mask = ((uint32_t)1 << exp) - 1; uint32_t step = (hash >> (32 - exp)) | 1; for (uint32_t index = hash;;) { index = (index + step) & mask; if (!table[index] || table[index]==key) { return table + index; } } } Keys must be non-zero, and tables are zero-initialized. Usage example: // Initialization enum { exp = 8 }; int32_t table[1<<8] = {}; // Producer for (int i = 0; i < nkeys; i++) { *lookup(keys[i], table, exp) = keys[i]; } // Consumer int32_t key = 1234; bool present = *lookup(key, table, exp); The only problem is the data race on table slots. Since consumers can tolerate out-of-order insertions, ordering does not matter and relaxed atomics eliminate the data race. Insert and query now have different requirements, so it makes sense to distinguish them. Starting with the latter: bool contains(int32_t key, int32_t *table, int exp) { uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32; uint32_t mask = ((uint32_t)1 << exp) - 1; uint32_t step = (hash >> (32 - exp)) | 1; for (uint32_t index = hash;;) { index = (index + step) & mask; int32_t k = __atomic_load_n(table+index, __ATOMIC_RELAXED); if (!k) { return false; } else if (k == ke ## Safe Optimistic Lock Coupling DevFeed: [Safe Optimistic Lock Coupling]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2026-04-29T10:22:56Z Content type: article Language: en Sources: [Database Architects]() Topics: [Concurrency](), [Concurrent Programming](), [Data structures](), [Scalability](), [race-condition]() Tags: [concurrent](), [cpu](), [data-structures](), [locking](), [locks](), [mutex](), [performance](), [race-condition](), [scalability](), [synchronization](), [thread](), [typesafety]() ### AI overview The article explains how lock coupling can limit the scalability of concurrent binary-tree lookups because readers contend on locks, especially at the root. It presents Optimistic Lock Coupling, in which readers validate version numbers without writes, and discusses the race-condition risk when values are used before validation. ### Source excerpt As the number of CPU cores keeps growing, the scalability of concurrent data structures becomes increasingly important. A data structure that works fine on 4 cores can become a bottleneck on 32, not because of algorithmic limitations, but because of how it synchronizes access. We illustrate that with a simple binary tree. Usually these data structures are protected by some kind of lock: struct Node { mutex lock; key_type key; value_type value; Node* left, *right; }; struct Tree { mutex lock; Node* root; }; When searching a value, we can traverse the data structure, lock the parts of the data we are currently touching, and release locks when we are done ("lock coupling"): option Tree::lookup(key_type key) { lock.lock_shared(); mutex* currentLock = &lock; Node* iter = root; option result; while (iter) { if (key == iter->key) { result = iter->value; break; } Node* next = (key < iter->key) ? iter->left : iter->right; if (next) next->lock.lock_shared(); currentLock->unlock(); currentLock = next ? &next->lock : nullptr; iter = next; } currentLock->unlock(); return result; } While conceptually simple, lock coupling has quite poor performance in practice. The problem is that it creates contention on the locks, in particular for the root node. Every lookup goes through the root node, thus the root node is constantly locked and unlocked. While there is no semantic contention between lookups, as all readers can read the root concurrently, there is physical contention on the lock itself, which limits scalability. This can be seen below, with concurrent lookups in a tree of 100,000 elements, executed on a 16-core / 32-thread 9950X3D. Lookup scalability: no locking vs lock coupling This contention problem can be solved by using Optimistic Lock Coupling, a synchronization technique where readers do not perform any writes. The key idea here is that writers lock as usual, and increase a version number when they are done updating. Readers read the version numb ## How CockroachDB v26.1 Uses Elastic Admission Control and Go Scheduler Changes for Background Work DevFeed: [How CockroachDB v26.1 Uses Elastic Admission Control and Go Scheduler Changes for Background Work]() Original publisher: [Read original article]() Author: David Taylor Published: 2026-04-14T00:00:00Z Content type: article Language: en Sources: [Cockroach Labs]() Topics: [CockroachDB](), [Go Language](), [Concurrent Programming](), [Latency](), [cpu]() Tags: [background-work](), [backups](), [cockroachdb](), [elastic](), [latency](), [processes](), [statistics](), [work]() ### AI overview This article explains how CockroachDB v26.1 uses elastic admission control and a change to the Go runtime scheduler to let background work use spare CPU capacity while limiting its impact on query latency. ### Source excerpt CockroachDB runs background work -- backups, schema changes, statistics collection, changefeeds -- in the same processes that serve user queries. Traditionally, this creates a tension... ## From error-handling to structured concurrency DevFeed: [From error-handling to structured concurrency]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2026-03-23T15:30:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Concurrency](), [Concurrent Programming](), [Error Handling](), [Exception]() Tags: [concurrency](), [error-handling](), [examples](), [exception](), [exception-handling](), [structured-concurrency]() ### AI overview This article examines how error-handling patterns based on stack unwinding and cleanup should be adapted for concurrent programs with multiple tasks. It introduces the problem of unhandled errors in concurrent execution and compares possible behaviors when one task fails. ### Source excerpt How should we think about error-handling in concurrent programs? In single-threaded programs, we've mostly converged on a standard pattern, with a diverse zoo of implementations and concrete patterns. When an error occurs, it is propagated up the stack until we find a stack frame which is prepared to handle it. As we do so, we unwind the stack frames in-order, giving each frame the opportunity to clean up or destroy resources as appropriate. [Next page]()