Multithreading. Paralleles Hello World. int main() { auto hello = [](auto tnum) { cout << "Thread " << tnum << " sagt Hello World\n"; };

Transkript

1 Multithreading Unter einem Thread versteht man eine Hardware-Ausführungseinheit, die ein Programmabarbeitet. Multithreading bedeutet demnach die parallele Ausführung von Programmteilen. Bisher haben wir (das ist die Standardeinstellung) jedes Programm nur durch einen Hauptthread ausführen lassen, der von C++ automatisch erzeugt wird. Dadurch beschäftigt sich jedoch nur ein Bruchteil der CPU, die 2-64 und mehr Hardware-Threads besitzt, mit dem Programm, der Rest führt andere Programme aus oder schläft. Wenn man das eigene Programm so aufteilen kann, dass mehrere Hardware-Threads zugleich daran arbeiten, könnte man theoretisch die Ausführungsgeschwindigkeit vervielfachen. Dazu ist es notwendig, den Code, der parallel verarbeitet werden soll, in eine Funktion (oder ein Lambda) zu packen, da die C++ Threadsbibliothek nur die Abarbeitung von kompletten Funktionen/Methoden/Lambdas unterstützt. Die Thread-Bibliothek ist derzeit noch etwas klein, vor allem ist man sich in der C++-Gemeinde noch nicht sicher, welcher Ansatz die besten Ergebnisse erzielen wird, sodass es derzeit mehrere konkurrierende Parallelisierungsverfahren gibt. Paralleles Hello World Betrachten wir einmal das Hello-World.cpp Programm mit einer Worker-Funktion (Lambda): hello(unsigned tnum) // kann von mehreren Threads aufgerufen werden hello(0); Das ist noch kein Multithreading, da das Lambda hello() nur vom einzigen Hauptthread ausgeführt wird. Nach dem Inkludieren von <thread> kann man das relativ leicht ändern. Mit dem Konstruktor aus der Threadbibliothek template<typename Function> std::thread(function&& f, ) erzeugt man einen neuen Thread, der f( ) ausführt und dann stoppt. Im Hauptprogramm steht dann:

2 thread thello, 1; t.join(); // erzeuge Thread t, der hello(1)abarbeitet // warte, bis t fertig ist Kompilieren muss man das mit der zusätzlichen Option pthread! Die Ausgabe ändert sich kaum (Thread 1... statt Thread 0...), aber der Ablauf ist ein ganz anderer: Der Hauptthread kreiert hier einen neuen Thread t, der sofort startet und die Funktion hello (das 1. Argument) mit den weiteren Argumenten aufruft (hier 1). Mit dem Verlassen der Funktion (des Lambdas) endet dieser Thread. Der Hauptthread wartet inzwischen in t.join() auf das Ende von t und macht dann alleine weiter. Das ist schon echtes Multithreading, obwohl man als Anwender nichts davon sieht. Der Hauptthread könnte natürlich nach der Erzeugung von t selbst auch etwas arbeiten und nicht nur auf das Ende von t warten: thread thello, 1; hello(0); t.join(); // schicke t an die Arbeit // arbeite selbst etwas // warte dann, bis t fertig ist Jetzt sieht man schon 2 Ausgaben. Das lässt sich schon noch steigern: Wir kreieren 20 neue Threads, die alle hello() aufrufen. Da man für alle Threads die join()-methode aufrufen muss (es gibt auch Alternativen, aber diese sind umständlicher), muss man alle Threads speichern. Das erledigt man am besten mit einem Container wie std::vector oder std::list und einer Schleife. Den Join macht man dann mit einem Range-based for.

3 std::vector<std::thread> meine_helferlein; for (unsigned i = 1; i <= 20; ++i) // 20 Threads z.b. meine_helferlein.push_back(threadhello, i); hello(0); // arbeite selbst etwas for (auto& t: meine_helferlein) // & ist wichtig!!!! t.join(); // warte auf das Ende aller Arbeiter Wer in Vorlesung 10 die Beispiele über das optimierte push_back() verstanden hat, würde obiges wesentlich effizienter programmieren: std::vector<std::thread> meine_helferlein; meine_helferlein.reserve(20); // reserviere den Platz vor for (unsigned i = 1; i <= 20; ++i) // emplace statt push meine_helferlein.emplace_back(hello, i); Hier sollte man schon das Hauptproblem des Multithreadings erkennen. Die Ausgabe könnte manchmal durcheinander sein, da die Threads um die Ausgabe auf den Bildschirm kämpfen und sich gegenseitig in die Quere kommen. Den Zugang zu einer gemeinsamen Ressource muss man manchmal exklusiv für sich reservieren, sonst könnten andere Threads dazwischenfunken. Hier gibt es keine optimale Universallösung, jede Situation erfordert unterschiedliche Techniken. Die 2 wichtigsten davon sind atomare Operationen und Locking-Mechanismen. Eine atomare Operation ist eine solche, die nicht von anderen Threads unterbrochen werden kann: z.b. ist der Aufruf einer Streamausgabe << atomar. Der Ausgabesalat entsteht nur, weil jeder Thread mehrere solcher Operationen machen will: cout << "Thread " << tnum << " sagt Hello World\n"; Das sind drei atomare Aufrufe (C-Stringliteral, Zahl, C-Stringliteral), aber zwischen diesen könnten andere Threads etwas ausgeben und so einen Ausgabesalat erzeugen. Die einfachste und schnellste Lösung in diesem Fall: Die Threads schreiben vorerst alles in einen privaten C++-String und geben diesen am Ende mit einer einzigen atomaren Streamausgabe auf std::cout aus. Das Schreiben in einen String erledigen wir mit einem std::ostringstream-objekt. auto hello = [](auto tnum) ostringstream oss;

4 ; oss << "Thread " << tnum << " sagt Hello World\n"; cout << oss.str(); // alles atomar ausgeben Die Locking-Technik erfordert den Einsatz eines Schlosses (std::mutex aus Includedatei <mutex>), das für alle Threads zugänglich sein muss (also wahrscheinlich global oder static ist bzw. vom Lambda per Referenz (!) aufgezeichnet werden muss). Vor jeder Ausgabe versucht der Thread, das Schloss zu schließen. Ist es bereits geschlossen (ein anderer Thread war schneller), so wird er automatisch angehalten, bis das Schloss frei wird und er es sodann selbst schließen kann. Bis zum Aufsperren nach getaner Arbeit sind nun die anderen Threads ausgesperrt. Damit man auf keinen Fall vergessen kann, das Schloss nach getaner Arbeit zu öffnen (und damit alle anderen Threads zu blockieren), überlässt man diese heikle Arbeit einem Spezialagenten wie std::scoped_lock< > ab C++17 (vor C++17 verwendet man std::lock_guard<std::mutex>), dem man im Konstruktor das Schloss zum Sperren übergibt und dessen Destruktor das Schloss am Ende automagisch freigibt. std::mutex lock_cout; // Ein globales Schloss für cout auto hello = [&lock_cout](auto tnum) scoped_lock sllock_cout; // C++17! sl sperrt ab cout << "Thread " << tnum << " sagt Hello World\n"; ; // sl sperrt automagisch auf Paralleles count up and down Im folgenden Beispiel addieren und subtrahieren die Threads von einem gemeinsamen int shared_int dieselbe Zahl, sodass dessen Anfangswert eigentlich erhalten bleiben sollte. Wie man sieht, ändert sich dieser ständig und unvorhersehbar: int shared_int = 0; void count_up_and_down(unsigned tnum) for (unsigned i = 0; i < 1'000'000; ++i) shared_int += tnum; // count up shared_int -= tnum; // count down

5 Der Grund ist wiederum, dass sich die Threads beim Zugriff auf den Integer in die Quere kommen (die Operation += und -= sind nicht atomar, obwohl es optisch so aussieht). Die Lösung mit dem Schloss funktioniert auch hier: int shared_int = 0; std::mutex lock_int; void count_up_and_down (unsigned tnum) for (unsigned i = 0; i < 1'000'000; ++i) std::scoped_lock sllock_int; // zusperren shared_int += tnum; // count up shared_int -= tnum; // automagisch aufsperren // count down Das Programm läuft jetzt korrekt aber recht langsam. In diesem Fall würde es sich eher anbieten, die Zugriffe auf den gemeinsamen Integer atomar zu machen. Dazu gibt es (nach #include <atomic>) neue Typen, auf die nur atomar zugegriffen werden kann: std::atomic<int> shared_int; // atomarer int-typ, = 0 geht NICHT void count(unsigned tnum) for (unsigned i = 0; i < 1'000'000; ++i) shared_int += tnum; // count up += ist hier atomar shared_int -= tnum; // count down Dieses Programm funktioniert ebenfalls korrekt und ist deutlich schneller. Ob die atomaren Datentypen schneller als der Einsatz eines std::mutex sind, hängt u.a. auch von der CPU ab. Besitzt diese eine Unterstützung für atomare Operationen, wird man dadurch einen Zeitvorteil haben. Kann die CPU keine atomaren Operationen, so muss die <atomic> Bibliothek intern diese mit einem mutex realisieren und der Zeitvorteil ist dahin. Es lohnt sich aber, es trotzdem zu versuchen. Welche Parallelisierungs-Möglichkeiten hat C++ 1) Die Variante mit std::thread ist nur eine Möglichkeit, die C++ derzeit bietet. Mit C++20 werden voraussichtlich noch einige weitere Varianten dazukommen. Die

6 Verwendung von std::thread ist definitiv die einfachste Methode, allerdings hat sie folgende Nachteile: Es ist kein Rückgabewert möglich, d.h. die auszuführende Funktion (meist ein Lambda) muss als Rückgabetyp void haben (ist bei Lambda ohnehin default). In keinem Thread darf es eine Exception geben, sonst wird das Programm unweigerlich beendet (kein try-catch() möglich). Threads MÜSSEN ge-join-ed werden (oder mit der Methode.detach() abgekoppelt werden), sonst endet das Programm mit Fehler! Für jeden Aufruf wird ein neuer Thread erzeugt, der nach getaner Arbeit wieder zerstört wird. Eine Wiederverwendung von Threads (z.b. durch Threadpools) ist nicht möglich. 2) die Parallelisierung durch std::async( ), welche die ersten 3 Nachteile von oben definitiv nicht besitzt und die auch (das hängt vom Compiler ab) mittels Threadpools realisiert werden kann. std::async( ) gibt ein std::future- Objekt zurück und benötigt daher (wie überraschend) das Inkludieren von <future>. In diesem Objekt wird der Thread in der Zukunft (, deshalb der Name) den Rückgabewert (oder eine allfällige Exception) speichern. Es gibt natürlich Methoden, dieses Objekt vom Kontrollprogramm abzufragen und so festzustellen, ob der Thread schon fertig ist ( valid() ), den Rückgabewert auszulesen ( get() ) und dabei auch allfällige Exceptions aufzufangen: mittels try catch( ). 3) Mit C++20 wird es z.b. paralleles std::for_each() und viele weitere STL- Algorithmen mit eingebauter Parallelisierung geben. Achtung: Beide Varianten (std::thread und std::async) können nur die Wertübergabe (also keinerlei Referenzen!) für die auszuführende Funktion (oder das Lambda). Will man unbedingt Referenzen an diese Funktionen übergeben, muss man diese in sogenannte Wrapper-Objekte stecken: std::ref(x) übergibt eine Referenz auf x per Wert std::cref(x) übergibt eine konstante Referenz auf x per Wert Wann lohnt sich Multithreading Das ist vielleicht die schwierigste Frage von allen. Sicher nur, wenn Hardware für mehrere unabhängige Threads vorhanden ist. Da die meisten modernen CPUs 2, 4 oder noch mehr Kerne haben, ist das heutzutage fast immer der Fall. Die Erzeugung und Verwaltung von Threads kostet Zeit. Daher müssen die Threads schon reichlich Arbeit erledigen, dass es sich auf der Uhr auszahlt. Muss man auch noch die

7 Threads synchronisieren, (d.h. einer darf erst arbeiten wenn ein anderer einen Checkpoint erreicht hat) wird es nochmals schwieriger. Am besten für Multithreading eignen sich Situationen, in denen die Threads unabhängig voneinander und ohne Streitigkeiten um Ressourcen ablaufen können. Viele Netzwerk- Serverdienste sind nach diesem Muster aufgebaut (pro Client ein Thread). Hier ist Multithreading fast schon Pflicht. Ebenso einfach geht die Parallelisierung in der Video- Kodierung: Jeder Thread übernimmt ein Paar Videoframes. Die Simulationstechnik ist auch eine ideale Anwendung für Multithreading. High Performance Computing verwendet Tausende von Threads auf vernetzten Systemen (vielleicht sogar Dutzende von Threads laut Obelix), um gewaltige Gleichungssysteme zu lösen (oder um unsere verschlüsselte Kommunikation zu knacken).