I have a question about mixing and matching boost::threads with some of the c++11 standard items, does this work? I haven't actually tested anything yet but I am working with a system that uses all boost::threads and thread groups and interrupt features that you don't get out of the box with the standard, so there is no changing. Our version of boost 1.50 and doesn't have the latest std::atomic and memory ordering stuff. I was wondering if I could use the std::atomic and std:: memory ordering operations load/fectch_add etc(acquire/release,relaxed) with the boost threads and have the same results as if they were std::thread. These are all pthreads under the hood on my linux machine so I am thinking the answer is yes I can mix and match. Although,I just wanted to confirm and see if anyone has had any compatibility issues between mixing boost::thread and the std::thread apis.
-
I would be more concerned about mixing code intended to be C++03 compliant with C++11 code. On a personal note I still consider the "threading" support for C++11 basically useless and with a really old design. – user2485710 Jun 05 '14 at 21:30
-
3@user2485710 That's quite a bold statement. Do you care to justify why C++11 threading support is "basically useless"? – JBentley Jun 05 '14 at 22:36
-
1@JBentley it's not task based, it's without any support to "signals" or async operations, the `std::async` is based on a thread, and a couple of other problems about the design and the implementation like with the destructors of `std::future` that are blocking and badly designed. There is probably something useful, but I really don't think that someone will achieve something good with that, plus in C++14 there will be some modification that will impact the C++11 threading model with a different behaviour. – user2485710 Jun 06 '14 at 08:50
3 Answers
That's an interesting question which I have been thinking of for a while since C++11 became widely available.
One general point, I notice that boost versions of std components often have extensions that provide more functionality than the std versions. For example, boost::bind provides more functionality than std::bind, boost <type_traits> are richer than std ones, boost::thread allows for thread cancellation/interrupts and std ones do not, etc..
With regards to boost threads vs std threads in particular, as you mention
... I am working with a system that uses all boost::threads and thread groups and interrupt features that you don't get out of the box with the standard...
I wanted to note that boost thread interruption cancellation does not come without a price, boost::condition_variable is really boost::condition_variable_any when thread cancellation is enabled in boost. boost::condition_variable_any maintains its own mutex and does more locking than the original POSIX pthread_cond_t that boost::condition_variable was designed to be a lightweight wrapper of. The thread interruption feature adds measurable 5-10% speed overhead to boost::condition_variable, condition variable: std vs boost chart.
Our version of boost 1.50 and doesn't have the latest std::atomic and memory ordering stuff. I was wondering if I could use the std::atomic and std:: memory ordering operations load/fectch_add etc(acquire/release,relaxed) with the boost threads and have the same results as if they were std::thread
std::atomic library do not use or depend on a particular threads library for certain built-in atomic types only (integers and pointers no wider than the natural platform width, e.g. 32 or 64-bit), or a platform, so you can mix and match thread with atomics libraries as you like, as long as you are careful to use std::atomic<T> where T's atomicity is supported by the hardware (again, integers and pointers), you can check that with std::atomic<T>::is_lock_free().
- 131,725
- 17
- 180
- 271
-
Thanks for the additional info as I didn't know about boost::condition_variable is really boost::condition_variable_any – bjackfly Jun 06 '14 at 16:25
-
1@bjackfly Sometimes I can't find a definition of something in boost, so I just run my compiler command line and change `-c` to `-E` and `-o .../xyz.o` to `-o xyx.i` to get a fully pre-processed macro-expanded translation unit where I find definitions of stuff using just plain inline textual search in emacs. This is how I stumbled upon `boost::condition_variable` maintaining its own mutex, and I was like this is not what I expected, what is going on here?... – Maxim Egorushkin Jun 07 '14 at 01:33
There isn't any technical reason why it shouldn't work. Both boost::thread and std::thread are just wrappers for native system threads, and all synchronization mechanisms are independent of what you have used to spawn the thread.
- 2,997
- 6
- 28
- 36
FYI, this other thread shows that there is indeed some compatibility issue between boost threads and std threads when managing signals/termination: Preventing thread from calling std::terminate() on detach after handled exception:
- 1
- 1