Tasks I. Andreas Görzen Benjamin Kotke Fabian Mierendorff Jonas Kemper Sebastian Wolf Timo Lorenz Wolfgang Laut. 16. Juli 2013

Transkript

1 Tasks I Andreas Görzen Benjamin Kotke Fabian Mierendorff Jonas Kemper Sebastian Wolf Timo Lorenz Wolfgang Laut 16. Juli

2 Inhaltsverzeichnis 1 Analyse Task State Segment Task-Register Task-Gates Thread-Zustände Prozess vs. Thread Einordnung von Prozessen, Threads und Tasks Global Descriptor Table Struktur GDT Initialisierung der GDT Laden der Global Descriptor Table Dispatcher Entwurf Klasse GDTManager Threads Scheduler Dispatcher Benutzung von Prozessen und Threads Threaderstellung Zusammenspiel mit dem Scheduler Fazit und Ausblick 14 2

3 1 Analyse 1.1 Task State Segment Beim Task-Wechsel möchte man den unterbrochenen Task zu einem späteren Zeitpunkt in dem Zustand 1 weiter ausführen, in dem er unterbrochen wurde. In der Intel IA32-Architektur wird dies mit Hilfe des Task State Segments (TSS) erreicht. Über das TSS können diese Werte durch den Prozessor abgerufen werden. Die Abbildung 1 zeigt den Aufbau des Task State Segments. Abbildung 1: Task-State-Segment Für das Task State Segment wird ein Deskriptor in der GDT abgelegt, dieser kann über einen Selektor des Deskriptors vom Prozessor geladen werden. Der Nachteil dieser Realisierung ist, das maximal 8189 Tasks abgelegt werden können, denn 1 Ein Zustand besteht aus Stack- und Instruction Pointer, Registerzuständen und Segmentselektoren 3

4 die GDT kann nicht mehr Einträge enthalten. Genauere Informationen zur GDT befinden sich in Abschnitt 1.7. Bei einem Task-Wechsel aktualisiert der Prozessor die dynamischen Werte, wie z.b.den Stack- oder Instruction-Pointer. Die Voraussetzung dafür ist, dass das Task-Register auf ein Task-State-Segment zeigt. Daher muss für den Initialprozess auch ein TSS erstellt werden und einmalig das Task-Register auf dieses geladen werden, damit zu anderen Prozessen gewechselt werden kann. Das Task-State-Segment bietet zusätzlich Schutz für IO, dieser Mechanismus wird jedoch bislang nicht berücksichtigt. 1.2 Task-Register Das Task-Register enthält einen 16-Bit Segmentselektor und den kompletten Segmentdeskriptor für die TSS des aktuellen Tasks. Diese Informationen sind aus dem TSS Deskriptor des aktuellen Tasks kopiert. Es hat einen sichtbaren Teil, der durch Software gelesen und geändert werden kann und einen unsichtbaren Teil, der vom Prozessor verwaltet wird. Die Befehle LTR (load task register) und STR (store task register) laden und lesen den sichtbaren Teil des Task-Registers: Die LTR Anweisung lädt einen Segmentselektor in das Task-Register der auf einen TSS Deskriptor in der GDT zeigt. Danach wird der unsichtbare Teil des Task-Registers mit Informationen des TSS Deskriptor befüllt. LTR ist eine privilegierte Anweisung die nur auf CPL 0 ausgeführt werden kann. Sie wird während der Systeminitialisierung benutzt, um einen Initialwert in das Task-Register zu speichern. Später ändert sich der Inhalt des Task-Registers implizit wenn ein Taskwechsel stattfindet. Die STR Anweisung speichert den sichtbaren Teil des Task-Registers in einem Mehrzweckregister oder Speicher. Diese Anweisung kann von jedem Privileglevel ausgeführt werden, um den aktuell laufenden Task zu identifizieren. 1.3 Task-Gates Ein Taskwechsel kann mithilfe eines Task-Gate vorgenommen werden. Es kann in der GDT, der LDT, oder IDT liegen. Dabei zeigt der TSS-Segmentselektor im Task-Gate auf denjenigen Segmentdeskriptor, der das TSS des Tasks definiert, Registe oder Speicher. Was denn nun? 4

5 zu dem gewechselt wird. Wenn durch einen Call, Jump oder Interrupt ein Task- Gate aufgerufen wird, so wird ein Task-Wechsel initiiert und der Zustand des bisher aktiven Tasks in dem TSS abgespeichert, das durch das Task-Register (TR) definiert ist. 1.4 Thread-Zustände Blockiert Der Thread verweilt in einem Wartezustand und muss auf die Erfüllung (mindestens) einer Wartebedingung (z.b.semaphore) warten. Sobald alle Bedingungen für den Thread erfüllt wurden, geht dieser in den Zustand Bereit über und erwartet die Prozessorzuteilung. Bereit Aktiv Die Threads, die in der Warteschlange stehen, werden als bereit bezeichnet. Nur einem Thread, für den keine Wartebedinungen vorliegen, kann die CPU zugeteilt werden. Durch Zuteilung der CPU wird der Thread in den Status Aktiv versetzt. In diesem Zustand bekommt der Thread exklusiv Rechenzeit der CPU zugeteilt. Welcher rechenwillige Thread zur Ausführung kommt, hängt vom Scheduler ab. Der Zustand kann sich ändern, wenn ein anderer Thread zur Ausführung gelangt und dem aktuellen Thread den Prozessor entzieht. Darüber hinaus können Wartebedingungen (z.b.warten auf Eingabedaten) entstehen, die den Thread in den Zustand Blockiert wechseln lassen. Ein Prozessor kann zu einem gegebenen Zeitpunkt immer nur einen Thread bearbeiten. Die Übergänge zwischen den Zuständen zeigt Abbildung 2. Abbildung 2: Threadzustände 1.5 Prozess vs. Thread Prozesse sind die Abfolge von bestimmten Ereignissen und lösungsorientiert. Als Spezialfall: in Betriebssystemen ist ein Prozess ein Vorgang, der durch ein 5

6 Programm kontrolliert wird, welches zur Ausführung einen Prozessor benötigt (Duden Informatik). Threads sind leichtgewichtigere Prozesse und erweitern das Prozessmodell. Threads bewirken, dass Teile innerhalb eines Prozesses quasi nebenläufig ausgeführt werden. Sofern das Betriebssystem dies unterstützt und die Betriebsmittel vorhanden sind, können Threads durch mehrere CPU-Kerne echt parallel ausgeführt werden. Threads die (echt) nebenläufig ausgeführt werden, teilen sich mit anderen Threads die Betriebsmittel des Rechners. 1.6 Einordnung von Prozessen, Threads und Tasks In unserem Projekt unterscheiden wir zwischen Prozessen, Threads und Tasks. Nachdem die Begriffe Prozess und Thread bereits grundlegend definiert wurden, soll nun eine auf dieses Projekt bezogene Abgrenzung statt finden. Prozesse und Threads sind Begriffe, die wir auf der Objektebene (High-Level) benutzen. Hierbei gilt, dass ein Prozess mehrere Threads beinhalten kann und ein Thread immer zu einem Prozess gehören muss. Der Begriff Task bezieht sich auf die Ausführung innerhalb der Hardware, konkret des Prozessors (Low-Level). Der Prozessor kennt weder Prozesse noch Threads. Für ihn gibt es nur Tasks, zwischen denen er wechseln kann. Diese Tasks können untereinander kommunizieren, wenn sie über einen gemeinsamen Speicherbereich verfügen, ähnlich wie es Threads eines Prozesses untereinander möglich ist. Daher entspricht in diesem Projekt ein Prozess im High-Level in etwa einem PageContext im Low-Level. Ein Thread im High-Level entspricht so einem Task im Low-Level. 1.7 Global Descriptor Table Da die Segmentregister mit 16 Bit etwas wenig Platz für die notwendigen Informationen anbieten, erhalten diese nur noch Selektoren also die Nummer eines Segments, das auf eine Tabelle verweist und zusätzliche Flags. Die wirklichen Beschreibungen dieser Segmente sind in der Global Descriptor Table (GDT) zu finden. Diese besteht aus mehreren Segmentdeskriptoren zu je 64 Bit, die sich direkt hintereinander in dieser Tabelle befinden. Tabelle 1 beschreibt einen Verweis auf die GDT. Die Global Descriptor Table ist eine Tabelle, um den Speicher, das Multitasking und verschiedene Gates zu verwalten. Sie beinhaltet verschiedene Informationen 6 Schulz: Tabelle 1 Unklar

7 Tabelle 1: Verweis auf die GDT über Speicherabschnitte. In dieser Tabelle können Segmente eingetragen werden, die zum Beispiel den Arbeitsspeicher in einen bestimmten Bereich adressieren und schützen. Die Struktur der Tabelleninhalte wird im folgenden Abschnitt beschrieben Struktur GDT Jeder Eintrag der GDT besteht aus 8 Byte und hat die in Tabelle 2 dargestellte Struktur. Tabelle 2: Struktur GDT-Eintrag Limit: Größe des Segments - 1 (entweder in Bytes oder in 4 KiB-Einheiten siehe Flags) Base: Die Adresse wo das Segment beginnt 7

8 Accessbyte: Zugriffsinformationen (Ring, executable, etc.) (Vollständig in Byte 5) Flags: Definiert die Segmentgrößeneinheit und 16/32?Bit. (Vollständig in Byte 6) Initialisierung der GDT Die GDT muss immer mindestens einen gültigen Deskriptor enthalten. Da dies schwierig zu gewährleisten ist, ist der erste Eintrag der GDT der sogenannte Nulldeskriptor. Dieser kann auf 0 gesetzt bzw. gelassen werden. Durch diese Konvention ist es möglich eine leere GDT zu erkennen und entsprechend zu behandeln. Ab dem folgenden Eintrag beginnen die tatsächlichen Deskriptoren. Zusätzlich zum Nulldeskriptor gibt es noch zwei weitere Deskriptoren, die vorhanden sein müssen: das Code- und Datensegment für den Kernel. Diese drei Standardeinträge sollte immer in der GDT vorhanden sein Laden der Global Descriptor Table Wenn sich im Speicher des Kernels eine GDT befindet, mit der er auf seine Segmente verweisen möchte, muss der Kernel noch das Register der GDT (GDTR) ändern. In diesem Register befinden sich zwei wichtige Informationen, die Adresse und das Limit der GDT. Dieses Register wird mit dem Befehl lgdtgeladen. Da dieses Register nur 6 Byte groß ist, kann dieser Befehl den neuen Wert nicht direkt als Operand entgegennehmen, sondern erwartet einen Zeiger auf eine Speicherstelle, die diese 6 Bytes enthält. Anschließend sollten alle Segmentregister neu geladen werden. 1.8 Dispatcher Der Dispatcher ist im Rahmen der Prozessverwaltung eines Betriebssystem tätig und dient dazu bei einem Kontextwechsel dem aktiven Thread die Ressourcen (CPU) zu entziehen und diese dem darauf folgenden Thread zuzuordnen. Es wird dem rechnenden Thread der Rechenkern entzogen und dieser dem nächsten Thread zugewiesen. Die Entscheidung, welcher Thread der Nachfolger ist, wird vom Scheduler getroffen. Scheduler und Dispatcher arbeiten Hand in Hand. 8

9 2 Entwurf Das für diesen Entwurf angefertigte Klassendiagramm befindet sich im Anhang. Im folgenden werden einige ausgewählte Aspekte näher beschrieben. 2.1 Klasse GDTManager Zur Verwaltung der GDT ist die Klasse GDTManager zuständig. Diese Klasse bietet alle Funktionalitäten, die für die Verwendung der GDT notwendig sind. Diese Klasse ist nach dem Entwurfsmuster Singleton umgesetzt und daher gibt es von ihr im gesamten Betriebssystem nur eine Instanz. Der Konstruktor dieser Klasse initialisiert die zuvor beschriebenen Pflichteinträge der GDT (Nulldeskriptor, Code/Datensegment für den Kernel). Die Operation setgdtentry() ermöglicht es, weitere Einträge in der GDT in lesbarer Form vorzunehmen. Listing 1 zeigt, wie die Parameter an die richtige Position in der Tabelle zugewiesen werden. Listing 1: Laden der GDT 1 void GDTManager : : loadgdt ( ) { 2 puts ( " Loading GDT from Kernelspace : " ) ; 3 struct GdtPtr { 4 uint16_t l i m i t ; 5 void base ; 6 } attribute ( ( packed ) ) ; 7 GdtPtr gdtptr ; 8 gdtptr. l i m i t = GDT_ENTRYS 9 sizeof ( CodeOrDataOrTaskSegmentDescriptor) 1; 10 gdtptr. base = start ; 11 / / load the gdt 12 asm( " lgdt %0" : : "m" ( gdtptr ) ) ; 13 / / load a l l selectors except CS f o r activating GDT 14 uint16_t a = 0x10; 15 asm ( "mov %0, ax ; " : : " r " (a) : ) ; 16 asm( "mov ds, ax" ) ; 17 asm( "mov es, ax" ) ; 18 asm( "mov fs, ax" ) ; 19 asm( "mov gs, ax" ) ; 20 asm( "mov ss, ax" ) ; Schulz: Implementierung!! 21 9

10 22 puts ( "OK\ r \n" ) ; 23 } 2.2 Threads Jeder Thread hat einen Zustand. Im Folgenden werden die möglichen Zustände beschrieben. RUNNABLE sind Threads, wenn sie lauffähig sind. Hier fehlt Text! vgl. Dokument von Schulz BLOCKED WAITING ist ein Thread, wenn er auf eine Semaphore wartet. ist der Startzustand eines Threads. In diesem Zustand kann ein Thread noch nicht ausgeführt werden. Er wartet auf seine Initialisierung. TERMINATED bedeutet, dass ein Thread fertig mit der Ausführung ist. RUNNING ist ein impliziter Zustand. Der Thread, der im Scheduler als aktuell laufender Thread ausgezeichnet ist, hat diesen Zustand. Gegenüber der Analyse wurde noch die Zustände Waiting und Terminated hinzugefügt. Waiting repräsentiert einen gerade erstellten Thread. Dieser geht nicht automatisch in den Zustand Runnable über, damit die Initialisierung in jedem Fall sauber abgeschlossen werden kann. Der Zustand Terminated dient dazu bereits abgearbeitete Threads zu erkennen, die nicht mehr benötigt werden. Im Prozess werden die Threads in Listen verwaltet. Für die Zustände RUNNA- BLE, WAITING und BLOCKED gibt es jeweils eine Liste. Ist ein Thread im Zustand TERMINATED, so wird dieser bei der nächsten Lauffähigkeits-Überprüfung vom Scheduler gelöscht. Wird der letzte Thread eines Prozesses entfernt, so wird der Prozess ebenfalls gelöscht. Die Übergänge zwischen den Threadzuständen zeigt Abbildung Scheduler Der Scheduler ist dafür zuständig, alle Prozesse und deren Threads zentral zu verwalten. Dazu ist er als Singleton realisiert und hat eine Liste aller Prozesse. Über die Prozesse hat er auch Zugriff auf die zugehörigen Threads. Da es sich um ein kooperatives Multitasking handelt wird aus der Liste aller Prozesse der Erste ausgewählt und nacheinander alle Threads des Prozesses abgearbeitet 10

11 Abbildung 3: Threadzustände bis sie fertig sind oder die Ressourcen abgeben. Die Prozesse sind nach ihrem Erstellungszeitpunkt geordnet. Falls keine Prozesse mehr vorhanden sind, läuft ein Idle-Prozess, der ständig Dispatcher::backToScheduler aufruft, um nach ausführbaren Threads zu suchen. Für die Ausführung eines neuen Prozesses benutzt der Scheduler den Dispatcher. Der Scheduler ist dafür zuständig alle Prozess und deren Threads zentral zu verwalten. Dazu ist er als Singleton realisiert und hat Zugriff auf eine verkettete Liste aller registrierten Prozesse über deren erstes Element (registeredprocesses - Änderung in: firstregisteredprocess später). Über die Prozesse hat er auch Zugriff auf die zugehörigen Threads. Da es sich um ein kooperatives Multitasking handelt wird, wenn ein neuer Thread ausgewählt werden soll (intern: choosenext ) immer der auf den aktuellen Thread folgende (currentthread->getnextthread() ), ausgewählt. Falls der aktuelle Thread keine folgengenden Threads hat, wird der nächste Prozess ausgewählt (currentthread- >getparent->getnextprocess() ). Falls jedoch irgendwann auch ein Prozess keinen Nachfolger mehr hat, wird wieder beim ersten Prozess begonnen. Die Prozesse sind nach ihrem Registrierungszeitpunkt geordnet, der erste Prozess ist immer der zuletzt registrierte. Falls die Prozesse keine lauffähigen Threads mehr besitzen läuft ein Idle-Prozess der ständig Dispatcher::backToScheduler aufruft, um nach ausführbaren Threads zu suchen. Für die Thread-Wechsel nutzt der Scheduler den Dispatcher. Im den Abbildungen 4 und 5 werden die internen Algorithmen des Schedulers dargestellt. Zunächst choosenext(), der den nächsten RUNNABLE-Thread sucht, im Anschluss loadnextprocess(), der dann ggf. den nächsten Prozess und den dazugehörigen RUNNABLE-Thread findet. Hier fehlt auch Text! 11

12 Abbildung 4: Scheduler Abbildung 5: loadnextprocess(processtostart) 12

13 2.4 Dispatcher Im Kontext des FHDW-OS ist der Dispatcher dafür verantwortlich, Task-Wechsel vorzunehmen. Da es sich beim Dispatcher nur um statische Methoden handelt wurde an dieser Stelle auf ein Singleton verzichtet. Der Dispatcher wird vom Scheduler aufgerufen und leitet den Task-Wechsel ein. Zusätzlich kann er von einem Thread benutzt werden, um seine Ausführung zu unterbrechen und an den Scheduler abzugeben. Die Klasse Dispatcher bietet dem Scheduler die Funktionen loadidlethread, loadtss und dispatch an. Die Funktion dispatch ist für den Prozesswechsel zuständig. Wie die einzelnen Aufrufe vom Scheduler zum Dispatcher aufgebaut sind, ist dem vorangegangenen Abschnitt zu entnehmen. Listing 2: Laden der TSS 1 void Dispatcher : : loadtss ( Selector tssselector ) { 2 Selector selector = tssselector ; / / needed f o r jump 3 FarPointer farptr ; 4 farptr. offset = 0; 5 farptr. selector = selector. combined ( ) ; 6 asm volatile ( "jmp fword ptr %0" : : "m" ( farptr ) ) ; 7 } Schulz: Implementierung!! 3 Benutzung von Prozessen und Threads 3.1 Threaderstellung Um Prozesse, Threads und das zuvor vorgestellte Konzept zu nutzen, benötigt man eine Unterklasse von der abstrakten Klasse Thread in Thread.h. In dieser Unterklasse muss man die run-methode implementieren, in der dann Aktionen ausgeführt werden können. Um den Thread zu starten, muss man die Methode StartRunning ausführen. Dies ändert den Zustand des Threads in RUNNABLE, sodass dieser vom Scheduler als lauffähig erkannt und irgendwann ausgeführt wird. 13

14 3.2 Zusammenspiel mit dem Scheduler Da das FHDW-OS auf kooperativem Multitasking basiert, müssen laufende Threads dem Scheduler melden, wenn sie ihre Ausführung unterbrechen wollen. Um diesen Vorgang durchzuführen, ruft der ausgeführte Prozess einfach die Methode backtoscheduler vom Dispatcher auf. Diese statische Methode übergibt daraufhin an den Scheduler, der den nächsten Thread auswählt. Ist die Run-Methode eines Threads abgeschlossen, wird der Zustand des Threads in TERMINATED geändert. Der Scheduler erkennt dies und löscht in diesem Fall den Thread. 4 Fazit und Ausblick Es wurde ein kooperatives Multitasking implementiert. Als Scheduling-Algorithmus wurde das Round-Robin Verfahren verwendet. Scheduler sowie Dispatcher dienen dabei als zentrale Klassen, um Task-Wechsel durchzuführen. Durch die Platzierung des Idle-Thread im Kernel-Space, ist für einen Wechsel zum Idle-Thread kein Kontextwechsel nötig, da der Kernel-Space immer gemappt ist. Es wurden Vorkehrungen getroffen, um zu einem späteren Zeitpunkt präemptives Multitasking umzusetzen. Dazu ist es notwendig, dass der Scheduler an bestimmten Punkten nicht unterbrochen werden kann. Dafür bietet es sich an, kritische Bereiche zu definieren, in denen keine Unterbrechungen gestattet sind. Dazu wurden bereits Methoden zum Betreten sowie Verlassen des kritischen Bereichs angelegt. In der Zukunft muss über eine Implementierung dieser Methoden nachgedacht werden und über Möglichkeiten Unterbrechungen zu verhindern. Denkbar wäre eine Maskierung der Interrupts. Darüber hinaus wird eine Instanz benötigt, die zeitgesteuert Prozesse bzw. Threads unterbricht und den Scheduler aufruft, der den Task-Wechsel durchführt. Für die in diesem Kapitel vorgestellten Konzepte wurden Informationen aus folgenden Quellen verwendet:

15 Abbildung 6: Klassendiagramm Tasks I 15