The other major component of any threads library, and certainly the case with POSIX threads, is
the presence of a condition variable. Condition variables are useful when some kind of signaling
must take place between threads, if one thread is waiting for another to do something before it
can continue. Two primary routines are used by programs wishing to interact in this way:
int pthread_cond_wait(pthread_cond_t* cond, pthread_mutex_t* mutex); int pthread_cond_signal(pthread_cond_t* cond);
To use a condition variable, one has to in addition have a lock that is associated with this condition
. When calling either of the above routines this lock should be locked.
The first routine, pthread_cond_wait(), puts the calling thread to sleep, and thus waits for some
other thread to signal it, usually when something in the program has changed that the now-
sleeping thread might care about. A typical usage looks like this:
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
pthread_mutex_lock(&lock);
while (ready == 0) {
pthread_cond_wait(&cond, &wait);
}
pthread_mutex_unlock(&lock);
In this code, after initialization of the relevant lock and condition, a thread checks to see if the
variable ready has yet been set to something other than zero. If not, the thread simply calls the
wait routine in order to sleep until some other thread wakes it.
The code to wake a thread, which would run in some other thread, looks like this:
pthread_mutex_lock(&lock); ready = 1; pthread_cond_signal(&cond); pthread_mutex_unlock(&lock);
A few things to note about this code sequence. First, when signaling as well as when modifying
the global variable ready, we always make sure to have the lock held. This ensures that we do
not accidentally introduce a race condition into our code.
Second, you might notice that the wait call takea a lock as its second parameter, whereas signal
call only takes a condiiton. The reason for this difference is that the wait call, in addition to putting
the calling thread to sleep, release the lock when putting said caller to sleep. Imagine if it did not:
how could the other thread acquire the lock and signal it to wake up? However, before returning
after being woken, the pthread_cond_wait() reacquires the lock, thus ensuring that any time the
waiting thread is running between the lock acquire at the beginning of the wait sequence, and
the lock release at the end, it holds the lock.
On last oddity: the waiting thread re-checks the condition in a while loop, instead of a simple if
statement. We will discuss this issue in detail when we study condiiton variables in a future
chapter, but in general, using a while loop is the simple and safe thing to do. Although it rechecks
the condition perhaps adding a little overhead, there are some pthread implementations that
could spuriously wake up a waiting thread; in such a case, without rechecking, the waiting thread
will continue thinking that the condition has changed even though it has not. It is safer thus to
view waking up as a hint that something might have changed, rather than an absolute fact.
Note that sometines it is temping to use a simple flag to signal between two threads, instead of
a condition variable and associated lock. For example, we could rewrite the waiting code above to
look more like this in the waiting code:
while (ready == 0)
;
Don't ever do this, for the following reasons. First, it performas poorly in many cases spinning for
a long time just wastes CPU cycles. Second, it is error prone. As recent research shows, it is
surprisingly easy to make mistaks when using flags as above to synchronize between threads;
in that study, roughly half the uses of these ad hoc synchronizations were buggy! Don't be lazy;
use condition variables even when you think you can get away without doing so.
If condition variables sound confusing, don't worry too much yet, we will be covering them in
great detail in a subsequent chapter. Until then, it should suffice to know that they exist and to
have some idea how and why they are used.
Compiling and Running
All of the code examples in this chapter are relatively easy to get up and running. To compile them
, you must include the header pthread.h in your code. On the link line, you must also explicitly link
with the pthreads libraary, by adding the -pthread flag.
For example, to compile a simple multi-threaded program, all you have to do is the following:
prompt> gcc -o main main.c -Wall -pthread
As long as main.c includes the pthreads header, you have now successfully compiled a concurrent
program. Whether it works or not, as usual, is a different matter entirely.
We have introduced the basics of the pthread library, including thread creation, building mutual
exclusion via locks, and signaling and waiting via condition variables. You don't need much else
to write robust and efficient multi-threaded code, except patience and a great deal of care.
We now end the chapter with a set of tips that might be useful to you when you write multi-
threaded code see the aside on the following page for details. There are other aspects of the API
that are interesting; if you want some more information, type man -k pthread on a linux system
to see over a hundred APIs that make up the entire interface. However, the basics discussed
herein should enable you to build sophisticated and hopefully, correct and perfromant multi-
threaded programs. The hard part with threads is not the APIs, but rather the tricky logic of how
you build concurrent programs. Read on to learn more.
Aside: Thread API Guidelines
There are a number of small but important things to remember when use the POSIX thread library
or really, any thread library to build a multi-threaded program. They are:
keep it small. Above all else, any code to lock or signal between threads should be as simple as
possible. Tricky thread interactions lead to bugs.
Minimize thread interactions. Try to keep the number of ways in which threads interact to a minimum.
Each interaction should be carefully thought out and constructed with tried and true approaches many
of which we will learn about in the coming chapters.
Initialize locks and condition variables. Failure to do so will lead to code that sometimes works and
sometimes fails in very strange ways.
Check your return codes. Of course, in any C and UNIX programming you do, you should be checking
each and every return code, and it's true here as well. Failure to do so will lead to bizarre and hard to
understand behavior, making you likely to scream, pull some of your hair, or both.
Be careful with how you pass arguments to, and return values from, threads. In particular, any time
you are passing a reference to a variable allocated on the stack, you aer probably doing something
wrong.
Each thread has its stack. As related to the point above, please remember that each thread has its
own stack. Thus, if you have a locally-allocated variable inside of some function a thread is executing
, it is essentially private to that thread; no other thread can easily access it. To share data between
threads, the values must be in the heap or othrewise some locale that is globally accessible.
Always use condition variables to signal between threads. While it is often tempting to use simple
flag, don't do it.
Use the manual pages. On linux, in particular, the pthread man pages are highly informative and
discuss much of nuances presented here, often in even more detail, read them carefully!