OOStuBS - Technische Informatik II (TI-II)
2.4
|
Die fünfte Aufgabe erweitert das OOstuBS um einen weiteren Thread-Zustand. Bisher wurden "bereit" und "aktiv" auf der Ebene des Schedulers umgesetzt, nun kommt noch "blockiert" hinzu. Dazu wird eine weitere Abstraktionsebene über den Klassen Thread und Scheduler. eingefügt. Oberhalb der erstgenannten wird die Klasse Customer eingefügt. Eine Instanz dieser Klasse kann als blockiert markiert und in einer separaten Queue organisiert werden. Verantwortlich dafür ist der Organizer, damit das short-term-scheduling des Scheduler und Dispatcher um ein mid-term-scheduling erweitert. Dabei werden Prozesse, die synchronisiert werden sollen oder auf eine I/O Operation warten, nicht an den Scheduler zur Ausführung übergeben und in seperaten Queues gespeichert. Die Entscheidung, ob ein Thread bereit werden kann (weil eine bestimmte Ressourcen bereit- steht) trifft ein ressourcenbezogener Semaphore.
Die Idee dieses Mechanismus soll an der I/O Klasse Keyboard verdeutlicht werden. Die Klasse erbt nunmehr ,wie im Klassendiagramm ersichtlich, von der Klasse Semaphore. Eine entsprechende Instanz wird im Konstruktor mit der Zahl der verfügbaren Ressourcen (hier "0") initialisiert. Mit der Anforderung einer Leseoperation unter Keyboard::getkey(), die abhängig von den Eingaben des Nutzers beliebig lange dauern kann, wird also jeder Thread blockiert. Erfolgt eine Eingabe, wird der Thread wieder dem Scheduler übergeben und bekommt im Falle der Ausführung das Ergebnis der getkey Funktion zugeordnet. Der Semaphore synchronisiert also die Tastatureingaben und zugehörigen Threads.
Die Vorlage umfasst die Implementierung einer kleinen Shell, unter der die 3 Anwendungen, Counter-1, Counter-2 und Rotating-Coursor in beliebiger Kombination gestartet und gestoppt werden können. Mit help kann eine Hilfe zu diesen Möglichkeiten aufgerufen werden.
Beachten Sie, dass das globale Objekt "scheduler" nunmehr eine Instanz der Klasse Organizer ist!