it-swarm.com.de

Thread-Kontextwechsel Vs. Prozesskontextwechsel

Kann mir jemand sagen, was in beiden Situationen genau gemacht wird? Was kostet jeder von ihnen am meisten?

93
Leon

Der Hauptunterschied zwischen einem Threadwechsel und einem Prozesswechsel besteht darin, dass während eines Threadwechsels der virtuelle Speicherplatz derselbe bleibt, nicht aber während eines Prozesswechsels .. .. Beide Typen beinhalten die Übergabe der Kontrolle an den Betriebssystemkern führen Sie den Kontextwechsel durch. Der Vorgang des Ein- und Ausschaltens des OS-Kerns zusammen mit den Kosten des Auswechselns der Register sind die größten Fixkosten für die Durchführung eines Kontextwechsels.

Unscharfere Kosten sind, dass ein Kontextwechsel mit den Cache-Mechanismen der Prozessoren einhergeht. Wenn Sie den Kontext wechseln, werden alle Speicheradressen, die der Prozessor in seinem Cache "speichert", praktisch unbrauchbar. Der große Unterschied besteht hier darin, dass beim Ändern des virtuellen Speicherplatzes der Translation Lookaside Buffer (TLB) oder ein gleichwertiger Prozessor des Prozessors geleert wird, wodurch Speicherzugriffe für eine Weile erheblich teurer werden. Dies geschieht nicht während eines Threadwechsels.

165
Abhay Buch

Bei der Prozesskontextumschaltung wird der Speicheradressenraum umgeschaltet. Dazu gehören Speicheradressen, Zuordnungen, Seitentabellen und Kernelressourcen - ein relativ teurer Vorgang. Bei einigen Architekturen bedeutet dies sogar das Leeren verschiedener Prozessor-Caches, die nicht über Adressräume gemeinsam genutzt werden können. Zum Beispiel muss x86 den TLB leeren, und einige ARM - Prozessoren müssen den gesamten L1-Cache leeren!

Threadwechsel ist Kontextwechsel von einem Thread zu einem anderen im selben Prozess (das Wechseln von Thread zu Thread über Prozesse ist nur Prozesswechsel). Das Wechseln des Prozessorzustands (wie der Programmzähler und der Registerinhalt) ist im Allgemeinen sehr effizient. 

9
aditya dogra

Zunächst bringt das Betriebssystem ausgehenden Thread in einen Kernelmodus, wenn es nicht bereits vorhanden ist, da Threadwechsel nur zwischen Threads ausgeführt werden kann, die im Kernelmodus ausgeführt werden. Dann wird der Scheduler aufgerufen, um eine Entscheidung über den Thread zu treffen, zu dem das Umschalten ausgeführt wird. Nachdem die Entscheidung getroffen wurde, speichert der Kernel einen Teil des Thread-Kontexts, der sich in der CPU (CPU-Register) befindet, an der dedizierten Stelle im Arbeitsspeicher (häufig auf dem Kernel-Stack des ausgehenden Threads). Dann führt der Kernel den Wechsel vom Kernel-Stack des ausgehenden Threads auf den Kernel-Stack des eingehenden Threads durch. Danach lädt der Kernel den zuvor gespeicherten Kontext des eingehenden Threads aus dem Speicher in die CPU-Register. Und kehrt schließlich wieder in den Benutzermodus zurück, jedoch im Benutzermodus des neuen Threads. Wenn das Betriebssystem festgestellt hat, dass eingehende Threads in einem anderen -Prozess ausgeführt werden, führt der Kernel einen zusätzlichen Schritt aus: Setzt einen neuen aktiven virtuellen Adressraum.

Die Hauptkosten in beiden Szenarien hängen mit einer Cache-Verschmutzung zusammen. In den meisten Fällen unterscheidet sich der von dem abgehenden Thread verwendete Arbeitssatz erheblich von dem Arbeitssatz, der vom eingehenden Thread verwendet wird. Infolgedessen beginnt der ankommende Thread mit einer Lawine von Cache-Fehlern in seinem Leben, wodurch alte und nutzlose Daten aus den Caches gelöscht und die neuen Daten aus dem Speicher geladen werden. Gleiches gilt für TLB (Translation Look Aside Buffer, der sich auf der CPU befindet). Beim Zurücksetzen des virtuellen Adressraums (Threads werden in verschiedenen Prozessen ausgeführt) ist die Strafe sogar noch schlimmer, da das Zurücksetzen des virtuellen Adressraums zum Leeren des gesamten TLBs even führt, wenn tatsächlich nur ein neuer Thread geladen werden muss einige neue Einträge. Infolgedessen beginnt der neue Thread sein Zeitquantum mit vielen TLB-Fehlern und häufigem Seitenaufruf. Die direkten Kosten für den Thread-Wechsel sind ebenfalls nicht unerheblich (von ~ 250 bis zu ~ 1500-2000 Zyklen) und hängen von der CPU-Komplexität, den Zuständen beider Threads und den von ihnen tatsächlich verwendeten Registersätzen ab.

P.S .: Guter Beitrag zum Kontextwechsel: http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

8
ZarathustrA
  • Prozessumschaltung: es ist ein Übergang zwischen zwei prozessbehafteten Speichern in einer Multiprogrammierungsumgebung;
  • Kontextumschaltung: Es handelt sich um einen sich ändernden Kontext von einem ausführenden Programm zu einer Interrupt-Service-Routine (ISR).
3
john

Beim Thread Context Switching bleibt der virtuelle Speicherplatz derselbe, während dies beim Process Context Switch nicht der Fall ist. Außerdem ist der Prozesskontextwechsel teurer als der Threadkontextwechsel.

2
Palak Jain

Obwohl die Thread-Kontextumschaltung den Ausführungskontext (Register, Stapelzeiger, Programmzähler) ändern muss, muss der Adressraum nicht geändert werden, wie dies bei Kontextumschaltungen von Prozessen der Fall ist. Es entstehen zusätzliche Kosten, wenn Sie den Adressraum wechseln, auf mehr Speicher zugreifen (Paging, Segmentierung usw.) und den TLB leeren müssen, wenn Sie einen neuen Prozess starten oder beenden ...

0
Herr Günther

Ich denke, der Hauptunterschied besteht darin, switch_mm() aufzurufen, die Speicherdeskriptoren für alte und neue Aufgaben behandelt. Im Falle von Threads ist der Adressraum des virtuellen Speichers unverändert (Threads teilen sich den virtuellen Speicher), so dass sehr wenig getan werden muss und daher weniger Kosten verursachen.

0
Dražen G.