Concurrency
BlitzQueue — lock-free MPMC message queue
A bounded multi-producer/multi-consumer queue in C++17 that sustains 2M+ messages/sec, benchmarked against a mutex baseline.
Role
Sole engineer
When
2026
Outcome
2M+ messages/sec
Stack
- Problem
- A mutex-guarded queue serialises every producer and consumer through one lock. Under contention that lock, not the work, becomes the throughput ceiling.
- Move
- Built a bounded ring buffer coordinated purely by atomics and per-slot sequence counters, with explicit memory ordering at each step and cache-line padding to keep hot indices off the same line.
- Result
- 2M+ messages/sec sustained, measured against a mutex implementation under Google Test, and exposed as a broker over gRPC and Boost.Asio with backpressure.
$ empty ring · head == tail · nothing to consume
- empty slot
- published
- head (producer)
- tail (consumer)
CONTEXT
Lock-free queues are easy to get subtly wrong. A per-slot sequence counter tells producers and consumers whether a slot is ready for them without a shared lock, but only if every load and store carries the right memory ordering — too weak and you read torn state, too strong and you have thrown away the reason for doing this at all.
The other half of the problem is layout. Producer and consumer indices that share a cache line will ping-pong that line between cores on every operation, and the resulting false sharing can erase the gains from going lock-free in the first place.
WHAT I DID
- Implemented a bounded ring buffer with per-slot sequence counters, using atomics and explicit acquire/release ordering rather than a shared lock.
- Padded hot indices to cache-line boundaries to eliminate false sharing between producers and consumers.
- Exposed the queue as a network broker over gRPC and Boost.Asio, with backpressure so producers slow down instead of overrunning the buffer.
- Benchmarked against a mutex-guarded baseline under Google Test to keep the comparison honest and repeatable.
RESULT
Sustained 2M+ messages/sec, with the mutex baseline measured in the same harness so the speedup is attributable to the queue design rather than the benchmark setup.