Betriebssysteme KU Tutorium zu Assignment 1

Transkript

1 Betriebssysteme KU Tutorium zu Assignment 1 SWEB-Tutoren irc://irc.at.euirc.net/bs 17. Oktober 2013

2 1 Multiprogramming in SWEB (Wiederholung) Memorymanagement Prozesse und Threads Erstellen von Prozessen Funktionsaufruf Syscalls Synchronisations-Mechanismen 2 Assignment 1 Task 1 - Multithreading Task 2 - Fork Weitere Tasks 3 Abgabe Designdokument Abgabe Schedule

3 1 Multiprogramming in SWEB (Wiederholung) Memorymanagement Prozesse und Threads Erstellen von Prozessen Funktionsaufruf Syscalls Synchronisations-Mechanismen 2 Assignment 1 Task 1 - Multithreading Task 2 - Fork Weitere Tasks 3 Abgabe Designdokument Abgabe Schedule

4 Address Space Layout in SWEB Jeder Prozess erhält eigenen Adressraum 0-2 GiB Programm 2-3 GiB Kernel (für alle Prozesse gleich) 3-4 GiB Identity-Mapped USERSPACE KERNEL 1:1 mapping 0 2GB 3GB 4GB Programmcode Stack

5 Page Directories Jeder Prozess (und Kernel-Thread) hat ein Page Directory Wird benötigt, um den virtuellen Adressraum (4 GB) auf den physikalischen abzubilden Bei System-Calls wird in den Kernel-Bereich gesprungen, Page Directory bleibt gleich Identity-Mapping, um geordnet auf physikalische Adressen zugreifen zu können Tafel: Wie funktioniert Adressauflösung mit Page Directory und Page Tables?

6 Thread Objects Overview Scheduler Schedules Thread Thread Thread Kernel Registers Kernel Registers Kernel Registers User Registers User Registers User Registers Inherits UserProcess CR3 Register Loader Manages Page Directory

7 Prozesse Abstrakte Klasse Thread davon abgeleitete Klasse UserProcess (...Multithreading?) nur beispielhafte Implementation instanziert Loader switcht in Run() in den Userspace Thread hält Loader-Objekt (...Multithreading?) Klasse Loader initialisiert virtuellen Adressraum (Page- Directory und Stack) Page Fault lädt Seite aus dem Executable nach cleanupuserspaceaddressspace(...) räumt Page- Directory wieder auf

8 Threads Thread-Objekte schedulbare Basiseinheit (Derzeit) drei mögliche Zustände Running: ausführbar bzw. wird gerade ausgeführt Sleeping: Thread blockiert/schläft. ToBeDestroyed: Thread wurde beendet und wird zerstört (von IdleThread) ausreichend? ( Stichwort Systemcall sleep) UserThreads für User-Prozesse müssen auch von Thread abgeleitet werden

9 Erstellen eines User-Prozesses in SWEB userspace/tests/example.c HDD Image: /user_progs/example.sweb in main.cpp:startup() zu user_progs[] hinzufügen cmake. && make

10 Funktionsaufruf im Detail (cdecl) Aufrufer Legt Argumente auf den Stack (push bzw. mov) Ruft Funktion auf (call) CPU legt Rücksprungadresse auf den Stack Kontrollfluss wird an Funktion übergeben (EIP- Register wird manipuliert) Funktion Arbeitet Code ab Legt Rückgabewert ins EAX- Register Führt ret- Instruction aus CPU nimmt Rücksprungadresse vom Stack Kontrollfluss zurück an den Aufrufer (erneut EIP- Register) Aufrufer räumt Stack auf

11 int foo(int arg) { return 5; } int main() { foo(1); return 0; } main: ; [...] movl $1, (%esp) call foo ; [...] 1 foo: pushl %ebp movl %esp, %ebp movl $5, %eax popl %ebp ret

12 int foo(int arg) { return 5; } int main() { foo(1); return 0; } main: ; [...] movl $1, (%esp) call foo ; [...] 1 RET foo: pushl %ebp movl %esp, %ebp movl $5, %eax popl %ebp ret

13 int foo(int arg) { return 5; } int main() { foo(1); return 0; } main: ; [...] movl $1, (%esp) call foo ; [...] 1 RET %ebp foo: pushl %ebp movl %esp, %ebp movl $5, %eax popl %ebp ret

14 int foo(int arg) { return 5; } int main() { foo(1); return 0; } main: ; [...] movl $1, (%esp) call foo ; [...] 1 RET %ebp foo: pushl %ebp movl %esp, %ebp movl $5, %eax popl %ebp ret

15 int foo(int arg) { return 5; } int main() { foo(1); return 0; } main: ; [...] movl $1, (%esp) call foo ; [...] 1 RET %ebp foo: pushl %ebp movl %esp, %ebp movl $5, %eax popl %ebp ret

16 int foo(int arg) { return 5; } int main() { foo(1); return 0; } main: ; [...] movl $1, (%esp) call foo ; [...] 1 RET foo: pushl %ebp movl %esp, %ebp movl $5, %eax popl %ebp ret

17 int foo(int arg) { return 5; } int main() { foo(1); return 0; } main: ; [...] movl $1, (%esp) call foo ; [...] 1 foo: pushl %ebp movl %esp, %ebp movl $5, %eax popl %ebp ret

18 System Calls im Kernel Userspace: syscall(...) Argumente und Syscallnummer in die Register (EAX, EBX...) Syscallnummern in common/include/kernel/syscall-definitions.h Sprung zum Kernel: IRQ 0x80 Kernel: Syscall::syscallException(...) switch(syscall_number) { case sc_exit: exit(arg1); break; /*... */ }

19 Prozesssynchronisation Problem: Mehrere Threads oder Prozesse teilen sich bestimmte Ressourcen Durch unkoordinierten Zugriff können diese zerstört werden Ressourcen können ungültig werden Daher zusätzliche Sicherheit erforderlich Gegenmaßnahmen Abschnitte mit geteilten Ressourcen identifizieren: kritische Abschnitte Zugang zu kritischen Abschnitten sichern Einige Mechanismen Mutex Semaphore Condition Variablen

20 Mutex - Mutual Exclusion Mutex - Mutual Exclusion Es gibt eine Lock Variable (gesetzt mittels atomic Operation z.b. xchg) Um den kritischen Abschnitt zu betreten, braucht jeder Thread den Lock Thread will Abschnitt betreten und Lock frei Thread besetzt Lock Lock nicht frei Thread wird schlafen gelegt (bis Lock wieder frei) Schlafende Threads Sleepers Liste Thread verlässt kritischen Abschnitt und gibt Lock frei (!) schlafender Thread wird geweckt

21 Semaphore Semaphore: Eigentlich Signalmasten bei Eisenbahnen Es gibt eine Zähl-Variable, initialisiert mit n Thread will Resource benutzen und Variable ist größer 0 Thread verringert Variable um 1 Variable ist 0 Thread wird schlafen gelegt (bis Variable größer 0) Schlafende Threads Sleepers Liste Thread braucht Resource nicht mehr und erhöht Zähler um 1 (!) schlafender Thread wird geweckt Anwendungen: Producer/Consumer (Wieviele Items sind in der Queue), Zahlenmäßig beschränkte Resource Im Basis-SWEB nicht implementiert!

22 Condition Variable Dienen der Prozesssynchronisation innerhalb eines kritischen Abschnitts Kritischer Abschnitt ist wieder durch Mutex geschützt Im kritischen Abschnitt kann der Thread seine Arbeit nur fortsetzen wenn eine bestimmte Bedingung erfüllt ist Thread wird schlafen gelegt bis Bedingung eintritt Inzwischen kann ein anderer Thread den kritischen Abschnitt betreten Wenn Condition eintritt, wird einer oder alle Threads informiert die auf diese warten Pro Bedingung eigene Condition Variable erforderlich

23 Condition Variable con t Wakeup- call - zwei Reaktionen möglich: Mesa Style: Schlafender Thread wartet, bis derjenige, der gerade im geschützten Bereich ist, fertig ist. Hoare Style: Schlafender Thread beginnt sofort und der Aufweckende wird schlafen gelegt. Allgemein Mesa Style üblicher Mutex und CV agieren Hand in Hand Wakeup-Calls werden nicht gespeichert

24 1 Multiprogramming in SWEB (Wiederholung) Memorymanagement Prozesse und Threads Erstellen von Prozessen Funktionsaufruf Syscalls Synchronisations-Mechanismen 2 Assignment 1 Task 1 - Multithreading Task 2 - Fork Weitere Tasks 3 Abgabe Designdokument Abgabe Schedule

25 Multithreading Wir wollen unsere Prozesse multithreaded machen Jeder Prozess hat eigenen virtuellen Adressraum Mehrere Ausführungsfäden (Thread = Faden) Beliebig viele (dh. nur durch Hardwarelimits beschränkt) Threads Vom Kernel verwaltet (einfacher als Verwaltung im Userspace)

26 Multithreading Designentscheidungen Was passiert wenn der erste Thread beendet wird? Wann werden Userspace und Loader aufgeräumt? Wie wird erkannt, dass eine als Thread laufende Funktion returniert? Wo Stacks platzieren? Was passiert bei fork/exec?

27 Multithreading in SWEB Derzeit pro UserProcess ein Kernel-Thread Wir wollen mehrere Thread-Objekte (z.b. UserThread)... die sich dasselbe Page- Directory und den Loader teilen Geteilte Resourcen gehören geschützt! Testprogramme bereitstellen (!)

28 Multithreading POSIX Thread Library man pthreads (oder im www nach pthreads suchen) Entscheiden, welche Syscalls sinnvoll sind Mindestens zu implementieren: Thread erzeugen (pthread_create) Thread beenden (pthread_exit) Thread zwangsweise beenden (pthread_cancel) Warten auf Thread (pthread_join)

29 System Call SC_FORK forkedid == 2 Process 1 test.sweb int main(...) { int forkedid; printf("hello World"); forkedid = fork(); if(forkedid > 0) printf("hello from parent"); else printf("hello from child"); } creates new process Process 2 test.sweb int main(...) { int forkedid; printf("hello World"); forkedid = fork(); forkedid == 0 if(forkedid > 0) printf("hello from parent"); else printf("hello from child"); } pid_t fork(void); erzeugt identes Abbild vom aufrufenden Prozess wird benötigt um weitere Programme im Userspace zu starten Returnwert: 0 für den Child-Prozess Prozess-ID des Childs für den erzeugenden Parent

30 Fork Designentscheidungen Was passiert wenn es mehrere Threads gibt? Was passiert mit benutzten Resourcen (Files, Mutexes,...)? Wie stellt man sicher, dass Kopiervorgang atomar ist? Fortgeschrittene Überlegung: Können sich die Prozesse bestimmte Seiten nicht teilen? (insb. Code)

31 System Call SC_EXEC Process 1 test.sweb int main(...) { printf("hello World"); exec(other.sweb); //only reached in case of //an error errorhandling(...); return; } Process 1 test.sweb int main(...) { printf("hello World"); exec(other.sweb); Process 1 other.sweb int main(...) { dosomething(); return; } int execv(const char *path, char *const argv[]); ersetzt Image des aktuellen Prozesses durch Image in der mit path angegebenen Datei - siehe Klasse Loader wird mit fork verwendet, um Programme zu starten Rückgabewert nur relevant im Fehlerfall

32 Anwendungsbeispiel fork/exec/waitpid int child_status; int pid = fork(); if(pid == 0) { // child process exec("programm.sweb"); } else if(pid > 0) { // parent process waitpid(pid, &child_status, WEXITED); }

33 System Call SC_EXEC mit Parameterübergabe int execv(const char *path, char *const argv[]); argv sollte an main-funktion des neuen Executables übergeben werden Wohin legt man die Parameter? Wie übergibt man sie an main?

34 System Call SC_WAITPID pid_t waitpid(pid_t pid, int *status, int options); Wartet bis der Child-Process mit der angegebenen PID terminiert Nötig für eine funktionierende Shell Rückgabewert des Prozesses wird auf die Adresse in status geschrieben

35 System Call SC_SLEEP unsigned sleep(unsigned seconds); aufrufender Thread wird (mindestens) für die angegebene Zeit schlafen gelegt Zeitangabe in Sekunden soll möglichst gut angenähert werden (!) einmal Aussetzen genügt sicher nicht vgl. Live- Programming: Thread schläft Anzahl an Ticks Umsetzbar zb mittels TimeStampCounter oder RealTimeClock

36 System Call SC_CLOCK clock_t clock(void); liefert Zeit, die der aufrufende Prozess seit Erzeugung auf CPU lief Zeit in Clocks (siehe man-page) bestmögliche Annäherung (TimeStampCounter oder RealTimeClock) vgl. SC_SLEEP

37 Resourcen-Verwaltung Jeder Prozess hat verschiedene Resourcen zur Verfügung (File-Deskriptoren, Mutexes, Shared-Memory-Bereiche,...) Diese Resourcen müssen verwaltet werden (Threads dürfen nur auf gültige Resourcen zugreifen können) Diese Resourcen müssen geschützt werden (Andere Prozesse dürfen nicht einfach so auf die Resourcen zugreifen können) Gute Basis-Implementierung erleichert Implementierung der anderen Tasks

38 Filesystem Systemcalls Syscalls: open, close, read, write schon vorhanden File-Descriptoren müssen pro Prozess vergeben werden ( Resourcen eines Prozesses ) Zugriff auf falsche /nicht geöffnete FDs muss behandelt werden bereits vorhandene FDs 0: stdout 1: stdin Filesystem-Zugriff selbst ist schon implementiert, es fehlt nur die Verwaltung für verschiedene Prozesse

39 Filesystem Systemcalls cont d Am besten Dateien im Ordner /user_progs erstellen (kein eigener Mount nötig). Fürs Testen interessant: manueller Mount der Partition, z.b. im Linux-Terminal, sweb-bin-ordner: mount SWEB-flat.vmdk -oloop,offset= <ziel-ordner> Oder in newfs:./utils/mount.sh (Vorsicht bei Schreibzugriffen!)

40 System Call SC PIPE int pipe(int filedes[2]); Erzeugt zwei File-Deskriptoren Was auf fildes[1] geschrieben wird, kann von fildes[0] gelesen werden Wird zb von einer Shell für IO redirection benötigt In diesem Zusammenhang: Wie können Prozesse File-Deskriptoren teilen, wenn sie das wollen? (!)

41 System Call SC ATEXIT int atexit(void (*func)()); registriert Funktion func, die beim Beenden des Prozesses aufgerufen werden soll Aufruf bei exit in umgekehrter Reihenfolge der Registrierung Mindestens 32 Funktionen müssen registriert werden können Wer führt die Funktionen aus wenn schon alle Threads tot sind?

42 System Call SC SHUTDOWN Fährt das System kontrolliert hinunter Alle Prozesse müssen beendet werden (berücksichtige auch atexit) Schalte PC aus (ACPI)

43 Semaphore Implementierung eines Standard-Semaphores Verwendung der vorhandenen Mechanismen z.b. Mutex Bereitstellung im Userspace mittels POSIX-Interface (sem_init, sem_wait,...)

44 Testprogramm für Semaphore Auswahl eines Standardproblems Consumer-Producer (Gemeinsamer Buffer, auf den mehrere Threads zugreifen um zu lesen/schreiben) Sleeping Barber (Kunden warten beim Frisör auf Haarschnitt, Frisör wartet auf Kunden, wenn keine da sind) Dining Philosophers (Philosophen wollen etwas essen und warten auf Besteck) Siehe zb Wikipedia für genauere Beschreibung

45 Locks und Condition Variables Locks im Userspace zur Verfügung stellen (Mutex) Condition Variables im Userspace zur Verfügung stellen Wieder über POSIX-Interface Testprogramme!

46 malloc/free Sinnvollerweise keine Systemcalls reine Userspace-Implementierung Heap-Verwaltung Speichere freie/belegte Blöcke in doppelt verketteten Listen Wenn Speicher angefordert wird, suche einen passenden freien Block und markiere ihn als belegt Wenn Speicher freigegeben wird, hänge den Block wieder in die Liste von freien Blöcken

47 System Call brk/sbrk Setzen den break, also das Ende des Heap brk setzt den Break, sbrk erhöht ihn um ein Inkrement Typischerweise ist brk ein Systemcall, sbrk nur ein Wrapper Wird von malloc/free benötigt, um Heap zu vergrößern/verkleinern Überlegung: Wo soll der Heap überhaupt liegen? Wer kümmert sich um das Mappen der Pages?

48 Fortgeschrittene Themen Treiber für Maus, Sound,... Suspend to Disk Besseres Filesystem (zb ext3) Shared Memory usw. (siehe LV-Homepage)

49 Ich habe ganz andere Ideen! Mail an Tutor Ungefähre max. Punkte Veröffentlichung einer Liste mit allen Ideen und ungefähren max. Punkten Unverbindlich: Ihr müsst die Idee nicht umsetzen (Pflichtaufgaben sind wichtiger!)

50 Bonus: Bug Reports BugReports bitte auf Sourceforge submitten zuerst vorhandene BugReports checken Möglichst ausführliche Bug Beschreibungen Möglichst kompakte Patches (!) Tutor Bescheid geben

51 Allgemeine Hinweise zur Abgabe Extrem langsame Performance der Abgabe kann zu Punkteabzügen führen Userspace-Programm, das Kernel zum Absturz bringt, bringt Punkteabzüge Interrupts/Scheduling disablen bringt Abzüge! (außer mit sehr guter Begründung und Absprache mit Tutor) Missachten der vorgegebenen Interfaces bringt Punkteabzüge (beachtet das Stubs-File auf der LV-Homepage!)

52 1 Multiprogramming in SWEB (Wiederholung) Memorymanagement Prozesse und Threads Erstellen von Prozessen Funktionsaufruf Syscalls Synchronisations-Mechanismen 2 Assignment 1 Task 1 - Multithreading Task 2 - Fork Weitere Tasks 3 Abgabe Designdokument Abgabe Schedule

53 Designdokument 1/3 Ausgangslage, Ziele Anforderungskatalog Betroffene Module Lösungskonzept neue Klassen, Schnittstellendefinition Ausführliche Beschreibung z.b. Klassendiagramm, Sequenzdiagramm Testfälle Reine Wiederholung der Aufgabenstellung bringt Punkteabzüge!

54 Designdokument 2/3 Auf den ersten beiden Seiten Executive Summary Kurze Übersicht über die Lösung Details wie Funktionsnamen und Rückgabewerte sind hier nicht erwünscht. Lesen des Executive Summary muss ausreichen, um das Design beurteilen zu können

55 Designdokument 3/3 Für den Rest gibt es keine formalen Anforderungen Design der Problemlösung sollte klar ersichtlich sein Mögliche Fehlersituationen beschreiben Lösungsmöglichkeiten anbieten Angabe der behandelten Fehlersituationen Angabe der nicht behandelten Fehlersituationen (mit Begründung!) Angabe von Returnwerten im Fehlerfall! Als PDF abzugeben

56 Abgabefunktionalität Ein Repository für Designdokument und Implementation Designdokument: doc/design_a1.pdf Readme: doc/readme_a1.txt oder doc/readme_a1.pdf Abgabe erfolgt durch taggen und pushen der Abgabeversion Designdokument (SubmissionD1) Implementierung (SubmissionI1) Abgabe: Pushen: git push Taggen: git tag <name> Tag Pushen: git push --tags (!) Changeset-ID auslesen: git show <name> Mailen an und an den Tutor. Betreff: Submission Team <teamid> <tag> <changesetid> siehe auch Lehrveranstaltungs-Homepage

57 Abgabeschluss Designdokument: 31. Oktober 2013, 18:00 Uhr Implementierung: 15. November 2013, 18:00 Uhr

58 Designdiskussionen Nächste Woche Anwesenheitspflicht (!) Sitzen in großem Kreis zwecks Diskussionen Keine Slides, keine Präsentation, Skizzen/Zeichnungen an der Tafel Alle Gruppenmitglieder sollten was zur Diskussion beitragen Gemeinsames Besprechen der Aufgabenstellung und der Designs Aufspüren von Schwächen im Design Wiederholung der Aufgabenstellung genügt nicht Sofortiges Feedback (Zettel und Stift mitnehmen!)

59 Abgabegespräche Anwesenheitspflicht Umfassende Kenntnisse der Gesamtlösung Von jedem Gruppenmitglied! Jedes Gruppenmitglied muss auch Änderungen am Code durchführen können! Termine werden noch bekannt gegeben (Newsgroup)

60 Fragen?