Friedrich-Alexander-Universität UnivisSuche FAU-Logo
Techn. Fakultńt Willkommen am Department Informatik FAU-Logo
Logo I4
Lehrstuhl für Informatik 4
Betriebssysteme
 
  Vorlesung
    - UnivIS-Infos
    - Inhalt
    - Folien
 
  Übungen
    - UnivIS-Infos
    - Inhalt
    - Mailingliste
    - Ergänzendes Material
    - Terminübersicht
    - Aufgaben
       * Umgebung
       * Typische Fehler
       * Aufgabe 1
          Dokumentation
       * Aufgabe 2
          Dokumentation
       * Aufgabe 3
          Dokumentation
       * Aufgabe 4
          Dokumentation
       * Aufgabe 5
          Dokumentation
       * Aufgabe 6
          Dokumentation
       * Aufgabe 7
          Dokumentation
 
  Evaluation
Department Informatik  >  Informatik 4  >  Lehre  >  WS 2010/11  >  Betriebssysteme  >  ├ťbungen  >  Aufgaben  >  Aufgabe 4

Aufgabe 4: Prozessumschaltung f├╝r OOStuBS/MPStuBS

Lernziele

  • Auffrischen der Assemblerkenntnisse (siehe auch Assembler-Crashkurs)
  • Verst├Ąndnis der Abl├Ąufe beim Prozesswechsel
  • Unterscheidung von aktiven und passiven Objekten

Aufgabenbeschreibung

Es soll eine einfache Prozessverwaltung implementiert werden, bei der die Benutzerprozesse die Prozessorabgabe im Sinne des Koroutinenkonzepts selbst regeln.

Dazu m├╝ssen einige Funktionen zum Zugriff auf die Struktur toc, die Klassen Coroutine, Dispatcher, Entrant und Scheduler, sowie die Funktion kickoff() implementiert werden. Au├čerdem soll OOStuBS/MPStuBS nun sp├Ątestens jetzt mit Application eine Anwendung erhalten.

Um die Prozessumschaltung ├╝berall in OOStuBS/MPStuBS ansprechen zu k├Ânnen, soll in Aufgabenteil B eine globale Instanz des Dispatchers angelegt und in Teil C durch eine globale Instanz scheduler des Schedulers ersetzt werden.

a4.dot

Klassen├╝bersicht f├╝r Aufgabe 4

Die Funktionsf├Ąhigkeit der genannten Klassen soll mit Hilfe eines aussagef├Ąhigen Testprogramms gezeigt werden. Dazu soll in main.cc nun zus├Ątzlich eine globale Instanz scheduler der Klasse Scheduler angelegt und ein erster Benutzerprozess application (ein Objekt der Klasse Application) erzeugt werden, der seinerseits weitere Benutzerprozesse erzeugt. Testet auch die Methoden Scheduler::exit() und Scheduler::kill(Entrant& item).

Implementierungshinweise

Zum Testen empfiehlt es sich, die Gesamtaufgabe in drei Teile zu teilen und mit Teil B und C erst zu beginnen, wenn Teil A (bzw. B) fertig implementiert und ausreichend getestet wurden. F├╝r diese Aufgabe k├Ânnt ihr die Interrupts wieder deaktivieren. Es laufen also nur die Coroutinen auf den/der CPU(s) und ihr braucht euch so nicht um Synchronisation zwischen Coroutinenkontrollfluss und Interrupthandlern zu k├╝mmern. Interrupts kommen erst wieder in Aufgabe 5 ins Spiel.

Teil A

Hier wird der Koroutinenwechsel realisiert. Es m├╝ssen also zun├Ąchst nur die Zugriffsfunktionen auf die Struktur toc und die Klasse Coroutine implementiert werden. Zum Testen der L├Âsung sollten in Application (hier noch als Spezialisierung der Klasse Coroutine) mehrere Benutzerprozesse (die ebenfalls von Coroutine abgeleitet werden m├╝ssen) erzeugt werden, welche jeweils nach einigen Anweisungen den Prozessor an die n├Ąchste Koroutine abgeben.

Teil B

Als n├Ąchstes kann der Dispatcher implementiert werden. Im Testprogramm sollte der Koroutinenwechsel nun ├╝ber den Dispatcher laufen k├Ânnen.

Teil C

Zum Schluss sollte der Scheduler hinzugef├╝gt werden, der die Prozessabstraktion Entrant ben├Âtigt. Im Testprogramm m├╝ssen die Anwendung und Benutzerprozesse (nun als Spezialisierungen der Klasse Entrant) beim Scheduler angemeldet werden. Daf├╝r brauchen sie sich nicht l├Ąnger gegenseitig zu kennen, denn die Auswahl des n├Ąchsten Prozesses kann nun der Scheduler ├╝bernehmen.

MPStuBS

Die Implementierung f├╝r MPStuBS ist analog zur Uniprozessorimplementierung aufgebaut. Die Prozesse werden in einer einzigen Bereitliste verwaltet. Jedoch kann es vorkommen, dass verschiedene Prozessoren zur gleichen Zeit auf die Datenstruktur des Schedulers zugreifen. Aufrufe des Schedulers m├╝ssen deswegen in MPStuBS auch bei kooperativem Scheduling synchronisiert werden.

Grunds├Ątzlich ist es f├╝r MPStuBS sinnvoll die Implementierung schrittweise wie oben beschrieben durchzuf├╝hren, dabei das Scheduling jedoch zuerst nur auf einer CPU zu starten. Erst wenn dies problemlos funktioniert, sollte das Scheduling auch auf den Applikationsprozessoren gestartet werden. Dies vereinfacht das Debugging enorm.

Es darf bei der Implementierung angenommen werden, dass immer genug Prozesse vorhanden sind, um alle Prozessoren zu besch├Ąftigen. Diese Vorraussetzung m├╝sst ihr dann aber nat├╝rlich auch in euerem Testprogramm erf├╝llen.

  Impressum Stand: 2010-12-06 08:46   BO, DL