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.
Globale Ersetzungsstrategie: Interrupt statt Trap bei Seitenfehler
Hallo,
diese Tatsache dürfte zwar nicht klausurrelevant sein, aber mich würde interessieren, warum man bei einer globalen Ersetzungsstrategie einen Interrupt und keinen Trap bei einem Seitenfehler bekommt? Ist eigentlich ein Trap nicht auch intern ein Interrupt, mit dem Unterschied, dass ein trap nur im lokalen Adressraum eines Prozesses wirken kann?
Vielen Dank!
Vergiss das am besten wieder ganz schnell - das ist ein Verwirrungsversuch von wosch. :rolleyes: Die Überlegung geht in etwa folgendermaßen:
Da man nicht weiß, welche Seiten wann ausgelagert werden, kann man auch nicht vorhersagen, an welcher Stelle im Programm ein Seitenfehler auftreten wird. In diesem Einzelaspekt verhalten sich Seitenfehler im Kontext einer globalen Ersetzungsstrategie ein ganz kleines bisschen ähnlich wie Interrupts.
Das ist aber nicht das entscheidende Kriterium! Entscheidend ist, ob die Ausnahme synchron zum Programmverlauf auftritt oder asynchron, und ob es einen unmittelbaren Kausalzusammenhang zwischen der Ausführung einer Instruktion und dem Auftreten der Ausnahme gibt (d. h. Instruktion X ist der Auslöser) oder nicht.
Ein Seitenfehler wird synchron ausgelöst durch eine Speicherzugriffsinstruktion und ist damit eindeutig ein Trap. Punkt.
[quote=Airhardt]Ein Seitenfehler wird synchron ausgelöst durch eine Speicherzugriffsinstruktion und ist damit eindeutig ein Trap. Punkt.
[/quote]
Wenn ich die globale Strategie noch richtig im Hinterkopf habe, dann kann das OS doch beliebige Seiten von dir ersetzen, ohne dass du der Auslöser warst. Insbesondere können Codeseiten von dir ersetzt werden, sodass auch bei einer Nicht-Speicherzugriffsinstruktion (z. B. ADD) ein Seitenfehler getriggert werden könnte. Also in dem Zusammenhang asynchron.
Ferner kann auch in folgendem Asm-Code in der zweiten Zeile ein Seitenfehler auftreten:
LOAD Speicherstelle 0xDEAD0000 -> R1
LOAD Speicherstelle 0xDEADB004 -> R2
Bei einer lokalen Ersetzungsstrategie könnte das Programm jedoch davon ausgehen, dass in der zweiten Zeile kein Seitenfehler auftritt. (Unter der Annahme, dass die Seitengröße und die Seitengrenzen bekannt sind.)
Das ändert nichts an der Tatsache, dass der Seitenfehler synchron auftritt und unmittelbar ausgelöst wird durch die Ausführung einer Instruktion - somit handelt es sich um einen Trap. 
Selbst wenn die Instruktion selbst nicht auf Speicher zugreift: Das Holen der Instruktion selbst ist auch ein Speicherzugriff.
Wenn man nach jeder Instruktionen einen Trap fürchten muss, dann macht die Unterscheidung Interrupt ↔ Trap aus meiner Sicht gerade nicht mehr so viel Sinn. Der Trap kann quasi jederzeit auftreten - genauso wie der Interrupt.
Du hast schon Recht, ein Trap könnte rein theoretisch jederzeit auftreten. Das ist aber nicht der entscheidende Punkt. Entscheidend ist, ob es einen unmittelbaren Kausalzusammenhang zwischen dem Prozess und der Ausnahme gibt - sozusagen, ob das Ereignis “von innen” kommt oder “von außen”.
Löst der Prozessor eine Ausnahme aus, weil er gerade eine ganz bestimmte Instruktion ausführt?
- Ja → Trap
- Nein → Interrupt