C++11 std::thread vs Posix threads

Question

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

Unwearied

In practise you should use std::async – Frizzell

@bamboon This suffers from the same problems as std::thread does – Rules

@hirschhornsalz from compiler-support view, yes. from a technical viewpoint it offers exception safety, which std::thread or pthreads don't. – Frizzell

#1274072 – Altman

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.

Rules

Do you have any evidence to back up these "performance bottleneck" claims? Also, std::thread and its raii-style is good because it can handle C++ exceptions while pthreads cannot out of the box. – Confab

@JesseGood My chess engine runs much slower when compiled for windows 64. While std::thread itself seems to run ok, related classes like std::condition_variable and std::mutex use up a lot more of time. The contention is low - in linux almost not measurable. I used gcc-4.7.* – Rules

@JesseGood For android, the decision finding is much simpler: std::thread just does not work at all . But hopefully this may change soon. – Rules

@JesseGood I totally agree that from the development POV std::thread is to be preferred - it has a much better abstration and plays very nicely with other thread related classes in C++11, like mutexes or even std::chrono. That and the "portability" was the reason I used it in the first place, only to get bitten quite a few times when it comes to actual porting. – Rules

Did you use mingw version of std::thread? Compared to MSVC I would expect a performance hit because they use a port of pthreads, but MSVC should be okay. – Confab

Yes, mingw. I too suspect the performance bottleneck somewhere in the WinThread/pthread/std::thread wrappers. – Rules

@user457015 I don't know. I would like to believe that my answer is supported by "facts, references, or expertise", but the mods don't seem to think so. – Rules

@Serthy at least to a certain degree - I'm wrestling with cross-compiling a simple program ( https://mcmap.net/q/136838/-issue-using-std-atomic_flag-with-worker-thread ) It works in my happy gcc/linux environment but when I go to compile for ARMv7 the application terminates instantaneously. pthreads are a pain in the butt compared to std::thread, but this answer nails it on the head with, "If you want to run code on many platforms, go for Posix Threads" – Sibilla

Use std::thread now and forever. It's cross platform and as another answerer said it's future proof and does not suffer from performance bottlenecks. – Afterward

One of us should update the answer directly to state exactly how the compatibility of std::thread fares today. Afaik it does really really well (eg, works perfectly for me with Win64) and I'd personally recommend std::thread in general first these days, but unfortunately nowhere near an expert on compatibility – Ostyak

std::thread works on Windows just fine since 2015. On the contrary, POSIX threads in VC++ do not exist. – Immersed

@GuntherPiez There are quite a few features supported in c++20, could you please update the answer and also suggestion about various platforms performances (in case you tried it)? – Alice

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.

Airbrush

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://mcmap.net/q/134648/-c-11-std-thread-vs-posix-threads, 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.

Licastro

actually, std::threads provides portability across all platforms that support C++11, whereas POSIX threads is only available on POSIX platforms (or platforms that strive for some minimal compatability). – Rose

From the practical POV this is just wrong. I actually decided a few month ago on this reasoning - it was a major mistake. In practice you have to use boost::thread on Win64 or Bionic (Android), because std::thread is still lacking big parts, where on Linux std::thread seems quite mature. – Rules

To summarize, c++11 std::thread is usable only with recent versions of GCC. It is not nearly complete in Visual Studio, therefore not usable on Windows. And of course it is absolutely missing in commercial compilers on UNIXes (Sun Studio on Solaris, HP aCC on HP-UX, IBM vacpp on AIX). Therefore, if your target platform is Linux only - c++11 std::thread is fine; if you also need Windows or other UNIX - boost::thread is the way to go. – Disallow

"std::thread provides portability across different platforms like Windows, MacOS, and Linux." as pthread – Closed

"may not be complete on all platforms yet" - that statement was made 11 years ago. – Saccharoid

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.

Gascony

I disagree. And heavy use of signals is a design pattern that can be avoided for most applications. – Gullett

Also, std::thread brings type safety that pthread doesn't have. – Fara

Answer 5

I just found that std::thread imposes a limit on the number of threads that POSIX threads doesn't have. It seems that the thread creation in C++ checks a systemd property named DefaultTasksMax, that is not checked by Posix libpthread.

I will soon update this answer with snippets in C++ and C that seem to prove this point.

Honour

where is your soon :< – Outfitter