Sharing state between threads
Two threads and one piece of data is the whole problem. Either you send the data, or you share it behind a lock, or you make it atomic — and each choice has a failure mode with a name: deadlock, poisoned mutex, lost update.
The last article is the one to read if you are deciding whether you need a lock at all.
Articles
Section titled “Articles”Nothing published in this chapter yet — all 10 articles are still to come.
Coming up (10)
- How to pass messages between threadsmpsc, and the sender you must drop
- What is the difference between mpsc and crossbeam channels?multi-consumer, selection, and cost
- How to share mutable state with a MutexArc<Mutex<T>> spelled out
- What are Mutex and RwLock?one writer, or many readers
- What is a MutexGuard, and how long does it live?the lock you are still holding
- How to fix a poisoned Mutexrecover, or decide that the data is gone
- How to avoid deadlockslock ordering, and holding a guard across a call
- When to use an atomic instead of a lockcounters, flags, and the orderings you need
- How to share state without a lockchannels, actors, and read-only Arc
- How to use crossbeam for concurrent data structuresscoped threads and multi-consumer channels