Programming Rust, 3rd Edition

Chapter 19. Threads

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the nineteenth chapter of the final book. Please note that the GitHub repo will be made active later on.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

In the long run it is not advisable to write large concurrent programs in machine-oriented languages that permit unrestricted use of store locations and their addresses. There is just no way we will be able to make such programs reliable (even with the help of complicated hardware mechanisms).

Per Brinch Hansen (1977)

Patterns for communication are patterns for parallelism.

Whit Morriss

If your attitude toward threads has changed over the course of your career, you’re not alone. It’s a common story.

At first, writing multithreaded code is easy and fun. The tools—locks, queues, and so on—are a snap to pick up and use. There are a lot of pitfalls, it’s true, but fortunately you know what they all are, and you are careful not to make mistakes.

At some point, you have to debug someone else’s multithreaded code, and you’re forced to conclude that some people really should not be using these tools.

Then at some point you have to debug your own multithreaded code.

Experience ...