https://github.com/awslabs/shuttle

Shuttle is a library for testing concurrent Rust code

https://github.com/awslabs/shuttle

Science Score: 36.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
    Found .zenodo.json file
  • DOI references
  • Academic publication links
  • Committers with academic emails
    2 of 13 committers (15.4%) from academic institutions
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (8.9%) to scientific vocabulary
Last synced: 10 months ago · JSON representation

Repository

Shuttle is a library for testing concurrent Rust code

Basic Info
  • Host: GitHub
  • Owner: awslabs
  • License: apache-2.0
  • Language: Rust
  • Default Branch: main
  • Homepage:
  • Size: 627 KB
Statistics
  • Stars: 857
  • Watchers: 18
  • Forks: 44
  • Open Issues: 36
  • Releases: 18
Created over 5 years ago · Last pushed 10 months ago
Metadata Files
Readme Changelog Contributing License Code of conduct Notice

README.md

Shuttle

crates.io docs.rs Tests

Shuttle is a library for testing concurrent Rust code. It is an implementation of a number of randomized concurrency testing techniques, including A Randomized Scheduler with Probabilistic Guarantees of Finding Bugs.

Getting started

Consider this simple piece of concurrent code:

```rust use std::sync::{Arc, Mutex}; use std::thread;

let lock = Arc::new(Mutex::new(0u64)); let lock2 = lock.clone();

thread::spawn(move || { *lock.lock().unwrap() = 1; });

assert_eq!(0, *lock2.lock().unwrap()); ```

There is an obvious race condition here: if the spawned thread runs before the assertion, the assertion will fail. But writing a unit test that finds this execution is tricky. We could run the test many times and try to "get lucky" by finding a failing execution, but that's not a very reliable testing approach. Even if the test does fail, it will be difficult to debug: we won't be able to easily catch the failure in a debugger, and every time we make a change, we will need to run the test many times to decide whether we fixed the issue.

Randomly testing concurrent code with Shuttle

Shuttle avoids this issue by controlling the scheduling of each thread in the program, and scheduling those threads randomly. By controlling the scheduling, Shuttle allows us to reproduce failing tests deterministically. By using random scheduling, with appropriate heuristics, Shuttle can still catch most (non-adversarial) concurrency bugs even though it is not an exhaustive checker.

A Shuttle version of the above test just wraps the test body in a call to Shuttle's check_random function, and replaces the concurrency-related imports from std with imports from shuttle:

```rust use shuttle::sync::{Arc, Mutex}; use shuttle::thread;

shuttle::check_random(|| { let lock = Arc::new(Mutex::new(0u64)); let lock2 = lock.clone();

thread::spawn(move || {
    *lock.lock().unwrap() = 1;
});

assert_eq!(0, *lock2.lock().unwrap());

}, 100); ```

This test detects the assertion failure with extremely high probability (over 99.9999%).

Shuttle is inspired by the Loom library for testing concurrent Rust code. Shuttle focuses on randomized testing, rather than the exhaustive testing that Loom offers. This is a soundness—scalability trade-off: Shuttle is not sound (a passing Shuttle test does not prove the code is correct), but it scales to much larger test cases than Loom. Empirically, randomized testing is successful at finding most concurrency bugs, which tend not to be adversarial.

License

This project is licensed under the Apache-2.0 License.

Security

See CONTRIBUTING for more information.

Owner

  • Name: Amazon Web Services - Labs
  • Login: awslabs
  • Kind: organization
  • Location: Seattle, WA

AWS Labs

GitHub Events

Total
  • Create event: 22
  • Release event: 1
  • Issues event: 9
  • Watch event: 144
  • Delete event: 15
  • Issue comment event: 26
  • Push event: 61
  • Pull request review comment event: 112
  • Pull request review event: 113
  • Pull request event: 49
  • Fork event: 7
Last Year
  • Create event: 22
  • Release event: 1
  • Issues event: 9
  • Watch event: 144
  • Delete event: 15
  • Issue comment event: 26
  • Push event: 61
  • Pull request review comment event: 112
  • Pull request review event: 113
  • Pull request event: 49
  • Fork event: 7

Committers

Last synced: about 3 years ago

All Time
  • Total Commits: 136
  • Total Committers: 13
  • Avg Commits per committer: 10.462
  • Development Distribution Score (DDS): 0.412
Past Year
  • Commits: 27
  • Committers: 8
  • Avg Commits per committer: 3.375
  • Development Distribution Score (DDS): 0.556
Top Committers
Name Email Commits
James Bornholt b****t@a****m 80
James Bornholt b****t@c****u 16
Rajeev Joshi j****v@a****m 13
Bernhard Kragl k****b@a****m 8
Rajeev Joshi 4****v@u****m 5
Alex Koshelev k****v@m****m 3
James Bornholt b****t@c****u 3
Jacob Van Geffen j****g@a****m 2
Sarek Høverstad Skotåm 4****o@u****m 2
Luke Nelson l****s@g****m 1
Luke Nelson l****s@l****t 1
Rajeev Joshi {****}@u****m 1
Van Geffen j****g@8****m 1
Committer Domains (Top 20 + Academic)

Issues and Pull Requests

Last synced: 10 months ago

All Time
  • Total issues: 29
  • Total pull requests: 215
  • Average time to close issues: 6 months
  • Average time to close pull requests: 10 days
  • Total issue authors: 13
  • Total pull request authors: 16
  • Average comments per issue: 0.76
  • Average comments per pull request: 0.53
  • Merged pull requests: 171
  • Bot issues: 0
  • Bot pull requests: 1
Past Year
  • Issues: 6
  • Pull requests: 63
  • Average time to close issues: about 3 hours
  • Average time to close pull requests: 4 days
  • Issue authors: 4
  • Pull request authors: 9
  • Average comments per issue: 0.0
  • Average comments per pull request: 0.63
  • Merged pull requests: 32
  • Bot issues: 0
  • Bot pull requests: 1
Top Authors
Issue Authors
  • jamesbornholt (6)
  • sarsko (5)
  • bkragl (4)
  • anacrolix (2)
  • chc4 (2)
  • MichaReiser (2)
  • XiangpengHao (2)
  • rluvaton (1)
  • dylanjwolff (1)
  • kvark (1)
  • cameronelliott (1)
  • v4ray (1)
  • 2M1 (1)
Pull Request Authors
  • sarsko (76)
  • jamesbornholt (65)
  • bkragl (18)
  • dylanjwolff (12)
  • Aurel300 (12)
  • jorajeev (11)
  • JacobVanGeffen (4)
  • akoshelev (4)
  • funemy (2)
  • progwriter (2)
  • nrebei2 (2)
  • lukenels (2)
  • arthurprs (2)
  • FinnitoProductions (1)
  • dependabot[bot] (1)
Top Labels
Issue Labels
bug (1)
Pull Request Labels
dependencies (1)

Packages

  • Total packages: 1
  • Total downloads:
    • cargo 2,053,887 total
  • Total docker downloads: 7
  • Total dependent packages: 9
  • Total dependent repositories: 4
  • Total versions: 20
  • Total maintainers: 2
crates.io: shuttle

A library for testing concurrent Rust code

  • Versions: 20
  • Dependent Packages: 9
  • Dependent Repositories: 4
  • Downloads: 2,053,887 Total
  • Docker Downloads: 7
Rankings
Docker downloads count: 6.0%
Dependent packages count: 6.3%
Downloads: 6.4%
Average: 8.0%
Stargazers count: 8.0%
Forks count: 10.5%
Dependent repos count: 10.8%
Maintainers (2)
Last synced: 10 months ago

Dependencies

Cargo.toml cargo
  • ansi_term 0.12.1
  • bitvec 0.21.0
  • generator 0.7.0
  • hex 0.4.2
  • rand 0.7.3
  • rand_core 0.5.1
  • rand_pcg 0.2.1
  • scoped-tls 1.0.0
  • smallvec 1.6.1
  • tracing 0.1.21
  • varmint 0.1.3
.github/workflows/audit.yml actions
  • actions/checkout v2 composite
.github/workflows/tests.yml actions
  • actions/checkout v2 composite