Async Mutexes

Summary

On Async Mutexes Nov 4, 2025 A short note on contradiction or confusion in my language design beliefs I noticed today. One of the touted benefits of concurrent programming multiplexed over a single thread is that mutexes become unnecessary. With only one function executing at any given moment in time data races are impossible. The standard counter to this argument is that mutual exclusion is a property of the logic itself, not of the runtime. If a certain snippet of code must be executed atomically with respect to everything else that is concurrent, then it must be annotated as such in the source code. You can still introduce logical races by accidentally adding an .await in the middle of the code that should be atomic. And, while programming, you are adding new .awaits all the time! This argument makes sense to me, as well its as logical conclusion. Given that you want to annotate atomic segments of code anyway, it makes sense to go all the way to Kotlin-style explicit async implicit await. The contradiction I realized today is that for the past few years I’ve been working on a system built around implicit exclusion provided by a single thread — TigerBeetle! Consider compaction, a code that is responsible for rewriting data on disk to make it smaller without changing its logical contents. During compaction, TigerBeetle schedules a lot of concurrent disk reads, disk writes, and CPU-side merges. Here’s an average callback: fn read_value_block_callback( grid_read: *Grid.Read, value_block: BlockPtrConst, ) void { const read: *ResourcePool.BlockRead = @fieldParentPtr("grid_read", grid_read); const compaction: *Compaction = read.parent(Compaction); const block = read.block; compaction.pool.?.reads.release(read); assert(block.stage == .read_value_block); stdx.copy_disjoint(.exact, u8, block.ptr, value_block); block.stage = .read_value_block_done; compaction.counters.in += Table.value_block_values_used(block.ptr).len; compaction.compaction_dispatch(); } This is the code (s...