C++11 std::threads vs posix threads

Question

Why should I prefer one or another in practice? What are technical differences except that std::thread is a class?

Answer 1

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 Android std::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 to std::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, like std::timed_mutex are still not implemented.

Answer 2

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. The std::thread library includes many abstract features, for example: scoped locks, recursive mutexes, future/promise design pattern implementations, and more.

Answer 3

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 over pthread 's because it should make your application more future-proof.

Answer 4

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.

Answer 5

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.