[F] Threads (Allgemein)
-
Hi,
wollte nur schonmal einen Beitrag erstellen, dass ich am Thema dran bin und es nicht vergessen habe
Morgen werde ich wohl schonmal eine Inhaltsübersicht reinstellen, zu der ihr dann auch fleißig Feeback geben dürft Da ich in der Woche arbeite, werde ich wohl tendenziell nur am Wochenende Zeit zum Schreiben finden.Gruß
-
So, hier endlich die versprochene Themenübersicht. Die Punkte in Klammern sind erstmal nur zur Info, was man unter einem Punkt zu erwarten hat. Evtl. könnte man das auch in Unterpunkte gliedern.
Wenn jemand Vorschläge/Ideen/Ergänzungen dazu hat, immer her damit!
1. Was ist ein Thread?
2. Warum überhaupt Multithreading? / Gründe für/gegen MT
3. Grundbegriffe (Parallelität, Synchronisierung, Skalierbarkeit)
4. Probleme mit Multithreading (Data-Races, Resource-Races)
5. MT auf Ebene des Betriebssystems (Kontextwechsel, Zeitscheiben)
6. Kommunikation zwischen Threads (Mutexe, Semaphoren, Zustandsvariablen, Nachrichten, gemeinsamer Speicher)
7. Unterstützung von MultiThreading durch C++
8. Debuggen von Multithread-Anwendungen
-
Das sieht nach viel Theorie aus.
Hast du in Kapitel 7 auch Beispiele eingeplant? Damit es vielleicht nach dem Lesen auch mal ausprobieren kann?
-
Ähm ich war jetzt im Stellenangebot davon ausgegangen, dass es zwei Artikel zu Threads gibt - einen recht theoretischen, da C++ von Haus aus Multithreading nicht direkt unterstützt, und einen praktischen, der das ganze Anhand von z.B. MFC/WinAPI zeigt - und dass ich dann den theoretischen schreibe. Mmh ist das jetzt ein Missverständis? Beispiele hätte ich mir jetzt in Form von Pseudocode gedacht, auf eine spezielle Implementierung wollte ich nicht eingehen.
Eine Aufteilung in zwei Artikel würde ich auch grundsätzlich nicht für verkehrt halten, da es schon ein eher großes Grundwissen braucht und man mit Multithreading sonst sehr schnell ins Wasser fällt.
-
Ups, ich hatte die Überschrift so verstanden, dass du kurz drauf eingehst.
Naja, dann muss ich mal sehen, ob sich noch jemand für den praktischen Teil findet - das war wirklich ein Mißverständnis, sorry.
-
Hm das ist jetzt doof gelaufen. Im Prinzip kann ich auch was zur Verwendung von WinAPI schreiben, alternativ hätte ich auch mit POSIX Threads Erfahrungen.
Allerdings wird mir das dann auch etwas viel. Wenn sich ein weiterer Schreiberling findet, wäre das nicht schlecht
-
Mach erstmal die Theorie in Ruhe fertig.
Wenn du dann noch Lust auf ne Zugabe hast, kannst du gerne weitere Artikel machen. Dann wird es eben eine kleine Serie.
WinAPI interessiert mindestens mich.
Was Posix ist weiß ich leider nicht.
-
Posix heißt Portable Operating System Interface for UniX und bietet genauso wie die WinAPI eine Schnittstelle für Threads. Für Linux/UNIX-Fans könnte man das evtl. vorstellen oder WinAPI gegenüberstellen. Da könnte ich sogar auf ein paar gemeine Feinheiten auf diversen UNIXen eingehen. Hmm... ich sehe mich gerade schon einen zweiten Artikel schreiben...
Ich mach erstmal den ersten und dann mal schauen
-
Leider muss ich an dieser Stelle mitteilen, dass mein Artikel etwas im Sande versandet ist. Die letzte Zeit (Monate) war einfach viel zu viel zu tun, da freut man sich über jedes freie Wochenende
Immerhin, über Weihnachten habe ich zwei Wochen frei, da werde ich dann hoffentlich auch wieder zum Schreiben kommen. Ich stelle euch zumindest schonmal das rein, was bis jetzt entstanden ist. Bitte die fehlenden Umlaute beim Lesen ignorieren... (Wichtige Aufgabe: Firefox updaten... 
) Wenn ihr schon Vorschläge / Ideen / Kritik dazu habt - natürlich immer her damit.1. Was ist überhaupt Multithreading?
Erinnern sich einige von euch noch an die guten alten Zeiten von DOS? Wenn man eine Anwendung gestartet hat, lief nur diese und nichts nebenher. Egal ob ein Word in schicker Turbovision-Optik oder der Norton-Commander. Heutzutage wäre so was absolut nicht mehr denkbar. Wer jetzt gerade diesen Artikel liest, hat zumindest seinen Browser offen, surft vielleicht noch nebenbei, hört Musik im WinAmp oder kompiliert ein Projekt im Hintergrund.
Was der Rechner da gerade betreibt ist Multitasking, mehrere Aufgaben laufen parallel ab (Task: Aufgabe). Geht man weiter ins Detail, so besteht jede Aufgabe aus einem oder mehreren Prozessen, die an ihrer Ausführung beteiligt sind (dabei muss man das Wort Prozess gar nicht mal streng aus Sicht des Betriebssystems sehen). Eine Datenbank-Anwendung besteht zum Beispiel aus einem Frontend-Prozess, der die Daten anzeigt und einem Backend-Prozess, der die Datenhaltung realisiert. In diesem Fall spricht man von Multiprocessing.
Prozesse lassen sich aber noch feiner aufteilen. Jeder Prozess hat eine Vielzahl von Teilaufgaben, die parallel ausgeführt werden können. Um beim Beispiel der Datenbank-Anwendung zu bleiben: Während in der Anwendung ein Bericht ausgedruckt wird, möchte man üblicherweise etwas anderes mit der Anwendung erledigen und nicht darauf warten, dass das Drucken fertig ist (was auf einem Netzwerkdrucker in einem Großraumbüro beliebig lange dauern kann). In diesem Fall hat die Anwendung mehrere "Threads of Execution" (Ausführungsfäden), oder kurz Threads. Diese Ebene der Aufgabenteilung nennt sich (logischerweise) Multithreading.2. Gründe für Multithreading
Nachdem diese Begrifflichkeit geklärt wurde, stellt sich nun die Frage, wann und warum man eine Multithread-Anwendung schreiben sollte. Vielleicht zuerst der wichtigste Grund, keine Multithread-Anwendung zu schreiben: Und zwar immer dann, wenn eine Singlethread-Anwendung ausreicht!
Nachdem wir damit sehr viele Fälle ausschließen konnten, kommen zur Ursprungsfrage zurück. Der wohl prominenteste Grund ist die Performancesteigerung bei der Verwendung von mehreren Prozessoren. Da die Steigerung der Leistungsfähigkeit der Prozessoren so langsam durch physikalische Probleme nachlässt (der 4GHz Pentium4 lässt schon lange auf sich warten), ist die gleichzeitige Verwendung von mehreren Prozessoren eine gute Möglichkeit zur weiteren Steigerung der Performance.
Ein anderer wichtiger Grund ist die Reaktionsfähigkeit einer Anwendung. Wenn die Datenbank-Anwendung eine Auswertung über eine Millionen Datenstze durchführt, soll das Fenster nicht stillstehen. Es soll sich neu zeichnen, einen Fortschrittsbalken anzeigen und ein Button "Abbrechen" soll auf eine Aktion des Anwenders reagieren können. Natrlich lässt sich in die Auswertungsfunktion ein Mechanismus einbauen, der die Aktualisierung der Oberflche anstößt - das zieht aber Detailprobleme nach sich. Es ist ausgesprochen schwierig, in einer nicht-trivialen Auswertungsfunktion Punkte zu finden, wo man die Aktualisierung auslöst. Im Normalfall wird die Aktualisierung entweder zu oft angestoßen und verbraucht dadurch zuviel Performance, oder es passiert zu selten und die Oberflche reagiert "hakelig". Es gibt den unmöglichsten Code, der versucht durch "intelligente Techniken" zu häufiges Aktualisieren zu verhindern. Es läuft normalerweise darauf hinaus, dass man in die (in unserem Beispiel) Auswertungsfunktion Code integriert, für den sie überhaupt nicht zuständig ist. Das Verständnis der Funktion wird immer schwieriger und die Design-Entscheidungen immer undurchsichtiger. Möchte man dann noch mehrere Auswertungen parallel durchführen, ist endgltig das Ende der Fahnenstange dieser Technik erreicht. Teilt man diese Aufgaben in Threads auf, so fliegt unnötiger Code aus der Auswertungsfunktion, die Aufgaben werden klar getrennt und die Oberflche reagiert nur genau dann, wenn das Betriebssystem es mitteilt.
Ein drittes Einsatzgebiet ist die Modellierung von Aufgaben. Drucken und Speichern sind z.B. Aufgaben, die kaum etwas miteinander gemein haben. Diese Unabhängigkeit kann man durch die Modellierung mit verschiedenen Threads ausdrücken.
Man könnte jetzt die berechtigte Fragen stellen, warum man nicht mehrere Prozesse verwenden sollte. Das ist zwar prinzipiell möglich (und je nach Einsatz auch sinnvoll), verkompliziert aber die Kommunikation. Während Threads auf die gleichen Variablen, Ressourcen etc. innerhalb des Prozesses zugreifen können, bleibt mehreren Prozessen dies verwehrt. Sie müssen ber gemeinsamen Speicher, Pipes, Sockets, Nachrichten oder sonstige Manahmen kommunizieren, die meist ein aufwändigeres Handling benötigen (beispielsweise muss man sicher ber Datenserialisierung Gedanken machen, was nicht trivial ist).
Wie wir jetzt gesehen haben, ist Multithreading toll: Es steigert die Performance, vereinfacht Programmcode und drückt die Zuständigkeiten von Code besser aus. Ab heute schreiben wir nur noch Multithread-Anwendungen. ..... Na ja, das ist nur die halbe Wahrheit. Neben diesen Vorteilen erfordert Multithreading aber ein großes Wissen über genau jenes, es erfordert ein anderes Denken beim Design und ist ein zustäzlicher Programmier-Aufwand zu den Aufgaben, die man sowieso schon zu erledigen hat. Zusätzlich handelt man sich eine ganz neue Klasse von Problemen ein, mit denen man in einer Singlethread-Anwendung so noch nie in Berührung gekommen ist. Der Punkt mit dem Wissen wird mit diesem Artikel angegangen - die auftretenden Probleme werden in einem späteren Abschnitt besprochen. Die anderen beiden Punkte sind Erfahrung, die sowohl mit dem erfolgreichen als auch nicht erfolgreichen Entwickeln von Multithread-Anwendungen einkehrt.
Wie sich jetzt nun erahnen lsst, ist das Entwickeln einer Multithread-Anwendung alles andere als eine Kleinigkeit. Man sollte den Mehraufwand nicht unterschätzen, gerade wenn die Entwicklung kommerziellen Hintergrund hat. Wie will man einem Kunden, der nichts von Programmierung versteht, eine zusätzliche Entwicklungszeit von mehreren Wochen glaubhaft machen, wenn die Effekte kein offensichtlicher Vorteil sind?
Deshalb noch mal das Statement vom Anfang dieses Abschnitts: Entwickle nie eine Multithread-Anwendung, wenn eine Singlethread-Anwendung ausreicht!3. Grundbegriffe (Parallelitt, Synchronisierung, Skalierbarkeit)
4. Probleme mit Multithreading (Data-Races, Resource-Races)
5. MT auf Ebene des Betriebssystems (Kontextwechsel, Zeitscheiben)
6. Kommunikation zwischen Threads (Mutexe, Semaphoren, Zustandsvariablen, Nachrichten, gemeinsamer Speicher)
7. Untersttzung von MultiThreading durch C++
8. Debuggen von Multithread-Anwendungen
-
*push* Ein kurzes Feedback / Meinungen / Kritik wäre wirklich toll
Dann wüsste ich schonmal, ob ich so weitermache wie bis jetzt oder ob ich bestimmte Sachen vielleicht anders anpacken sollte, bevor ich hinterher den ganzen Artikel auf den Kopf stelle. Damit der Teil angenehmer zu lesen ist, habe ich mal die Umlaute ergänzt ^^
-
Ich finds interessant
-
Die ersten zwei Abschnitte machen inhaltlich auf jeden Fall was her, sind gut geschrieben und auch schön ausführlich...
Damit der Teil angenehmer zu lesen ist, habe ich mal die Umlaute ergänzt ^^
aber du musst dringend Absätze einbauen, die Leserlichkeit leidet stark unter dem fetten Block Text.
-
GPC schrieb:
aber du musst dringend Absätze einbauen, die Leserlichkeit leidet stark unter dem fetten Block Text.
Ja das hatte ich vor... Hmm stimmt, das ist schon fast Augenkrebs-verdächtig
Ansonsten werde ich mich jetzt die nächsten Tage intensiv damit befassen.