Does Windows std::thread uses internally PPL?

Question

Is the implementation of Visual Studio 2015's std::thread internally based on PPL's task system?

The background of my question is, does it make sense to use std::thread for several tasks, because they are already executed balanced on the common threadpool, or is it better to execute the tasks via PPL tasks?

According to (Which std::async implementations use thread pools?) this seems to be, but since the question is rather old I would like to get an "official" answer.

Counterpoint

It uses the same foundation as PPL, the concurrency runtime. It is an (almost) complete replacement of the OS primitives, focus was on getting better scaling on many-core CPUs. And I suspect the somewhat idle hope that it will be ported some day. It is not a great joy to debug btw. std::thread is a rather bare class, use PPL for what it adds. Like a threadpool, parallel_for, etcetera. – Weatherboarding

Answer 1

Yes and No.

for std::thread:
std::thread constructor (thread file) calls
_Launch (xthread file) which calls
_Thrd_startX (xthread file) which calls
_Thrd_start(cthread.c file) which calls
_beginthreadex (cthread.c file).

I don't have _beginthreadex code, but in the file atlbase.h, some microsoft developer left the following comment :

// _beginthreadex calls CreateThread which will set the last error
// value before it returns.

so no PPL involed.

But, std::async calls concurrency::create_task behind the scens, and then it will use the windows API based thread pool.

The background of my question is, does it make sense to use std::thread for several tasks...?

I have used Casablanca which uses PPL. I also played with PPL as standalone.
I don't like it at all performance wise. my own threadpool + std::future + std::promise were literally houndered times faster than concurrency::task objects. It is really falls short against the C# version TPL. I would only use it if performace does not matter for that project.

Bullroarer

Answer 2

From the horse's mouth :

We’ve reimplemented the STL’s multithreading primitives to avoid using the Concurrency Runtime (ConcRT). Using ConcRT was a good idea at the time (2012), but it proved to be more trouble than it was worth. Now we’re using the Windows API directly

IIRC, PPL was also based on ConcRT, but that doesn't mean that the Standard Library was built on top of PPL. They existed side by side. See this question for a stacktrace that captures ConcRT underneath std::thread. No PPL in sight.

Horaciohorae