Wenn die logischen Optimierungsmaßnahmen nicht ausreichend sind, können wir in manchen Situationen noch arbeitsteilig vorgehen. Dies geht aber leider nicht immer – die Primzahlenermittlung aus dem vorausgegangenen Kapitel wäre ein Kandidat, bei dem die arbeitsteilige Ermittlung nur bedingt möglich ist. Der Grund liegt daran, dass die Berechnungen aufeinander aufbauen. Wir können die höheren Faktoren erst dann performant bestimmen, wenn wir die niedrigeren ermittelt haben. Rechnungen, welche unabhängig voneinander durchgeführt werden können, sind jedoch ohne weiteres aufteilbar. In diesem Kapitel werde ich eine Fraktal Berechnung als Beispiel nehmen, da es zum einen ein sehr oft zitiertes Beispiel ist und zum anderen einfach schön aussieht 😊

Doch beginnen wir wie immer mit grundsätzlichen Überlegungen. Bevor wir in die rechenintensive Fraktal Berechnung einsteigen müssen wir uns nochmal vergegenwärtigen, welche Ressourcenbeschränkungen eine schnellere Abarbeitung unseres Codes verhindern. Die offensichtliche ist natürlich die CPU, welche einfach nur eine gewisse Anzahl an Aktionen pro Zeit durchführen kann. Hier ist schlichtweg die Kapazität des Rechenkerns ausgeschöpft. Es gibt jedoch in manchen Programmen noch einen zweiten Engpass – und zwar externe Ressourcen, wie bspw. durch die Kommunikation über das Netzwerk. Die sequenzielle Abarbeitung unseres Codes führt nämlich unweigerlich dazu, dass wenn eine Aktion nicht abgeschlossen ist, die Codeausführung nicht weitergeht. Stellen wir uns bspw. vor wir haben ein Programm, welches Daten von einem entfernten Server lädt. Wenn der Server nun nicht schnell genug antwortet, muss unser Programm auf diese Antwort warten. Und in genau dieser Zeit könnte unser Programm eventuell sinnvollere Dinge tun.

Wir unterscheiden also zwei verschiedene Situationen, welche die Ausführungsgeschwindigkeit unseres (theoretisch perfekt optimierten) Codes begrenzen – CPU-Last und „warten“. Bei den kompilierten Programmiersprachen ist die Lösung für beide Fälle meist die gleiche und wird im Regelfall unter dem Begriff „Multithreading“ subsumiert. Bei Skriptsprachen wie Python, wird zwischen diesen beiden Fällen CPU/warten unterschieden – man spricht (zumindest in Python) von Multithreading und Multiprocessing. Während „Multithreading“ in Python verschiedene Threads bezeichnet, welche aber in einem Core laufen, versteht man dort unter „Multiprocessing“ die Nutzung verschiedener Cores. Um diesen Zusammenhang nochmal klarzumachen, stellen wir uns folgende Situation vor. Ein Maler hat die Aufgabe, mehrere Leinwände anzumalen. Da er den Pinsel nicht auswaschen kann und es für ihn tragbar ist mit einer helleren Farbe auf dem Pinsel in einen dunkleren Farbtopf einzutauchen, muss er zuerst die gelbe, dann die rote und am Schluss die schwarze Leinwand anmalen:

Wenn nun der gelbe Farbeimer leer ist bevor die Leinwand komplett bemalt wurde, muss er zwangsweise warten, bis ein neuer geliefert wird. Der gesamte Prozess ist also blockiert, obwohl der eigentliche Prozessor (also unser Maler) nichts macht, außer warten. Dies wäre ein „singlethreaded“ Programm, welches „synchron“ abgearbeitet wird. Wenn er aber nun für jede Farbe einen eigenen Pinsel hätte, so könnte er während der Wartezeit auf den neuen gelben Eimer anfangen, die rote und schwarze Leinwand anzumalen. Sobald der gelbe Eimer da ist, könnte er mit der gelben Leinwand weitermachen. Dies wäre aus Python Sicht ein „multithreaded“ Programm, in anderen Programmiersprachen würde man hierzu „asynchron“ sagen. Hätte unser Maler aber Unterstützung von zwei weiteren Malern, so könnten alle drei Leinwände parallel bemalt werden – zumindest solange Farbe da ist. Dies wäre aus Python Sicht ein „multiprocessing“ Programm. Aus Sicht von Java oder C# würde man auch letzteres als „multithreaded“ Programm bezeichnen, da dort Threads immer unabhängig laufen. Wie wir sehen, werden die Begriffe leider bei den unterschiedlichen Programmiersprachen unterschiedlich belegt. Um diesen Umstand etwas besser in Worte zu fassen, können wir mit unserem kleinen „Malbeispiel“ drei geeignetere, weil interpretationsfreie, Begriffe erklären. Die Umsetzung unserer Malaufgabe mit nur einem Pinsel wäre ja ein Beispiel für synchrones Abarbeiten. Sobald wir mehr als einen Pinsel verwenden, sprechen wir hier von einer asynchronen Abarbeitung – wir sind also mehr oder weniger frei in unserer Entscheidung, in welcher Reihenfolge wir abarbeiten. Sobald wir nun mit mehr als einem Maler agieren, würden wir von einer parallelen Abarbeitung sprechen, welche in sich wiederum zwingend asynchron ist. So viel ist anfangs zur Terminologie wichtig, damit alle Leser vom Gleichen ausgehen.

Gehen wir nun in die Details der Verarbeitung. Wie wir in den ersten Kapiteln des Buches geklärt haben, ist die CPU in der Lage, an einer zentralen Stelle binäre Daten miteinander zu verknüpfen. Die Taktfrequenz bestimmt nun, wie viele solche Verknüpfungen pro Sekunde möglich sind. Wenn man schnellere Prozessoren haben möchte, dann hatte man früher im Wesentlichen zwei Optionen. Erstens kann man die Aktion pro Takt effektiver gestalten. Wir haben in Kapitel 4 beispielsweise gesehen, dass wir ganze Zahlen relativ einfach mit Hilfe von Hardwarelogik addieren und basierend auf mehreren Additionen hintereinander eine Multiplikation realisieren können. Diese Multiplikation kann man aber effektiver gestalten, wenn man sie bereits hardwareseitig in einem Schritt durchführt. Gleiches gilt für die komplizierteren Gleitkommaoperationen. Man könnte sie aus einzelnen Operationen mit ganzen Zahlen aufbauen, oder eine FPU (Floating Point Unit) auf dem Prozessor hinterlegen, die sich hierum kümmert. Diese Optionen sind aber irgendwann ausgeschöpft, da man früher oder später alle logisch möglichen Optimierungen implementiert hat. Die zweite Möglichkeit der Performancesteigerung ist schlichtweg die Erhöhung der Taktrate – man versucht also pro Sekunde mehr Operationen durchzuführen. Hier gibt es jedoch physikalische Grenzen. Die wahrscheinlich wichtigste ist die Wärmeentwicklung, welche pro elektrischer Aktion entsteht. Steigt die Anzahl der Aktionen pro Sekunde, steigt auch die kumulierte Wärmeentwicklung pro Zeit, welche irgendwie abgeführt werden muss. Mit speziellen Kühlvorkehrungen kann man Prozessoren zwar „hochtakten“ – also die Taktrate über das empfohlene Maß erhöhen, was aber ein vergleichsweise hoher Aufwand ist. Die derzeitig maximal möglichen Prozessortakte bei klassischen CPUs für den PC Einsatz liegen bei 3-4 GHz im Normalbetrieb, was so etwas wie eine „natürliche“ Grenze für den Betrieb in realistischen Betriebsumgebungen ist. Man sieht dies sehr schön daran, dass sich dieser Wert seit 2005 nicht wirklich geändert hat. Um nun den Trend der immer leistungsfähigeren CPUs fortzusetzen, haben zu diesem Zeitpunkt die Multicore Prozessoren Einzug in die PCs gehalten, wodurch das Thema Multithreading (oder im Fall von Python Multiprocessing) interessant wurde. Multicore bedeutet, dass man in einen Prozessorchip einfach mehrere parallel arbeitende Rechenkerne einbaut – vereinfacht gesprochen, mehrere CPUs auf einem Chip.

Wenn wir als Programmierer dieses Potential nun ausnutzen wollen, müssen wir unser Programm genau darauf ausrichten. Das zentrale Problem ist hier, dass unser Code sequenziell abgearbeitet wird – Zeile für Zeile. Alle Programme, welche wir bis hier in diesem Buch durchgearbeitet haben, folgen diesem Paradigma. Unser Prozessor (oder Interpreter) hat sich die main-Methode gesucht, diese gestartet und ist dann Schritt für Schritt dem Code gefolgt. Dieses Durcharbeiten unseres Programms erfolgt in einem sogenannten „Thread“. Unser Betriebssystem zeigt uns dann auch in den Ressourcenmonitoren an, wie viele Threads der Rechner derzeit verwaltet. Unser Programm wäre dann einer dieser Threads. Wenn wir nun den Rechner in die Lage versetzen wollen, unser Programm parallel abzuarbeiten, müssen wir ihm irgendwie die Möglichkeit geben, mehrere „Handlungsstränge“ zu verfolgen, er muss also in mehreren Threads laufen. Diese Art der Programme nennen wir im allgemeinen „multithreaded“. Allen multithreaded Programmen ist jedoch gemein, dass wir mit einem Hauptthread starten, der wiederum Subthreads initiiert. Die Notwendigkeit einer main-Methode bleibt also bestehen.

Der untere Teil der Abbildung 2 ist das bis jetzt bekannte Konzept. Die oberen Sub-Threads kommen nun neu hinzu. Jeder dieser Threads (und natürlich auch die einzelnen Threads des Betriebssystems und wenn wir mit Java, C# oder einer Skriptsprache arbeiten auch die der Laufzeitumgebung) muss von einem CPU-Kern abgearbeitet werden. Das Betriebssystem kümmert sich unter anderem darum, dass jeder Thread entsprechend einer CPU zugewiesen wird. Da aber fast immer weniger Kerne als Threads vorhanden sind, muss ein Kern mehrere Threads bedienen. Dies geht aber nur sequenziell (genauso wie unser Farbeimerbeispiel mit mehreren Pinseln, aber nur einem Maler). Das heißt ein Kern verarbeitet einen Teil des ersten Threads, dann einen Teil des zweiten und so weiter, bis er wieder Zeit für den ersten Thread hat. Wenn wir als Programmierer nun Performancegewinne durch Parallelisierung erreichen wollen, ist es hilfreich zu wissen, wie viele Cores ein Prozessor aufweist. Bei der Ermittlung der Kernanzahl muss man noch wissen, dass vor allem bei Intel Prozessoren ein Hardwarekern noch in virtuelle Kerne aufgeteilt wird – sprich der Prozessor bietet dem Betriebssystem meist doppelt so viele Kerne an, als hardwareseitig implementiert sind, was man als „Hyperthreading“ bezeichnet. Die Technologie dahinter ist aber so gestaltet, dass eine Aufteilung auf zwei virtuelle Kerne tatsächlich einen Performancegewinn bringt, obwohl beide auf dem gleichen Hardwarekern laufen. Insofern unterscheiden wir als Programmierer hier nicht zwischen logischen und realen Kernen. Nun hat das Betriebssystem noch die Aufgabe zu verhindern, dass zwei Programme auf den gleichen Speicherbereich zugreifen können. Das hat zum einen natürlich seinen Grund in der Sicherheit, damit die Programme sich nicht gegenseitig „ausspionieren“ können, aber auch einen ganz einfachen technischen Grund. Wenn ein Thread gerade Daten verändert und der andere sie auslesen möchte, entstehen mitunter nicht konsistente Datenkonstellationen. Da die Programme aufgrund der genannten Sicherheitsbedenken „Herr“ über ihre Datenbereiche sind, ist das bei einem singlethreaded Szenario kein Problem. Bei Programmen, welche mehrere Threads nutzen aber sehr wohl! Das Betriebssystem muss also wissen, dass zu einem Programm mehrere Threads gehören und sie sich Speicherplatz teilen, bzw. gegenseitig auf die Daten zugreifen dürfen. Das ist in den einzelnen Sprachen unterschiedlich gelöst und bedarf im Regelfall einige Codeelemente, welche auf den ersten Blick „nervig“ sind, aber genau auf diese Problematik hin ausgerichtet sind.

Mit dem Paradigmenwechsel, Code nun parallel in mehreren Threads abzuarbeiten, handeln wir uns aber eine ganz neue Art von möglichen Fehlerquellen ein, nämlich die Zeit! Hierzu überlegen wir mal ein Beispiel außerhalb der Computerwelt. Gehen wir mal davon aus, Kinder wollen bunte Papierflieger bauen. Nun haben sie die Möglichkeit, dies mit einem „Thread“ durchzuführen, sprich ein Kind baut die Flieger und malt sie anschließend an:

Der Algorithmus wäre also, dass der erste Arbeitsvorgang „die Flieger zu bauen“ bestimmt, wie viele Flieger benötigt werden. Der zweite Arbeitsgang arbeitet dann einfach alle Flieger ab und bemalt sie. Sobald kein weißer Flieger mehr zu sehen ist, bricht der Malvorgang ab. Nun könnten die Kinder auf die Idee kommen, die beiden Aktivitäten an zwei Kinder aufzuteilen und sie zu parallelisieren:

Das Kind für das Bemalen der Flieger darf nun natürlich erst beginnen, wenn der erste Flieger gefaltet wurde. Die Frage ist nun was passiert, wenn das Falten des Fliegers mehr Zeit in Anspruch nimmt als das Bemalen. Natürlich wären die Kinder jetzt so schlau und würden aufeinander warten – aber wenn wir uns mal wieder den Titel des Buches in Erinnerung rufen – der Computer ist nun mal nicht „schlau“ – sieht die Sache wieder anders aus. Er würde schlichtweg nach dem Bemalen des ersten Fliegers keinen weißen Flieger mehr finden (der zweite Flieger wird ja gerade erst gefaltet) und den zweiten Thread einfach beenden. Wir hätten 19 weiße und einen bunten Flieger. Wenn allerdings das Bemalen länger dauert als das Falten, dann kommen 20 bunte Flieger heraus. In der sequenziellen Abarbeitung haben wir dieses Problem nicht – wir erhalten immer 20 bunte Flieger, egal welcher Vorgang länger dauert. In der Programmierung kommt nun ein weiteres Problem hinzu. Natürlich kann man davon ausgehen, dass im Test schon herauskommt, was länger dauert – Bemalen oder Falten. Es kann aber durchaus sein, dass auf einem anderen Rechner die Situation genau andersherum ist. Somit kann der Test auf einem Testrechner ein richtiges Ergebnis hervorbringen, auf einem Kundenrechner aber ein falsches. Weiterhin bieten einem alle Entwicklungsumgebungen die Möglichkeit, Programmabarbeitungen temporär anzuhalten, um sich den Zustand des Programms anzusehen. Wir werden hierüber später nochmal beim Thema „Debuggen“ sprechen. Das heißt, dass wir durch das temporäre Anhalten des multithreaded Programms im Zweifelsfall ein fundamental anderes Ergebnis erhalten, als wenn wir es normal durchlaufen lassen würden – das Anhalten verändert ja die Durchlaufzeit eines Vorgangs. Diese Situation darf aber auf keinen Fall akzeptiert werden! Ein Programm muss unabhängig von der Zeit immer das gleiche Ergebnis liefern. Ein weiteres Problem ist, wenn zwei Threads plötzlich zum gleichen Zeitpunkt auf eine Ressource zugreifen möchten. In unserem Papierfliegerbeispiel wäre es, wenn beide parallel arbeitenden Kinder eine gemeinsame Ablage für ihre Flieger hätten und sich darüber streiten, wer nun seinen Flieger ablegen darf. Auch solche Probleme können bei multithreaded Programmen auftreten.

Wenn unsere Programme, oder auch Teilmodule von Programmen (bspw. Klassen), dies Problemstellungen umgehen – sprich zeitunabhängig immer gleich fehlerfrei funktionieren, so sind sie „threadsafe“. Wir sehen uns nun mal ein programmiertes Beispiel an, welches nicht threadsafe oder zu Deutsch nicht „threadsicher“ ist. Hierzu müssen wir erstmal die Grundlagen für Multithreading legen. Unterschiedlich lange Ausführungen simulieren wir hier einfach mit einem Pause-Befehl, welchen die meisten Programmiersprachen unterstützen. Machen wir das Ganze mal in C# und beginnen mit dem Hauptprogramm:

Als nächstes schreiben wir die Klasse, die sich um den Start des zusätzlichen Threads kümmert, welche ich MyMainHandler getauft habe:

Kurze Erklärung der Codezeilen: Die Klasse implementiert zwei Methoden. Die erste ist dafür zuständig, den Thread zu starten, wofür eine eigene Klasse MyThreadClass instanziiert wird. Diese soll die Arbeit wiederum in einem eigenen Thread verrichten. Die Threadklasse „Thread“ liegt in der Bibliothek „System.Threading“, weshalb sie mit using bekannt gemacht werden muss. Diese Threadklasse ist ein Behälter, in den wir unsere Threadklasse legen – bzw. eigentlich nur die Methode, welche aufzurufen ist – in unserem Fall doYourWork. Sobald der Thread gestartet wurde, meldet die Methode auf der Konsole, dass dies erfolgt ist. Die zweite Methode empfängt von außen einfach eine Nachricht. Diese wird später vom Thread für eine Mitteilung genutzt.

Die eigentliche Threadklasse soll nun die Methode doYourWork() umsetzen:

Kurze Erklärung der Codezeilen: Die Klasse erwartet zwei Parameter im Konstruktor, welche in die gleichnamigen Instanzvariablen geschrieben werden. mainProg ist die Referenz auf den aufrufenden Handler und someInfo ein beispielhafter Wert, welcher später der Ausgabe dient. Die Methode doYourWork() hat keine Parameter – die von außen bereitgestellten Informationen (wie bspw. someInfo) wurde ja über den Konstruktor (bzw. könnten über Settermethoden) geliefert werden. Innerhalb der Methode wird eine Schleife 5 mal wiederholt, und mit Hilfe von Thread.Sleep(2000); eine 2 Sekunden Pause eingelegt, was eine aufwändige Verarbeitung simulieren soll. Nachdem die Pause vorbei ist, wird auf der Konsole eine entsprechende Meldung ausgegeben. Am Ende der Schleife ruft der Thread durch unsere MyThreadClass Klasse nochmal in MyMainHandler die Methode threadFinishInfo() auf, damit in unserem Beispiel auch eine Kommunikation vom Thread zum Aufrufenden gezeigt werden kann.

Wenn wir den Code laufen lassen, sehen wir nach einer gewissen Zeit folgende Nachrichten:

Das ist auf den ersten Blick überraschend. Das Programm wird zuerst beendet und dann werden die Thread Ausgaben gemacht. Dies liegt streng genommen daran, dass die Ausgabe „Programmende“ nicht ganz korrekt ist. Was endet, ist die Main Methode. Die Threads laufen weiter und erst wenn der letzte Thread beendet ist, dann stoppt das Gesamtprogramm, was im Wesentlichen die .NET Laufzeitumgebung ist. Dies können wir sehr viel besser sehen, wenn wir unser Programm nicht über VSCode laufen lassen, sondern es direkt mit einem Doppelklick im FileExplorer starten. Dies trägt den Namen csharp.exe und befindet sich im Projektunterordner bin\Debug\net5.0:

Wenn wir es mit einem Doppelklick starten, dann sehen wir, dass die Konsole erst schließt, wenn die letzte Ausgabe getätigt wurde:

Wenn wir unsere Main Methode nun so laufen lassen wollen, dass sie erst zusammen mit dem gesamten Programmausführung endet, müssen wir unser kleines Programm etwas anpassen. Wir merken uns in der Klasse MyMainHandler, dass wir gerade einen Thread gestartet haben und können die Methode startLogic() dazu erweitern erst dann zu stoppen, wenn kein Thread mehr läuft:

Lassen wir nun das Programm wieder laufen, sehen wir eine „sinnvollere“ Ausgabe:

Nun, da wir die ersten Gehversuche mit Threads gemacht haben, realisieren wir ein Programm, welches eine typische Verletzung der Threadsafe Regeln darstellt. Dieses Verhalten nennen wir auch „Race condition“, da aufgrund von zeitlichen Konstellationen einzelne Aktionen zu früh oder zu spät erfolgen. Sehen wir uns das Konstrukt erstmal grafisch an. Wir haben ein zentrales Programm, welches irgendwelche Berechnungen durchführt, die eine gewisse Zeit dauern. Das (kumulierte) Ergebnis wird in einer zentralen Variablen gehalten. In unserem Fall simulieren wir die Rechenzeit mit einer Pause, und das kumulierte Ergebnis ist einfach nur ein Zähler, der um eins hochgezählt wird:

Nun realisieren wir eine Logik, welche zwei Threads startet, die wiederum diese zentrale Funktionalität nutzen müssen:

Sehen wir uns die Belegung der Variable kumErg mal im Zeitablauf in zwei verschiedenen zeitlichen Konstellationen an.

In beiden Szenarien wird zuerst Thread 1 gestartet, der wiederum die zentrale Funktionalität aufruft. Diese liest kumErg, erhöht sie von 0 auf 1 und schreibt sie wieder zurück. Parallel macht Thread 2 das gleiche. Wenn nun, wie im linken Bild, Thread 2 aufgerufen wird, ohne dass kumErg von Thread 1 zurückgeschrieben wurde, liest Thread 2 ebenfalls die 0 und erhöht auf 1. Somit schreiben beide die 1 zurück. Warten wir wie im rechten Szenario mit dem Aufruf von Thread 2, liest dieser die von Thread 1 zurückgeschriebene 1, erhöht auf 2 und schreibt sie zurück – wir haben also aufgrund eines zeitlichen Unterschiedes zwei verschiedene Endergebnisse. Nun wollen wir das Ganze mal in die Tat umsetzen. Dafür schreiben wir unsere Klassen MyMainHandler und MyThreadClass um. Beginnen wir mit MyMainHandler:

Die Klasse MyThreadClass wird eigentlich nur noch verschlankt, da die Berechnung ja nun zentral in doConsumingStuff() liegt:

Wir erkennen, dass die Methode doConsumingStuff() parallel läuft. Bevor „Done with call of Thread 1“ ausgegeben wird, finden wir „Thread 2 called me“. Es ist also genau die Situation wie die linke Seite von Abbildung 9, weshalb kumErg auch auf 1 gesetzt wurde. Erhöhen wir nun den Wert von Sleep() der Methode doConsumingStuff() von 50 auf 300, dann sieht das Ergebnis wie folgt aus:

Hier endet doConsumingStuff() aus dem Aufruf des Thread 1, bevor Thread 2 aufruft – wir erhalten also die 2 in kumErg. Die Frage ist nun, wie wir es schaffen, dass sowohl bei einer sleep() Zeit von 50, als auch 300 für kumErg die 2 herauskommt. Der Grund für diese Problematik ist ja der gleichzeitige Zugriff der beiden Threads auf die Funktion doConsumingStuff(). Eine Möglichkeit wäre, wenn wir eine bool Variable hätten, welche immer dann auf true ist, wenn gerade jemand in der Methode doConsumingStuff() wäre und vor jedem Zugriff diese zyklisch prüfen würde, bis sie freigegeben wurde. In doConsumingStuff() müsste dann am Anfang diese Variable mit this.doConsumingStuffIsBlocked = true; gesetzt und am Ende wieder auf false gesetzt werden. Der Aufruf in doThreadedWork() müsste dann wie folgt aussehen:

Die grundsätzliche Funktionalität dieses Vorgehens sollte einleuchten – doThreadedWork() würde also so lange mit dem Aufruf von doConsumingStuff() warten, bis die Funktion vom aktuellen Nutzer freigegeben wurde. Allerdings hätten wir das Problem damit immer noch nicht vollständig in den Griff bekommen. Es wäre zum einen möglich, dass genau in den 10 ms Wartezeit sich ein anderer Thread dazwischenschiebt – wir hätten also kein „first come first serve“ Verhalten. Zweitens ist es nicht auszuschließen, dass zwischen der while Schleife und dem Aufruf von doConsumingStuff() ein anderer Thread ebenfalls doConsumingStuff() aufruft und wir dann wieder einen parallelen Zugriff haben.

Um diese Probleme nun zu lösen, bieten die verschiedenen Programmiersprachen Konzepte an, den Zugriff auf zentrale Funktionen bzw. Objekte zu „synchronisieren“. C# bietet hier einen ganzen Strauß an Möglichkeiten, von denen ich hier nur eine herauspicken werde. Wer hier tiefer einsteigen will, muss sich mit den einschlägigen Manuals und Büchern auseinandersetzen. Wir verwenden ein C# Konzept, „Attribute“ vor Methoden zu setzen. Diese stellen eine Art Metainformation für die Laufzeitumgebung und den Compiler dar. Eine dieser Metainformationen ist, dass wir eine gesamte Methode synchronisieren wollen:

Wir ergänzen also vor der Methode ein Attribut, welches in C# in eckigen Klammern notiert wird. Damit der Compiler dies akzeptiert, muss System.Runtime.CompilerServices über using bekannt gemacht werden. Wenn wir nun das Programm mit 50 ms Wartezeit laufen lassen, erhalten wir wieder das gleiche Ergebnis wie mit 300 ms – unsere Methode doConsumingStuff() ist nun threadsicher. Aus Sicht der Performanceoptimierung haben wir damit aber den Vorteil der Arbeitsteilung verspielt:

Aufgrund der Nutzung einer zentralen Funktionalität kann keine Parallelisierung mehr erfolgen, was natürlich einleuchtend ist. Nun müssen wir uns nochmal vor Augen führen, was die Notwendigkeit der Synchronisation in unserem Programm eigentlich bedingt, nämlich der Zugriff auf die Variable kumErg. Wenn nun in den Berechnungen diese Variable eine Rolle spielt und zwischendurch nicht verändert werden kann, können wir das Programm schlichtweg nicht mit einer Parallelisierung beschleunigen, da der „Bottleneck“ kumErg ist. Gehen wir nun mal davon aus, dass in unserer mit Sleep(200) simulierten Berechnung in den ersten 100 ms kumErg gar keine Rolle spielt, sondern nur in den zweiten 100 ms. Wenn dem so ist, können wir unsere Methode intelligenter gestalten, indem wir die beiden Teile der Simulation aufteilen:

Wie erwähnt ist diese Anpassung nur sinnvoll, wenn in der ersten Hälfte der mit Sleep() simulierten Berechnung kumErg keine Rolle spielt. Da die ganze Methode aber noch synchronisiert ist, haben wir (noch) nichts gewonnen. Nun haben wir zwei Möglichkeiten. Entweder wir lagern die drei markierten Codezeilen in ein eigenes Unterprogramm aus und synchronisieren nur dieses Unterprogramm, oder wir synchronisieren nur einen Teil des doConsumingStuff() Programms, was mit der statischen Klasse Monitor ermöglicht wird:

Wir haben den gesperrten Bereich also auf das minimal notwendige begrenzt. Man spricht hier auf von einer atomaren Befehlssequenz – also ein kleinstmöglicher Codebereich, welcher nicht durch andere Threads gestört werden darf. Die Monitor Klasse übernimmt die Funktion einer Ampel, welche die Nutzung von Code freigibt oder blockiert. Solche Konstrukte nennt man in der Programmierung auch „Semaphore“, was eigentlich die Bezeichnung eines mechanischen Zugsignals ist.

C# bietet darüber hinaus noch weitere Mechanismen für das Sperren von Codebereichen an – unter anderem auch eine Klasse, welche von Microsoft direkt „Semaphore“ getauft wurde. Ein weiterer gängiger Begriff für Elemente, welche solche kritischen parallelen Zugriffe regeln ist „Mutex“, was für „mutual exclusive“ (also in etwa „gegenseitig exklusiv“) steht. In C++ wird uns dieser Begriff begegnen. An diesem Punkt können wir eine Frage klären, die sich vielleicht bei den String Klassen dem ein oder anderen gestellt hat. Warum sind Strings immutable, also nicht veränderbar? Der Grund liegt unter Anderem in der Threadsicherheit. Wenn wir einen String haben, auf den mehrere Threads zugreifen müssen, dann möchten wir allen die gleiche „Wahrheit“ bieten. Wenn der String jedoch von einem Thread geändert werden kann während der andere gerade darauf zugreift, wird das Ergebnis nicht mehr sicher vorhersagbar.

Nun, da wir ein grundsätzliches Verständnis von Threads haben, können wir uns an ein aufwändigeres Projekt wagen, welches von einem multithreaded Ansatz profitiert – die vor allem bei Mathematikern beliebte Mandelbrotmenge aka. „Apfelmännchen“. Hier handelt es sich um ein sehr anschauliches Beispiel der Chaostheorie. Damit wir das Ganze auch wirklich verstehen, müssen wir ganz kurz in die Mathematik, und zwar in die Welt der komplexen Zahlen abschweifen. Die Idee der komplexen Zahlen entstammt aus folgender Forderung:

Wer jetzt aber ins Grübeln kommt, der denkt erstmal richtig – eine (reelle) Zahl mit sich selbst multipliziert kann niemals einen negativen Wert ergeben, da eine negative Zahl im Quadrat immer positiv ist (also bspw. -1 * -1 = +1). Die sogenannte „imaginäre Zahl“ j wurde aber genau so definiert, dass das Quadrat -1 ergibt (deswegen der Name „imaginäre Zahl“). Nun kann man eine Mischung aus imaginären und reellen Zahlen herstellen, indem man sie einfach zusammenzählt: c = 3j + 5. Die Zahl c hat also den imaginären Wert 3 und den realen Wert 5, was man wiederum grafisch in einem Koordinatensystem darstellen kann:

Nun kann man komplexe Zahlen auch miteinander multiplizieren. c1 * c2 ist also

und natürlich auch addieren. c1 + c2 ist:

Eine weitere, wichtige Eigenschaft ist die Entfernung vom Ursprung, was mit dem Pythagoras ermöglicht wird, was wir auch als Betrag bezeichnen. Diese Funktionalitäten können wir nun in eine Klasse gießen:

Nun können wir die Zahl 3j + 5 bspw. mit der Zahl 1j – 0.5 multiplizieren:

Die Ausgabe lautet:

Wenn wir dies einzeichnen sehen wir, dass unser Punkt gedreht und verschoben wurde:

Eine Multiplikation ist also eine Transformation des Ursprungspunktes, bei dem der Betrag die Verschiebung vom bzw. zum Ursprung festlegt und der Winkel zur Re-Achse den Rotationswinkel. Dies ist beispielsweise für die Programmierung von Rotationen sehr hilfreich. Wenn wir bspw. eine Rotation um 15° benötigen, muss der Imaginärteil sin(15°) = 0.2588190451 und der Realteil cos(15°) = 0.9659258263 betragen. Folgender Code würde also einen Kreis in 15° Schritten basierend auf unseren Punkt c abbilden:

Gerade für schnelle grafische Applikationen ist dies eine gern genommene Variante, animierte Rotationen zu implementieren, da bei einem zyklischen Update der Rotation nur einmal mit Sinus und Cosinus die Rotationsgeschwindigkeit festgelegt wird und dann lediglich Multiplikationen und Additionen für die Neupositionierung benötigt werden. Auch die Überlagerung von Rotationen ist mit diesem Konzept sehr einfach machbar. In 3D Applikationen, in denen wir drei Rotationsachsen kennen, hat man dieses Konzept um zwei imaginäre Werte erweitert – den sogenannten Quaternionen. Der Vollständigkeit halber zeige ich hier noch den Effekt der Verschiebung. In unserem Beispiel ist der Betrag der multiplizierten komplexen Zahl 0.2588190451 j + 0.9659258263 gleich 1, da nach Pythagoras die Wurzel aus 0.25881904512 + 0.96592582632 eins ergibt. Wenn wir jedoch beide nun um 10 Prozent auf 0.232937141 j + 0.869333244 j reduzieren, erhalten wir folgenden Grafen, in dem die neuen Punkte immer jeweils um 10% in Richtung Ursprung wandern:

Ein gewisser Herr Benoît Mandelbrot hat nun entdeckt, dass eine iterative Berechnung folgender Formel:

mit dem Startwert z0 = 0 und einem beliebigen Punkt c auf der komplexen Ebene ein chaotisches Verhalten, ähnlich einem Doppelpendel, aufweist. Die Idee ist, dass man c auf einem beliebigen Punkt auf der komplexen Ebene festlegt, diesen zum Punkt z0 = 0 hinzuaddiert und diesen dann dem Punkt z1 zuordnet. Im nächsten Schritt quadriert man z1 und addiert den Punkt c wieder hinzu. Das Ganze wiederholt man einige male und beobachtet, ob sich der Ergebnispunkt über eine gewisse Grenze vom Ursprung entfernt. Wenn dem so ist, markiert man den Punkt mit einer Farbe, welche man abhängig von der Anzahl der Durchläufe wählen kann. Wenn er innerhalb der Grenze bleibt, markiert man den Punkt c einfach schwarz. Im folgenden Bild sehen wir die Abfolge des Punktes c1=0,25 j + 0,25, welcher irgendwann im Punkt 0,354 j + 0,146 konvergiert. Insofern färben wir den Punkt c1 schwarz ein. Der Punkt c2=0,3 j - 0,8 hingegen schaukelt sich auf und geht irgendwann über alle Grenzen hinaus, weshalb wir ihn mit einer Farbe belegen:

Das Besondere an dieser Grafik ist nun, dass sie einen unendlich langen Umfang besitzt. Man kann also unendlich nah an die Grenze der schwarzen Menge „zoomen“:

Je näher man an die Grenze geht, umso mehr Iterationen muss man durchführen, um feststellen zu können, ob der entsprechende Punkt konvergiert oder nicht. Aus Sicht des Grafen ist eine Erhöhung der Iterationen eine Steigerung des Detailgrades. Also ein idealer Showcase für performancefressende Aktionen eines Prozessors. Das Besondere daran ist auch, dass jeder Punkt c unabhängig von allen anderen berechnet werden kann – perfekt also für ein multithreaded Programm.

Um dieses Projekt zu realisieren, ergänzen wir unsere ComplexNumber Klasse um ein paar Methoden. Dies dient zum einen dazu, dass wir weniger Code in der aufrufenden Klasse haben und zum anderen der Reduktion von Rechenschritten.

Als nächstes müssen wir uns um ein Konzept der Datenhaltung kümmern. Das Ziel soll sein, in einer Pixelgrafik alle Punkte einzeln zu prüfen. Da dies eine zweidimensionale Datenstruktur ist, werden wir diese genauso auch aufbauen – mit einem zweidimensionalen Array von int Werten. Diese können wir dann einfach durch unser Bitmap Schreibprogramm aus dem Kapitel 15 auf das Filesystem verbannen. Die 0x000000 war hierbei die Farbe Schwarz und Weiß die 0xFFFFFF. Wenn wir also eine Grafik mit 2048 x 1024 Bildpunkten haben möchten, benötigen wir das Array new int[2048,1024].

In der Abbildung sehen wir, dass die Arraypositionen oben links mit 0/0 beginnen und nach rechts die Spalten- und nach unten die Zeilenindizes erhöhen, das Koordinatensystem der komplexen Zahlen sich aber von der Mitte her ausbreitet. Wir benötigen also noch ein Konzept, wie wir die Arraypositionen in das Koordinatensystem überführen. Hierzu brauchen wir die Größe eines Pixels. Im vereinfachten Bild der Abbildung ist ein Pixel genau 0,1 x 0,1 Längeneinheiten des Koordinatensystems. Diesen Wert speichern wir in einer Variablen pixelDist vom Typ double. Die Größe des Bildes ist somit Anzahl Pixel * pixelDist. Da wir meist die halbe Größe benötigen, speichern wir die halbe Breite in halfDimRe und die halbe Höhe in halfDimIm ab. Damit wir den Zoom Punkt beliebig verschieben können, wird einfach der Koordinatenwert der Mitte des abgebildeten Ausschnitts in der komplexen Ebene vorgegeben, mit startRe und startIm. Dies wird immer die Mitte der Bilddatei sein. Somit können wir den Koordinatenwert jedes Pixel bestimmen, welche durch r (Row) und c (Column) gegeben sind:

Pixel(r,c) = -1*(startIm - (halfDimIm - r) * pixelDist) j * startRe - (halfDimRe - c) * pixelDist

Die -1 vor dem Imaginärteil bildet die inverse Richtung der imaginären Achse (zeigt nach oben) und der Reihenfolge der Zeilenindizes (steigen nach unten) ab. Als nächstes überlegen wir uns die Logik für die Abbildung der Iterationen in einen Farbwert. Die Farben liegen ja im Bereich von 0x000000 bis 0xFFFFFF und die maximalen Iterationen zwischen 0 und den aktuell vorgegebenen maximalen Iterationen. Diese erhöhen sich aber mit der Erhöhung des Detailgrades. Wir werden später aber noch sehen, dass wir aufgrund der Rechengenauigkeit eine Obergrenze haben werden. Eine gute Annahme für die maximalen Iterationen könnten wir dann ermitteln – ich greife jedoch vor und setze die maximale Anzahl der Iterationen mit 2500 an. Der ermittelte Iterationswert i ist genau die Anzahl an Durchläufen, bei denen der Betrag von z über einer vorgegebenen Grenze liegt. Insofern bietet es sich an, den Farbwert einfach im gleichen Verhältnis zu belegen: public class FractalBuilder { private int dimX; private int dimY; private int halfDimRe; private int halfDimIm; private int maxIteration; private double startRe; private double startIm; private double thresSquare; private double pixelDist; private int[,] pixel; public FractalBuilder(double threshold, int maxIteration, double pixelDist, double startRe, double startIm, int dimX, int dimY) { this.thresSquare = threshold * threshold; this.maxIteration = maxIteration; this.dimX = dimX; this.dimY = dimY; this.startRe = startRe; this.startIm = startIm; this.pixelDist = pixelDist; this.halfDimRe = dimX / 2; this.halfDimIm = dimY / 2; this.pixel = new int[dimY, dimX]; } … … public void calcPixel() { ComplexNumber z = new ComplexNumber(0,0); for (int r = 0; r < dimY; r++) { for (int c = 0; c < dimX; c++) { z.reset(); double re = startRe - (halfDimRe - c) * pixelDist; double im = -1 * (startIm - (halfDimIm - r) * pixelDist); for (int i = 0; i < maxIteration; i++) { z.square(); z.addC(re, im); if (z.getDistSquare() > thresSquare) { setPixel(r, c, i * 0xffffff / 2500); break; } } } } } … … public void startCalculation() { calcPixel(); } private void setPixel(int r, int c, int color) { pixel[r, c] = color; } public void writeDataToFile(String fileName) { byte[] data = BitmapGenerator.prepareBmp(pixel); File.WriteAllBytes(fileName, data); } … class BitmapGenerator { public static byte[] prepareBmp(int[,] pixel) { byte[] head = { 0x42, 0x4d, // ASCII für BM 0x00, 0x00, 0x00, 0x00, // Dateigröße 0x00, 0x00, 0x00, 0x00, // immer 00 0x36, 0x00, 0x00, 0x00, // Offset Bilddaten 0x28, 0x00, 0x00, 0x00, // Größe Infoheader 0x00, 0x00, 0x00, 0x00, // Breite 0x00, 0x00, 0x00, 0x00, // Höhe 0x01, 0x00, // immer 01 00 0x18, 0x00, // Farbtiefe 0x00, 0x00, 0x00, 0x00, // keine Komprimierung 0x00, 0x00, 0x00, 0x00, // Größe Bilddaten 0x00, 0x00, 0x00, 0x00, // Auflösung horizontal - Standard 00 0x00, 0x00, 0x00, 0x00, // Auflösung vertikal - Standard 00 0x00, 0x00, 0x00, 0x00, // Farbtabelleninfo – Standard 00 0x00, 0x00, 0x00, 0x00 // Farbtabelleninfo – Standard 00 }; if (pixel.GetLength(0) == 0) { return null!; } if (pixel.GetLength(1) == 0) { return null!; } int height = pixel.GetLength(0); int width = pixel.GetLength(1); int noOfZero = (4 - ((3*width) % 4)) % 4; int noOfImgBytes = height * (3*width + noOfZero); int fileSize = head.Length + noOfImgBytes; if (!setBytesLittleEnd(2, fileSize, head)) { return null!;} if (!setBytesLittleEnd(18, width, head)) { return null!;} if (!setBytesLittleEnd(22, height, head)) { return null!;} if (!setBytesLittleEnd(34, noOfImgBytes, head)) { return null!;} byte[] data = new byte[fileSize]; int pos = 0; for (int i = 0; i < head.Length; i++) { data[pos++] = (byte)head[i]; } for (int r = 0; r < height; r++) { for (int c = 0; c < width; c++) { setBytesLittleEnd(pos, pixel[r,c], data); pos += 3; } for (int c = 0; c < noOfZero; c++) { data[pos++] = 0x00; } } return data; } int dimX = 2048; int dimY = 1024; double threshold = 10; double startRe = 0.36001014891; double startIm = 0.350001; double pixelDist = 0.001; int maxIteration = 50; FractalBuilder fb = new FractalBuilder(threshold, maxIteration, pixelDist, startRe, startIm, dimX, dimY); fb.startCalculation(); fb.writeDataToFile("C:\\temp\\myFractal.bmp"); … double pixelDist = 0.001; long start = DateTimeOffset.Now.ToUnixTimeMilliseconds(); for (int i = 0; i < 50; i++) { FractalBuilder fb = new FractalBuilder(threshold, maxIteration, pixelDist, startRe, startIm, dimX, dimY); fb.startCalculation(); fb.writeDataToFile("C:\\temp\\myFractal_" + i + ".bmp"); Console.WriteLine("Done Writing File " + i); pixelDist /= 2; maxIteration += 50; } Console.WriteLine("Time in ms: " + (DateTimeOffset.Now.ToUnixTimeMilliseconds() - start)); private int noOfThreads = 0; public void startCalculation(int cpuCount) { int noLinesPerThread = dimY / cpuCount; int rFrom = 0; int rTo = 0; int threadCount = 0; for (int i = 1; i <= cpuCount; i++) { rTo = (i == cpuCount) ? dimY : i * noLinesPerThread; FractalWorker myWorker = new FractalWorker(rFrom, rTo, this, "thread " + threadCount++); Thread threadInstance = new Thread(myWorker.doWork); rFrom = rTo; changeNoOfThreads(true); threadInstance.Start(); } do { Thread.Sleep(10); } while (noOfThreads > 0); } [MethodImpl(MethodImplOptions.Synchronized)] private void changeNoOfThreads(bool increase) { if (increase) { noOfThreads++; } else { noOfThreads--; } } [MethodImpl(MethodImplOptions.Synchronized)] private void setPixel(int r, int c, int color) { pixel[r, c] = color; } public void threadDone() { changeNoOfThreads(false); } public void calcPixel(int fromY, int toY) { ComplexNumber z = new ComplexNumber(0,0); for (int r = fromY; r < toY; r++) { for (int c = 0; c < dimX; c++) { … public class FractalWorker { private int fromY; private int toY; private String name; private FractalBuilder fb; public FractalWorker(int fromY, int toY, FractalBuilder fb, String name) { this.fromY = fromY; this.toY = toY; this.fb = fb; this.name = name; } public void doWork() { Console.WriteLine("Start Thread " + name); fb.calcPixel(fromY, toY); fb.threadDone(); } } … FractalBuilder fb = new FractalBuilder(threshold, maxIteration, pixelDist, startRe, startIm, dimX, dimY); fb.startCalculation(2); fb.writeDataToFile("C:\\temp\\myFractal_" + i + ".bmp"); … public class FractalWorker implements Runnable { private int fromY; … @Override public void run() { fb.calcPixel(fromY, toY); fb.threadDone(); } } public void startCalculation(int cpuCount) { … Thread threadInstance = new Thread(myWorker); threadInstance.start(); do { try { Thread.sleep(10); } catch (InterruptedException e) { e.printStackTrace(); } } while (noOfThreads > 0); } … private synchronized void changeNoOfThreads(boolean increase) { if (increase) { noOfThreads++; } else { noOfThreads--; } } private synchronized void setPixel(int r, int c, int i) { pixel[r][c] = i; } … void threadedMethod(FractalBuilder* fb, int fromY, int toY) { fb->changeNoOfThreads(true); fb->calcPixel(fromY, toY); fb->changeNoOfThreads(false); } … #include <thread> #include <mutex> #include <vector> … static void startMulti(int noOfCores) { … std::vector<std::thread> threads; for (int img = 0; img < 50; img++) { FractalBuilder* fb = new FractalBuilder(threshold, maxIteration, pixelDist, startRe, startIm, dimX, dimY); int rFrom = 0; int rTo = 0; for (int i = 1; i <= noOfCores; i++) { rTo = (i == noOfCores) ? dimY : i * noLinesPerThread; threads.push_back(std::thread(threadedMethod, std::ref(fb), rFrom, rTo)); rFrom = rTo; } for (std::thread & th : threads) { th.join(); } threads.clear(); … class FractalBuilder { private: std::mutex pixel_lock; std::mutex noOfThreads_lock; … void setPixel(int r, int c, int i) { pixel_lock.lock(); pixel[r*dimX + c] = i; if (pixel[r*dimX + c] < 0) { std::cout << "error"; } pixel_lock.unlock(); } void changeNoOfThreads(bool increase) { noOfThreads_lock.lock(); if (increase) { noOfThreads++; } else { noOfThreads--; } noOfThreads_lock.unlock(); } … console.log("start"); let time = 5000; let avgTime = time/getNoOfCycles(time); console.log("result " + avgTime*1000000 + " ns"); function getNoOfCycles (dTime) { let count = 0; let start = Date.now(); let end = Date.now(); while(end - start < dTime) { end = Date.now(); count++; } return count; } <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <script> function startCode() { logInfo("start"); let time = 5000; let avgTime = time / getNoOfCycles(time); logInfo("result " + avgTime*1000000 + " ns"); } function check1() { logInfo("check1"); } function check2() { logInfo("check2"); } function logInfo(info) { var logDif = document.getElementById("logOut"); logDif.innerHTML = logDif.innerHTML + "<br/>" + info; } function getNoOfCycles(dTime) { let noOfCycles = 0; let start = Date.now(); let end = Date.now(); while(end - start < dTime) { end = Date.now(); noOfCycles++; } return noOfCycles; } </script> </head> <body onload="initProgram()"> <h1>LoopTest</h1> <button id="startCode" onclick="startCode()">go!</button> <button id="check1" onclick="check1()">check1</button> <button id="check2" onclick="check2()">check2</button> </br></br> <div id="logOut">Log:</div> </body> <html> function check1() { setTimeout(logInfo, 3000, "check1"); } Log: start result: 91.35541192657692 ns check2 check1 let noOfCycles = 0; let time = 5000; let fractions = 100; let countDown = 0; function startCode() { logInfo("start"); countDown = fractions; noOfCycles = 0; setTimeout(getNoOfCycles, 0, (time / fractions)); } function check1() { logInfo("check1"); } function check2() { … function getNoOfCycles(dTime) { let start = Date.now(); let end = Date.now(); while(end - start < dTime) { end = Date.now(); noOfCycles++; } if (--countDown == 0) { let avgTime = time / noOfCycles; logInfo("result " + avgTime*1000000 + " ns"); } else { setTimeout(getNoOfCycles, 0, (time / fractions)); } } function getLocationInfo() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { logInfo(JSON.parse(xhr.responseText).country); } } xhr.open("GET", "http://ip-api.com/json", true); xhr.send(); } function getFakeInfo() { var success = 1; if (success == 1) { setTimeout(function() {logInfo("Germany")}, 100); } } function getFakeInfo() { var success = 1; if (success == 1) { setTimeout(() => {logInfo("Germany")}, 100); } } function requestFakeInfo(callback) { var success = 1; if (success == 1) { setTimeout(() => {callback("Germany")}, 100); } } … … function getFakeInfo() { requestFakeInfo(logInfo); } function requestFakeInfo(resolve, reject) { var success = Math.floor(Math.random() * 2); if (success == 1) { setTimeout(() => {resolve("Germany")}, 100); } else { setTimeout(() => {reject("Error in request")}, 100); } } … function getFakeInfo() { requestFakeInfo(logInfo, alert); } function requestFakeInfo() { return new Promise((resolve, reject) => { var success = Math.floor(Math.random() * 2); if (success == 1) { setTimeout(() => {resolve("Germany")}, 100); } else { setTimeout(() => {reject("Error in request")}, 100); } }); } … function getFakeInfo() { requestFakeInfo() .then(logInfo) .catch(alert); } <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <script src="fractalThread.js"></script> <script> … </script> </head> <body onload="prepareCanvas()"> <button id="noThread" onclick="startFractal ()">no Thread</button> <button id="withThread" onclick="startFractalThread()">Thread</button> <button id="check" onclick="addLogInfo('.')">check</button> </br></br> <canvas id="myCanvas" width="2048" height="1024"></canvas> <div id="logOut">Log:</div> </body> <html> let canv; let myContext; let subGraph; let counter = 0; … function prepareCanvas() { canv = document.getElementById("myCanvas"); myContext = canv.getContext("2d"); subGraph = myContext.createImageData(config.dimX, 1); } let cpuCount = 4; let dimY = 1024; let dimX = 2048; let pixelDist = 0.001; let maxIteration = 50; let worker = []; for (let i = 0; i < cpuCount; i++) { worker[i] = new Worker('fractalThread.js'); worker[i].addEventListener('message', function(e) { drawImage(e.data); }); } class FractalConfig { constructor(dimX, dimY, rFrom, rTo, maxIteration, pixelDist) { this.dimX = dimX; this.dimY = dimY; this.rFrom = rFrom; this.rTo = rTo; this.threshold = 10; this.maxIteration = maxIteration; this.pixelDist = pixelDist; this.startRe = 0.36001014891; this.startIm = 0.350001; this.halfDimRe = this.dimX / 2; this.halfDimIm = this.dimY / 2; this.thresSquare = this.threshold * this.threshold; this.sendMessage = false; } } let config = new FractalConfig(2048, 1024); function drawImage(data) { let calcResult = JSON.parse(data); let pixel = calcResult.pixel; let dat = subGraph.data; for (var y = calcResult.rTo - 1; y >= calcResult.rFrom; y--) { for (var x = 0; x < calcResult.dimX; x++) { dat[x*4+0] = (pixel[y][x] >> 16) & 0xff; dat[x*4+1] = (pixel[y][x] >> 8) & 0xff; dat[x*4+2] = pixel[y][x] & 0xff; dat[x*4+3] = 0xff; } myContext.putImageData(subGraph, 0, y ); } if (calcResult.rTo == dimY) { pixelDist /= 2; maxIteration += 50; counter++; addLogInfo("<br/>" + counter); } } function addLogInfo(info) { document.getElementById("logOut").innerHTML += info; } function startFractalThread() { let noLinesPerThread = dimY / cpuCount; let rFrom = 0; let rTo = 0; let threadCount = 0; for (let i = 1; i <= cpuCount; i++) { rTo = (i == cpuCount) ? dimY : i * noLinesPerThread; rTo = Math.floor(rTo); let config = new FractalConfig(dimX, dimY, rFrom, rTo); config.sendMessage = true; worker[i-1].postMessage(JSON.stringify(config)); rFrom = rTo; } } function startFractal() { let config = new FractalConfig(dimX, dimY, 0, dimY); config.sendMessage = false; drawImage(calcPixel(JSON.stringify(config))); } class ComplexNumber { constructor(re, im) { this.re = re; this.im = im; } square() { var r = this.re * this.re - this.im * this.im; var i = 2 * this.re * this.im; this.re = r; this.im = i; } getDistSquare() { return this.re * this.re + this.im * this.im; } addC(re, im) { this.re += re; this.im += im; } reset() { this.re = 0; this.im = 0; } } function calcPixel(data) { let config = JSON.parse(data); let pixel = Array(config.dimY); let z = new ComplexNumber(0, 0); let delta = 0xffffff / 2500; for (var r = config.rFrom; r < config.rTo; r++) { pixel[r] = Array(config.dimX); for (var c = 0; c < config.dimX; c++) { pixel[r][c] = 0; z.reset(); var posX = config.startRe - (config.halfDimRe - c) * config.pixelDist; var posY = -1*(config.startIm - (config.halfDimIm - r) * config.pixelDist); for (var i = 0; i < config.maxIteration; i++) { z.square(); z.addC(posX, posY); if (z.getDistSquare() > config.thresSquare) { pixel[r][c] = Math.floor(i * delta); break; } } } } let graphicData = { rFrom:config.rFrom, rTo:config.rTo, dimX:config.dimX, dimY:config.dimY, pixel:pixel }; var jsonData = JSON.stringify(graphicData); if (config.sendMessage) { self.postMessage(jsonData); } else { return jsonData; } } self.addEventListener('message', function(e) { calcPixel(e.data); }); chrome.exe --allow-file-access-from-files msedge.exe --allow-file-access-from-files import time def doWait(waitTime): print("before wait") time.sleep(waitTime) print("after wait") def startWaitCheck(): waitTime = 10 print("start") doWait(waitTime) print("end") startWaitCheck() start before wait after wait end import time from threading import Thread def doWait(waitTime): print("before wait") time.sleep(waitTime) print("after wait") def startWaitCheck(): waitTime = 10 myThread = Thread(target=doWait, args=(waitTime, )) print("start") myThread.start() print("end") myThread.join() startWaitCheck() start before waitend after wait import time import math from threading import Thread def calcRoots(id, noOfItr): print("start " + id) for i in range(0, noOfItr, 1): math.sqrt(i) def startLoadTestMT(): noOfThreads = 1 myThreads = [] noOfItr = 10000000 print("start main") for i in range(0, noOfThreads, 1): myThreads.append(Thread(target=calcRoots, args=("thrd." + str(i), noOfItr))) for myThread in myThreads: myThread.start() for myThreads in myThreads: myThreads.join() print("end main") start = time.time() startLoadTestMT() print("duration: " + str(time.time() - start)) import time import math from multiprocessing import Process def calcRoots(id, noOfItr): print("start " + id) for i in range(0, noOfItr, 1): math.sqrt(i) def startLoadTestMP(): noOfThreads = 8 myThreads = [] noOfItr = 10000000 print("start main") for i in range(0, noOfThreads, 1): myThreads.append(Process(target=calcRoots, args=("thrd." + str(i), noOfItr))) for myThread in myThreads: myThread.start() for myThreads in myThreads: myThreads.join() print("end main") if __name__ == '__main__': start = time.time() startLoadTestMP() print("duration: " + str(time.time() - start)) class CalcRoots(Thread): duration = 0 def __init__(self, id, noOfItr): Thread.__init__(self) self.id = id self.noOfItr = noOfItr def run(self): start = time.time() print("start " + self.id) for i in range(0, self.noOfItr , 1): math.sqrt(i) self.duration = time.time() - start print("duration of " + self.id + ": " + str(self.duration)) def startLoadTestOO(): noOfWorkObj = 8 myWorkObj = [] noOfIterations = 10000000 print("start main") for i in range(0, noOfWorkObj, 1): myWorkObj.append(CalcRoots("thrd." + str(i), noOfIterations)) for myWO in myWorkObj: myWO.start() for myWO in myWorkObj: myWO.join() print(myWO.duration) print("end main") import time import math from multiprocessing import Process, Queue class CalcRoots(Process): duration = 0 def __init__(self, myQueue, id, noOfItr): Process.__init__(self) self.id = id self.noOfItr = noOfItr self.myQueue = myQueue def run(self): start = time.time() print("start " + self.id) for i in range(0, self.noOfItr , 1): math.sqrt(i) duration = time.time() - start print("duration of " + self.id + ": " + str(duration)) self.myQueue.put([self.id, duration]) def startLoadTestOO(): noOfWorkObj = 8 myWorkObj = [] noOfIterations = 10000000 myQueue = Queue() print("start main") for i in range(0, noOfWorkObj, 1): myWorkObj.append(CalcRoots(myQueue, "thrd." + str(i), noOfIterations)) for myWO in myWorkObj: myWO.start() while 1: running = any(p.is_alive() for p in myWorkObj) while not myQueue.empty(): info = myQueue.get() print("duration: " + info[0] + " " + str(info[1])) if not running: break for myWO in myWorkObj: myWO.join() print("end main")