1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176
//! Loom is a tool for testing concurrent programs.
//!
//! # Background
//!
//! Testing concurrent programs is challenging. The Rust memory model is relaxed
//! and permits a large number of possible behaviors. Loom provides a way to
//! deterministically explore the various possible execution permutations.
//!
//! Consider a simple example:
//!
//! ```ignore
//! use std::sync::Arc;
//! use std::sync::atomic::AtomicUsize;
//! use std::sync::atomic::Ordering::SeqCst;
//! use std::thread;
//!
//! #[test]
//! fn test_concurrent_logic() {
//! let v1 = Arc::new(AtomicUsize::new(0));
//! let v2 = v1.clone();
//!
//! thread::spawn(move || {
//! v1.store(1, SeqCst);
//! });
//!
//! assert_eq!(0, v2.load(SeqCst));
//! }
//! ```
//!
//! This program is obviously incorrect, yet the test can easily pass.
//!
//! The problem is compounded when Rust's relaxed memory model is considered.
//!
//! Historically, the strategy for testing concurrent code has been to run tests
//! in loops and hope that an execution fails. Doing this is not reliable, and,
//! in the event an iteration should fail, debugging the cause is exceedingly
//! difficult.
//!
//! # Solution
//!
//! Loom fixes the problem by controlling the scheduling of each thread. Loom
//! also simulates the Rust memory model such that it attempts all possible
//! valid behaviors. For example, an atomic load may return an old value instead
//! of the newest.
//!
//! The above example can be rewritten as:
//!
//! ```ignore
//! extern crate loom;
//!
//! use loom::sync::atomic::AtomicUsize;
//! use loom::thread;
//!
//! use std::sync::Arc;
//! use std::sync::atomic::Ordering::SeqCst;
//!
//! #[test]
//! fn test_concurrent_logic() {
//! loom::fuzz(|| {
//! let v1 = Arc::new(AtomicUsize::new(0));
//! let v2 = v1.clone();
//!
//! thread::spawn(move || {
//! v1.store(1, SeqCst);
//! });
//!
//! assert_eq!(0, v2.load(SeqCst));
//! });
//! }
//! ```
//!
//! Loom will run the closure many times, each time with a different thread
//! scheduling The test is guaranteed to fail.
//!
//! # Writing tests
//!
//! Test cases using loom must be fully determinstic. All sources of
//! non-determism must be via loom types. This allows loom to validate the test
//! case and control the scheduling.
//!
//! Tests must use the loom synchronization types, such as `Atomic*`, `Mutex`,
//! `Condvar`, `thread::spawn`, etc. When writing a concurrent program, the
//! `std` types should be used when running the program and the `loom` types
//! when running the test.
//!
//! One way to do this is via cfg flags.
//!
//! It is important to not include other sources of non-determism in tests, such
//! as random number generators or system calls.
//!
//! # Yielding
//!
//! Some concurrent algorithms assume a fair scheduler. For example, a spin lock
//! assumes that, at some point, another thread will make enough progress for
//! the lock to become available.
//!
//! This presents a challenge for loom as the scheduler is not fair. In such
//! cases, loops must include calls to `yield_now`. This tells loom that another
//! thread needs to be scheduled in order for the current one to make progress.
//!
//! # Dealing with combinatorial explosion
//!
//! The number of possible threads scheduling has factorial growth as the
//! program complexity increases. Loom deals with this by reducing the state
//! space. Equivalent executions are elimited. For example, if two threads
//! **read** from the same atomic variable, loom does not attempt another
//! execution given that the order in which two threads read from the same
//! atomic cannot impact the execution.
#![doc(html_root_url = "https://docs.rs/loom/0.1.0")]
#![deny(missing_debug_implementations, missing_docs)]
#![cfg_attr(test, deny(warnings))]
#[macro_use]
extern crate cfg_if;
// extern crate libc;
#[macro_use]
extern crate scoped_tls;
#[cfg(feature = "generator")]
extern crate generator;
#[cfg(feature = "fringe")]
extern crate fringe;
// The checkpoint feature enables serialization of the check exploration to
// disk. This is useful for replaying a known failing permutation.
cfg_if! {
if #[cfg(feature = "checkpoint")] {
extern crate serde;
#[macro_use]
extern crate serde_derive;
extern crate serde_json;
}
}
macro_rules! if_futures {
($($t:tt)*) => {
cfg_if! {
if #[cfg(feature = "futures")] {
$($t)*
}
}
}
}
#[doc(hidden)]
#[macro_export]
macro_rules! debug {
($($t:tt)*) => {
if $crate::__debug_enabled() {
println!($($t)*);
}
};
}
pub mod fuzz;
mod rt;
pub mod sync;
pub mod thread;
#[doc(inline)]
pub use fuzz::fuzz;
if_futures! {
extern crate futures as _futures;
pub mod futures;
}
pub use rt::yield_now;
#[doc(hidden)]
pub fn __debug_enabled() -> bool {
rt::execution(|e| e.log)
}