C++11 thread implementation backend

Question

Possible Duplicate:
In g++ is C++ 11 thread model using pthreads in the background?

I have read from somewhere that OpenMP is implemented using PThreads in Linux systems although they seem quite different to me. Considering the (relative) similarities between C++11 threads and PThreads I was wondering,

Does anyone know if C++11 threads implemented using PThreads or any other multithreading library in gcc or clang?

OpenMP and PThreads can be mixed together but they are two different things. You should have a look there http://stackoverflow.com/questions/3949901/pthreads-vs-openmp and there http://stackoverflow.com/questions/7433685/mixing-openmp-with-pthreads. — ForceMagic, Oct 09 '12 at 20:51
With regards to you remark about OpenMP and pthreads. OpenMP is just a set of syntax and semantics to describe how to thread an application. pthreads is a library that actually gives the means to thread an application. — CrazyCasta, Oct 09 '12 at 20:51
Yes, libg++ uses pthreads. I recall having to link to it when compiling. — Pubby, Oct 09 '12 at 20:52
@CrazyCasta that's exactly what I mean. As far as I understand `C++11` is just a set of syntax and semantics so I was wondering how they went to implement it. — none, Oct 09 '12 at 20:53
Well, you said "...although they seem quite different to me." wrt OpenMP and pthreads, so I just wanted to clarify that one is a description (OpenMP) and the other is the implementation (pthreads). However similar/different they may seem, the connection is only that pthreads is being used to implement OpenMP. — CrazyCasta, Oct 09 '12 at 20:56
@CrazyCasta oh I meant the difficulty of mapping OpenMP to pthreads. If they have done that succesfully, it should be much easier to map C++11 threads to pthreads. that question you linked is a duplicate btw, sry I missed that one. we can leave the question open though in case someone want to discuss this for clang. — none, Oct 09 '12 at 21:02
So you want to use std::thread for your threads but then use pthread to muck around with the internals? Sounds like a bad idea to me. If gcc were to every change what they use or how they expose the connection to pthreads your code might die. Whereas if you just use pthreads for everything, you'll be fine unless pthreads makes what would be considered a **major** change. — CrazyCasta, Oct 09 '12 at 21:08
@CrazyCasta I never said I want to muck around or anything. I don't understand what you mean.. — none, Oct 09 '12 at 21:13
@CrazyCasta - But note that `std::thread::native_handle_type` was introduced precisely for this kind of mucking... — rodrigo, Oct 09 '12 at 21:16
@rodrigo Perhaps the POSIX standard requires (or will require) that `native_handle()` return a pthread id. However, based on the C++ standard, gcc could decide that they need a tidbit more information than just the pthread id and change the `native_handle_type` to be some class/struct that include a bit more data and then the pthread handle. — CrazyCasta, Oct 09 '12 at 21:21
@gokcehan Perhaps I am confused then. I was assuming that you wanted to know the underlying implementation so that you could do something more with it (i.e. change the priority or affinity for instance). — CrazyCasta, Oct 09 '12 at 21:23
@CrazyCasta Actually I was just planning to use helgrind on it. Since it supports pthreads, it may be possible that it also supports C++11 thread indirectly. I wouldn't dare tingling the code =P — none, Oct 09 '12 at 21:39
@gokcehan Ah, I got confused when you said "mapping" wrt openmp/pthreads/std::thread. I thought you were referring to getting a pthread id from an openmp/std::thread, but now I understand you meant mapping as in "implementing with pthreads". So yes, this was all silly dialog :P (silly on my part) — CrazyCasta, Oct 09 '12 at 21:43
@CrazyCasta: I think that the intention and rationale of `native_handle()` is to return the most simple value that can be used as a handle for the thread implementation in use. It is not explicitly required to be anything, but I think it is safe to assume that _if_ pthreads are used then `native_handle_type` will be `pthread_t` (and if Windows threads, then it will be a `HANDLE`, and so on). — rodrigo, Oct 09 '12 at 22:32

score 1 · Accepted Answer · edited Oct 09 '12 at 21:17

There are multiple parts of C++ 2011 multi-threading:

Higher-level abstractions like std::thread, std::mutex, std::condition_variable, etc. These abstractions are implemented in terms of pthreads for both libc++ (clang's native library) and libstdc++ (gcc's native library). libstdc++ uses an indirection (gthr.h) which can be used to, e.g., stub things out for a single threaded implementation. This is quite obvious from the source of the different synchronization classes.
The lower-level synchronization facilities, i.e., atomics and the various memory visibility controls, are not available from pthreads. It seems both gcc and clang implement these using compiler build-ins which probably create suitable instructions. I haven't tracked down the actual code for either of these, however.
It isn't sufficient to implement things in the library: the compiler needs to be prevented from reordering instruction across synchronization primitives and it needs to make values visible in appropriate locations.

C++11 thread implementation backend

1 Answers1

Linked