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