Die einfache Antwort lautet, dass nicht alle Threads gleichzeitig ausgeführt werden. Für eine ausführlichere Erklärung lesen Sie bitte weiter.
Der Task-Scheduler des Betriebssystems dient im Allgemeinen zum Planen von Anwendungen. Auf diese Weise können Sie eine Aufgabe ausführen, während der Computer an einer anderen arbeitet. In früheren Zeiten bestand der Lackmustest für Multitasking darin, eine Diskette zu formatieren und dabei etwas anderes zu tun. Wenn Sie das Betriebssystem wirklich testen möchten, müssen Sie eine Diskette formatieren, während Sie eine Datei über ein Modem herunterladen, das an die serielle Schnittstelle angeschlossen ist. Da die Hardware leistungsfähig genug wurde, um dies tatsächlich auf sinnvolle Weise zu tun, wurde in solchen Tests manchmal auch die Videowiedergabe durchgeführt. Wenn der Task Scheduler des Betriebssystems diese Aufgaben reibungslos ausführen könnte, könnte er alles erledigen.
Der Taskplaner plant jedoch keine Anwendungen (Prozesse), sondern Threads . Jede Anwendung verfügt über mindestens einen Thread, kann jedoch möglicherweise eine große Anzahl von Threads verwenden, um die von ihr ausgeführte Arbeit in verwandte oder unabhängige Teile aufzuteilen. In einer Anwendung ist es beispielsweise üblich, einen Thread zu haben, der die Benutzeroberfläche verwaltet, und einen anderen Thread zu erstellen, wenn der Benutzer einen möglicherweise lang andauernden Vorgang einleitet (z. B. Drucken, Neuberechnen einer Tabelle, Ausführen einer Entwicklungsumgebung) eine Symbolsuche usw. usw.). Einige Programmierumgebungen führen einige Threads ein, die für den Programmierer unsichtbar sind. zum Beispiel Java und .NET tun könnten Garbage Collectionin einem separaten Thread, der sich der unmittelbaren Kontrolle des Programmierers entzieht. Einige Programme erstellen frühzeitig eine Reihe von Threads und bündeln sie, da das Erstellen neuer Threads eine vergleichsweise teure Operation ist (Sie müssen also nicht unbedingt jedes Mal einen Thread erstellen, wenn Sie einen benötigen). Alles, was eine Vorschau ausführt, wird normalerweise in einem separaten Thread ausgeführt, sodass der Rest der Benutzeroberfläche während der Erstellung der Vorschau weiterhin reagiert. Und so weiter. Alles in allem bedeutet dies, dass die Anzahl der Threads im System jederzeit ein Vielfaches der Anzahl der Prozesse betragen kann.
Jeder Thread kann sich in einem von wenigen möglichen Status befinden, der wichtigste Unterschied besteht jedoch in den Status " Laufen" , " Laufen" und " Warten" . Die Terminologie kann leicht abweichen, aber das ist die allgemeine Idee. Zu jeder Zeit, nur ein Thread pro virtuellem (wegen der Hyper - Threading und ähnliche Technologien) CPU - Kern kann laufen (das heißt, Maschinencode Befehle ausführt), aber eine beliebige Anzahl von Threads können sein runnable (was bedeutet , dass es ein Kandidat zu bekommen die CPU, wenn der Scheduler das nächste Mal eine Entscheidung treffen muss, welcher Thread ausgeführt werden darf). Warten (auch als blockiert bezeichnet) Threads sind genau das, was auf etwas wartet - die häufigsten Fälle sind wahrscheinlich, dass sie auf Benutzer-, Festplatten- oder Netzwerk-E / A warten (insbesondere Benutzereingaben sind außergewöhnlich langsam).
Die im Task-Manager angezeigte Thread-Anzahl gibt die Gesamtzahl der Threads in einem dieser Status an. Auf dem Windows 7-System, auf dem ich dies schreibe, sind derzeit etwa 70 Prozesse gestartet, aber fast 900 Threads. Bei all den Hintergrundprozessen zur Bewältigung verschiedener Aufgaben und wie sie wahrscheinlich in eine Vielzahl von Threads unterteilt sind, ist dies keine unverschämte Zahl.
Der Task-Scheduler eines vorbeugenden Multitasking-Betriebssystems befasst sich in der Regel mit einer Art Hardware-Interrupt-Hook. Dies bedeutet, dass der Kernel die CPU anhalten kann, wenn er keine nützliche Arbeit zu erledigen hat (dies ist mit ziemlicher Sicherheit einer der Gründe, wenn nicht der Grund, warum Linux die HLTAnweisung beim Booten auf IA-32 überprüft-kompatible CPUs (und führt wahrscheinlich ähnliche Überprüfungen für andere Architekturen durch), in der Gewissheit, dass zu einem vernünftigen Zeitpunkt ein Interrupt ausgelöst und der Task-Scheduler aufgerufen wird. Da der Interrupt unabhängig von der von der CPU ausgeführten Arbeit ausgelöst wird (das ist die Idee, die hinter Interrupts steckt), wird der Scheduler regelmäßig ausgeführt und kann bestimmen, welcher Thread während der folgenden Zeitscheibe ausgeführt werden soll. Da Kontextwechsel relativ teuer sind, kann normalerweise (zumindest über den Quellcode) eingestellt werden, wie aggressiv der Scheduler zwischen Threads wechselt. Durch häufigeres Wechseln der Threads reagiert das System schneller, der Mehraufwand für das Wechseln bedeutet jedoch, dass die Gesamtzeit zum Beenden eines bestimmten Satzes von Tasks länger ist. Am schnellstenDas System wechselt nur dann zwischen Threads, wenn der laufende Thread nicht mehr ausgeführt werden kann (was bedeutet, dass er blockiert wird, wenn er auf etwas wartet oder seine Arbeit beendet hat), da dies den Overhead minimiert, während das am schnellsten reagierende System zwischen Threads wechselt Jedes Mal, wenn der Scheduler aufgerufen wird, wird die durchschnittliche Wartezeit minimiert, bevor ein bestimmter Thread CPU-Zeit erhält. Die ideale Einstellung liegt normalerweise irgendwo dazwischen, und der Kompromiss zwischen diesen Optionen ist wahrscheinlich ein wichtiger Grund, warum Linux mehrere Scheduler zur Auswahl sowie einige Optimierungsparameter über die Kernelkonfiguration anbietet.
Auf der anderen Seite verlassen sich kooperative Multitasking-Betriebssysteme und -Umgebungen ( Windows 3.x ist ein Beispiel) darauf, dass jede Anwendung die Kontrolle regelmäßig an den Scheduler übergibt. In der Regel gibt es eine API-Funktion, die speziell dafür vorgesehen ist, und oft tun dies viele API-Funktionen im Rahmen ihres internen Ausführungsflusses, da dies dazu beiträgt, die Benutzerfreundlichkeit zu verbessern. Dieser Entwurfsansatz funktioniert gut, solange sich alle Anwendungen gut verhalten und die Steuerung in kurzen Intervallen während lang andauernder Vorgänge (lang andauernd bedeutet mehr als einen kleinen Bruchteil einer Sekunde) abtreten, aber eine Anwendung, die nicht verstopfen kann das gesamte System. Dies ist ein wichtiger Grund, warum Windows 3.x beim oben erwähnten Multitasking-Test unter OS / 2 so schlecht abgeschnitten hatEnglisch: emagazine.credit-suisse.com/app/art...1007 & lang = en Eine Anwendung könnte das Diskettenlaufwerk anweisen, einen bestimmten Sektor zu schreiben, und die Zeit, die bis zur Rückgabe des Anrufs erforderlich war, könnte tatsächlich messbar sein (Dutzende bis Hunderte von Millisekunden oder Sekunden) Mehr); Bei einem präventiven Multitasking-System bricht der Scheduler beim nächsten geplanten Aufruf ein. Beachten Sie, dass der aktuell "laufende" Thread durch den Schreibaufruf blockiert wird, und wechseln Sie einfach zu einem anderen Thread, der ausgeführt werden kann. (In der Praxis ist es etwas komplizierter, aber das ist die allgemeine Idee.)
Sowohl in präventivem Multitasking als auch in kooperativen Umgebungen besteht die Möglichkeit, dass unterschiedliche Threads unterschiedliche Prioritäten haben. Beispielsweise ist es wahrscheinlich wichtiger, den Thread, der Daten über eine Kommunikationsverbindung empfängt, rechtzeitig auszuführen, als den Thread, der die Systemzeitanzeige aktualisiert, sodass der empfangende Thread eine hohe Priorität und der Updater-Thread für die Zeitanzeige eine niedrige Priorität hat . Thread-Prioritäten spielen eine Rolle bei der Entscheidung des Schedulers, welcher Thread ausgeführt werden soll (z. B. sehr vereinfacht)Threads mit hoher Priorität sollten immer vor Threads mit niedriger Priorität ausgeführt werden. Selbst wenn der Thread mit niedriger Priorität noch zu arbeiten hat, hat er Vorrang, wenn der Thread mit hoher Priorität ausführbar wird. Solche spezifischen Planungsentscheidungen haben jedoch keine Auswirkungen auf den zugrunde liegenden Mechanismusentwurf.