BSY - Betriebssysteme

Mehrere Threads pro Prozess

• Threadwechsel weniger aufwendig bzw. billiger
• Aufgabenteilung
• Unterstützt Multicore-Prozessoren

Das BS kennt das Konzept des Threads nicht.

• Kann schnell erzeugt und verwendet werden. Er braucht nur Stack und Speicher für die Register
• Threadweschsel sind schnell
• Threads benötigen wenig Ressourcen, keinen neuen Adressraum, keinen eigenen Datenbereich oder Programmcode und keine zusätzlichen BS-Ressourcen.

=> Thread ist "billig"

• Daten Server
  • mehrere Anfragen "gleichzeitig" innerhalb kurzer Zeit bearbeiten
  • pro Anfage ein Thread ist effizienter als ein Prozess
• Spreadsheet
  • Ein Thread behandelt Anzeige und Input
  • ein Thread fürht Befehle aus (im Hintergrund)
• Parallelverarbeitung mit viel Kommunikation
  • Zugriff auf gemeinsame Datenbereiche ist effizienter
  • Matrixmultiplikation auf mehrere Threads verteilen
• Programme mit Vorer- und Hintergrundaktivitäten
  • z.B. in regelmässigen Abständen Daten sichern

Wenn kein Multiprozessing notwendig ist doer wenn mehrere Prozesse notwendig sind, z.B. Sicherheit, etc.

• New
• Ready
• Running
• Blocked
• Stopped

Weil alle Threads im gleichen Adressraum sind.

Alle Threads terminieren.

• user level threads: der Prozess blockiert
• kernel level threads: der Thread blockiert

• User-Level Threads (ULT)
• Kernel-Level Threads (KLT)

Hierbei ist die Anwendung verantwortlich für das Threadmanagement (Bibliotheksfunktionen)

Theradwechsel benötigt keine Kernel Mode Privilegien und Threadscheduling ist applikationsspezifisch wählbar

Thread Bibliothek

• Speichern und Rückspeichern des Threadkontextes
• Threas erzeugen und beenden
• Scheduling

Der Kernel weiss nichts von Threadaktivitäten, kontrolliert aber nach wie vor die Prozessaktivitäten

Thread macht ein System Call. Der ganze Prozess blockiert, auch die anderen Threads dieses Prozesses. Die meisten System Calls haben diese Wirkung.

Aus Sicht des Threadscheduliers ist der Thread nach wie vor am Laufen. Die Thread Zustände sind unabhängig von Prozesszuständen.
Threads können nicht unterbrochen werden. Sie können nur freiwillig die Kontrolle über CPU abgeben.

Vorteile:

• Threadwechsel involviert Kernel nicht
• Läuft auf jedem BS (Bibliothek notwendig)
• Schedulingverfahren kann anwendungsspezifisch gewähtl werden, aber oft nicht preemptive
• Schnell und einfach

Nachteile:

• Die meisten System Calls blockieren. Prozess blockiert und damit auch die anderen Threads des Prozesses
• Nur der Kernel kann Prozesse zuweisen, d.h. Parallelverarbeitung ist nicht möglich
• Page Fault eines Threads blockiert ganzen Prozess

Thread Management geschieht durch Kernel.

• Keine Bibliothek, sondern API zu Threadfunktionen des Kernels
• Kernel verwaltet Kontextinformationen von Prozessen und Threads
• Threadwchsel erfordert Intervention des Kernels
• Schedulierbare Einheit: Therad
• Threads können auf mehrere Prozessoren verteilt werden

Vorteile:

• Kernel kennt alle Threads. Ein Prozess mit 10 Threads kann anders behandelt werden als ein Prozess mit einem Thread
• Scheduling auf Thread Basis
• geeignet für Anwendungen, die häufig blockieren, z.B. Server mit viel Interprozesskommunikation.
• Kernelfunktionen können selbst Multithreaded sein
• geeignet für SMP

Nachteile:

• Threadwechsel innerhalb eines Prozesses durch Kernel kostet 2 Mode Switches
• spürbarer Overhead und höhere Kernelkomplexität. Jeder Thread benötigt Thread Control Block (TCB)
• sprürbar langsamer bei 1 CPU

Therads werden im User Space erzeugt. Scheduling und Synchronisation geschehen hauptsächlich im User Space.

Programmierer kann zur Optimierung die Anzahl KLTs anpassen.

Es gibt keinen Schutz der Daten gegen unbeabsichtigten Zugriff.

Koordination der Ausführung von Threads. Es garantiert die Datenkonsistenz (keine Race-Conditions)

Gleichzeitiger Zugrif von 2 oder mehr Threads, davon 1 Schreibzugriff.

Der Monitor liest Job um Job vom Eingabegerät und legt den Job im Anwenderprogramm-Bereich ab.

Die Monitor-Instruktionen starten das Anwenderprogramm und warten auf die Instruktion "END OF PROGRAMM" oder auf Fehler.

Der resident Monitor steuert den Ablauf, der immer im Speicher steht.

Hilfsfunktionen, etc. werden nach Bedarf mit Anwenderprogrammen geladen.

Wenn ein Job in den Speicher geladen wurde wird die Kontrolle an den Job abgegeben. Sobald der Job terminiert, geht die Kontrolle zurück an den Monitor (Bei END OF PROGRAM oder Fehler).

Die Resultate werden an entsprechende Ausgabegeräte weitergegeben.

I/O Operationen sind langsam im Vergleich zur Ausführung von Instruktionen (CPU oft idle).

Programme mit vielen I/O Operationen verbingen die meiste Zeit mit Warten und die CPU-Auslastung ist sehr schlecht.

Mehrere Programme sind im Speicher. Während ein Programm auf I/O Operationen wartet, führt der Monitor ein anderes Programm aus (interleaving, concurrent).

Dies benötigt HW-Unterstützung:

• I/O Interrupts und (wenn möglich) DMA, damit Instruktionen während I/O Operationen ausgeführt werden.
• Speicherverwaltung (Memory Management) um mehrere lauffähige Jobs im Speicher zu halten.

Und SW-Unterstützung:

• Scheduling, damit klar ist, welcher Job als nächstes ausgeführt wird.
• Steuerung und Kontrolle des Zugriffs auf Ressourcen, um Konflikte zu vermeiden, bzw. zu lösen.

• Interrupts
  • Programmunterbruch -> Programmumschaltung möglich
• Timer
  • verhindert, dass Job unendlich lange läuft
  • time-out Interrupt -> Rückkehr in Monitor
• Speicherschutz
  • Anwenderprogramm kann nicht versehentlich in Speicherbereich des (residenten) Monitors schreiben.
• Privilegierte Instruktion
  • Nur vom Monitor ausführbar, z.B. I/O Instruktionen
  • von den meisten modernen Prozessoren (und BS) unterstützt

Die ersten Betriebssysteme waren Batchsysteme.

Der Anwender übergibt einen Job (Lochkarte oder Band) an den Operator. Der Operator reiht mehrere Jobs sequentiell in einem Eingabegerät auf. Das nennt man dann Batch.

Ein spezielles Programm, der Monitor, kontrolliert die Ausführung der Jobs im Batch (sequentielle Verarbeitung).

Der für die Steuerung wichtige Teil des Monitors nennt man Resident Monitor. Er ist immer im Speicher.

Hilfsprogramme werden nach Bedarf geladen.

Bei Batch Multiprogramming ist keine Interaktion mit dem Anwender möglich.
Time Sharing erweitert Multiprogramming. Es ermöglicht die gleichzeitige (concurrent) Ausführung mehrerer interaktiver Programme. Die CPU-Zeit wird auf mehrere Benutzer verteilt und es ist ein "gleichzeitiger" Zugriff durch mehrere Benutzer möglich.

1. Der Mensch hat "lange" Reaktionszeiten
2. TSS benötigen ca. 2 sec. Rechenzeit pro Minute
3. Der Anwender erhält Rechenleistung nur für gewisse Zeitdauer

Fazit:

ca. 30 Anwender könnten ohne wahrnehmbare Verlängerung der Reaktionszeit (<= 100ms) das System gemeinsam nutzen.
Weil es mehrere Benutzer gibt, wird aber ein Schutz des File Systems und des Arbeitsspeichers notwendig.

Schutz des File Systems und des Arbeitsspeichers, da es mehrere Benutzer gibt.

Das CTSS war sehr einfach im Vergleich zu heutigen TS-Systemen.

• Monitor war klein
• Jobs immer vollständig in Speicherbereich geladen
• Auslagern von suspendierten Jobs nur wenn notwendig
• max. 32 Benutzer

Uniprogrammed Batch System

• Job aus Batch im Speicher
• sequentielle Verarbeitung der Jobs
• Monitor zur Steuerung, keine Interaktion mit Anwender

Multiprogrammed Batch System

• mehrere Jobs im Speicher
• benötigt Scheduler, Interrupts und Speicherverwaltung

Time Sharing System

• Gleichzeitige Verarbeitung mehrerer interaktiver Jobs
• benötigt Schutz des Filesystems und des Arbeitsspeichers
• benötigt Mutex (gegenseitiger Ausschluss), z.B. Zugriff auf Drucker

• nichtdeterminischtisches Programmverhalten
  • Das Resultat der Berechnung war abhängig von anderen aktiven Programmen.
• Gegenseitiger Ausschluss
  • mehr als ein Programm greift gleichzeitig auf Ressource zu
• Synchronisation
  • Signale beim Warten verloren.
• Deadlocks
  • Programme warten gegenseitig, z.B. auf Freigabe von Ressourcen

• Prozesse
• Scheduling und Ressourcenverwaltung
• Datenmanagement
  • Speicherverwaltung
  • File-Systeme
• Schutz und Sicherheit
• System-Architektur

Das Programm in Ausführung.

Die Zuteilung von Rechenleistung. Das Betriebssystem unterhält dafür Queues (Wartelisten).

• Ready Queue
  • Prozesse warten im Speicher auf CPU
• Wait Queues
  • Prozesse warten auf entsprechendes I/O Gerät oder I/O Operation
• Long Term Queue
  • Prozesse warten auf Zulassung zum System
  • Lässt beschränkte Anzahl von Prozessen zu

Die Verwaltung und Zuteilung von Ressourcen.

Sie berücksichtigt:

• Fairness
  • Alle Prozesse haben grundsätzlich gleiche Zugriffsrechte
• differenzierte Behandlung
  • verschiedene Klassen von Prozessen berücksichtigen globale Aspekte
  • z.B. Prozesse, die auf I/O Daten warten, sofort einplanen, wenn Daten verfügbar
• Effizienz
  • max. Durchsatz, min. Antwortzeit
  • möglichst viele Benutzer bedienen

• Prozessisolation
  • Kein gegenseitiger Zugriff auf Speicher und Daten möglich
• automatische Speicherallokation
  • Programmierer muss sich nicht um Speicher kümmern
  • Betriebssystem weist Speicher nach Bedarf zu
• Schutz und Zugriffskontrolle
  • Zugriffskontrolle und Schutz bei gemeinsamer Nutzung des Speichers