Worker pools, channels, and mutexes - backed by pthreads.

Anton Z's resource offers insights, tutorials, and resources for software developers and technology enthusiasts. Readers can learn about coding best practices, software architecture patterns, and emerging technologies. With articles, tutorials, and code samples, Anton Z provides  guidance and expertise for building software applications and advancing technical skills.

Anton Zhiyanov

A deep dive into implementing Go-style concurrency primitives in C using POSIX threads, as part of the Solod project — a Go-to-C transpiler. Covers mutex/cond wrappers, atomics, worker pools, and buffered/unbuffered channels, with detailed benchmark comparisons against Go. Key finding: pthread-based concurrency matches Go within ~10% for coarse-grained pooled workloads, but is 7-23x slower for fine-grained blocking operations due to kernel wakeup costs vs. Go's userspace scheduler. Design decisions include choosing pthreads over fiber libraries for simplicity, keeping concurrency in the stdlib rather than the language, and using timeouts instead of implementing select.

Go-flavored concurrency in C

The 7-23x gap on fine-grained ops is exactly the M:N-vs-1:1 threading tax. A blocked goroutine parks in userspace in a few ns, but a contended pthread cond_wait falls into a futex plus a kernel scheduler wakeup — microseconds, and it gets worse with core count as the run-queue lock heats up. The gap mostly closes if you batch work so channel ops amortize across a larger unit, which is why the pooled-coarse case lands within 10%. Skipping select was the right call too: a faithful select needs to register a goroutine on N wait queues at once, which pthreads can’t express without a userspace runtime.

This is a great reminder that Go’s concurrency model isn’t just syntax; the scheduler is a huge part of the story. For coarse work pthreads being close is impressive, but those fine-grained wakeup costs are the real lesson.

Vert nice post, thanks for sharing