Why should I prefer one or another in practice?
What are technical differences except that std::thread
is a class?
相关问题
- Sorting 3 numbers without branching [closed]
- How to compile C++ code in GDB?
- Why does const allow implicit conversion of refere
- thread_local variables initialization
- What uses more memory in c++? An 2 ints or 2 funct
相关文章
- Class layout in C++: Why are members sometimes ord
- How to mock methods return object with deleted cop
- Which is the best way to multiply a large and spar
- C++ default constructor does not initialize pointe
- Difference between Thread#run and Thread#wakeup?
- Selecting only the first few characters in a strin
- Java/Spring MVC: provide request context to child
- What exactly do pointers store? (C++)
For me the deciding technical difference is the absence of signal handling primitives in std as opposed to pthreads. The inability to properly dictate signal handling in a Unix process using std alone is AFAIK a debilitating flaw in the use of std::thread as it bars one from setting up the bona fide multi-threaded signal handling pattern to process all signals in a dedicated thread and block them in the rest. You are forced to assume std::thread is implemented using pthreads and hope for the best when using pthread_sigmask. Handling signals properly is non-negotiable in Unix systems programming for the enterprise.
As at 2016, std::thread is a toy; simple as that.
If you want to run code on many platforms, go for Posix Threads. They are available almost everywhere and are quite mature. On the other hand if you only use Linux/gcc
std::thread
is perfectly fine - it has a higher abstraction level, a really good interface and plays nicely with other C++11 classes.The C++11
std::thread
class unfortunately doesn't work reliably (yet) on every platform, even if C++11 seems available. For instance in native Androidstd::thread
or Win64 it just does not work or has severe performance bottlenecks (as of 2012).A good replacement is
boost::thread
- it is very similar tostd::thread
(actually it is from the same author) and works reliably, but, of course, it introduces another dependency from a third party library.Edit: As of 2017,
std::thread
mostly works on native Android. Some classes, likestd::timed_mutex
are still not implemented.The
std::thread
library is implemented on top of pthreads in an environment supporting pthreads (for example: libstdc++).I think the big difference between the two is abstraction.
std::thread
is a C++ class library. Thestd::thread
library includes many abstract features, for example: scoped locks, recursive mutexes, future/promise design pattern implementations, and more.std::thread
provides portability across different platforms like Windows, MacOS, and Linux.As mentioned by @hirshhornsalz in the comments below and related answer https://stackoverflow.com/a/13135425/1158895,
std::thread
may not be complete on all platforms yet. Even still, (it will be in the near future) it should be favored overpthread
's because it should make your application more future-proof.The OpenMP
http://www.openmp.org/
is a standardized, SMP based multithreading standard that has been working on Linux and Windows for over a decade already. The OpenMP is available by default with all compilers, including GCC and Microsoft Visual Studio.
One thing to watch out for, when using the OpenMP, is that if there are more threads than there are CPU-cores, then the performance will go down due to the context switching related overhead. The second thing to keep in mind is that the initialization of an actual, operating system level, thread is relatively expensive. The initialization is a fraction of a second, but in some applications the very small fractions accumulate to a considerable expense.
For software architecture requirements related concurrency You may want to search for some implementation of "lightweight threads" or "green threads" in stead of using the OpenMP. The difference is that the OpenMP threads are actual, operating system level, threads, but the "green threads" can be just "simulated threads" that are executed by using some small number of real threads.