boost::thread and std::thread compatibility issues?
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()
.