Verwendet Windows Std :: Thread intern PPL?

Question

Ist die Implementierung des std :: -Threads von Visual Studio 2015 intern auf dem Task-System von PPL basiert?

Der Hintergrund meiner Frage ist, macht es Sinn, std :: thread für mehrere Aufgaben zu verwenden, weil sie bereits auf dem gemeinsamen threadpool ausgeglichen ausgeführt werden, oder ist es besser, die Aufgaben über PPL-Aufgaben auszuführen?

Laut (Which std::async implementations use thread pools?) scheint dies zu sein, aber da die Frage eher alt ist, würde ich gerne eine "offizielle" Antwort bekommen.

Answer 1

Ja und Nein

für std::thread:
std::thread Konstruktor (thread Datei) ruft
_Launch (xthread-Datei), die
_Thrd_startX (xthread Datei) ruft die
_Thrd_start (cthread.c Datei) ruft die Anrufe
_beginthreadex (cthread.c Datei).

Ich habe nicht _beginthreadex Code, sondern in der Datei atlbase.h, einige Microsoft-Entwickler verlassen den folgenden Kommentar:

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

so keine PPL involed.

Aber, std::async ruft concurrency::create_task hinter den Szenarien, und dann wird es die Windows-API-basierte Thread-Pool verwenden.

Der Hintergrund meiner Frage ist, macht es Sinn, std::thread für mehrere Aufgaben zu verwenden ...?

Ich habe Casablanca verwendet, die PPL verwendet. Ich habe auch mit PPL als Standalone gespielt.
Ich mag es überhaupt nicht leistungsfähig. mein eigener threadpool + std::future + std::promise wurde buchstäblich mal schneller abgehängt als concurrency::task Objekte. Es ist wirklich zu kurz gegen die C# Version TPL. Ich würde es nur benutzen, wenn Leistung für dieses Projekt nicht wichtig ist.

Answer 2

From the horse's mouth:

wir die Multithreading Primitiven des STL neu implementiert haben die Concurrency Runtime (ConcRT) zu vermeiden, mit. Die Verwendung von ConcRT war eine gute Idee unter der Zeit (2012), aber es erwies sich als mehr Mühe, als es wert war. Jetzt wir verwenden den Windows-API direkt

IIRC, PPL auch auf ConcRT beruhte, aber das bedeutet nicht, dass die Standardbibliothek wurde oben auf PPL gebaut. Sie bestanden Seite an Seite. Ein StackTrace, der ConcRT unterhalb von std::thread abbildet, finden Sie unter this question. Kein PPL in Sicht.