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.
:
Bearbeitet durch User
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.
Jens G. schrieb: > Auch bleibt das für kooperativen Multitasking typische Hängenbleiben des > Gesamtsystems aus, wenn mal ein Prozess unkooperativ wird RTOS für sicherheitskritische Anwendungen verwenden kooperatives Multitasking, weil preemptives Multitasking nicht-deterministisches Laufzeit-Verhalten hat, das zumindest bislang nicht letztendlich beherrschbar ist: https://de.wikipedia.org/wiki/Priorit%C3%A4tsinversion https://de.wikipedia.org/wiki/Berechenbarkeitstheorie http://electronics.stackexchange.com/questions/78439/what-are-the-benefits-of-a-non-preemptive-os-and-the-price-for-these-benefits
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.