2014-11-19 17 views
12

Ich lese http://olk.github.io/libs/fiber/doc/html/ Es scheint mir, dass mit Boost.Fiber C++ näher an Erlangs Fähigkeit kommt, Tausende von "Prozessen" zu haben, auch bekannt als "grüne Prozesse [Threads]" http://en.wikipedia.org/wiki/Green_threads.Mit Boost.Fiber kommt C++ dem Erlang-Style-Prozess/den Threads einen Schritt näher?

Meine Frage ist, ist Boost.Fiber bereit für die Produktion, gibt es jetzt C++ Alternativen, die bessere Dokumentation und Beispiele haben? Jemand erwähnte leichte Threads, aber ich finde keinen Hinweis darauf. Eine letzte Frage ist, warum enthält der C++ - Standard keine Fasern?

Der Grund, warum ich daran interessiert bin, ist, weil ich Echtzeit-Updates habe, bei denen eine Wertänderung Hunderte von kleinen, aber peinlich parallelen Berechnungen bewirken kann (spawnt). Das C++ - Thread-Modell funktioniert nicht sehr gut, imo. Bitte keine GPU, da es momentan zu lange dauert, die Informationen von und zur GPU zu übertragen.

Ich weiß, dass Erlang viel mehr ist als das, also erziehe mich bitte nicht über Erlang vs C++ im allgemeinen Fall.

+0

Wirklich das ist ein Problem mit der Planung und Kontextwechsel: http://www.linuxplumbersconf.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf – Ivan

Antwort

13

Boost.Fiber wurde von der Boost-Community im Januar 2014 überprüft und es wurde festgestellt, dass es erhebliche zusätzliche Arbeit erfordert. Sehen Sie die Ergebnisse der Community-Review unter http://lists.boost.org/boost-announce/2014/01/0393.php.

C++ 17 sucht auch nach einem WinRT-ähnlichen M: N-Threading-Modell, das auf fortsetzbaren Funktionen basiert und das vorgeschlagene hawn-Schlüsselwort verwendet. Microsoft hat Unterstützung in ihrem Compiler implementiert, und abgesehen von magischen Speicherzuordnungstricks für Futures sieht es sehr vielversprechend aus. Das relevante N-Papier ist N4134 (http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4134.pdf), und wie Sie sehen werden, würde diese Formulierung von wiederaufsetzbaren Funktionen tatsächlich eine Erlang-Typ-Skalierbarkeit bereitstellen, selbst wenn die Syntax ein wenig stumpf ist (hey, es ist C++, wenn seine Syntax jemals einfach ist) !).

Wenn Sie jetzt eine portable Lösung benötigen, gehen Sie entweder die stackless Coroutroute mit ASIO (Vorsicht: spröde) oder feinkörnige ASIO-Handler mit ASIO-Strängen, die eine Klasseninstanz als Ausführungsstatus verwenden Gleiche oder sonst Boost.Fiber. Wenn Sie nur das Windows benötigen, würde ich mit Microsofts proprietären Erweiterungen voranzutreiben selbst, sie sind sehr anders als sie zu verlassen, wenn sie nicht im Stich lassen WinRT :)

Edit: Der Autor von Boost.Fiber sagt mir, dass ab Januar 2015 sind die von der Community Review empfohlenen Änderungen abgeschlossen und abgesehen von Dokumentationsverbesserungen gilt Fiber als bereit für die Aufnahme in den offiziellen Boost. Wenn dies tatsächlich der Fall ist, dann ist Fiber wahrscheinlich die beste Lösung, bevor die offizielle C++ 17-Sprachenunterstützung für endgültige fortsetzbare Funktionen in Compilern erscheint.

+0

Danke. Das ist hilfreich und interessant. Eine Sache, die ich bemerkt habe, ist, dass zuerst C++ 14/17 zuerst den Begriff der Parallelität implementieren muss, um diese Begriffe zu implementieren. Macht also std :: erwarten Sinn ohne std :: thread oder std :: threadpool? – Ivan

+0

@Ivan: Sie haben den Nagel auf den Kopf getroffen, dass das Komitee entscheidet, welches Parallelitätsmodell verwendet werden soll. Ich würde sagen, dass sie derzeit geteilt sind, mit Hartmut (über HPX) und Microsoft über WinRT, die ein M: N-Threading-Modell verwenden, wobei M Kernel-Threads und N Coroutinen sind. Auch, weil die Concurrency-Studiengruppe nur eine Meinung hat, bedeutet das nicht, dass sie das Komitee notwendigerweise überzeugen werden, obwohl, wenn wir sagen, Clang und MSVC beide die experimentelle Compiler-Unterstützung implementieren, würde ich sagen, dass dies die Diskussion besiegeln würde. –

+0

@Ivan: In Bezug auf erwarten (nicht std :: erwarten, wird ein Schlüsselwort sein) erfordern std :: thread, der aktuelle Plan ist, dass es ein zukünftiges und Thread-Konzept (erinnern Konzepte sind in C++ 17), und wenn Ein Typ erklärt sich selbst als Implementierung des Konzepts, dann akzeptiert der Compiler das theoretisch. Daher sollte boost :: thread genauso mit "erwarten" funktionieren wie std :: thread, ähnlich wie boost :: future vs std :: future. –