EmptyCrate Software. Travel. Stuff.

We've covered the "Assembly Language", "C" and "C++" of the C++ threading world, and now we are going to try and move beyond that.

In the "C++" example we showed a object that automatically managed a thread's life time and used the thread to calculate the Fibonacci sequence in the background. Using templates we should be able to make a generic version of the Fibonacci calculator thread.

I'm going to cover a thread safety strategy I have been thinking about lately. Let's look at an example for a typical "lock the variables as you use them" approach:

I am proposing the following changes to the typical approach:

If boost::threads represent the C of multithreaded programming, then RAII and automatically managed threads represent the C++ of multithreaded programming.

In the last article we promised that using more RAII would allow us to get this code even smaller and better to manage. Here is the result of that:


class threaded_class
{
public:
threaded_class()
: m_stoprequested(false),
m_thread(boost::bind(&threaded_class::do_work, this)) //Note 2
{
}

~threaded_class()
{

If pthreads represent the assembly language of multithreading programming, then boost::threads represent the C of multithreaded programming.

Boost threads introduce some handy code saving features for the creation of threads, which is nice, but not as important as the RAII techniques they put to use for mutex management. In this case an example is worth a thousand words. Here is the same code we wrote in for pthreads rewritten for boost::threads:


class threaded_class
{
public:
threaded_class()

My apparent memory leak from the other day did in fact turn out to be leaking thread resources. The key: Don't Join on Yourself!

If a thread attempts to call pthread_join on itself it is likely to cause a deadlock in that thread that you may never know about. Particularly if you are using some sort of worker-thread model that creates and destroys threads often.

A simple way to catch this problem would be to add an assertion in your destructor.


class threaded_class
{
~threaded_class()
{

During the course of debugging a potential memory leak at work I noticed that Linux seems to allocate at least 8M of memory for each thread created.

This very simple test program illustrates the memory allocations: