Rust - Thinking about threading

Previously published

This article was previously published on len-learns-rust.com. A full index of these articles can be found here.

My threading background in C++ on Windows and Linux goes back a long way and that means that I have some set ways of doing things that may not map directly to the Rust way of doing things. I tend to use threads with the following patterns at present:

  • A thread starts up, waits on one or more externally controlled ’events’ and, when one of these is triggered the thread does something, or shuts down.
  • A thread starts up and waits for items to arrive on a queue and processes work items until the queue tells it that its time to shut down.
  • Often I have a pool of threads fed from a single queue in a multiple-producer, multiple-consumer style.
  • Too often I have multiple-threads that need to access shared data and that lock the data around their access so that the data remains consistent.
  • Often I use a variation on the ‘actor’ design using my Activatable Object pattern which is a variation on the Active Object pattern.

My intention is to first try and do the things that I usually do and see how these map to Rust, then, look at the idiomatic threading patterns in Rust. Effectively, what I’d like to do now is understand threading enough so that I can do the various things that I’m used to doing in C++ in Rust. Ideally I’ll end up with a threadpool that I can send work to and that works efficiently and can execute work items that I send to it and that can be shut down cleanly when I’m done with it. In the past I’ve done complex things with pools that can be expanded as they get busy and then contract when they are less busy, but this has become a little less relevant with today’s hardware.

But first, simple threading…