Friedrich-Alexander-Universität Erlangen-Nürnberg  /   Technische Fakultät  /   Department Informatik
Aufgabe 4: Threadumschaltung fĂŒr OOStuBS/MPStuBS

Lernziele

  • Auffrischen der Assemblerkenntnisse (siehe auch Assembler-Crashkurs)
  • VerstĂ€ndnis der AblĂ€ufe beim Threadwechsel
  • Unterscheidung von aktiven und passiven Objekten

Aufgabenbeschreibung

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

Dazu mĂŒssen einige Funktionen zum Zugriff auf die Struktur stack, die Klassen Dispatcher, Thread und Scheduler, sowie die Low-Level Funktionen zum Kontextwechsel implementiert werden. Außerdem soll OOStuBS/MPStuBS nun spĂ€testens jetzt mit Application eine Anwendung erhalten.

Um die Threadumschaltung ĂŒ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.

dot_a4.png
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 mit mehreren Benutzerthreads gefĂŒllt werden, welche sich Ă€hnlich zu den bisherigen Testprogrammen jeweils auf einer eigenen Bildschirmposition bemerkbar machen. Testet auch die Methoden Scheduler::exit() und Scheduler::kill(Thread *item).

Implementierungshinweise

Zum Testen empfiehlt es sich, die Gesamtaufgabe in den folgenden drei Schritten zu bearbeiten und erst mit den Schritten B und C zu beginnen, wenn der die vorherigen Schritte A (bzw. B) fertig implementiert sind und jeweils ausgiebig getestet wurden. FĂŒr diese Aufgabe könnt ihr die Interrupts wieder deaktivieren. Es laufen also nur die Threads auf den/der CPU(s) und ihr braucht euch so nicht um Synchronisation zwischen Threadkontrollfluss und Interrupthandlern zu kĂŒmmern. Interrupts kommen erst wieder in Aufgabe 5 ins Spiel.

Schritt A

Hier wird der Threadwechsel realisiert. Es mĂŒssen also zunĂ€chst nur die Zugriffsfunktionen auf die Struktur stack und die Klasse Thread implementiert werden. Zum Testen der Lösung sollten mehrere Threads angelegt werden, welche jeweils nach einigen Anweisungen den Prozessor an den nĂ€chsten Thread abgeben.

Schritt B

Als nĂ€chstes kann der Dispatcher implementiert werden. Im Testprogramm sollte der Threadwechsel nun ĂŒber den Dispatcher laufen können.

Schritt C

Zum Schluss sollte der Scheduler hinzugefĂŒgt werden. Im Testprogramm mĂŒssen die Anwendung und Benutzerthreads nun beim Scheduler angemeldet werden. DafĂŒr brauchen sie sich nicht lĂ€nger gegenseitig zu kennen, denn die Auswahl des nĂ€chsten Threads kann nun der Scheduler ĂŒbernehmen.

MPStuBS

Die Implementierung fĂŒr MPStuBS ist analog zur Uniprozessorimplementierung aufgebaut. Die Threads 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. Insbesondere ist darauf zu achten, dass ein auf der aktuellen CPU laufender Thread nicht vorzeitig fĂŒr die AusfĂŒhrung auf einer anderen CPU bereitgestellt werden darf.

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 Threads vorhanden sind, um alle Prozessoren zu beschĂ€ftigen. Diese Voraussetzung mĂŒsst ihr dann aber natĂŒrlich auch in euerem Testprogramm erfĂŒllen. Es empfiehlt sich dabei, den Threadwechsel intensiv mit verschieden vielen Threads zu testen.