What does HackerNews think of loom?

Rust's tokio has a project called loom as well which can do permutation testing of async code: https://github.com/tokio-rs/loom

> Mutexes are very cheap in the uncontended case

It was a while ago I was deep into this mess so forgive any ignorance–but–iirc the thread-mutex dogma[1] has many pitfalls despite being so widely used. Primarily they’re easy to misuse (deadlocks, holding a lock across a suspend point), and have unpredictable performance because they span so far into compiler, OS and CPU territory (instruction reordering, cache line invalidation, mode switches etc). Also on Arm it’s unclear if mutices are as cheap because of the relaxed memory order(?). Finally code with mutices are hard to test exhaustively, and are prone to heisenbugs.

Now, many if not most of the above apply to anything with atomics, so lock-free/wait-free won’t help either. There’s a reason why a lot of concurrency is ~phd level on the theoretical side, as well as deeply coupled with the gritty realities of hardware/compilers/os on the engineering side.

That said, I still think there’s room for a slightly expanded concurrency toolbox for mortals. For instance, a well implemented concurrent queue can be a significant improvement for many workflows, perhaps even with native OS support (io_uring style)?. Another exciting example is concurrency permutation test frameworks[2] for atomics that reorder operations in order to synthetically trigger rare logical race conditions. I’ve also personally had great experience with the Golang race detector. I hope we see some convergence on some of this stuff within a few years. Concurrency is still incredibly hard to get right.

[1]: I say this only because CS degrees has preached mutices to as the silver bullet for decades.

[2]: https://github.com/tokio-rs/loom

There is Loom[1] (part of the Tokio project) for exhaustively testing multithreaded code. Though as far as I can tell it is designed for debugging threads, not async tasks.

[1] https://github.com/tokio-rs/loom

> In the case of threading, what you would need to do is essentially have a compiler/runtime that goes out of its way to order and time operation in a random/adversarial manner.

> others that modify the compiler itself to replace the concurrency primitives with runtime functions, that can then execute them in a fuzzed order.

Loom[1] is somewhat of that. It's a testing system (not a runtime for a full app) which tests multiple permutations of program execution (all possible permutations I think, limited by test case complexity or an optional "maximum thread switch count"), as well as modeling atomic/weak memory effects to some degree.

[1]: https://github.com/tokio-rs/loom

This is a good question. Yes, it's exactly the same kind of problem. There is potentially a difference between Rust's memory model and what's actually present on any given target host. x64 has a "strong" memory model which that ordering will always be implicitly acquire/release. Compare this to ARM which is "weak" where your relaxed ordering will actually be relaxed. (There's actually quite a bit more nuance, discussed well here[0].) It's important to write code that is correct with regard to Rust's memory model so that it's portable, but if you don't have a weakly ordered machine to test on it's tricky. Loom[1] is helpful in this regard. This is true of any language that allows you to write atomic code where you specify the ordering.

[0] https://preshing.com/20120930/weak-vs-strong-memory-models/ [1] https://github.com/tokio-rs/loom