EmptyCrate Software. Travel. Stuff.

While debugging my massively multithreaded C++ application I would notice times where the application would seem to pause for a few moments. During one of these pauses I halted the application and attached to it with the debugger (GDB). From within GDB I listed (info threads), switched to (thread <num>) and looked at the stack (bt) of each thread running.

I saw something surprising and very telling. Nearly every single thread that was supposed to be performing work was actually blocked on a mutex inside of either malloc or free.

I recently had the need to be able to query the WMI via WQL (which are very fascinating and helpful technologies, actually) from C++. WQL essentially provides an SQL interface for querying system properties of a running computer.

The process of running and returning a WQL query from C++ has several steps to it, so I found the official example for how to do this on Microsoft's website.

I will not quote the full original code here, but I will comment on it. It makes a pretty good object lesson in how to not program in C++.

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.

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()
    {

Understanding RAII is critical to understanding good C++ design.

RAII stands for "Resource Acquisition Is Initialization." The basic idea is that an object fully manages all of its own resources.

Understanding object lifetime is critical to understanding RAII. For the purposes of this article we will only be discussing objects created on the stack, not on the heap. That is, objects not created with "new."

There are just a couple of simple rules to understanding lifetime: