What are threads?
Every modern operating system has support for threads, and most programming environments provide some level of support for threading. What threads give you is the ability for your program to do more than one thing at once. The problem with threads is the way that they can dramatically increase the complexity of your program.
First, a little background, so we’re all on the same page. In Computer Science, as in the physical sciences, using a simplified model makes it easier to discuss complex phenomena without getting bogged down in insignificant details. The trick of course, is in knowing where your simplifications deviate from reality in a way that affects the validity of the results. While spherical cows on an infinite frictionless plane do make the calculations easier, sometimes the details matter.
When Real Computer Scientists ™ are discussing problems in concurrent programming (like the Dining Philosophers), they’ll sometimes refer to a Process, which is kind of abstract ideal of a computer program. Multiple Processes can be running at the same time in the same system, and can also interact and communicate in various ways.
The threads provided by your favorite operating system and programming language are something basically similar to this theoretical concept of a Process, with a few unfortunate details of implementation.
The New Jersey approach
I couldn’t find a definitive reference to the history of the development of threads as we know them today, but the model most people are familiar with arose out of POSIX, which was largely an attempt to formalize existing practice in UNIX implementations.
It turns out that POSIX Threads, Mach Threads, Windows Threads, Java Threads, and C# Threads all work very much the same, since they’re all implemented in more or less the same way. The object-oriented environments wrap a thin veneer of objects around a group of extremely low-level functions, but you’ve got your basic operations of create(), join(), and exit(), as well as operations on condition variables and mutexes. For the rest of this rant, I’ll refer to these as “Pthreads”, for convenience.
Pthreads are an example of the Worse is better philosophy of software design, as applied to the problems of concurrent programming. The POSIX threading model is just about the simplest possible implementation of multi-threading you could have. When you want to create a new thread, you call pthread_create(), and a new thread is created, starting execution with some function you provide. The newly-created thread is created by allocating some memory for a stack for the new thread, loading up a couple of machine registers, and jumping to an address.
Shared state – two models
In the Pthreads model, all of your threads share the same address space. This makes sharing data between threads very simple and efficient. On the other hand, the fact that all of the state in the program is accessible and changeable from every thread can make it very difficult to ensure that access to all this shared state is managed correctly. Race conditions, where one thread attempts to update a data structure at the same time that another thread is trying to access or change that same structure, are common.
The problem with the all state is shared model is that it doesn’t match up very well with what you’re generally trying to accomplish when you spawn a thread. You’ll normally create a new thread because you want that thread to do something different than what the main thread is already doing. This implies that not all of the state in the parent thread needs to be available to be modified in the second thread. But because of the way threads are created in this model, it’s easier (for the OS or language implementor) to share everything rather than a well-defined subset, so that’s what you get.
The other major model for multi-threading is known as message-passing multiprocessing. Unless you’re familiar with the Occam or Erlang programming languages, you might not have encountered this model for concurrency before.
There are a number of variations on the message-passing model, but they all have one thing in common: In the message-passing model, your threads don’t share any state by default. If you want some information to go from one thread to another, you need to do it by having one thread send a message to the other thread, typically by calling a function provided by the system for just this purpose. Two popular variants of the message-passing model are “Communicating Sequential Processes” and the “Actor model”.
You can get a nice introduction to the message-passing model by reading the first couple chapters of the Occam Reference Manual, which is apparently available online these days (I got mine by digging around in a pile of unwanted technical books at a former employer). Occam is of course the native language of the Transputer, a very inventive but commercially unsuccessful parallel processor architecture from the UK which made a big splash in the mid-80’s before vanishing without a trace.
Why would you want to learn about this alternative model, when Pthreads have clearly won the battle for the hearts and minds of the programming public? Well, besides the sheer joy of learning something new, you might develop a different way of looking at problems, that’ll help you top make better use of the tools that you do use regularly. In addition, as I’ll explain in Part II of this rant, there’s good reason to believe that message-passing concurrency is going to be coming back in a big way in the near future.
Enough rope to hang yourself with
As I mentioned earlier, the Pthreads model implies that all of your program’s address space is shared between all threads. Most (all?) implementations allow you to allocate some amount of thread-local storage, but in general, the vast majority of your program’s state is shared by every thread. This implies that every thread has the ability to modify the value of any variable, and call any arbitrary function, at any time. This is a really powerful tool, but like all powerful tools, it can be dangerous if misused.
It’s extremely difficult to predict what the behavior of even fairly simple code will be, when multiple threads can run it simultaneously. For more complex code, the problem rapidly becomes intractable. In a low-level language like C, you need to know the intimate details of how the compiler will optimize your code, which operations are guaranteed to be completed atomically, what the register allocation policy is, etc, etc. In a JIT-compiled language like Java or C#, it’s impossible to even know what machine code will be used at runtime, so analyzing runtime behavior in detail just isn’t possible.
An unlocked gun cabinet
I think one of the major problems with Pthreads is that it’s too easy to make something that almost works. This then leads to an unwarranted belief that multi-threaded programming is simple. For example, say you’ve got a simple interactive GUI application, and you think that the application takes too long to calculate something after the user presses a button. The “obvious” solution to this problem is to have your button-press handler spawn off a new thread to perform the long-running operation.
So you try this, and it works perfectly on the first try – the child thread launches, and then calculates away while the main thread goes back to handling the UI. You still need to notify the main thread when the calculation is complete, but there any number of easy ways to do this, and you probably won’t have much trouble figuring that out. Gee, that wasn’t so difficult, I wonder why people say that multi-threaded programming is difficult?
It’s this sort of ad-hoc approach to creating threads that gets people into trouble. They create a new thread to solve one problem, and then another, and then they suddenly realize that thread A and thread M are interacting in a bad way. So they protect some critical data structures with mutexes, and before they know it, they’re trying to debug a deadlock situation where they don’t even understand how those two pieces of code could interact.
You need to really think about why you’re creating a thread, before you spawn it. I’m not going to go so far as to say that creating threads while your program is running (rather than at startup) is de-facto proof that you’re doing something wrong, but it’s definitely a strong indication that you’re not thinking about what your threads are for with any great rigor.
How to not shoot yourself in the foot
… is going to be the subject of Part II. Sorry for the cliff-hanger ending, but I wanted to get at least a little of this published, and potentially get some comments on it, before finishing the rest.
markbessey.blog 
Leave a Reply