it-swarm.dev

Was können mehrere Threads tun, was ein einzelner Thread nicht kann?

Während Threads die Ausführung von Code beschleunigen können, werden sie tatsächlich benötigt? Kann jeder Code mit einem einzigen Thread ausgeführt werden oder gibt es etwas, das nur mit mehreren Threads erreicht werden kann?

102
AngryBird

Erstens können Threads die Ausführung von Code nicht beschleunigen. Sie lassen den Computer nicht schneller laufen. Sie können lediglich die Effizienz des Computers steigern, indem sie Zeit verwenden, die sonst verschwendet würde. Bei bestimmten Verarbeitungsarten kann diese Optimierung die Effizienz erhöhen und die Laufzeit verkürzen.

Die einfache Antwort lautet ja. Sie können jeden Code schreiben, der in einem einzelnen Thread ausgeführt werden soll. Beweis: Ein einzelnes Prozessorsystem darf Anweisungen nur linear ausführen. Das Betriebssystem verfügt über mehrere Ausführungszeilen, die Interrupts verarbeiten, den Status des aktuellen Threads speichern und einen anderen starten.

Die Antwort komplex ist ... komplexer! Der Grund dafür, dass Multithread-Programme häufig effizienter sind als lineare, liegt in einem Hardware- "Problem". Die CPU kann Berechnungen schneller ausführen als Speicher- und Festplatten-E/A. So wird beispielsweise eine "add" -Anweisung viel schneller ausgeführt als ein "fetch". Caches und das Abrufen dedizierter Programmanweisungen (hier nicht genau bekannt) können dies bis zu einem gewissen Grad bekämpfen, aber das Geschwindigkeitsproblem bleibt bestehen.

Threading ist eine Möglichkeit, diese Nichtübereinstimmung zu bekämpfen, indem die CPU für CPU-gebundene Anweisungen verwendet wird, während IO Anweisungen abgeschlossen sind. Ein typischer Thread-Ausführungsplan wäre wahrscheinlich: Daten abrufen, Daten verarbeiten, Daten schreiben Das Abrufen und Schreiben dauert 3 Zyklen und die Verarbeitung dauert zur Veranschaulichung einen. Sie können sehen, dass der Computer beim Lesen oder Schreiben nichts für jeweils 2 Zyklen ausführt? Offensichtlich ist es faul und wir müssen unsere Optimierungspeitsche knacken!

Wir können den Prozess mithilfe von Threading neu schreiben, um diese verschwendete Zeit zu nutzen:

  1. # 1 holen
  2. keine Operation
  3. # 2 holen
  4. # 1 ist fertig, verarbeite es
  5. schreibe # 1
  6. # 1 holen
  7. # 2 ist fertig, verarbeite es
  8. schreibe # 2
  9. hol # 2

Und so weiter. Natürlich ist dies ein etwas ausgeklügeltes Beispiel, aber Sie können sehen, wie diese Technik die Zeit nutzen kann, die sonst für das Warten auf E/A aufgewendet würde.

Beachten Sie, dass das oben gezeigte Threading die Effizienz nur bei stark IO gebundenen Prozessen) steigern kann. Wenn ein Programm hauptsächlich Dinge berechnet, wird es nicht viele "Löcher" geben, in denen wir mehr arbeiten könnten Außerdem gibt es einen Overhead von mehreren Anweisungen beim Wechseln zwischen Threads. Wenn Sie zu viele Threads ausführen, verbringt die CPU die meiste Zeit mit dem Wechseln und arbeitet nicht viel an dem Problem. Dies wird als Thrashing bezeichnet =.

Das ist alles gut und schön für einen Single-Core-Prozessor, aber die meisten modernen Prozessoren haben zwei oder mehr Kerne. Threads dienen immer noch dem gleichen Zweck - um die CPU-Auslastung zu maximieren, aber dieses Mal können wir zwei separate Anweisungen gleichzeitig ausführen. zur gleichen Zeit. Dies kann abnehmen Laufzeit um einen Faktor von wie vielen Kernen verfügbar sind, da der Computer tatsächlich Multitasking und keine Kontextumschaltung ausführt.

Bei mehreren Kernen bieten Threads eine Methode zum Aufteilen der Arbeit zwischen den beiden Kernen. Das Obige gilt jedoch weiterhin für jeden einzelnen Kern; Ein Programm, das eine maximale Effizienz mit zwei Threads auf einem Kern ausführt, wird höchstwahrscheinlich mit einer maximalen Effizienz von etwa vier Threads auf zwei Kernen ausgeführt. (Die Effizienz wird hier durch minimale NOP-Befehlsausführungen gemessen.)

Die Probleme beim Ausführen von Threads auf mehreren Kernen (im Gegensatz zu einem einzelnen Kern) werden im Allgemeinen von der Hardware behoben. Die CPU stellt sicher, dass sie die entsprechenden Speicherplätze sperrt, bevor sie darauf liest/schreibt. (Ich habe gelesen, dass hierfür ein spezielles Flag-Bit im Speicher verwendet wird, dies kann jedoch auf verschiedene Arten erreicht werden.) Als Programmierer mit höheren Sprachen müssen Sie sich auf zwei Kernen keine Gedanken mehr machen müsste mit einem.

TL; DR: Threads können die Arbeit aufteilen, damit der Computer mehrere Aufgaben asynchron verarbeiten kann. Auf diese Weise kann der Computer mit maximaler Effizienz ausgeführt werden, indem die gesamte verfügbare Verarbeitungszeit genutzt wird, anstatt zu sperren, wenn ein Prozess auf eine Ressource wartet.

112
Michael K

Was können mehrere Threads tun, was ein einzelner Thread nicht kann?

Nichts.

Einfache Beweisskizze:

  • [Church-Turing-Vermutung] ⇒ Alles, was berechnet werden kann, kann von einer Universal Turing-Maschine berechnet werden.
  • Eine Universal-Turingmaschine ist mit einem Gewinde versehen.
  • Ergo kann alles, was berechnet werden kann, von einem einzelnen Thread berechnet werden.

Beachten Sie jedoch, dass dort eine große Annahme verborgen ist: Die verwendete Sprache innerhalb des einzelnen Threads ist Turing-vollständig.

Die interessantere Frage wäre also: "Kann das Hinzufügen von nur Multithreading zu einer nicht Turing-vollständigen Sprache Turing-vollständig machen?" Und ich glaube, die Antwort lautet "Ja".

Nehmen wir Total Functional Languages. [Für diejenigen, die nicht vertraut sind: Genau wie funktionale Programmierung mit Funktionen programmiert, programmiert Total Functional Programming mit Total Functions.]

Total Functional Languages ​​sind offensichtlich nicht Turing-vollständig: Sie können keine Endlosschleife in eine TFPL schreiben (tatsächlich ist das so ziemlich die Definition von "total"), aber Sie können = In einer Turing-Maschine gibt es daher mindestens ein Programm, das nicht in eine TFPL, sondern in eine UTM geschrieben werden kann. Daher sind TFPLs weniger rechenintensiv als UTMs.

Sobald Sie jedoch einer TFPL Threading hinzufügen, erhalten Sie Endlosschleifen: Führen Sie einfach jede Iteration der Schleife in einem neuen Thread aus. Jeder einzelne Thread gibt immer ein Ergebnis zurück, daher ist es Total, aber jeder Thread erzeugt auch einen neuen Thread, der die nächste Iteration ad infinitum ausführt.

Ich denke dass diese Sprache Turing-vollständig wäre.

Zumindest beantwortet es die ursprüngliche Frage:

Was können mehrere Threads tun, was ein einzelner Thread nicht kann?

Wenn Sie haben eine Sprache, die keine Endlosschleifen ausführen kann, dann Multithreading ermöglicht es Ihnen, Endlosschleifen auszuführen.

Beachten Sie natürlich, dass das Laichen eines Threads ein Nebeneffekt ist und unsere erweiterte Sprache daher nicht nur nicht mehr vollständig, sondern auch nicht mehr funktionsfähig ist.

38
Jörg W Mittag

Theoretisch kann alles, was ein Multithread-Programm tut, auch mit einem Single-Thread-Programm ausgeführt werden, nur langsamer.

In der Praxis kann der Geschwindigkeitsunterschied so groß sein, dass man kein Single-Thread-Programm für die Aufgabe verwenden kann. Z.B. Wenn Sie jeden Abend einen Batch-Datenverarbeitungsjob ausführen und es mehr als 24 Stunden dauert, bis ein einzelner Thread abgeschlossen ist, haben Sie keine andere Möglichkeit, als ihn multithreaded zu machen. (In der Praxis ist der Schwellenwert wahrscheinlich sogar noch niedriger: Oft müssen solche Aktualisierungsaufgaben am frühen Morgen abgeschlossen sein, bevor Benutzer das System wieder verwenden. Außerdem können andere Aufgaben von ihnen abhängen, die ebenfalls in derselben Nacht abgeschlossen werden müssen Die verfügbare Laufzeit kann nur wenige Stunden/Minuten betragen.)

Das Ausführen von Computerarbeiten an mehreren Threads ist eine Form der verteilten Verarbeitung. Sie verteilen die Arbeit auf mehrere Threads. Ein weiteres Beispiel für verteilte Verarbeitung (mit mehreren Computern anstelle mehrerer Threads) ist der SETI-Bildschirmschoner: Das Knacken so vieler Messdaten auf einem einzelnen Prozessor würde schrecklich lange dauern, und die Forscher würden es vorziehen, die Ergebnisse vor der Pensionierung zu sehen ;-) Sie jedoch Sie haben nicht das Budget, einen Supercomputer so lange zu mieten, deshalb verteilen sie den Job auf Millionen von Haushalts-PCs, um ihn billig zu machen.

22
Péter Török

Obwohl Threads ein kleiner Schritt von der sequentiellen Berechnung zu sein scheinen, stellen sie tatsächlich einen großen Schritt dar. Sie verwerfen die wichtigsten und attraktivsten Eigenschaften der sequentiellen Berechnung: Verständlichkeit, Vorhersagbarkeit und Determinismus. Threads als Berechnungsmodell sind absolut nicht deterministisch, und die Aufgabe des Programmierers besteht darin, diesen Nichtdeterminismus zu beschneiden.

- Das Problem mit Threads (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf).

Die Verwendung von Threads bietet zwar einige Leistungsvorteile, da Sie die Arbeit auf mehrere Kerne verteilen können, sie sind jedoch häufig mit einem hohen Preis verbunden.

Einer der Nachteile bei der Verwendung von Threads, die hier noch nicht erwähnt wurden, ist der Verlust der Ressourcenkompartimentierung, der bei Prozessbereichen mit einem Thread auftritt. Angenommen, Sie stoßen auf einen Segfault. In einigen Fällen ist es möglich, dies in einer Multiprozessanwendung zu beheben, indem Sie einfach das fehlerhafte Kind sterben lassen und ein neues wieder erscheinen lassen. Dies ist im Apache-Prefork-Backend der Fall. Wenn eine httpd-Instanz ausfällt, ist der schlimmste Fall, dass die bestimmte HTTP-Anforderung für diesen Prozess möglicherweise gelöscht wird, Apache jedoch ein neues untergeordnetes Element erzeugt und häufig die Anforderung, wenn sie nur erneut gesendet und bearbeitet wird. Das Endergebnis ist, dass Apache als Ganzes nicht mit dem fehlerhaften Thread entfernt wird.

Eine weitere Überlegung in diesem Szenario sind Speicherlecks. Es gibt einige Fälle, in denen Sie einen Thread-Absturz ordnungsgemäß behandeln können (unter UNIX ist die Wiederherstellung von bestimmten Signalen - sogar Segfault/Fpviolation - möglich), aber selbst in diesem Fall haben Sie möglicherweise den gesamten von diesem Thread zugewiesenen Speicher verloren (Malloc, neu usw.). Während Ihr Prozess möglicherweise weiterlebt, verliert er mit der Zeit mit jedem Fehler/jeder Wiederherstellung mehr und mehr Speicher. Auch hier gibt es bis zu einem gewissen Grad Möglichkeiten, dies zu minimieren, wie beispielsweise die Verwendung von Speicherpools durch Apache. Dies schützt jedoch immer noch nicht vor Speicher, der möglicherweise von Bibliotheken von Drittanbietern zugewiesen wurde, die der Thread möglicherweise verwendet hat.

Und wie einige Leute betont haben, ist es vielleicht am schwierigsten, Synchronisationsprimitive zu verstehen, um sie wirklich richtig zu machen. Dieses Problem an sich - nur die allgemeine Logik für Ihren gesamten Code richtig zu machen - kann große Kopfschmerzen verursachen. Mysteriöse Deadlocks können in den seltsamsten Zeiten auftreten, und manchmal erst, wenn Ihr Programm in Produktion ist, was das Debuggen umso schwieriger macht. Hinzu kommt, dass die Synchronisationsprimitive je nach Plattform häufig stark variieren (Windows vs. POSIX) und das Debuggen oft schwieriger sein kann, sowie die Möglichkeit, dass die Rennbedingungen jederzeit (Start/Initialisierung, Laufzeit und Herunterfahren) möglich sind. Das Programmieren mit Threads hat für Anfänger wirklich wenig Gnade. Und selbst für Experten gibt es immer noch wenig Gnade, nur weil das Wissen über das Einfädeln selbst die Komplexität im Allgemeinen nicht minimiert. Jede Zeile mit Thread-Code scheint manchmal die Gesamtkomplexität des Programms exponentiell zu verschärfen und die Wahrscheinlichkeit zu erhöhen, dass ein versteckter Deadlock oder eine seltsame Race-Bedingung jederzeit auftaucht. Es kann auch sehr schwierig sein, Testfälle zu schreiben, um diese Dinge herauszufinden.

Aus diesem Grund sind einige Projekte wie Apache und PostgreSQL größtenteils prozessbasiert. PostgreSQL führt jeden Backend-Thread in einem separaten Prozess aus. Dies lindert natürlich immer noch nicht das Problem der Synchronisation und der Rennbedingungen, aber es bietet einiges an Schutz und vereinfacht in gewisser Weise die Dinge.

Mehrere Prozesse, die jeweils einen einzelnen Ausführungsthread ausführen, können viel besser sein als mehrere Threads, die in einem einzelnen Prozess ausgeführt werden. Mit dem Aufkommen eines Großteils des neuen Peer-to-Peer-Codes wie AMQP (RabbitMQ, Qpid usw.) und ZeroMQ ist es viel einfacher, Threads auf verschiedene Prozessbereiche und sogar auf Maschinen und Netzwerke aufzuteilen, was die Dinge erheblich vereinfacht. Trotzdem ist es keine Silberkugel. Es gibt immer noch Komplexität zu bewältigen. Sie verschieben einfach einige Ihrer Variablen aus dem Prozessbereich in das Netzwerk.

Das Fazit ist, dass die Entscheidung, in den Bereich der Threads einzutreten, nicht leicht fällt. Sobald Sie dieses Gebiet betreten, wird fast augenblicklich alles komplexer und ganz neue Arten von Problemen treten in Ihr Leben ein. Es kann lustig und cool sein, aber es ist wie Atomkraft - wenn etwas schief geht, kann es schlecht und schnell gehen. Ich erinnere mich, dass ich vor vielen Jahren einen Kurs in Kritikalitätstraining besucht habe und Bilder von Wissenschaftlern in Los Alamos gezeigt habe, die im Zweiten Weltkrieg in den Labors mit Plutonium gespielt haben. Viele haben wenig oder gar keine Vorsichtsmaßnahmen gegen den Fall einer Exposition getroffen, und im Handumdrehen - in einem einzigen hellen, schmerzlosen Blitz wäre alles für sie vorbei. Tage später waren sie tot. Richard Feynman bezeichnete dies später als " kitzelt den Drachenschwanz ." So kann das Spielen mit Threads sein (zumindest für mich). Es scheint auf den ersten Blick ziemlich harmlos zu sein, und wenn Sie gebissen werden, kratzen Sie sich am Kopf, wie schnell die Dinge sauer wurden. Aber zumindest werden dich Threads nicht töten.

11
Mike Owens

Erstens wird eine Single-Threaded-Anwendung niemals eine Multi-Core-CPU oder ein Hyper-Threading nutzen. Aber selbst auf einem Single-Core hat eine Single-Threaded-CPU mit Multithreading Vorteile.

Überlegen Sie sich die Alternative und ob Sie das glücklich macht. Angenommen, Sie haben mehrere Aufgaben, die gleichzeitig ausgeführt werden müssen. Zum Beispiel müssen Sie weiterhin mit zwei verschiedenen Systemen kommunizieren. Wie geht das ohne Multithreading? Sie würden wahrscheinlich Ihren eigenen Scheduler erstellen und ihn die verschiedenen Aufgaben aufrufen lassen, die ausgeführt werden müssen. Dies bedeutet, dass Sie Ihre Aufgaben in Teile aufteilen müssen. Sie müssen wahrscheinlich einige Echtzeitbeschränkungen erfüllen und sicherstellen, dass Ihre Teile nicht zu viel Zeit in Anspruch nehmen. Andernfalls läuft der Timer bei anderen Aufgaben ab. Dies erschwert die Aufteilung einer Aufgabe. Je mehr Aufgaben Sie selbst verwalten müssen, desto mehr Aufteilung müssen Sie vornehmen und desto komplexer wird Ihr Scheduler, um alle Einschränkungen zu erfüllen.

Wenn Sie mehrere Threads haben, kann das Leben einfacher werden. Ein vorbeugender Scheduler kann einen Thread jederzeit stoppen, seinen Status beibehalten und einen anderen neu starten. Es wird neu gestartet, wenn Ihr Thread an der Reihe ist. Vorteile: Die Komplexität des Schreibens eines Schedulers wurde bereits für Sie erledigt und Sie müssen Ihre Aufgaben nicht aufteilen. Außerdem kann der Scheduler Prozesse/Threads verwalten, die Sie selbst nicht einmal kennen. Und wenn ein Thread nichts tun muss (er wartet auf ein Ereignis), nimmt er keine CPU-Zyklen in Anspruch. Dies ist nicht so einfach zu erreichen, wenn Sie Ihren Down-Single-Threaded-Scheduler erstellen. (Etwas einzuschlafen ist nicht so schwierig, aber wie wacht es auf?)

Der Nachteil der Multithread-Entwicklung besteht darin, dass Sie sich mit Parallelitätsproblemen, Sperrstrategien usw. auskennen müssen. Das Entwickeln von fehlerfreiem Multithread-Code kann sehr schwierig sein. Und das Debuggen kann noch schwieriger sein.

10
Mark

gibt es etwas, das nur mit mehreren Threads erreicht werden kann?

Ja. Sie können keinen Code auf mehreren CPUs oder CPU-Kernen mit einem einzigen Thread ausführen.

Ohne mehrere CPUs/Kerne können Threads weiterhin Code vereinfachen, der konzeptionell parallel ausgeführt wird, z. B. die Clientbehandlung auf einem Server. Ohne Threads können Sie jedoch dasselbe tun.

9
Mud

Bei Threads geht es nicht nur um Geschwindigkeit, sondern auch um Parallelität.

Wenn Sie keine Batch-Anwendung wie von @Peter vorgeschlagen haben, sondern ein GUI-Toolkit wie WPF, wie können Sie mit nur einem Thread mit Benutzern und Geschäftslogik interagieren?

Angenommen, Sie erstellen einen Webserver. Wie würden Sie mehr als einen Benutzer gleichzeitig mit nur einem Thread bedienen (vorausgesetzt, keine anderen Prozesse)?

Es gibt viele Szenarien, in denen nur ein einfacher Thread nicht ausreicht. Aus diesem Grund finden jüngste Fortschritte wie der Intel MIC-Prozessor mit mehr als 50 Kernen und Hunderten von Threads statt.

Ja, parallele und gleichzeitige Programmierung ist schwierig. Aber notwendig.

Durch Multithreading kann die GUI-Schnittstelle während langer Verarbeitungsvorgänge weiterhin reagieren. Ohne Multithreading würde der Benutzer nicht mehr in der Lage sein, ein gesperrtes Formular zu beobachten, während ein langer Prozess ausgeführt wird.

6
LarsTech

Multithread-Code kann die Programmlogik blockieren und auf veraltete Daten zugreifen, wie dies bei einzelnen Threads nicht möglich ist.

Threads können einen obskuren Fehler von etwas nehmen, von dem ein durchschnittlicher Programmierer erwarten kann, dass er ihn debuggt, und ihn in den Bereich verschieben, in dem Geschichten über das Glück erzählt werden, das erforderlich ist, um denselben Fehler mit heruntergelassenen Hosen zu erkennen, wenn ein aufmerksamer Programmierer zufällig nur den richtiger Moment.

5
bmike

apps, die sich mit Blockierung befassen IO, die auch auf andere Eingaben (die GUI oder andere Verbindungen) reagieren müssen), können nicht als Singlethread erstellt werden

das Hinzufügen von Überprüfungsmethoden in der Bibliothek IO lib), um zu sehen, wie viel ohne Blockierung gelesen werden kann, kann dies helfen, aber nicht viele Bibliotheken geben hierfür vollständige Garantien

4
ratchet freak

Viele gute Antworten, aber ich bin mir nicht sicher, ob ich es so formulieren würde - vielleicht bietet dies eine andere Sichtweise:

Threads sind nur eine Vereinfachung der Programmierung wie Objekte oder Akteure oder für Schleifen (Ja, alles, was Sie mit Schleifen implementieren, können Sie mit if/goto implementieren).

Ohne Threads implementieren Sie einfach eine State Engine. Ich musste dies viele Male tun (Das erste Mal, als ich es tat, hatte ich noch nie davon gehört - ich habe nur eine große switch-Anweisung gemacht, die von einer "State" -Variablen gesteuert wird). Zustandsautomaten sind immer noch weit verbreitet, können aber ärgerlich sein. Mit Fäden verschwindet ein riesiger Teil der Kesselplatte.

Sie erleichtern es einer Sprache auch, ihre Laufzeitausführung in mehrere CPU-freundliche Blöcke zu unterteilen (Schauspieler auch, glaube ich).

Java bietet "grüne" Threads auf Systemen, auf denen das Betriebssystem keine Threading-Unterstützung bietet. In diesem Fall ist es einfacher zu erkennen, dass es sich eindeutig nur um eine Programmierabstraktion handelt.

4
Bill K

Erstens können Threads zwei oder mehr Dinge gleichzeitig ausführen (wenn Sie mehr als einen Kern haben). Sie können dies zwar auch mit mehreren Prozessen tun, einige Aufgaben sind jedoch nicht sehr gut auf mehrere Prozesse verteilt.

Außerdem enthalten einige Aufgaben Leerzeichen, die Sie nicht einfach vermeiden können. Zum Beispiel ist es schwierig, Daten aus einer Datei auf der Festplatte zu lesen und Ihren Prozess gleichzeitig etwas anderes tun zu lassen. Wenn für Ihre Aufgabe unbedingt viele Daten von der Festplatte gelesen werden müssen, wird Ihr Prozess viel Zeit damit verbringen, auf die Festplatte zu warten, unabhängig davon, was Sie tun.

Zweitens können Sie mithilfe von Threads vermeiden, dass Sie große Mengen Ihres Codes optimieren müssen, die nicht leistungskritisch sind. Wenn Sie nur einen Thread haben, ist jeder Code leistungskritisch. Wenn es blockiert, sind Sie versunken - keine Aufgaben, die durch diesen Prozess erledigt würden, können Fortschritte machen. Bei Threads wirkt sich ein Block nur darauf aus, dass Threads und andere Threads kommen und an Aufgaben arbeiten können, die von diesem Prozess ausgeführt werden müssen.

Ein gutes Beispiel ist der selten ausgeführte Fehlerbehandlungscode. Angenommen, eine Aufgabe stößt auf einen sehr seltenen Fehler, und der Code zur Behandlung dieses Fehlers muss in den Speicher verschoben werden. Wenn die Festplatte ausgelastet ist und der Prozess nur einen einzigen Thread hat, kann kein Vorwärtsfortschritt erzielt werden, bis der Code zur Behandlung dieses Fehlers in den Speicher geladen werden kann. Dies kann zu einer Berstreaktion führen.

Ein anderes Beispiel ist, wenn Sie möglicherweise sehr selten eine Datenbanksuche durchführen müssen. Wenn Sie auf die Antwort der Datenbank warten, wird Ihr Code eine große Verzögerung erfahren. Sie möchten sich jedoch nicht die Mühe machen, den gesamten Code asynchron zu machen, da dies so selten vorkommt, dass Sie diese Suchvorgänge durchführen müssen. Mit einem Thread für diese Arbeit erhalten Sie das Beste aus beiden Welten. Ein Thread für diese Arbeit macht es nicht leistungskritisch, wie es sein sollte.

0
David Schwartz

Betriebssysteme verwenden das Time-Slicing-Konzept, bei dem jeder Thread seine Ausführungszeit erhält und dann vorab geprüft wird. Ein solcher Ansatz kann das derzeitige Threading ersetzen, aber das Schreiben eigener Scheduler in jeder Anwendung wäre übertrieben. Außerdem müssten Sie mit E/A-Geräten usw. arbeiten. Und würde Unterstützung von der Hardwareseite erfordern, damit Sie Interrupts auslösen können, damit Ihr Scheduler ausgeführt wird. Grundsätzlich würden Sie jedes Mal ein neues Betriebssystem schreiben.

Im Allgemeinen kann Threading die Leistung verbessern, wenn Threads auf E/A warten oder schlafen. Außerdem können Sie reaktionsschnelle Schnittstellen erstellen und Prozesse stoppen, während Sie lange Aufgaben ausführen. Außerdem verbessert Threading die Situation auf echten Multicore-CPUs.

0
Coder