FSI Informatik/pruefungen/hauptstudium/ls4/bsoostubsgetkey

Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » Kleine Erklärung zu getkey() in OOStuBS (Übersicht)
Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
====== Kleine Erklärung zu getkey() in OOStuBS ======

In BS kommt oft die Frage was passiert wenn ein Prozess in OOSTUBS ein
read()/getkey() macht. Dazu habe ich mal eine Zusammenfassug geschrieben die
hoffentlich auch anderen hilft. Garantie gibts keine.

Vorbedingung: der Prozess ist im Zustand blockiert und wartet auf die Semaphore
die das konsumierbare Betriebsmittel "Tastaturzeichen" verwaltet (dahingekommen
ist der Prozesss durch die blockierende P()-Operation in getkey()), die die
block()-Methode des Schedulers aufgerufen hat. P hat um sich ein Secureobjekt
und macht ein leave() (um den krit. Abschnitt freizugeben) nachdem es block()
augerufen hat. block() setzt den Prozess von der Bereitliste auf eine Warteliste
die mit dem "Zeichen vorhanden Event" verknuepft ist, anschliessend findet eine
Schedulingentscheidung statt.

Ein anderer Prozess ist dann vom Scheduler ausgewaehhlt und vom Dispatcher
eingelastet worden.

1. Taste wird gedrueckt

2. elektrisches Signal wird vom Tastaturcontroller an den APIC zugestellt und ueber den APIC-BUS an einen APIC zugestellt.

3. Interrupts vom Keyboardcontroller werden gesperrt

4. APIC nimmt eine Priorisierung vor und meldet den Interrupt sowie dessen Nummer zu gegebener Zeit an die CPU (Eintritt in Ebene 1, implizite Unterbrechung aller tieferen Kontrollfluesse) + Zustandsicherung (Statusregister)

5. Die Nummer dient als Index in die Interruptvektortabelle wo sich ein Zeiger auf die Behandlungsroutine befindet, nach dem Leeren der Pipeline und Herstellung eines Konsistenten Zustandes in der CPU wird diese Funktion angesprungen. In Oostubs ist ueberall eine ASM-Kopplungsroutine in diese Tabelle ingetragen, die fluechtige Register sichert, da die eigentlich Behandlung in Hochsprache stattfindet.

6. Man kommt im guardian() heraus und diese Funktion arbeitet den Prolog der Interruptabarbeitung ab, das gelesene Zeichen wird hier in einen Puffer kopiert (das kann auch erst im Epilog passieren, das macht den Prolog kuerzer aber man kann eher Zeichen verlieren)

7. Es wird ein Epilog relayed

8. Interrupts vom Tastaturkontroller werden wieder zugelassen, nachdem der Interrupt bestaetigt(rueckgesetzt) wurde (Ebene 1 wird verlassen (iret durch die asm-kopplungsroutine))

9. Der anhaengige Epilog wird abgearbeitet (Ebene .5 wird betreten).

Hier gibt es jetzt zwei Moeglichkeiten, abhaengig davon auf welcher Ebene der Prozess war, der auf das Zeichen warten sollte:
a) Prozess war auf Ebene 0 und suspendiert und der guard (krit. Abschnitt) ist
frei -> Die Semaphore die das Tastaturzeichen verwaltet macht einfach ein V()
sobald ihr Epilog dran war. Der Epilog wird direkt ausgefuehrt und nicht erst in
die queue gehaengt.
b) Prozess war auf Ebene .5 (d.h. der guard war nicht available) -> der Prozess
kommt jetzt wegen der Sequentialisierung nochmal dran und der P()-Syscall wird
fertig ausgefuehrt. Die Vorbedingung wird also erst jetzt erfuellt, da zum
Zeitpunkt des Tastendrucks der Syscall unterbrochen wurde und der Prozess zum
Beispiel noch auf der Bereitliste steht. Der Epilog des Tastaturinterrupts wurde
da der krit. Abschnitt belegt war in die Epilogqueue eingehaengt. Erst nachdem
der Prozess den kritischen Abschnitt freigegeben hat wird in dem damit
einhergehenden leave() irgendwann der Epilog der das V() macht ausgefuehrt.

10. im V() wird der Prozess durch den Scheduler vom Zustand blockiert in den Zustand bereit ueberfuehrt.

11. weitere Epiloge werden abgearbeitet (eventuell auch eine anstehende Schedulingentscheidung die den Prozess direkt einlastet).

Hier bin ich mir nicht 100% sicher ob immer vor der Rueckkehr auf Ebene 0 eine
Schedulingentscheidung getroffen werden sollte oder ob man einfach wartet bis
die Zeitscheibe des gerade laufenden Prozesses ablaeuft und dann halt eine
Schedulingentscheidung trifft. Wenn man jedesmal eine Schedulingentscheidung
trifft hat man halt immer overhead, tut man es aber nie kann es passieren dass
es zu einer Prioritaetsverletzung kommt (angenommen wir haetten im OOSTUBS
Scheduler Prioritaeten :-)), weil ein Prozess mit einer hoeheren Prioritaet als
der aktuell laufende deblockiert worden sein koennte und dann nicht sofort
eingelastet wird. Ich denke ich wuerde in der Pruefung versuchen mich hier aus
der Affaere zu ziehen indem ich sage ich fordere immer eine
Schedulingentscheidung an, aber die prueft nur ob sich an der Bereitliste
irgendwas geaendert hat und returned einfach sofort wenn dem nicht so ist. Die
Aenderung an der Bereitliste kann man einfach dadurch erreichen das man im
block()/wakeup() ein entsprechendes flag setzt. Dadurch hat man einen sehr
geringen overhead, weil die Entscheidung nicht lange dauert wenn nichts passiert
ist. Eine Prioritaetsverletzung hat man aber so ausgeschlossen.

12. Wechsel auf Ebene 0 durch resume auf den einzulastenden Prozess nach
Abarbeitung aller Epiloge. Genauer ist man nach resume() noch im Kern, aber nach
Ende der Epilogqueue erfolgt ein retne() das uns auf Ebene 0 zurueckbringt.

13. getkey() kehrt zurueck und returned das gelesene Zeichen

 --- //spjsschl//