This question already has answers here:
Is it smart to replace boost::thread and boost::mutex with c++11 equivalents?
(7 answers)
Closed 9 years ago.
What are the advantages/disadvantages of using the C++11 multithreading classes versus the ones found in Boost? I will only be using Linux so I do not require portability. Is there a lack of features in one of the libraries? Any known limitations? Better syntax?
Standard threads have the advantage of being standardised, therefore portable to any compliant implementation.
The Boost thread library is more or less identical; the standard library was based on that library, and there has been an effort to make Boost a conformant implementation of the standard. It has a few extensions which might be useful, including:
join with timeout
thread interruption
thread groups
extra lock types
In general, boost classes are only wrappers around functions/objects that exist in given OS. Their main advantage is that boost contains versions written for most operating systems, hence the wrapper provides portability the original functions/objects sometimes do not.
If there is nothing else your need from boost I would strongly suggest using standard C++11 threads.
Reasons:
boost will not provide more than the system allows for
your code will not have any wrapper overhead (however small it may be)
boost support for c++11 threads is a new feature and I would fear that it could introduce some errors in the boosts' implementation
you will not have to rely on boost libraries and will save yourself time compiling and linking them, etc.
you will not have to update boost, because you will not be using it
Of course, boost has some pros also:
many people know boost and the code will (possibly) be easier to read
if you decide you need to port the code you may have an easier time (though C++11 is standard, so somewhere down the line all compilers will implement it)
Related
For what purpose may synchronization primitives and containers from Boost library be needed if the project uses C++ 11/14/17 in which there are already containers and synchronization primitives?
I know that Boost.asio is usually used in work with the network, Boost.spirit - usually for parsing of text. Do you know about the usual purpose of the other parts of Boost?
This question is from the C++ interview.
Boost is older than C++ 11 so many synchronization priminitives were there before they made it to the standard. This was feasible because the OSes already contained thread and synchronization functions so boost could wrap around them.
That said, at this point the C++ standard allows for trivial threading/synchronization. It's adequate for the average C++ developer. In complex sync scenarios you might need some boost-enhanced libraries, or even OS-dependant APIs, for example in Windows, WaitForMultipleObjects().
What is the real difference between std::mutex and boost::mutex? Which one is faster in terms of implementation and compilation? Are both of them portable?I read my questions related to it but there is no clear mention of difference . std mutex is supported only since c++11 so the older compilers dont support it . Are boost mutex supported by older compilers or not? If the foremost condition requires the code to be portable , then what should be prefered?
As a default choice you should prefer std::anything to boost::samething because it's a part of standard library and hence is more portable since it doesn't introduce external dependency.
You can't really compare std::mutex and boost::mutex in general because there is no one and only std::mutex, it's implementation depends on the standard library implementation that you are using which usually is a part of your toolchain.
There might be a case when you discover using empirical evidence that std::mutex you are using is in some regard "worse" than boots::mutex. In this case it might be reasonable to switch to it, but only if it's really justified and you have an actual evidence (e.g. performance measurement) of that. Even then it seems like a last resort. It might be better to switch to a different standard library implementation or to a different toolchain or upgrade your current one if possible.
Consider boost as a laboratory for prototyping std features. Many std facilities were originally implemented on boost. The difference is that std takes care of consistency and forward compatiblity, while boost targets new horizons. Nothing prevents boost from applying breaking changes in forth coming versions, but it also provides answers to more questions than std. My personal preference is std first - when possible - and boost next - when needed. I generally avoid pre c++11 platforms, unless I am forced to face.
# std::mutex for me every time, for the reason #Henri states it is (obviously) part of the C++ standard so you can rely on it being available everywhere.
Using boost, on the other hand, means that you have to link against the boost library. While this is widely available and offers a number of handy extra features it's quite heavyweight and you wouldn't want to pull it in just for this.
Also, std::mutex may be faster. The cross-platform nature of boost means that things that rely on OS support (which would include mutexes) can sometimes be less efficient. But this would not be a major factor in my thinking.
But if measuring performance is important to you, you should run your own benchmark. You can do this (roughly) over at (say) Wandbox - they support the boost library there.
The focus of Boost is trying new techniques and introducing new capabilities. The focus of the C++ standard is specifying requirements in a way that (in most cases) can be implemented portably. A number of features from boost have found their way into the C++ standard, but were often changed quite a bit in that transition - to improve portability, sometimes improve reliability, etc.
If your implementation (compiler and library) is C++11 or later, and you intend to not to port to older implementations, then definitely use std::mutex. It is part of the standard, from 2011, so preferable. No need to rely on third-party libraries. You will only need boost if you need bleeding edge features of boost that the C++ standard does not support (which means things other than mutex).
Some exceptions to the above: there are some features of boost (including related to threading and mutexes) that haven't made their way into a C++ standard, and some features in the C++ standard that are not in boost.
If you need to use (or support or port to) an older implementation, then consider using boost::mutex. You will, in most cases, need to install a version of boost separately, with your chosen implementation (some compiler versions have shipped with a version of boost, but don't rely on it). If there isn't a version of boost that works with your compiler/library, then (to state the obvious) you will not be able to use boost::mutex.
Boost has had the thread library (which includes mutex) since about version 1.25.0, which dates from late 2001. Which suggests boost is an option if your compiler is no older than (rough guess) early 2000s.
If you need to support an implementation that is significantly older than the early 2000s, then you may be out of luck using boost::mutex, and will need to resort to other libraries/frameworks or get your hands dirty writing OS-specific code.
This question already has answers here:
Is there any cross-platform threading library in C++?
(12 answers)
Closed 8 years ago.
C++11's threading library is wonderful looking. It's small, simple, standard, and portable. Unfortunately, I'm locked to Visual Studio 2010 which obviously doesn't have that available to it.
My questions are, what multi-threading libraries are available that provide a similar level of functionality, while being portable and reliable? Is it possible (physically and legally) to obtain the corresponding <thread> library to use in VS2010? Are there disadvantages to using a separate library (maybe not as actively maintained since C++11 fills that role, etc)?
First, take a look on wikipedia list of C++ multi-threading libraries. Some very well documented library can by POCO C++. However, you can also see related question Is there any cross-platform threading library in C++?.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
In g++ is C++ 11 thread model using pthreads in the background?
I have read from somewhere that OpenMP is implemented using PThreads in Linux systems although they seem quite different to me. Considering the (relative) similarities between C++11 threads and PThreads I was wondering,
Does anyone know if C++11 threads implemented using PThreads or any other multithreading library in gcc or clang?
There are multiple parts of C++ 2011 multi-threading:
Higher-level abstractions like std::thread, std::mutex, std::condition_variable, etc. These abstractions are implemented in terms of pthreads for both libc++ (clang's native library) and libstdc++ (gcc's native library). libstdc++ uses an indirection (gthr.h) which can be used to, e.g., stub things out for a single threaded implementation. This is quite obvious from the source of the different synchronization classes.
The lower-level synchronization facilities, i.e., atomics and the various memory visibility controls, are not available from pthreads. It seems both gcc and clang implement these using compiler build-ins which probably create suitable instructions. I haven't tracked down the actual code for either of these, however.
It isn't sufficient to implement things in the library: the compiler needs to be prevented from reordering instruction across synchronization primitives and it needs to make values visible in appropriate locations.
Which way is better for a novice student who has never used boost?
When a new standard arrives, the answer will be obvious, but now I have doubts. Pro for boost is that it's much closer to future standard.
Another pro for Boost is that it uses common C++ idioms for describing, initializing, running, and joining threads (using idioms like RAII and allowing the use of functors and similar C++-specific tools).
Lower-level libraries like APR rely on the use of C-like idioms, which for a C++ developer can prove to be more error-prone (such as the use of function pointers).
In my opinion, Boost::Thread is easier to use because it allows me to use the C++ idioms that I use elsewhere in my code. With APR, I may as well be using pthreads.
As boost::thread can be seen as the draft for the comming standard library implementation of threads, using it and maybe replace it by std::thread in some years might be the best thread library to know first.