loom
eioio
loom | eioio | |
---|---|---|
14 | 25 | |
1,896 | 517 | |
3.1% | 2.3% | |
6.8 | 9.0 | |
7 days ago | 7 days ago | |
Rust | OCaml | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
loom
- Turmoil, a framework for developing and testing distributed systems
-
An Introduction to Lockless Algorithms
> 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
-
Should atomics be unsafe?
Of course atomics are absolutely essential for some of the libraries we take for granted, such as Arc and Tokio. But if you start reading the code and comments and issues and PRs around code like that, you'll see how much work it took to mature them to the point we can now rely on them. That's why tools like Loom exist.
-
Best tool to find deadlocks (in async code)
loom and shuttle can help you narrow down the problem.
-
Does Rust not need extra linting and sanitizing tools like C++?
Unless you are writing unsafe code, you generally don't need to use sanitizers. If you do write unsafe code, checking it with a sanitizer would be a great idea. Two most useful tools here I think are miri and loom.
-
The Deadlock Empire
https://github.com/tokio-rs/loom perhaps? It also models weak memory reordering, but takes some work to integrate into existing apps.
For triggering race conditions in compiled binaries, you could try https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo....
-
What could Go wrong with a mutex? (A Go profiling story)
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
-
Cooptex - Deadlock-free Mutexes
That tool seems similar to https://github.com/tokio-rs/loom, insofar as detecting potential locking errors. These are useful during development, but could still miss production cases (as dev never perfectly matches production). This crate is meant to not have to worry about possibly deadlocking.
-
A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
Rust doesn't catch memory ordering errors, which can result in behavioral bugs in safe Rust and data races and memory unsafety in unsafe Rust. But Loom is an excellent tool for catching ordering errors, though its UnsafeCell API differs from std's (and worse yet, some people report Loom returns false positives/negatives in some cases: https://github.com/tokio-rs/loom/issues/180, possibly https://github.com/tokio-rs/loom/issues/166).
- Multicore OCaml: April 2021
eioio
-
Eio 1.0 Release: Introducing a new Effects-Based I/O Library for OCaml
the actual project (Readme has some code samples): https://github.com/ocaml-multicore/eio
-
OCaml: a Rust developer's first impressions
For 5.0+ you might want to look at https://github.com/ocaml-multicore/eio for how effects can make async much more pleasant
- Alternatives to scala FP
-
How Much Memory Do You Need to Run 1 Million Concurrent Tasks?
Great post! I would love to see this extended to OCaml 5 (with eio) and Haskell
- Eio -- Effects-Based Parallel IO for OCaml
-
OCaml 5.0.0: multicore support and effect handlers for OCaml
Second, effects enable a new style of concurrency libraries like eio that forgoes the need to wrap every asynchronous computation in a monad.
- OCaml 5.0 Multicore is out
-
What’s so great about functional programming anyway?
> This is realllly unidiomatic in real world Haskell.
Whether idiomatic or not does not matter. It proves my point:
IO won't save you, and even very mundane effects are not part of the game…
Idris is the "better Haskell" sure, but the effect tracking is still part of the uncanny valley (still IO monad based).
Koka is a toy, and Frank mostly "only a paper" (even there is some code out there).
The "Frank concept" is to some degree implemented in the Unison language, though:
https://www.unison-lang.org/learn/fundamentals/abilities/
Having a notion of co-effects (or however you please to call them) is imho actually much more important than talking about effects (as effects are in fact neither values nor types—something that all the IO kludges get wrong).
I think the first practicable approach in the mainstream about this topic will be what gets researched and developed for Scala. The main take away is that you need to look at things form the co-effects side first and foremost!
In case anybody is interested in what happens in Scala land in this regard:
https://www.slideshare.net/slideshow/embed_code/key/aLE9M37d...
https://docs.scala-lang.org/scala3/reference/experimental/cc...
But also the development in OCaml seems interesting:
https://github.com/ocaml-multicore/eio#design-note-capabilit...
Look mom, "effects", but without the monad headache!
-
Practical OCaml, Multicore Edition
To enable access to all these features, an exciting new library called Eio is being developed. It uses a new paradigm of direct-style concurrent I/O programming, without the need for monads or async/await, thus avoiding the function colour problem.
What are some alternatives?
console - a debugger for async rust!
ocaml-multicore - Multicore OCaml
roast - 🦋 Raku test suite
shuttle - Shuttle is a library for testing concurrent Rust code
domainslib - Parallel Programming over Domains
TLAPLUS_DeadlockEmpire - Specs and models for solving the DeadlockEmpire problems using TLA+ and TLC
rescript-compiler - The compiler for ReScript.
triple-buffer - Implementation of triple buffering in Rust
effects-examples - Examples to illustrate the use of algebraic effects in Multicore OCaml
Rudra - Rust Memory Safety & Undefined Behavior Detection
weave - A state-of-the-art multithreading runtime: message-passing based, fast, scalable, ultra-low overhead