Crossbeam: Concurrent Programming Tools for Rust

What Crossbeam Solves, and Who It Is For

Crossbeam is not a single library. It is a family of crates that together cover the parts of concurrent Rust that the standard library either handles with locks or does not address at all. The README lists the tools by category: atomics (AtomicCell, AtomicConsume), data structures (deque, ArrayQueue, SegQueue), memory management (epoch), thread synchronization (channel, Parker, ShardedLock, WaitGroup) and utilities (Backoff, CachePadded, scope). The intended audience is the person writing the scheduler, not the person using it. Work-stealing deques are described in the README as "primarily intended for building task schedulers", which is an unusually honest scoping statement: you reach for crossbeam-deque when you are implementing a runtime, and you reach for crossbeam-channel when you are wiring threads together at an application level. The project also serves Rust programmers who need to share mutable state across threads without a lock, which is what AtomicCell provides as "a thread-safe mutable memory location". If your problem is ordinary parallelism with clear ownership boundaries, the standard library's scoped threads and channels may be enough, and Crossbeam adds a dependency without adding much.

How the Crates Fit Together

The main crossbeam crate re-exports tools from smaller subcrates, and the README is explicit that it does so: crossbeam-channel for message passing, crossbeam-deque for work-stealing deques, crossbeam-epoch for epoch-based garbage collection, crossbeam-queue for concurrent queues, and crossbeam-utils for atomics, synchronization primitives, scoped threads and other utilities. There is one more subcrate, crossbeam-skiplist, which the README says is "not yet included in crossbeam" and provides concurrent maps and sets based on lock-free skip lists. That distinction matters when you are choosing a dependency: if you need a concurrent map, you are adding crossbeam-skiplist directly, and the README's word "experimental" is the only status signal you get. The memory management story is the part that most distinguishes the project. Epoch-based garbage collection is what lets a lock-free structure defer destruction of a node until no thread can still hold a reference to it. Building a concurrent data structure without a reclamation scheme means either leaking memory or freeing something another thread is about to read. Crossbeam exposes the mechanism rather than hiding it, which is why the README groups epoch under memory management and not under data structures. The feature flags follow the same layered logic: the default feature is std, which enables alloc, which in turn enables the alloc-dependent parts of crossbeam-epoch and crossbeam-queue. The README marks AtomicCell, AtomicConsume, Backoff and CachePadded as usable in no_std environments, and ArrayQueue, SegQueue and epoch as usable in no_std only when the alloc feature is enabled.

Installing Crossbeam and Sending Messages Between Threads

Crossbeam is distributed through Cargo, and the README gives the dependency line directly. Add the umbrella crate to Cargo.toml with the version string shown in the README:

[dependencies]
crossbeam = "0.8"

The README's Compatibility section states that Crossbeam supports stable Rust releases going back at least one year, that the minimum supported Rust version is 1.74, and that a new minor version is released whenever the MSRV is raised. The Cargo.toml for the crate confirms this with rust-version = "1.74" and edition = "2021", so a toolchain older than 1.74 will refuse to build it.

A first real use is a multi-producer multi-consumer channel. The README describes crossbeam-channel as providing "multi-producer multi-consumer channels for message passing", which is the capability the standard library's mpsc channel does not offer on the receiving side. The pattern is to create a channel, move a clone of the sender into each worker, and receive in a loop on the consumer side. Because the receiver is itself cloneable, several threads can pull from the same channel, which is how you build a work queue where any idle worker picks up the next item. The sender and receiver types are the ones documented under crossbeam::channel, and the API surface there is the place to check the exact method names for your version rather than assuming them.

For thread lifetimes, the scope function is the other piece worth knowing early. The README describes it as being "for spawning threads that borrow local variables from the stack". That removes the 'static bound you would otherwise fight when passing references into worker threads, and it is the reason scope appears in the utilities list alongside Backoff and CachePadded rather than in the synchronization list.

Where Crossbeam Is the Wrong Choice

Lock-free is not a synonym for faster. If your critical section is short and uncontended, a mutex is simpler and the compiler's optimizer can do more with it. Crossbeam does not hide the complexity of lock-free reasoning; it gives you the primitives and leaves the correctness argument to you. The epoch collector is the clearest example. It reclaims memory on the assumption that threads participate in the epoch protocol. A thread that holds a reference into a crossbeam data structure without pinning itself in the current epoch is a use-after-free waiting to happen, and nothing in the type system stops you. That is the failure mode to take seriously: the bugs are not compile errors, they are rare crashes under load.

The dependency footprint is the second consideration. The umbrella crate pulls in crossbeam-channel, crossbeam-deque, crossbeam-epoch, crossbeam-queue and crossbeam-utils, each of which is versioned and released separately. The recent release list shows exactly this: crossbeam-utils 0.8.23, crossbeam-queue 0.3.14 and crossbeam-epoch 0.9.21, all published on the same day. If you only need scoped threads and CachePadded, depending on crossbeam-utils alone is the narrower choice, and the README's crate list tells you which subcrate owns which tool. Finally, crossbeam-skiplist is described as experimental and excluded from the umbrella crate, so a project that needs a concurrent map is depending on a subcrate the README does not present as settled.

Crossbeam Versus Rayon

Rayon is the natural comparison for anyone arriving at Crossbeam looking for parallelism, and the two solve different problems. Rayon gives you a parallel iterator and a work-stealing thread pool you do not have to build. Crossbeam gives you the work-stealing deque that such a pool is built from, and the README says as much by describing crossbeam-deque as "primarily intended for building task schedulers". The practical difference is who owns the scheduling policy. With Rayon you express the computation and the library decides how to split it. With Crossbeam you write the loop that pops a task, runs it, and pushes stolen work back, and you decide when a worker should spin, yield or park. Crossbeam's Backoff utility exists for exactly that decision: the README describes it as being "for exponential backoff in spin loops", which is a concern that never surfaces in a Rayon program. If your goal is to parallelize an existing loop over a collection, Rayon is the shorter path. If your goal is a runtime, a custom executor or a data structure that other code will call concurrently, Crossbeam is aimed at you.

Maintenance, Releases and Licence Terms

The repository is not archived, and the last push was on 2026-09-07. Releases are frequent and per-subcrate rather than monolithic: crossbeam-utils 0.8.23, crossbeam-queue 0.3.14 and crossbeam-epoch 0.9.21 were all published on 2026-09-05. That release cadence has an upgrade cost attached. Because the umbrella crate re-exports the subcrates, a change in crossbeam-epoch can move the version of crossbeam you resolve in your lockfile even when you did not touch your own dependency line. The Cargo.toml comment block also shows the maintainers' own checklist for publishing, which includes updating CHANGELOG.md, updating README.md when the major or minor version increases, and running ./tools/publish.sh crossbeam <version>. That is a manual, documented process, and it is the reason to read the changelog rather than assume a patch bump is inert.

On licensing, the README states the project is "Licensed under either of Apache License, Version 2.0 or MIT license at your option", and the repository root carries both LICENSE-APACHE and LICENSE-MIT. The Cargo.toml records license = "MIT OR Apache-2.0". The README adds a caveat worth reading in full: "Some Crossbeam subcrates have additional licensing notices", and points to the other readme files in the repository. It also states that contributions are dual licensed under the same terms unless explicitly stated otherwise. If you vendor or redistribute a subcrate, check that subcrate's own readme rather than relying on the root licence alone. This is a description of what the files say, not legal advice; your own counsel should review redistribution terms.

Editorial conclusion

Adopt Crossbeam if you are building a task scheduler, a lock-free data structure or a multi-producer multi-consumer pipeline in Rust and you accept that you are taking on a low-level concurrency toolkit rather than an application framework. Do not adopt it if a mutex, a std::sync::mpsc channel or a thread pool already meets your throughput needs, because lock-free code is harder to reason about and harder to debug. Before committing, verify the minimum supported Rust version against your toolchain (the Cargo.toml sets rust-version = 1.74), check whether the subcrate you need is covered by the umbrella crate or only available separately, and read the epoch documentation on deferred destruction if you plan to build your own concurrent structure.

Frequently asked questions

Official sources

1. crossbeam-rs/crossbeam on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases