Concurrency Programming (10): How BlockingQueue and Channels Work — From Runtime to CPU

The article compares the implementations of BlockingQueue, channels, and queue.Queue in Java, Go, and CPython. These data structures provide guarantees around Atomicity, Visibility, and Ordering across different layers of the runtime, standard libraries, and hardware.

At the language/library layer:

In Java, the ArrayBlockingQueue uses a lock (ReentrantLock) for atomicity, ensuring one enqueue or dequeue operation updates the queue state without interference from other threads. Visibility and ordering are maintained through the lock, making the producer's writes visible to the consumer once the lock is acquired.

In Go, channels achieve atomicity by acquiring a lock (chanlock) before updating buffer state or finding a waiting peer. Visibility is ensured by the lock's order, with writes taking effect before reads. Ordering is provided through acquire/release semantics and memory ordering constraints on the x86-64 hardware.

At the hardware layer:

Atomicity is achieved through atomic instructions like LOCK CMPXCHG, which update shared data without interference. Visibility relies on cache coherence protocols (MESIF or MOESI) to ensure updates are propagated to all caches. Ordering is managed by acquire and release memory fences, ensuring the correct sequence of read-modify-write operations.

In summary, all three implementations rely on a combination of locks, atomic instructions, cache coherence, and memory ordering to provide consistent guarantees across the runtime, standard library code, and hardware. These primitives enable thread-safe communication and synchronization, even in the presence of concurrent access.