Prozess wird von Scheduler verdrängt....

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Prozess wird von Scheduler verdrängt…
Hi,
wenn ein laufender Prozess durch einen Scheduler verdrängt wird, ist er dann sofort wieder bereit, oder wird er zunächst blockiert und dann erst wieder bereit ??

doch blockiert
ich glaube er kann nicht sofort wieder bereit sein-
nach laufend kann er entweder blockieren oder terminieren-
nach unserem Schema aus Skript …

er ist bereit
ihm fehlt nur das Betriebsmittel CPU, somit ist er sofort wieder im Zustand bereit, ohne zu blockieren


alles klar. vielen dank


Nein, das stimmt nicht!

Auf Seite VII-16 gibt es eine Kante von laufend nach bereit
(relinquish). Das ist genau die Situation, wenn ein Prozess
den Prozessor aufgrund der Scheduling-Entscheidung aufgibt.

Das „durch den Scheduler verdraengen“ funktioniert ja so, dass
ein Prozess per system call oder einen anderen trap in den Systemkern wechselt
(also von Ebene 3 auf Ebene 2 nach Seite III-34).
Im Betriebssystemprogramm ruft er dann die Schedulerfunktion auf und
stellt da drin quasi selbst fest, dass er „sich jetzt selbst verdraengen muss“ und
ruft als Folge dessen die relinquish-Funktion auf (oder wie immer die im jeweiligen
Betriebssystem heisst). Vorher sucht er in der Scheduling-Funktion noch den
Prozess aus, den er statt dessen aktivieren moechte.
relinquish und Aktivieren des Nachfolge-Prozesses ist dann letztlich eine
Aktion (entspricht einem Koroutinen-Wechsel). Dabei geht der aufrufende
Prozess in den Zustand bereit und der nachfolger wechselt von bereit nach
laufend.


Ja, aber wie funktioniert dann Vollverdrängung?
Denn was ist, wenn ein Prozess längere Zeit keinen Trap verursacht?


soweit ich das verstanden hab, kommt dann irgendwann ein poses art clock signal(hardwaremaessig realisiert ?!?) und entreisst den prozessor das programm. :wink:
Der prozess ist dann zwar immer noch bereit aber wird nicht mehr abgearbeitet.


Also eigentlich müsste der schedular regelmäßig durch einen Interupt aufgerufen werden. Zumindes war das bei meinem uC-schedular so. Ich vermute mal dass bei unterschiedlichen Zeitscheiben einfach der Timer entsprechend eingestellt wird.
Also wird der schedular entweder

  • durch das Programm selber aufgerufen (legt sich selber schlafen).
  • durch einen Timerinterupt aufgerufen.
  • durch das OS aufgerufen, weil ein Prozess auf ein Betriebsmittel warten muss(zB pagefault - trap). - Wenn der trap ohne verzögerung behoben werden kann müsste das Programm doch den Rest seiner Zeitscheibe weiterarbeiten dürfen, oder?

Im zweiten Fall kann der Shedular kann der Prozess den Prozess ja gleich wieder einlasten - es ist ja durchaus bereit.