Auf einem preemptiven Kernel kann ein im Kernelmodus laufender Prozess durch einen anderen Prozess ersetzt werden, während er sich mitten in einer Kernelfunktion befindet.
Dies gilt nur für Prozesse, die im Kernelmodus ausgeführt werden, eine CPU, die Prozesse im Benutzermodus ausführt, gilt als "idle". Wenn ein Prozess im Benutzermodus einen Dienst vom Kernel anfordern möchte, muss er eine Ausnahme ausgeben, die der Kernel verarbeiten kann.
Als Beispiel:
Bearbeiten Sie A führt einen Ausnahmehandler aus, Prozess B durch eine IRQ-Anfrage geweckt wird, ersetzt der Kernel den Prozess A mit B (ein erzwungener Prozessschalter). Bearbeiten Sie A bleibt unvollendet. Der Scheduler entscheidet danach, ob A verarbeitet wird bekommt CPU-Zeit oder nicht.
Verarbeiten Sie auf einem nicht präemptiven Kernel A nur die gesamte Prozessorzeit verbraucht hätte, bis er fertig ist oder sich freiwillig dafür entscheidet, anderen Prozessen zu erlauben, ihn zu unterbrechen (ein geplanter Prozesswechsel).
Die heutigen Linux-basierten Betriebssysteme enthalten in der Regel keinen vollständig präemptiven Kernel, es gibt immer noch kritische Funktionen, die ohne Unterbrechung laufen müssen. Ich denke also, man könnte dies einen "selektiven präemptiven Kernel" nennen.
Abgesehen davon gibt es Ansätze, den Linux-Kernel (fast) vollständig präemptiv zu machen.
- Echtzeit-Linux-Wiki
- LWN-Artikel
die Vorrangigkeit ist -> Die Fähigkeit des Betriebssystems, eine aktuell geplante Aufgabe zugunsten einer Aufgabe mit höherer Priorität zu unterbrechen oder zu stoppen. Die Planung kann eine Prozess- oder E/A-Planung usw. sein, ist aber nicht darauf beschränkt.
Unter Linux waren User-Space-Programme schon immer präemptiv:Der Kernel unterbricht User-Space-Programme, um zu anderen Threads zu wechseln, indem er den regulären Takt verwendet. Der Kernel wartet also nicht darauf, dass User-Space-Programme den Prozessor explizit freigeben (was beim kooperativen Multitasking der Fall ist). Das bedeutet, dass eine Endlosschleife in einem User-Space-Programm das System nicht blockieren kann.
Bis 2.6er Kernel war der Kernel selbst jedoch nicht präemptiv:Sobald ein Thread in den Kernel eingetreten ist, konnte er nicht präemptiv zur Ausführung eines anderen Threads verdrängt werden. Dieses Fehlen einer Präemption im Kernel verursachte jedoch mehrere Probleme in Bezug auf Latenz und Skalierbarkeit. Daher wurde Kernel-Preemption in 2.6-Kernels eingeführt, und man kann es mit der Option CONFIG_PREEMPT aktivieren oder deaktivieren. Wenn CONFIG_PREEMPT aktiviert ist, kann Kernelcode überall präemptiv ausgeführt werden, außer wenn der Code lokale Interrupts deaktiviert hat. Eine Endlosschleife im Code kann nicht mehr das gesamte System blockieren. Wenn CONFIG_PREEMPT deaktiviert ist, wird das 2.4-Verhalten wiederhergestellt.
Rezitiert und formatiert von:http://www.linuxquestions.org/questions/linux-general-1/pre-emptive-vs-non-pre-emptive-kernel-582437/