Threads FAQ

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. The terms here refer to each other in a myriad of ways, so the best way to navigate through this section is to read it, and then read it again. Don’t be afraid to skip forwards or backwards as the need appears. Async safety (POSIX) Some library routines can be safely called from within signal handlers; these are referred to as async-safe. A thread that is executing some async-safe code will not deadlock if it is interrupted by a signal. If you want to make some of your own code async-safe, you should block signals before you obtain any locks. ...

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. By default, POSIX threads are created non-detached. You need to perform a join on each non-detached thread, or else storage will never be freed up when they exit. As an alternative, you can create detached threads, for which storage will be freed as soon as they exit. This latter approach is generally better; you should only create non-detached threads if you explicitly need to know when or if they exit.

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. Asynchronous cancellation of threads is, in general, evil. The reason for this is that it is usually difficult or impossible to guarantee that the recipient of an asynchronous cancellation request will not be in a critical section. If a thread should die in the middle of a critical section, this will almost certainly cause your program to misbehave. ...

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. With POSIX threads, it is not possible for a thread to join(), or wait for the termination of, a non-specific thread; you have to identify the thread you’re waiting for. Yes, there is a rationale behind the absence of this feature. Unix programmers are used to being able to call the wait() in such a way that it will return when any child process exits, but expecting this to work for threads can cause confusion. The important thing to note here is that Unix processes are based around a notion of parent and child; this is a notion that is not present in most threads systems. Since threads don’t have this notion, join()ing on “any” thread could have the undesirable effect of having a join() return once a completely unrelated thread happened to exit. ...

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. On Unix systems, using threads and signals together is a nightmare. A lot of programmers start out by writing their code under the mistaken assumption that they can set a separate signal handler for each thread; this is not the way things work. You can block or unblock signals on a thread-by-thread basis, but this is not the same thing as having a separate handler per thread. ...

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. The notion of a thread, as a sequential flow of control, dates back to 1965, at least, with the Berkeley Timesharing System. Only they weren’t called threads at that time, but processes [Dijkstra, 1965]. Processes interacted through shared variables, semaphores, and similar means. Max Smith did a prototype threads implementation on Multics around 1970; it used multiple stacks in a single heavyweight process to support background compilations. ...

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. If you are talking about “mainstream” systems programming languages on popular operating systems, there are three main families of threads. POSIX-style threads, which generally run on Unix systems Microsoft-style threads, which generally run on Windows systems Java threads, which are specific to the Java language, but run on a variety of operating systems Other software systems have their own ways of handling threads and concurrency. They are too numerous to cover, but here are a few links to the threading systems of popular cross-platform software systems. ...

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. A thread is an encapsulation of the flow of control in a program. Most people are used to writing single-threaded programs–that is, programs that only execute one path through their code “at a time”. Multithreaded programs may have several threads running through different code paths “simultaneously”. Why are some phrases above in quotes? The exact meaning of the term “thread” is not generally agreed upon. One of the more common usages denotes a “lightweight” process (sequential flow of control) which shares an address space and some other resources with others, and for which context switching time is lower than for “heavyweight” (i.e. kernel-supported) processes. In a typical process in which multiple threads exist, the system’s CPUs may be executing instruction for zero or more threads at any one time. The number of executing threads depends on the number of CPUs in the system, and also on how the threading subsystem is implemented. A machine with n processing units can, intuitively enough, run no more than n threads in parallel, but it may give the appearance of running many more than n “simultaneously”, by sharing the CPUs among threads. Some of the features which distinguish different approaches to threading are listed below: ...

This FAQ originated on Usenet in the early-to-mid 1990s; it survives here mainly for historical curiosity rather than as a source of current best practices. There are two approaches to providing system calls and library interfaces that will work with multithreaded programs. One is to simply wrap all the appropriate code with mutexes, thereby guaranteeing that only one thread will execute any such routine at a time. While this approach mostly works, it provides terrible performance. For functions that maintain state across multiple invocations (e.g. strtok() and friends), this approach simply doesn’t work at all, hence the existence of _r interfaces on many Unix systems (see below). ...