tokio-rs/loom has 2,862 GitHub stars and 156 forks. GitHot measured +1 stars in 24 hours. Last checked 2026-11-08 18:44 UTC. Last push 2026-02-20.
Concurrency permutation testing tool for Rust.
What you can do
- SeqCst accesses (e.g. load, store, ..): They are regarded as AcqRel. That is, they impose weaker synchronization, causing Loom to generate false alarms (not complete). See #180 for example. On the other hand, fence(SeqCst) is supported.
- Load buffering behavior: Loom does not explore some executions that are possible in the C11 memory model. That is, there can be a bug in the checked code even if Loom says there is no bug (not sound). See the load_buffering test case in tests/litmus.rs.
Measured star growth
- in 24h
- +1
- in 7 days
- Update delayed
- in 15 days
- Update delayed
- in 1 month
- Update delayed
Net star changes over overlapping periods, not daily totals. Missing measurements are left blank. Stars measure attention, not software quality.
README.md
OriginalLoom
Loom is a testing tool for concurrent Rust code. It runs a test many times, permuting the possible concurrent executions of that test under the C11 memory model. It uses state reduction techniques to avoid combinatorial explosion.
Quickstart
The loom documentation has significantly more documentation on
how to use loom. But if you just want a jump-start, first add this to
your Cargo.toml.
[target.'cfg(loom)'.dependencies]
loom = "0.7"
Next, create a test file and add a test:
use loom::sync::Arc;
use loom::sync::atomic::AtomicUsize;
use loom::sync::atomic::Ordering::{Acquire, Release, Relaxed};
use loom::thread;
#[test]
#[should_panic]
fn buggy_concurrent_inc() {
loom::model(|| {
let num = Arc::new(AtomicUsize::new(0));
let ths: Vec<_> = (0..2)
.map(|_| {
let num = num.clone();
thread::spawn(move || {
let curr = num.load(Acquire);
num.store(curr + 1, Release);
})
})
.collect();
for th in ths {
th.join().unwrap();
}
assert_eq!(2, num.load(Relaxed));
});
}
Then, run the test with
RUSTFLAGS="--cfg loom" cargo test --test buggy_concurrent_inc --release
Unsupported features
Loom currently does not implement the full C11 memory model. Here is the (incomplete) list of unsupported features.
SeqCstaccesses (e.g.load,store, ..): They are regarded asAcqRel. That is, they impose weaker synchronization, causing Loom to generate false alarms (not complete). See #180 for example. On the other hand,fence(SeqCst)is supported.- Load buffering behavior:
Loom does not explore some executions that are possible in the C11 memory
model. That is, there can be a bug in the checked code even if Loom says
there is no bug (not sound). See the
load_bufferingtest case intests/litmus.rs.
License
This project is licensed under the MIT license.
Contribution
Unless you explicitly state otherwise, any contribution intentionally
submitted for inclusion in loom by you, shall be licensed as MIT,
without any additional terms or conditions.
Explore related projects
codecrafters-io/build-your-own-x
Master programming by recreating your favorite technologies from scratch.
561,232 starspublic-apis/public-apis
A collective list of free APIs
497,482 starsmorluto/rea
Reverse engineer anything with agents, from app behavior down to native binaries.
445,616 starsopenclaw/openclaw
The AI that really does things. Any OS. Any Platform. The lobster way. 🦞
394,229 stars