[go: up one dir, main page]

coco/
lib.rs

1//! Concurrent collections.
2//!
3//! This crate offers several collections that are designed for performance in multithreaded
4//! contexts. They can be freely shared among multiple threads running in parallel, and
5//! concurrently modified without the overhead of locking.
6//!
7//! <!--
8//! Some of these data structures are lock-free. Others are not strictly speaking lock-free, but
9//! still scale well with respect to the number of threads accessing them.
10//! -->
11//!
12//! # Collections
13//!
14//! The following collections are available:
15//!
16//! * [`Stack`]: A lock-free stack.
17//! * [`deque`]: A lock-free work-stealing deque.
18//!
19//! # Which collection should you use?
20//!
21//! ### Use a [`Stack`] when:
22//!
23//! * You want a simple shared collection where objects can be insert and removed.
24//! * You want to avoid performance degradation due to locking.
25//! * You want the last-in first-out order of elements.
26//!
27//! ### Use a [`deque`] when:
28//!
29//! * You want one thread inserting and removing objects, and multiple threads just removing them.
30//! * You don't care about the order of elements.
31//!
32//! # Garbage collection
33//!
34//! An interesting problem concurrent collections deal with comes from the remove operation.
35//! Suppose that a thread removes an element from a lock-free map, while another thread is reading
36//! that same element at the same time. The first thread must wait until the second thread stops
37//! reading the element. Only then it is safe to destruct it.
38//!
39//! Programming languages that come with garbage collectors solve this problem trivially. The
40//! garbage collector will destruct the removed element when no thread can hold a reference to it
41//! anymore.
42//!
43//! This crate implements a basic garbage collection mechanism, which is based on epochs (see the
44//! `epoch` module). When an element gets removed from a concurrent collection, it is inserted into
45//! a pile of garbage and marked with the current epoch. Every time a thread accesses a collection,
46//! it checks the current epoch, attempts to increment it, and destructs some garbage that became
47//! so old that no thread can be referencing it anymore.
48//!
49//! That is the general mechanism behind garbage collection, but the details are a bit more
50//! complicated. Anyhow, garbage collection is designed to be fully automatic and something users
51//! of concurrent collections don't have to worry about.
52//!
53//! [`Stack`]: stack/struct.Stack.html
54//! [`deque`]: deque/fn.new.html
55
56#![cfg_attr(feature = "nightly", feature(const_fn))]
57
58extern crate either;
59
60#[macro_use(defer)]
61extern crate scopeguard;
62
63pub mod deque;
64pub mod epoch;
65pub mod stack;
66
67pub use stack::Stack;