Zitat:
Wenn du lediglich das Hängen der Anwendung vermeiden willst, reicht es ja schon, wenn du die Berechnung insgesamt in einen eigenen Thread verlagerst.
Hab ich ja schon..
Einen der nur für die berechnungen zuständig ist.
Ich verstehe nicht warum ein System nicht in der lage ist zu erkennen wenn ein core ausgelastet ist
um dann diesen auf die übrigen zu verteilen.
Was für einen Sinn hat sonst ein 4 Kern prozessor wenn er nicht dynamisch vom system verwaltet wird
um eventuelle auslastungen eines Kerns zu verhindern.
Doch. Genau das macht das System (bzw. Konkret: Der sogenannte 'Scheduler' des Betriebssystems) ja auch.
Bitte versteh das jetzt nicht falsch, aber mir scheint Dir fehlen ein bisschen die Grundlagen beim Multithreading.
Versuchen wir das also mal aufzuräumen, dann verstehst Du auch die Problematik dahinter und siehst vielleicht auch Lösungsansätze bei Deinem konkreten Problem.
Erstens: Multithreading kommt von multiple threads. Nicht von einen Thread (Faden) auf mehrere CPUs/Kerne verteilen.
Das Betriebsystem (bzw. wieder der Scheduler), verwaltet mehrere Prozesse. Jeder Prozess hat mindestens einen (Haupt-)Thread und kann daneben noch mehrere andere Nebenläufige Threads haben.
Der Scheduler kann nun die einzelnen Threads der unterschiedlichen Prozesse je nach ihrer Priorität auf die verfügbaren Kerne verteilen.
Damit irgendwann mal alle Prozesse laufen, kann ein gerade laufender Thread zu jedem beliebigen Zeitpunkt eingefroren und ein anderer Thread (ggf. des gleichen oder eines anders Prozesses) an dem Zeitpunkt seines letztens Einfrierens weitergelaufen lassen werden. Diesen Wechsel des gerade ausgeführten Threads auf einem Kern nennt man Kontextwechsel (und das ist ein relativ teurer Prozess, da dabei der Teil des Programmes mit allen Daten im Stack-Speicher aus allen Registern des Kerns und dem jeweiligen First- und Second-Level Cache der CPU in einen anderen Speicherbereich kopiert wird, und der neue Thread mit allen seinen aktuellen Nutzdaten in die Register der CPU und die Caches reinkopiert werden muss).
Daraus ergibt sich dann auch folgendes: Mehr Threads = mehr Kontextwechsel = mehr Rechenaufwand. Ab einer gewissen Anzahl an Threads wird Multithreading also sogar wieder Kontraproduktiv.
Zurück zum Thread: Einer davon kann immer nur auf genau einem Kern laufen.
Ein Thread ist dabei der Ablauf eines konkreten Pfades in einem Programm.
Stelle Dir z.B. eine längere Funktion vor, die Du programmiert hast. Diese Funktion wird Operation für Operation nacheinander auf einem Kern abgearbeitet. Dabei kann es *jederzeit* zwischen zwei Operationen zu einem STOP Deiner Programmausführung und zu einem Kontextwechsel kommen (z.B. Dein Audioplayer berechnet die nächsten 15ms Soundausgabe vor). Danach läuft dann Dein Programm wieder weiter.
Wie würdest Du nun versuchen wollen, diese lange Funktion auf zwei Kernen gleichzeitig auszuführen?
Das ist unmöglich, denn die Operationen in Deiner Funktion müssen ja nacheinander ausgeführt werden, oder?
Stell Dir vor Du hast ein Programm mit 64 Zeilen Code. Und einen Rechner mit 64 Kernen. Und alle Kerne würden absolut Zeitgleich(!) beginnen, jeweils eine Zeile Deines Programmes abzuarbeiten. Ginge das? Was ist, wenn Zeile 63 eine Variable Benötigt, die erst in Zeile 30 berechnet wird, und zwar aus Werten die aus Zeile 4 und 5 kommen?
Da ein Kern nicht in die Zukunft sehen kann, und die anderen Kerne ja noch nicht mit ihrer Berechnung fertig sind, müsste er warten, bis alle vorherigen Kerne jeweils ihre eine einzige Operation ausgeführt haben. Dann kann das auch gleich nur auf einem Kern laufen.
Dir bleibt also nur, zu einem *definierten* Zeitpunkt in Deinem Programm zu sagen, dass ein neuer Thread gestartet wird.
Diesem gibst Du eine Methode mit, die dann in diesem anderen Thread abgearbeitet wird.
Dieser Thread läuft möglicherweise(!) parallel zu Deinem Hauptthread ab. Oder hinterher. Oder vorher. Du hast hier kaum Einfluss darauf, da der Scheduler des Betriebssystems die Threads auf die Kerne verteilt. Ist die Methode die in dem Thread ablaufen soll dann Zuende berechnet und folgen keine weiteren Anweisungen mehr, so wird der Thread beendet. Die anderen Threads Deines Programmes haben lediglich die Möglichkeit (solange sie gerade laufen), andere Deiner Threads ggf. zu pausieren, pausierte wieder zu starten oder zu beenden. Solange ein Thread pausiert, wird er vom Scheduler nicht mehr eingesetzt.
So, bleibt nur noch ein Problem: Die Synchronisierung.
Alle Threads Deines Prozesses haben Zugriff auf den gleichen (Heap-) Speicher. Lediglich der Stack ist pro Thread separat.
Wenn Du also ein Objekt hast, und auf dieses Objekt aus mehreren Threads zugreifst, teilen sich die Threads die Daten.
Nun Stell Dir vor, auf dem Objekt ist ein (
Unicode)String-Property.
Thread 1 befüllt dieses Property gerade aus einer Benutzereingabe. Benutzer tippt langsam, und der Scheduler schiebt zwischendurch ein paar mal den Audioplayer für ein paar Millisekunden rein.
Thread 2 liest nun den Inhalt des Strings.
Der Zustand des Strings ist zu keinem Zeitpunkt wohldefiniert. Es kann durchaus passieren, dass Thread 1 eingefroren wird, nachdem er nur ein enzelnes Byte eines gerade eingetippten Zeichens in den Speicher geschrieben hat, und das zweite
Unicode-Byte des Zeichens noch gar nicht im Objekt abgelegt wurde.
Wenn nun während dieser Pause Thread 2 den String liest, dann bekommt er nur halbfertig geschrieben Daten.
Damit so etwas nicht passiert und sichergestellt ist, das ein Thread nur valide Daten bekommt, gibt es methoden zur Thread-Synchronisierung. z.B. Mutexe.
Grob gesagt muss Thread 1 den Speicherbereich des Strings vor dem Schreiben sperren. Jeder der lesen will, muss gucken ob der speicher nicht gesperrt ist. Wenn ja, wird dem Scheduler gesagt: "Pausiere mich, bis der bereich frei ist". Thread 1 kann in Ruhe schreiben und nimmt die Sperre hinterher weg. Dann laufen die anderen lesenden Threads weiter.
Der Trick beim Mutithreading ist also
1.) Seine Aufgaben SO auf mehrere Threads aufzuteilen, dass diese Sperren (Locks) so selten wie möglich genutzt werden müssen und
2.) Herauszufinden, wie viele Threads optimal sind um eine Beschleunigung zu erzielen und wie wenig Threads optimal sind, um nicht zu viele Kontextwechsel zu provozieren.