Sam
Was bedeutet “Systemaufruf blockieren”?
In meinem Kurs zu Betriebssystemen studieren wir die Multithread-Programmierung. Ich bin mir nicht sicher, was gemeint ist, wenn ich in meinem Lehrbuch lese: “Es kann zulassen, dass ein anderer Thread ausgeführt wird, wenn ein Thread einen blockierenden Systemaufruf durchführt.”
Ein blockierender Systemaufruf muss warten, bis die Aktion abgeschlossen werden kann. read() wäre ein gutes Beispiel – wenn keine Eingabe bereit ist, bleibt es dort und wartet, bis eine bereit ist (vorausgesetzt, Sie haben es natürlich nicht auf nicht blockierend gesetzt, in diesem Fall wäre es kein blockierender Systemaufruf ). Während ein Thread auf einen blockierenden Systemaufruf wartet, kann ein anderer Thread natürlich etwas anderes tun.
Dies bedeutet, dass, wenn ein Benutzer-Thread diesen blockierenden Systemaufruf verwendet hat, er wartet (dieser Thread ist blockiert) und ein anderer Benutzer-Thread dem Kernel-Thread zuordnen kann, der dem vorherigen ?
– Sam
11. Oktober 2013 um 2:26 Uhr
Ich habe keine Ahnung, welchen Kurs Sie nehmen oder was es Ihnen zu sagen versucht, aber ich könnte es mir vorstellen. Ein Many-to-One-Multithreading-Modell verknüpft mehrere Benutzer-Threads mit einem einzigen Kernel-Thread. Wenn sich dieser Kernel-Thread in einem blockierenden Systemaufruf befindet, müssen alle damit verbundenen Benutzer-Threads ebenfalls warten. Bei einem Eins-zu-Eins-Modell ist dies nicht der Fall, da alle Benutzer-Threads ihren eigenen Kernel-Thread haben, sodass, wenn ein Kernel-Thread blockiert ist, ein anderer etwas anderes tun kann.
– Krähenmann
11. Oktober 2013 um 2:34 Uhr
Ich habe so ziemlich die gleiche Frage. wenn es ein Viele-zu-Eins-Modell ist und wenn ein Benutzer-Thread einen blockierenden Systemaufruf machen möchte. Müssen alle anderen Threads auch aufhören? (Können nur Kernel-Threads Systemaufrufe machen?)
– Codebewusst
13. Mai 2017 um 18:14 Uhr
@PaulGriffiths Was ist die Beziehung zwischen blockierenden Anrufen und Ertragspunkten? (Im nesC-Papier gibt es in diesem Satz eine implizite Beziehung zwischen ihnen: „Wir müssten blockierende Aufrufe in atomaren Abschnitten verbieten sowie blockierende Aufrufe als Ertragspunkte für die Aufgabenplanung behandeln.)
– Novemberland
7. Oktober 2017 um 21:00 Uhr
@Novemberland: Ein Ertragspunkt ist ein geeigneter Ort (z. B. ein Ort, an dem er keinen exklusiven Zugriff auf eine gemeinsam genutzte Ressource hat), an dem eine Aufgabe die Möglichkeit hat, ihre Ausführung freiwillig aufzugeben. Normalerweise möchte er dies tun, bevor seine Zeitscheibe überschritten wird. Da ein blockierender Systemaufruf für lange Zeit blockiert werden könnte, möglicherweise weit über die Zeitscheibe der Aufgabe hinaus, wäre die Eingabe eines Aufrufs ein idealer Ort für einen Yield Point in einem System, in dem Aufgaben freiwillig die Kontrolle abgeben.
– Krähenmann
8. Oktober 2017 um 5:28 Uhr
Bei einem blockierenden Systemaufruf kann der Aufrufer nichts tun, bis der Systemaufruf zurückkehrt. Wenn der Systemaufruf langwierig sein kann (z. B. Datei-IO oder Netzwerk-IO einbeziehen), kann dies eine schlechte Sache sein (z. B. stellen Sie sich einen frustrierten Benutzer vor, der in einer Anwendung auf die Schaltfläche „Abbrechen“ hämmert, die nicht antwortet, weil dieser Thread blockiert ist und auf a wartet Paket aus dem Netzwerk, das nicht ankommt). Um dieses Problem zu umgehen (um nützliche Arbeit zu leisten, während Sie auf die Rückkehr eines blockierenden Systemaufrufs warten), können Sie Threads verwenden – während ein Thread blockiert ist, können die anderen Threads weiterhin nützliche Arbeit leisten.
Die Alternative sind nicht blockierende Systemaufrufe. In diesem Fall kehrt der Systemaufruf (fast) sofort zurück. Bei längeren Systemaufrufen wird das Ergebnis des Systemaufrufs entweder später an den Anrufer gesendet (z. B. als eine Art Ereignis oder Nachricht oder Signal) oder von dem Anrufer später abgefragt. Auf diese Weise können Sie einen einzelnen Thread haben, der darauf wartet, dass viele verschiedene lange Systemaufrufe gleichzeitig ausgeführt werden. und vermeidet den Ärger mit Threads (und Sperren, Race-Bedingungen, den Overhead von Thread-Wechseln usw.). Es erhöht jedoch auch den Aufwand, der mit dem Abrufen und Verarbeiten der Ergebnisse des Systemaufrufs verbunden ist.
Es ist (fast immer) möglich, einen nicht blockierenden Wrapper um einen blockierenden Systemaufruf zu schreiben; wobei der Wrapper einen Thread erzeugt und (fast) sofort zurückkehrt, und der erzeugte Thread den blockierenden Systemaufruf ausführt und entweder die Ergebnisse des Systemaufrufs an den ursprünglichen Aufrufer sendet oder sie dort speichert, wo der ursprüngliche Aufrufer sie abfragen kann.
Es ist auch (fast immer) möglich, einen blockierenden Wrapper um einen nicht blockierenden Systemaufruf zu schreiben; wo der Wrapper den Systemaufruf ausführt und auf die Ergebnisse wartet, bevor er zurückkehrt.
Welche Beziehung besteht zwischen nicht blockierenden Systemaufrufen und Split-Phase-Operationen? Das zweite ist nur eine kleine Teilmenge des ersten? Gibt es andere Arten von Operationen in Bezug auf nicht blockierende Systemaufrufe? Oder sind sie ein und dasselbe? Danke im Voraus!
– Novemberland
7. Oktober 2017 um 20:57 Uhr
Hartmut
Ich würde vorschlagen, diesen sehr kurzen Text zu lesen:
http://files.mkgnu.net/files/upstare/UPSTARE_RELEASE_0-12-8/manual/html-multi/x755.html
Insbesondere können Sie dort nachlesen, warum das Blockieren von Systemaufrufen bei Threads und nicht nur bei gleichzeitigen Prozessen ein Problem sein kann:
Dies ist besonders problematisch für Anwendungen mit mehreren Threads, da das Blockieren eines Threads bei einem Systemaufruf die Aktualisierung des Codes eines anderen Threads auf unbestimmte Zeit verzögern kann.
Ich hoffe es hilft.
