But let's turn things over: why not use pthread instead of creating another API? I think it is clear that using pthreads has a few advantages. What is the drawback?
RAII?
If the response is "API on top of pthreads" then why discuss pthreads at all?
Here is how I understand your question: does it make sense to formalize a lower level API behind <thread>. If we lived in a world where pthreads did not exist, I wouldn't care much one way or another; but we don't. So I think you're asking the wrong question. I think it's more appropriate to ask ourselves: 1) Given that pthreads is already a very solid formal standard, and given that there is a lot of legacy code already written for it, does it make sense to also formally standardize it as the abstraction layer of the C++ <thread> support? 2) Does adopting pthreads as the standard lower level abstraction of the C++ <thread> layer make it in any way harder to implement the C++ <thread> layer, compared to an implementation that does not formalize a lower level interface? 3) Does a formal pthread layer introduce any overhead in the higher level C++ <thread> layer? In particular we need to examine the answer to 2) and 3) wrt the Windows <thread> implementation, since on Posix the answer is clear. Emil Dotchevski