Context schaltet schlafende / wartende Threads ein

Ich versuche zu verstehen, wie Betriebssysteme mit der Kontextumschaltung in verschiedenen Modellen umgehen, um besser zu verstehen, warum die NIO-Leistung bei großen Anforderungsspitzen besser ist. Abgesehen von der Tatsache, dass die Anzahl der Threads begrenzt sein kann, bin ich gespannt, wie sich das Blockieren von Vorgängen in dieser großen Anzahl von Anforderungen auf die Ressourcennutzung auswirken kann.

Bei einer Anforderung pro Thread-Modell, z. B. einer Servlet 2.5-basierten Webanwendung, wechselt der Betriebssystemkontext zwischen all diesen 500 Threads, um den benötigten zu finden, wenn 499 Threads auf die Datenbank-E / A warten und nur ein Thread ausgeführt werden muss Arbeit? Um einen Kontextwechsel durchzuführen, muss das Betriebssystem den aktuellen Thread-Status speichern und den Status des nächsten Threads wiederherstellen. Danach stellt das Betriebssystem fest, dass es keine CPU-Zeit benötigt, und wechselt so lange den Kontext, bis es den Thread findet, der Arbeit benötigt. Wie sieht dies auch im Hinblick auf die Servernutzung aus? Ist die CPU niedrig, da sie meist nur an die IO-Kosten für das Ein- und Auslagern von Kontexten gebunden ist, anstatt tatsächlich etwas zu berechnen?

Vielen Dank im Voraus für jede Hilfe. Wenn Sie mich in die Richtung von Büchern, Lehrbüchern usw. lenken können, würde ich das auch sehr begrüßen.

Antworten auf die Frage(2)

Ihre Antwort auf die Frage