Hallo,
ich habe eine Verständnisfrage und hoffe mit eurer Hilfe etwas Licht in
mein Dunkel zu bekommen.
Angenommen ich habe ein OS und zwei Apps, zwischen denen hin- und
hergeschaltet werden soll. Also der Kernel soll für ein schönes
Scheduling zwischen beiden Apps sorgen.
Der Kernel läuft im "Privilege Level 0" (PL0) und die Apps in PL1.
Dh. zwischen den Apps switchen, Scheduling, kann ich nur, wenn ich mich
im PL0 befinde, oder?
Wenn ich im PL0 bin und (ein bißchen) App1 ausführen will, wechselt der
Kernel mit einem Syscall in PL1.
So. Um in PL0 zurückzuwechseln muss App1 jetzt selbst einen Syscall
ausführen, oder?
Aber woher weiß App1, wann es den Syscall ausführen muss?
Eigentlich möchte App1 doch solange den Prozessor besetzen wie es kann,
bzw. bis App1 fertig ist.
Wie unterbricht der Kernel App1, wenn der Kernel zur Zeit gar nicht
aktiv ist, solange der App1 in PL1 arbeitet?
alexP schrieb:> Um in PL0 zurückzuwechseln muss App1 jetzt selbst einen Syscall> ausführen, oder?
Das ist nur im kooperativen Multitasking so. Im /preemptiven
Multitasking/ erfolgt ein Taskwechsel auch ohne Mitwirkung der Tasks
z.B. beim Auftreten von Hardwareinterrupts wie dem Timerinterrupt.
Taskswitching erledigt bei Win der Taskmanager und die Taskpriorisierung
hat per se mal nix mit dem Privileglevel zu tun.
guck ma:
https://www.lowlevel.eu/wiki/Protected_Mode
Heinz V. schrieb:> Taskswitching erledigt bei Win der Taskmanager
Der Threadstarter schrieb "ein OS", ohne sich auf ein konkretes
Betriebssystem zu beziehen.
Das Taskswitching macht unter Windows übrigens der Scheduler; der
Taskmanager ist nur ein Programm zur Anzeige der Taskliste und anderen
Informationen.
Rufus Τ. F. schrieb:> Der Threadstarter schrieb "ein OS", ohne sich auf ein konkretes> Betriebssystem zu beziehen.>> Das Taskswitching macht unter Windows übrigens der Scheduler; der> Taskmanager ist nur ein Programm zur Anzeige der Taskliste und anderen> Informationen.
Jo, hast ja recht, allerdings wird der 'normale' Nutzer eher den
Taskmanager als Frontend zu Gesicht bekommen als den Scheduler.
Heinz V. schrieb:> allerdings wird der 'normale' Nutzer eher den Taskmanager als Frontend> zu Gesicht bekommen als den Scheduler.
Der Scheduler ist nicht mit dem Scheduler zu verwechseln ("Geplante
Tasks"), und auch unnormale Benutzer bekommen den für die
Taskumschaltung zuständigen Scheduler nie zu Gesicht. Bei keinem
Betriebssystem.
Rufus Τ. F. schrieb:> Der Scheduler ist nicht mit dem Scheduler zu verwechseln ("Geplante> Tasks"), und auch unnormale Benutzer bekommen den für die> Taskumschaltung zuständigen Scheduler nie zu Gesicht. Bei keinem> Betriebssystem.
Ja, ich hab grade in winnt/system32 nachgeschaut, es gibt keine
scheduler.exe, muss wohl irgendeine DLL mit nicht aussagekräftigem Namen
sein.
Auch Preemptive Multitasking hat kooperative Taskwechsel.
Der uebliche Systemcall fuer Taskwechsel ist sind
Delay, Waitsemaphore, Waitforsingleobject, Waitformultipleobjects.
Ausser Delay, sieht man die nicht, sondern die sind in Multithreaded
Objekten, sowie in Treibern drin.
Preemptive Multitasking ist kooperatives Multitasking plus Zeitscheiben.
@ Heinz V. (heinz_v)
>Ja, ich hab grade in winnt/system32 nachgeschaut, es gibt keine>scheduler.exe, muss wohl irgendeine DLL mit nicht aussagekräftigem Namen>sein.
Der Scheduler ist Teil des Kernels. Das ist also keine separater
Prozess.
@ Noch nicht Rentner
>Auch Preemptive Multitasking hat kooperative Taskwechsel.>Der uebliche Systemcall fuer Taskwechsel ist sind>Delay, Waitsemaphore, Waitforsingleobject, Waitformultipleobjects.>Ausser Delay, sieht man die nicht, sondern die sind in Multithreaded>Objekten, sowie in Treibern drin.>Preemptive Multitasking ist kooperatives Multitasking plus Zeitscheiben.
Das ist ganz einfach Interprozesskommunikation (IPC), worüber sich die
Prozesse miteinander kontrolliert unterhalten und synchronisieren
können. Das hat nix mit dem eigentlichen kooperativen Multitasking zu
tun. Daß der Kernel/Scheduler aber solche Systemcalls dazu nutzt, um
einen Taskwechsel zu machen, ist halt nur logisch, denn zum Warten
braucht ein Prozess ja eigentlich keine CPU-Zeit.
Auch bleibt das für kooperativen Multitasking typische Hängenbleiben des
Gesamtsystems aus, wenn mal ein Prozess unkooperativ wird.
alexP schrieb:> Der Kernel läuft im "Privilege Level 0" (PL0) und die Apps in PL1.> Dh. zwischen den Apps switchen, Scheduling, kann ich nur, wenn ich mich> im PL0 befinde, oder?
Der Scheduler ist Teil des Kernels, läuft also unter PL0.
> Wenn ich im PL0 bin und (ein bißchen) App1 ausführen will, wechselt der> Kernel mit einem Syscall in PL1.
Der Begriff Syscall wird verwendet, wenn eine Anwendung (PL1) einen
Dienst des Kernels in Anspruch nehmen möchte. Der Kernel selbst führt
üblicherweise keine Syscalls aus, denn innerhalb des Kernels reicht ein
Funktionsaufruf.
Der Scheduler im Kernel aktiviert also einfach App1 (setzt also die
Datenstrukturen passend und führt ein "Return To Userspace" oder
äquivalent aus).
> So. Um in PL0 zurückzuwechseln muss App1 jetzt selbst einen Syscall> ausführen, oder?
Bei kooperativem Multitasking: Ja.
Bei präemptivem Multitasking: Nicht zwingend. App1 darf jederzeit
unterbrochen werden.
> Aber woher weiß App1, wann es den Syscall ausführen muss?
Bei kooperativem Multitask: Wann immer App1 mit den anderen Apps
kooperieren möchte. Außerdem üblicherweise immer dann, wenn App1 einen
Syscall ausführt (um z.B. die nächste Eingabe zu erhalten, also "sage
mir, wo die Maus geklickt hat", "sage mir, welche Taste gedrückt
wurde").
> Eigentlich möchte App1 doch solange den Prozessor besetzen wie es kann,> bzw. bis App1 fertig ist.
Wenn App1 nicht auf Eingaben reagiert (weil sie z.B. eine komplexe
Rechnung durchführt), dann blockiert App1 den Prozessor (bei
kooperativem Multitasking).
> Wie unterbricht der Kernel App1, wenn der Kernel zur Zeit gar nicht> aktiv ist, solange der App1 in PL1 arbeitet?
Wenn ein Interrupt feuert (z.B. die Netzwerkkarte hat ein Paket
erhalten, die Maus wurde bewegt, eine Taste wurde gedrückt), dann muss
der Kernel darauf immer reagieren. Der Scheduler im Kernel entscheidet
dann, ob er App1 weiterhin ausführen möchte oder nicht.
Bei präemptivem Multitasking wird vom Timer regelmäßig (z.B. alle 10ms)
ein Interrupt ausgelöst, der den Scheduler anweist, auch andere Apps
ranzulassen.
