Antworten:
Auf einem präemptiven Kernel kann ein Prozess, der im Kernelmodus ausgeführt wird, während der Ausführung einer Kernelfunktion durch einen anderen Prozess ersetzt werden.
Dies gilt nur für Prozesse, die im Kernelmodus ausgeführt werden. Eine CPU, die Prozesse im Benutzermodus ausführt, wird als "inaktiv" betrachtet. Wenn ein Benutzermodus-Prozess einen Dienst vom Kernel anfordern möchte, muss er eine Ausnahme ausgeben, die der Kernel behandeln kann.
Als Beispiel:
Process Aführt einen Exception-Handler aus, Process Bwird durch eine IRQ-Anfrage aufgeweckt, der Kernel ersetzt Process Adurch B(einen erzwungenen Prozesswechsel). Prozess Ableibt unvollendet. Der Scheduler entscheidet danach, ob der Prozess ACPU-Zeit bekommt oder nicht.
Auf einem nicht vorbeugenden Kernel Ahätte der Prozess nur die gesamte Prozessorzeit in Anspruch genommen, bis er fertig ist, oder freiwillig entschieden, dass andere Prozesse ihn unterbrechen (ein geplanter Prozesswechsel).
Heutige Linux-basierte Betriebssysteme enthalten in der Regel keinen vollständig präemptiven Kernel. Es gibt immer noch wichtige Funktionen, die ohne Unterbrechung ausgeführt werden müssen. Man könnte das also einen "selektiven präventiven Kernel" nennen.
Abgesehen davon gibt es Ansätze, um den Linux-Kernel (fast) vollständig präemptiv zu machen.
Die Einschränkung ist -> Die Fähigkeit des Betriebssystems, eine aktuell geplante Aufgabe zu Gunsten einer Aufgabe mit höherer Priorität zu deaktivieren oder zu beenden. Die Planung kann eine Prozess- oder E / A-Planung usw. sein, ist jedoch nicht darauf beschränkt.
Unter Linux waren User-Space-Programme immer verboten: Der Kernel unterbricht User-Space-Programme, um mithilfe des normalen Taktsymbols zu anderen Threads zu wechseln. Der Kernel wartet also nicht darauf, dass User-Space-Programme den Prozessor explizit freigeben (was beim kooperativen Multitasking der Fall ist). Dies bedeutet, dass eine Endlosschleife in einem User-Space-Programm das System nicht blockieren kann.
Bis 2.6 Kernel war der Kernel selbst nicht vorinstallierbar: Sobald ein Thread in den Kernel eingetreten ist, konnte er nicht vorinstalliert werden, um einen anderen Thread auszuführen. Dieses Fehlen einer Vorbelegung im Kernel verursachte jedoch verschiedene Probleme hinsichtlich Latenz und Skalierbarkeit. Daher wurde die Kernel-Preemption in 2.6-Kerneln eingeführt, und man kann sie mit der Option CONFIG_PREEMPT aktivieren oder deaktivieren. Wenn CONFIG_PREEMPT aktiviert ist, kann der Kernel-Code überall vorgezogen 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.
Zitiert und formatiert von: http://www.linuxquestions.org/questions/linux-general-1/pre-emptive-vs-non-pre-emptive-kernel-582437/
Mit einem vorläufigen Kernel kann ein Prozess vorgezogen werden, während er im Kernelmodus ausgeführt wird. Ein nicht vorbeugender Kernel lässt nicht zu, dass ein Prozess, der im Kernel-Modus ausgeführt wird, vorbeugt. Ein Kernel-Modus-Prozess wird ausgeführt, bis er den Kernel-Modus verlässt, blockiert oder freiwillig die Kontrolle über die CPU abgibt. Offensichtlich ist ein nicht vorbeugender Kernel im Wesentlichen frei von Race-Bedingungen für Kerneldatenstrukturen, da jeweils nur ein Prozess im Kernel aktiv ist. Wir können nicht dasselbe über präemptive Kernel sagen, daher müssen sie sorgfältig entworfen werden, um sicherzustellen, dass freigegebene Kerneldaten frei von Race-Bedingungen sind. Preemptive Kernel sind für SMP-Architekturen besonders schwierig zu entwerfen, da in diesen Umgebungen zwei Kernel-Mode-Prozesse gleichzeitig auf verschiedenen Prozessoren ausgeführt werden können. Ein präemptiver Kernel ist besser für die Echtzeitprogrammierung geeignet. Dies ermöglicht es einem Echtzeitprozess, einen aktuell im Kernel ausgeführten Prozess zu verhindern. Darüber hinaus kann ein präemptiver Kernel reaktionsfähiger sein, da das Risiko geringer ist, dass ein Kernel-Modus-Prozess für einen beliebig langen Zeitraum ausgeführt wird, bevor der Prozessor an wartende Prozesse übergeben wird. Natürlich kann dieser Effekt minimiert werden, indem Kernel-Code entworfen wird, der sich nicht auf diese Weise verhält. Im weiteren Verlauf dieses Kapitels erfahren Sie, wie verschiedene Betriebssysteme die Preemption innerhalb des Kernels verwalten. Dieser Effekt kann minimiert werden, indem Kernel-Code entworfen wird, der sich nicht auf diese Weise verhält. Im weiteren Verlauf dieses Kapitels erfahren Sie, wie verschiedene Betriebssysteme die Preemption innerhalb des Kernels verwalten. Dieser Effekt kann minimiert werden, indem Kernel-Code entworfen wird, der sich nicht auf diese Weise verhält. Im weiteren Verlauf dieses Kapitels erfahren Sie, wie verschiedene Betriebssysteme die Preemption innerhalb des Kernels verwalten.