GCCs Verhalten mit std :: async (std :: launch :: async) vs. Clangs Verhalten

8

Hat jemand Erfahrung mit dem ziemlich neuen std::async ? Wir implementieren derzeit einen parallelen Dateiparser, der einen Dateiblock liest und diesen Chunk an eine asynchrone Funktion übergibt.

Mit Clang (v3.0) funktioniert diese Methode sehr gut mit den standardmäßigen std::async -Richtlinien (implementierungsabhängig). Auf einem Zweikerngerät werden bis zu 4 Threads ausgelöst, was sehr gut funktioniert.

Aber mit GCC (v4.7) erzeugt der Dateilese-Thread keine neuen Threads, wodurch das Programm am Ende vollständig sequenziell wird.

Mit std::launch::async machen beide Versionen ziemlich genau dasselbe (was der Fall sein sollte).

Kennt jemand den aktuellen Stand der C ++ 11 Threading-Fähigkeiten von GCC? Oder könnte dies ein Fehler in unserer Implementierung sein?

Kurzcode:

%Vor%     
Bouncner 07.04.2012, 23:35
quelle

3 Antworten

15

Das Verhalten ist innerhalb der Spezifikation, auch wenn es nicht das ist, was Sie wünschen. Wenn Sie keine Start-Richtlinie angeben, wird sie als async|deferred interpretiert, was bedeutet, dass die Implementierung selbst entscheiden muss. GCC wählt immer deferred , wenn eine Auswahl getroffen wurde.

    
ephemient 08.04.2012, 02:20
quelle
5

EDIT2: Ich werde ein bisschen mehr erklären.

std :: async verspricht eine Zukunft; das heißt: wenn du es willst, wird es da sein. Es kann jetzt berechnet werden, es kann berechnet werden, wenn Sie danach fragen, wir versprechen nur, dass es passieren wird.

Wie das Poster unter mir bemerkt, ist GCC standardmäßig zurückgestellt (was bedeutet, dass es dieses Versprechen erfüllen wird, wenn es darum gebeten wird, und wahrscheinlich nicht vorher). Der Grund für diese Standardeinstellung liegt darin, dass GCC noch keine ordnungsgemäße C ++ 11-Threading-Unterstützung bietet. Es hat keinen guten internen Thread-Scheduler, neben vielen anderen Dingen. Es ist ein bisschen wie ein Hack. Nein, eher wie ein Haufen Hack. In der Tat, wenn Sie in C ++ 11 Thread-Code in GCC schreiben, ist es eher so, dass wenn sie Features implementieren, es richtig funktioniert; Gerade jetzt funktioniert es meistens richtig. Ich meine, du bekommst das Ergebnis am Ende, oder?

Wenn Sie ihm sagen, dass er einen Thread starten soll, wird es, weil es zu dumm ist (im Moment) zu erkennen, dass er es selbst tun kann und sollte (im Gegensatz zu CLang, das momentan einen besseren internen Thread-Scheduler hat).

EDIT: Ernsthaft? Fehlinformiertes Down-Modding!

Hier ist meine Referenz! Ссылка . Beachten Sie, dass fast alles unter 'Nebenläufigkeit' einschließlich 'Speichermodell' als NEIN notiert wird. GCC.GNU.org. Sie sind die Autorität auf GCC Sie wissen.

Leicht bearbeitet von meinem Kommentar:

Ich würde wirklich Boost empfehlen. Es wird kein großer Sprung zur richtigen C ++ 11-Unterstützung sein, wenn GCC bereit ist. Die neuen Threading-Modelle in C ++ 11 erfordern ein anderes Speicherlayout als GCC oder MSVC und sind noch nicht wirklich implementiert.

    
std''OrgnlDave 07.04.2012 23:50
quelle
1

Ich verstehe also, dass dies zwei Jahre später ist, aber ich kann nicht anders, als das Bedürfnis zu haben, auf @std''OrgnlDaves Kommentar über GCC vs. CLang zu antworten, um darauf hinzuweisen, dass zumindest derzeit, Jan. 2015, beide klingeln Version 3.5 und GCC Version 4.9 haben genau das gleiche Verhalten. Dieses Verhalten wird, wenn keine Startrichtlinie bereitgestellt wird, standardmäßig abweichend sein und ausgeführt werden, wenn future :: get aufgerufen wird, und nur wenn die Async-Startrichtlinie explizit bereitgestellt wird, führt entweder der Compiler zur Ausführung der Funktion im Hintergrund.

    
Steve Thibault 07.01.2015 21:17
quelle

Tags und Links