Since boost is mainly just a wrapper around pthreads (on posix platforms) it helps to know what is going on underneath. In attempting to be generic, boost leaves the platform specific functionality unwrapped. In order to get to it you need to use the native_handle() calls.
Thread enables the use of multiple threads of execution with shared data in portable C++ code. The Boost. Thread library was originally written and designed by William E.
There are several differences between Boost.Thread and the C++11 standard thread library:
std::async
, but Boost does notboost::shared_mutex
for multiple-reader/single-writer locking. The analogous std::shared_timed_mutex
is available only since C++14 (N3891), while std::shared_mutex
is available only since C++17 (N4508).boost::unique_future
vs std::future
)std::thread
are different to boost::thread
--- Boost uses boost::bind
, which requires copyable arguments. std::thread
allows move-only types such as std::unique_ptr
to be passed as arguments. Due to the use of boost::bind
, the semantics of placeholders such as _1
in nested bind expressions can be different too.join()
or detach()
then the boost::thread
destructor and assignment operator will call detach()
on the thread object being destroyed/assigned to. With a C++11 std::thread
object, this will result in a call to std::terminate()
and abort the application.To clarify the point about move-only parameters, the following is valid C++11, and transfers the ownership of the int
from the temporary std::unique_ptr
to the parameter of f1
when the new thread is started. However, if you use boost::thread
then it won't work, as it uses boost::bind
internally, and std::unique_ptr
cannot be copied. There is also a bug in the C++11 thread library provided with GCC that prevents this working, as it uses std::bind
in the implementation there too.
void f1(std::unique_ptr<int>);
std::thread t1(f1,std::unique_ptr<int>(new int(42)));
If you are using Boost then you can probably switch to C++11 threads relatively painlessly if your compiler supports it (e.g. recent versions of GCC on linux have a mostly-complete implementation of the C++11 thread library available in -std=c++0x
mode).
If your compiler doesn't support C++11 threads then you may be able to get a third-party implementation such as Just::Thread, but this is still a dependency.
std::thread
is largely modelled after boost::thread
, with a few differences:
- boost's non-copyable, one-handle-maps-to-one-os-thread, semantics are retained. But this thread is movable to allow returning thread from factory functions and placing into containers.
- This proposal adds cancellation to the
boost::thread
, which is a significant complication. This change has a large impact not only on thread but the rest of the C++ threading library as well. It is believed this large change is justifiable because of the benefit.
- The thread destructor must now call cancel prior to detaching to avoid accidently leaking child threads when parent threads are canceled.
- An explicit detach member is now required to enable detaching without canceling.
- The concepts of thread handle and thread identity have been separated into two classes (they are the same class in
boost::thread
). This is to support easier manipulation and storage of thread identity.- The ability to create a thread id which is guaranteed to compare equal to no other joinable thread has been added (
boost::thread
does not have this). This is handy for code which wants to know if it is being executed by the same thread as a previous call (recursive mutexes are a concrete example).- There exists a "back door" to get the native thread handle so that clients can manipulate threads using the underlying OS if desired.
This is from 2007, so some points are no longer valid: boost::thread
has a native_handle
function now, and, as commenters point out, std::thread
doesn't have cancellation anymore.
I could not find any significant differences between boost::mutex
and std::mutex
.
Enterprise Case
If you are writing software for the enterprise that needs to run on a moderate to large variety of operating systems and consequently build with a variety of compilers and compiler versions (especially relatively old ones) on those operating systems, my suggestion is to stay away from C++11 altogether for now. That means that you cannot use std::thread
, and I would recommend using boost::thread
.
Basic / Tech Startup Case
If you are writing for one or two operating systems, you know for sure that you will only ever need to build with a modern compiler that mostly supports C++11 (e.g. VS2015, GCC 5.3, Xcode 7), and you are not already dependent on the boost library, then std::thread
could be a good option.
My Experience
I am personally partial to hardened, heavily used, highly compatible, highly consistent libraries such as boost versus a very modern alternative. This is especially true for complicated programming subjects such as threading. Also, I have long experienced great success with boost::thread
(and boost in general) across a vast array of environments, compilers, threading models, etc. When its my choice, I choose boost.
There is one reason not to migrate to std::thread
.
If you are using static linking, std::thread
becomes unusable due to these gcc bugs/features:
Namely, if you call std::thread::detach
or std::thread::join
it will lead to either exception or crash, while boost::thread
works ok in these cases.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With