Multithreadingbibliotheken

[FredK]

Hi!

Ich bin im Moment auf der Suche nach einer Bibliothek für Multithreading. Ich habe bisher unter Windows programmiert. Meine Teamkollegen programmieren leider /zum Glück unter Linux und MacOS. Von daher ist es mir vor allem wichtig, dass die Lib plattformunabhängig ist.
Ich hatte schon ein bisschen recherchiert und Boost gestoßen, die ja auch einen Multithreadingteil hat. Außerdem gibt es ja POSIX Threads, für die es auch eine Windowsportierung gibt.
Würd halt gerne ne kleine und einfach zu verwendende/installierende Lib benutzen, von daher finde ich Boost ein bisschen zu umfangreich. Bei POSIX Threads bin ich mir halt nicht sicher, wie gut sich das mit Windows (und Mac) verträgt.
Vielleicht habt ihr ja noch einen heißen Tip, oder könnnt eure Erfahrungen einbringen.
Vielen Dank im Vorraus! ;-)

[Schrompf]

Boost.Threads sind einfach zu benutzen - unter Linux und Mac müssten sie meist schon da sein, unter Windows gibt's die schön einfachen Fertig-Installer von BoostProConsulting - die sind auch auf der Boost-Webseite verlinkt. Boost bietet allerdings nur die Grundlagen der Multithreading-Programmierung: Mutex, Locks, Threads und so.

Wenn es etwas komplexer sein darf, empfehle ich Intels Threading Building Blocks. Die kann man LowLevel benutzen wie auch Boost::Threads, aber darüber hinaus bietet es ein Framework für parallele Verarbeitung aller möglicher Algorhythmen, parallele Container und sowas. Ich benutze nur einen kleinen Teil davon, weil deren Grundprinzipien für parallele Verarbeitung leider sehr auf große Datenmengen ausgelegt sind und nicht mit heterogenen Aufgaben mit IO-Kontakt, Wartezeiten und sowas klarkommen. Trotzdem ist es noch ein Gewinn - die ConcurrentQueue z.b. ist ein Fire&Forget-Ding, auf das ich immer wieder gern zurückkomme.

Installation ist einfach, weil vieles Prebuilt mitgeliefert wird.

[Matthias Gubisch]

Ich würde dir ebenfalls zu TBB raten, ist wirkliche ein brauchbares Framework, und vor allem kostenlos.
Der Taskmanager skaliert gut auf die aktuelle Kernzahl und sorgt auch durch automatische Umverteilung von Aufgaben für eine gleichmäige Auslastung der CPU-Kerne.

Darf ich fragen was für ein Projekt dahintersteckt?

[Jonathan]

Mal eine generelle Frage: Früher hab ich mal gehört, mit Multithreading handelt man sich fiese Probleme ein, weil das Programmverhalten schwerer zu durchblicken ist und seltsame Bugs entstehen können, die fast nie auftreten, aber dann eben manchmal alles crashen lassen.
Nun, mittlerweile glaube ich, wenn man mitdenkt, und weiß was man da tut, kann man die meisten dieser Fehler wohl von vornherein vermeiden. Aber trotzdem: Wie schwer ist es, Multithreading einzubauen? Also ich schätze, sowas wie Ressourcen im Hintergrund zu laden, sollte relativ einfach sein, aber wie sieht es beispielsweise aus, wenn Spiellogik und Rendering auf getrennten Kernen laufen sollen? Natürlich arbeiten die teilweise auf den selben Daten, aber durch geschickte Kapselung kriegt man es ja beispielsweise recht einfach hin, dass nur die Spiellogik die Spielerposition setzen darf und das Rendering imemr nur den aktuellen Wert ausliest. Aber reichen derart einfache Überlegungen oder hat man bei sowas schon ein riesen Problem und muss bei absolut jeder Programmzeile genau darauf achten, was man eigentlich gerade tut?
Wenn es sich vom Aufwand her rechnet, würde ich sowas gerne demnächst mal probieren, denn die Vorteile scheinen ja enorm zu sein.

[simbad]

Die Probleme entstehen im allgemeinen durch die Verwendung einer Variablen durch mehr als einen Thread.
Besonders deutlich wird das beim Einfügen eines Elements mitten in einer doppelt verketteten Liste. Während der eine Thread gerade dabei ist die Pointer umzusortieren löscht ein anderer Thread eines der Elemente, die daran beteiligt sind. Das Ergebnis ist ziemlich deutlich: Chaos in der Liste.

In der Zeit, o gott ist das lange her, als man vorzugsweise Single-Core/Single-Socket Computer hatte, sind solche Fehler meist erst nach langer Laufzeit oder unter Last aufgetreten, weil ja durch den einzelnen Core auch immer nur einer der Threads abgearbeitet werden konnte. Die Chance das dann diese parallel Verarbeitung zu Problemen führte war in vielen Fällen geringer.
In heutigen Multi-Core Systemen kann man recht sicher sein, das es schnell zu merkwürdigen Verhalten kommt.

Damals wie heute gibt es dafür entsprechende Mechanismen, Mutex/CriticalSection, um sicherzustellen, das an den Problemstellen immer nur einer der Threads ändert. Diese muss man dann eben einsetzen.

Man muss eben den Überblick behalten, welche Daten nur von einem Thread genutzt werden und welche von mehreren Threads. Durch Minimierung der Datenmenge, die von mehreren Threads genutzt werden, kann man das Problem nochmal ein wenig entzerren.

Ich habe für meine Anwendungen, die eigentlich immer mehrere Threads benutzen, als Regel aufgestellt, das jeder Thread nur auf seinen lokalen Daten arbeitet. Das ist natürlich manchmal nicht sinnvoll, aus Geschwindigkeitgründen z.B.. Aber dadurch ist die Menge Daten die mittel Mutex/CriticalSection geschützt werden muss überschaubar. Es hilft einfach von vornherein die Menge der Fehlerquellen zu minimieren.

Wenn man dann die Threads auf ganze Funktionsblöcke verteilt, Netzwerk-Kommunikation, Spieler-Interaktion, Rendern, Collision-Detection, dann kann man sich bei der Implementierung auf die Lösung der Einzelprobleme konzentrieren. Als Denksportaufgabe hat man dann nur noch die Kommunikation zwischen diesen Funktionsblöcken.

Fehlersuche gestalltet sich manchmal etwas Schwierig, da manche Fehler nur im ungebremsten Zustand auftreten, also ohne einen Debugger im Hintergrund. Da muss man dann auf die guten, alten Debug-Ausgaben zurückgreifen, wie man das schon in den 80er Jahren gemacht hat.

So. Frühstück. :)