186

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

Ajay
  • 18,086
  • 12
  • 59
  • 105
Shamdor
  • 3,019
  • 5
  • 22
  • 25

4 Answers4

138

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.

Gunther Piez
  • 29,760
  • 6
  • 71
  • 103
  • 23
    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. – Jesse Good Oct 30 '12 at 10:29
  • @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 Oct 30 '12 at 11:22
  • @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 Oct 30 '12 at 11:24
  • @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. – Gunther Piez Oct 30 '12 at 11:28
  • 2
    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. – Jesse Good Oct 30 '12 at 21:17
  • Yes, mingw. I too suspect the performance bottleneck somewhere in the WinThread/pthread/std::thread wrappers. – Gunther Piez Oct 30 '12 at 21:34
  • @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. – Gunther Piez Jul 12 '13 at 08:57
  • 3
    @Serthy at least to a certain degree - I'm wrestling with cross-compiling a simple program ( http://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" – darkpbj Jun 17 '15 at 16:13
  • 4
    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. – KeyC0de Sep 25 '19 at 11:19
  • 1
    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 – DragonJawad Aug 04 '20 at 12:44
  • 6
    `std::thread` works on Windows just fine since 2015. On the contrary, POSIX threads in VC++ do not exist. – rustyx Aug 27 '20 at 10:06
  • @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)? – Milind Deore Nov 13 '20 at 07:09
74

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.

sbi
  • 219,715
  • 46
  • 258
  • 445
Akira Takahashi
  • 2,912
  • 22
  • 107
40

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.

Community
  • 1
  • 1
Brady
  • 10,207
  • 2
  • 20
  • 59
  • 2
    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). – Tobias Langner Oct 30 '12 at 07:28
  • 2
    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. – Gunther Piez Oct 30 '12 at 08:39
  • 4
    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. – vond Oct 30 '12 at 09:46
  • "std::thread provides portability across different platforms like Windows, MacOS, and Linux." as pthread – user457015 Jan 19 '14 at 15:53
12

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.

Waslap
  • 572
  • 3
  • 23