blog.ebg13.at

It’s been a while since I used the boost library. The threads library is pretty nice, but there is one major issue concerning member initialization order and thread construction.
Consider the following situation: I am writing a client library for a daemon. It’s connected via tcp. Now, I want to be notified whenever a new message from the server arrives from the daemon. I know that these days I would use asio but we are not 100 % sure it’s fully available on our target plattform (gumstix / openembedded thingy), so I went for the old and proven workhorse: a thread and a select statement. we have boost available so I went for the Boost.Thread for usage. turns out that the version available is 1.33.1. Well, bad luck, threads are noncopyable in that version (they are moveable in 1.34.0). This means, that whenever you want to have a thread as a member variable of a class, the thread will have to start when you construct the class. This was fine with me.

I want the the library to connect to a daemon on a port through a connect command which can later disconnect and reconnect to a different host as well. Not that we utterly need it, but it’s always nice if it’s there. So, the thread starts without having a connected socket and waits on a condition for socket to be created by the connect() member function. so, at the beginning of the threads processing loop it locks the mutex and enters a condition.wait(mutex) until the socket is valid. The connect method on the other hand, locks the mutex, creates the socket, unlocks the mutex again and notifies the condition variable. This is afaik the correct pattern to do this, and it works great. There is only one major problem: When you have a thread as a member variable, you better be sure that you have it listed AFTER the mutex (and possible also the condition var) in the class.

Otherwise the thread is created in the constructor and it’s run function immediatly starts running into the condition variable, which waits on a uninitialized mutex (jup, uninitialized). The mutex is uninitialized, because it is declared AFTER the thread variable which is constructed first. BAM. Result: the condition locks the mutex and after that the mutex is constructed in the inializer list (and probably reset). now the connect method does a notifiy via the condition variable (which sits ontop of the mutex) and does not find any waiting threads, even tough the spawned thread is hanging in a system wait somewhere. It won’t ever be notified. Lost. Gone.

All of this only because I declared the thread variable before the mutex / condition variables. nice, huh?. Note that with boost thread being moveable now, I wouldn’t create the thread in the constructor anymore. I’d have a start method which creates a new thread and moves it to the local member variable.

So, rule #1 check your member initialization order when using boost::threads!

This entry was posted on Monday, September 29th, 2008 at 12:58 and is filed under IT. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.