C++11 std::threads vs posix threads

c++ multithreading c++11 pthreads

106,145

Solution 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.

Solution 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.

Solution 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.

Solution 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.

View more solutions

106,145

Shamdor

Updated on July 08, 2022

Comments

Shamdor almost 2 years

Why should I prefer one or another in practice? What are technical differences except that std::thread is a class?
- Stephan Dollberg over 11 years
  
  In practise you should use std::async
- Gunther Piez over 11 years
  
  @bamboon This suffers from the same problems as std::thread does
- Stephan Dollberg over 11 years
  
  @hirschhornsalz from compiler-support view, yes. from a technical viewpoint it offers exception safety, which std::thread or pthreads don't.
- Ciro Santilli OurBigBook.com almost 9 years
  
  stackoverflow.com/questions/1273572/…
Tobias Langner over 11 years

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).
Gunther Piez over 11 years

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.
vond over 11 years

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.
Jesse Good over 11 years

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.
Gunther Piez over 11 years

@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.*
Gunther Piez over 11 years

@JesseGood For android, the decision finding is much simpler: std::thread just does not work at all . But hopefully this may change soon.
Gunther Piez over 11 years

@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.
Jesse Good over 11 years

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.
Gunther Piez over 11 years

Yes, mingw. I too suspect the performance bottleneck somewhere in the WinThread/pthread/std::thread wrappers.
Gunther Piez almost 11 years

@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.
user457015 over 10 years

"std::thread provides portability across different platforms like Windows, MacOS, and Linux." as pthread
darkpbj almost 9 years

@Serthy at least to a certain degree - I'm wrestling with cross-compiling a simple program ( stackoverflow.com/q/30893684 ) 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"
Erik Alapää over 7 years

I disagree. And heavy use of signals is a design pattern that can be avoided for most applications.
alfC about 6 years

Also, std::thread brings type safety that pthread doesn't have.
KeyC0de over 4 years

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.
DragonJawad almost 4 years

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
rustyx over 3 years

std::thread works on Windows just fine since 2015. On the contrary, POSIX threads in VC++ do not exist.
Milind Deore over 3 years

@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)?