C++11 std::threads vs posix threads
C++MultithreadingC++11PthreadsC++ Problem Overview
Why should I prefer one or another in practice?
What are technical differences except that std::thread is a class?
C++ Solutions
Solution 1 - C++
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 - C++
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 - C++
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 - C++
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.