Was passiert bei Blocking Calls im Betriebssystem?



  • Hi,

    ich frage mich gerade, was ein Betriebssystem bei "Blocking Calls" auf dem Prozessor ausführt. Es wird ja nicht den Befehl so lange "aktiv" halten bis das Ergebnis von der Hardware da ist oder?. Da ich leider recht wenig Verständnis von Assembler habe, kann ich mir die Frage nicht selber beantworten. Ich freue mich auf eure Antworten 🙂



  • Hi,

    der Scheduler des Betriebssystems weisst dem Thread keine Rechenzeit mehr zu. Sobald die Daten da sind auf die der Thread wartet (das Betriebssystem weiss, wenn ein Thread auf Daten von einem Gerät wartet) wird ihm wieder Rechenzeit zugewiesen, die Funktion läuft zu Ende durch und gibt die Kontrolle wieder an dein Programm ab.
    Wenn du das nicht ganz verstehst, guck dir mal verträngendes Multitasking an.



  • Ist es dann eine gute Art und Weise, einen Thread, der auf das Ergebnis eines solchen Calls wartet, zu "killen" (beispielsweise unter Windows per TerminateThread), wenn man z. B. sein Programm geschlossen hat und nicht länger warten will? Und man natürlich keine Möglichkeit hat, den Call anderweitig abzubrechen 😃



  • Wenn der Thread sich aufgrund von falschem Code in einem Blocking Call "aufhängt" bleibt einem ja nichts anderes übrig. Aber moderne Betriebssysteme können damit gut umgehen und machen eigentlich keine Probleme.



  • prozess x will von der festplatte lesen. das dauert, also legt das OS den prozess schlafen. in der zwischenzeit bekommen andere prozesse die cpu zur verfügung gestellt. wenn für x dann die daten bereit stehen, wird der prozess wieder geweckt.



  • Blocker schrieb:

    Hi,

    ich frage mich gerade, was ein Betriebssystem bei "Blocking Calls" auf dem Prozessor ausführt. Es wird ja nicht den Befehl so lange "aktiv" halten bis das Ergebnis von der Hardware da ist oder?. Da ich leider recht wenig Verständnis von Assembler habe, kann ich mir die Frage nicht selber beantworten. Ich freue mich auf eure Antworten 🙂

    nicht alle Aufrufe kann das Betriebssystem sofort erledigen.
    Das einfachste Beispiel ist wohl ein Sleep(...) Aufruf: Der Prozess sagt dem OS, dass es x Sekunden pausiert werden will.
    Das OS vermerkt sich, wann der Prozess wieder geweckt werden soll, und vermerkt außerdem, dass der Prozess jetzt pausiert ist.

    Dann schaut es in der Liste aller Prozesse nach, welcher Prozess stattdessen die CPU zur Verfügung gestellt bekommt. Dieser Prozess lauft dann eine Zeit lang (bis dessen maximale Zeitspanne überschritten ist, oder dieser selbst einen blockierenden Aufruf macht), danach ist es Zeit für den nächsten Prozess.

    Das OS bekommt über Interrupts mit, wenn der Timer Baustein "tickt", also z.B. 1ms weitergezählt hat. Irgendwann ist der Zeitpunkt erreicht, an dem unser Prozess wieder geweckt werden möchte. Das OS führt dazu wiederum einen Task Switch durch, sodass unser Prozess wieder läuft.

    Noch kurz zum Task Switch: Die CPU hat ein Register(instruction pointer, "EIP"), in welchem immer vermerkt ist, von welcher Adresse der nächste Befehl gelesen werden soll.
    Wenn das OS einen Prozess auswechselt, so merkt es sich, welche Adresse in dem Register war. Beim erneuten aktivieren wird diese Adresse wieder in das Register geschrieben, sodass die CPU genau mit dem passenden Befehl weitermacht.
    (Natürlich passiert bei einem Task Switch viel mehr)



  • Killer schrieb:

    Ist es dann eine gute Art und Weise, einen Thread, der auf das Ergebnis eines solchen Calls wartet, zu "killen" (beispielsweise unter Windows per TerminateThread), wenn man z. B. sein Programm geschlossen hat und nicht länger warten will? Und man natürlich keine Möglichkeit hat, den Call anderweitig abzubrechen 😃

    Threads zu killen ist nie "eine gute Möglichkeit".
    Man hat auch praktisch immer andere Möglichkeiten als den Thread einfach abzuschiessen.

    Und wenn alle Stricke reissen, dann würde ich den Prozess killen.



  • @player424
    Ich finde "Rechenzeit zuweisen" sehr esoterisch ausgedrückt. Ich kann mir nicht vorstellen dass sich da jmd. was drunter vorstellen kann.

    @fsdfdsfs
    Du versuchst zwar das ganze etwas genauer zu beschreiben. Was nett ist. Aber das Thema ist denke ich einfach zu komplex um es in 5-10 Sätzen zu beschreiben.



  • hustbaer schrieb:

    @fsdfdsfs
    Du versuchst zwar das ganze etwas genauer zu beschreiben. Was nett ist. Aber das Thema ist denke ich einfach zu komplex um es in 5-10 Sätzen zu beschreiben.

    Das Betriebssystem verwaltet die Threads. Wenn ein Thread nun auf ein Ereignis wartet (wie zB er hat Sleep() aufgerufen oder wartet auf das ankommenen eines TCP Pakets auf der Netzwerkkarte) dann wird der Thread schlafen gelegt. Das Betriebssystem verteilt konstant die Rechenzeiten auf die einzelnen Threads - eine CPU kann ja, vereinfacht gesagt, nur einen Befehl gleichzeitig ausfuehren und somit simuliert das Betriebssystem nur die Faehigkeit mehreres gleichzeitig machen zu koennen in dem es sehr schnell zwischen den einzelnen Threads hin und her schaltet. Wenn ein Thread nun schlaeft und auf etwas wartet, wird ihm keine Zeit auf der CPU zugewiesen und alle anderen Threads haben mehr Zeit ihre Arbeit zu erledigen.

    So in etwa?



  • @Shade Of Mine
    Ja, das ist gut.
    Auf dieser Abstraktionsebene geht das noch.
    fsdfdsfs hat halt ein Level niedriger angesetzt (Timer, Register, ...), und da wird's mit 5-10 Sätzen einfach knapp.


Log in to reply