Übersicht / Geschichte der Betriebssysteme

Übersicht / Geschichte
Übersicht / Geschichte
der Betriebssysteme
Tanenbaum
Stallings
Glatz
1
Kap. 1.1, 1.2, 1.5, 1.7
Kap. 2.1 - 2.5
Kap. 1
ZHAW, BSy, M. Thaler
Dezember 16
1
Inhalt
Lehrziele
Geschichtliche Entwicklung
• Batch Systeme, Multiprogramming, Time Sharing Systeme,
Problemstellungen
Grundkonzepte aktueller Betriebssysteme
• Prozesse, Scheduling und Ressourcenverwaltung,
Speicherverwaltung, Schutz und Sicherheit,
Systemarchitektur
Aktuelle Betriebssysteme
• Microkernel Architektur, Virtualisierung, Real-Time BS,
Symmetrisches Multiprocessing, Multithreading,
2
ZHAW, BSy, M. Thaler
Dezember 16
2
Lehrziele
Sie können
• den Begriff Betriebsystem erklären
• die Begriffe Batchbetriebssystem, Uniprogramming,
Multiprogramming , Time Sharing erklären und diskutieren
• den Begriff Monitor erklären
• Problemstellungen bei frühen Betriebssystemen aufzählen
• grundlegende Konzepte von Betriebssystemen aufzählen und
diskutieren
• aktuelle Betriebssystemtypen aufzählen, erklären und diskutieren
• die Begriffe Multithreading und symmetrisches Multiprocessing
erklären und diskutieren
3
ZHAW, BSy, M. Thaler
Dezember 16
3
(R)Evolution bei Hardware
Entwicklung der Betriebssysteme
• eng verknüpft mit Entwicklung der Computer-Hardware
• seit 1953
Hardware Komponenten ca. um Faktor 109 besser
Typischer Rechner
1981
MIPS
Kosten/MIPS
Speicher
Disk
Netzwerk
Adressbits
4
1
150‘000
128
10
9600
16
Fr
KByte
MByte
Bit/s
Bit
2015
Faktor
150'0001)
150'000
50·106
130'000
300'000
11·106
4
0.5
16
3
100
64
Rp
GByte
TByte
GBit/s
Bit
1) Intel i7, Extreme Edition, 3.3GHz (1000$), Quelle Wikipedia
ZHAW, BSy, M. Thaler
Dezember 16
4
Geschichtliche Entwicklung: 5 Generationen
1945-1955
1955-1965
1965-1980
Röhren
Steckbretter
Transistoren
Batchsysteme
IC's
Multiprogramming
kein Betriebssystem
keine Software
"Monitor"
Assembler,
Fortran, Cobol,
Bibliotheken
Technologie
Betriebssysteme
Multics
OS/360
• Unix (Mini)
1972
1980Personal
Computer
1990Mobile
Computer
• MS-DOS 1.0 • WIN 3.0
• WIN NT
• MacOS
• OS/2 • Linux
UNIX (Micro)
iPhone
(2007)
Android
(2008)
SMPKommunikationsScheduling
protokolle
(Multicore)
Spooling Integrierte SchaltungenDistributed Computing
Transistoren
Multiprogramming
Personal Computer
Batchsysteme
Multiprogramming
Graphische
Schutzmechanismen
Benutzeroberflächen
Cloud
Time Sharing
Offene Systeme
Computing
Process Scheduling
MULTICS
UNIX (Mini)
UNIX (Micro)(OpenStack
"Monitor"
Memory Management
CPU
CPU
CPU
CPU
OS/360
2009)
• MS-DOS 1.0
• WIN 3.0
on-line File Systeme
Assembler, Fortran
Real-Time Systeme
• MacOS • WIN NT
Cobol, Programmbibliotheken
• OS/2
Bildschirmterminals
Lochstreifen, -Karten
Multicoreerste PC's
Prozessoren
Batchverarbeitung
KommunikationsVektor- und Mehr(2004)
prozessorsysteme
protokolle
Spooling
I/O Prozessoren
Multiprogramming
Verdrängung Mainframes
Common Level 3 Cache
Schutzmechnismen
Distributed
Computing
Befehlskompatible
durch PC's
und WS's
Touch
Rechnerfamilien
Screens
Vernetzung
zunehmende
(PDP-6/10/11...)
Bedeutung
Technologie
Röhren
Konzepte
Steckbretter
Betriebssysteme
kein Betriebssystem
no Software
GPU
Erkenntnisse
Eingabe über
Schalter
Hardware
DEC PDP-1
Intel i75 Haswell
PCI Express Controller
Batchverarbeitung
Memory ControllerZHAW, BSy, M. Thaler
Dezember 16
• 5 Generationen von elektronischen Comptern
- Röhren
Batchsysteme, Uniprogramming
- Transistoren
Batchsysteme, Multiprogramming
- Integrierte Schaltungen
Time Sharing
- Personal Computer
CP/M: Control Program for Microcomputers
DOS: Disk Operating Systems
- Mobile Computers
5
Geschichtliche Entwicklung: 5 Generationen
1945-1955
1955-1965
1965-1980
Röhren
Steckbretter
Transistoren
Batchsysteme
IC's
Multiprogramming
kein Betriebssystem
keine Software
"Monitor"
Assembler,
Fortran, Cobol,
Bibliotheken
Technologie
Betriebssysteme
Multics
OS/360
• Unix (Mini)
1972
1980Personal
Computer
• MS-DOS 1.0 • WIN 3.0
• WIN NT
• MacOS
• OS/2 • Linux
UNIX (Micro)
Spooling
Multiprogramming
Schutzmechanismen
Time Sharing
Process Scheduling
Memory Management
on-line File Systeme
Real-Time Systeme
Eingabe über
Schalter
Graphische
Benutzeroberflächen
Offene Systeme
Bildschirmterminals
erste PC's
Vektor- und Mehrprozessorsysteme
Lochstreifen, -Karten
Hardware
Mobile
Computer
Kommunikationsprotokolle
Distributed Computing
Batchverarbeitung
Konzepte
1990-
I/O Prozessoren
Befehlskompatible
Rechnerfamilien
(PDP-6/10/11...)
6
Verdrängung Mainframes
durch PC's und WS's
Vernetzung zunehmende
Bedeutung
ZHAW, BSy, M. Thaler
iPhone
(2007)
Android
(2008)
SMPScheduling
(Multicore)
Cloud
Computing
(OpenStack
2009)
MulticoreProzessoren
(2004)
Touch
Screens
Dezember 16
• 5 Generationen von elektronischen Comptern
- Röhren
Batchsysteme, Uniprogramming
- Transistoren
Batchsysteme, Multiprogramming
- Integrierte Schaltungen
Time Sharing
- Personal Computer
CP/M: Control Program for Microcomputers
DOS: Disk Operating Systems
- Mobile Computers
6
Batch-Systeme
7
• Erste Betriebssysteme
ZHAW, BSy, M. Thaler
Dezember 16
Batchsysteme:
- Mitte 50er Jahre, General Motors auf einer IBM 701
- Anwender übergibt Job (Lochkarten oder Band) an den Operator
- der Operator reiht mehrere Jobs sequentiell in einem Eingabegerät auf
Batch
- ein spezielles Programm, der Monitor, kontrolliert Ausführung der Jobs im Batch
(sequentielle Verarbeitung)
- der für die Steuerung wichtige Teil des Monitors
Monitor
immer im Speicher
Resident
- Hilfsprogramme werden nach Bedarf eingelesen
7
Der Monitor: ein Minimalsystem
Ein Programm
• bei Hardware-Reset des Prozessors gestartet
- HW-Reset
default HW settings
• intialisiert
- Interruptvektoren
falls vorhanden
- Kommunikation mit Anwender
- in komplexeren Systemen
Speicher- / IO-Schnittstellen, etc.
Cache, MMU, Disk-Controller, etc.
• stellt zur Verfügung
- Debugging-Hilfen, einfache Funktionen
Beispiele
• einfacher Monitor: CT, komplexer Monitor: BIOS bei PC's
8
ZHAW, BSy, M. Thaler
Dezember 16
• Initailisierung
- Interruptvektoren
setzt nicht gebrauchte Vektoren auf Default Wert → z.B. nur IRET
- einfache Kommunikation mit Anwender für
setzen und lesen von Parametern, Speicher, etc.
laden von Programmen (M86)
debuggen von Programmen (single step)
etc.
- einfache Schnittstellen, so dass HW nicht beschädigt wird
- einfachen bootloader starten, falls vorhanden (z.B. aus Flash)
• zusätzlich bei komplexen System (z.B. BIOS)
- Initialisierung von
weiteren HW Komponeneten
• Cache Controller
• Memory Management Unit (MMU)
Speicher
• Check auf korrekte Funktionalität
• wie viel Speicher ist vorhanden
• etc.
Disk IO
- ev. boot loader starten
8
... Batch-Systeme: Monitor
Speicherlayout
Interrupt
Processing
Monitor
Device
Drivers
Monitor
• liest Job um Job vom Eingabegerät
• legt Job im Anwenderprogramm-Bereich ab
Job
Sequencing
Monitor-Instruktionen
• starten Anwenderprogramm
• warten auf
- Instruktion "END OF PROGRAMM"
- oder Fehler
Contrl. Language
Interpreter
User Program
Area
Uniprogramming
• nur ein Programm im Speicher
9
ZHAW, BSy, M. Thaler
Dezember 16
Batch-Verabeitung
• Monitor
- resident Monitor: steuert den Ablauf steht immer im Speicher
- Hilfsfunktion, etc. werden nach Bedarf mit Anwenderprogrammen geladen
- wenn Job in Speicher geladen
- wenn Job terminiert
Kontrolle an Job
Kontrolle zurück an Monitor
End Of Program oder Fehler
- Resultate werden an entsprechende Ausgabegeräte weitergegeben
• Monitorsteuerung (gelb) und Programm (grau) z.B. auf Lochkarten
9
Batch Systeme: Uniprogramming
I/O Operationen
• sehr langsam im Vergleich zur Ausführung von Instruktionen
CPU oft idle
Programme mit viel I/O Operationen
• verbringen meiste Zeit mit Warten
• sehr schlechte CPU-Auslastung
Run
wait for I/O
Run
Run
wait for I/O
t
Zeit
10
ZHAW, BSy, M. Thaler
Dezember 16
10
Batch Systeme: Multiprogramming
Mehrere Programme im Speicher
• Programm wartet auf I/O Operation
• Monitor führt anderes Programm aus (interleaving, concurrent)
Multiprogramming bzw. Multitasking
Run
wait for I/O
Run
wait for I/O
Run
Run
wait for I/O
wait for I/O
Run
wait for I/O
Run
Run
wait for I/O
Run
Run
Run
Run
Run
wait for I/O
wait for I/O
t
11
ZHAW, BSy, M. Thaler
Dezember 16
• Benötigte Hardwareunterstützung
- I/O Interrupts und (wenn möglich) DMA
Instruktionen können während I/O Operationen ausgeführt werden
- Speicherverwaltung (memory management)
mehrere lauffähige Jobs im Speicher halten
• Softwareunterstützung
- Scheduling
welcher Job wird als nächstes ausgeführt
- Steuerung und Kontrolle des Zugriffs auf Ressourcen
Konflikte vermeiden, resp. lösen
11
MP: nowendige HW-Unterstützung
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
12
ZHAW, BSy, M. Thaler
Dezember 16
12
Beispiel 3 Jobs: Uni- vs. Multiprogramming
CPU
CPU
97%
Memory
100%
Memory
20%
40%
30%
Disk
90%
Disk
100%
Terminal
Printer
10%
Printer
100%
40%
100%
Terminal
10%
70%
100%
JOB1
JOB2
JOB3
Jobs
Jobs
JOB1
0
5
JOB2
10
JOB3
15
20
25
25
0
5
10
15
Ressourcenauslastung in %
13
ZHAW, BSy, M. Thaler
Dezember 16
• 3 Jobs mit minimalen Konflikten beim Zugriff auf Ressourcen
- Annahme
Job 2 und 3 erhalten genügend CPU-Zeit für I/O Aktivitäten
Jobs können in minimaler Zeit ablaufen
- Ressourcenbedarf der Jobs
Job 1
Job 2
Job 3
heavy compute
heavy I/O
heavy I/O
5 Min.
15. Min
10. Min
50 K
100 K
80 K
Need disk
no
no
yes
Need terminal
no
yes
no
Need printer
no
no
yes
Type of job
Duration
Memory req.
- Ressourcenauslastung des Rechners durch Jobs
Uniprogramming
Multiprogramming
Processor use
17%
33%
Memory use
30%
67%
Disk use
33%
67%
Printer use
33%
67%
Elapsed time
30 Min.
15 Min.
Throughput rate
6 jobs/hr
12 jobs/hr
Av. turnaround time
17 Min.
10 Min.
13
Time Sharing Systeme (TSS)
Batch Multiprogramming
• keine Interaktion mit Anwender möglich
Time Sharing erweitert Multiprogramming
• gleichzeitige (concurrent) Ausführung mehrerer interaktiver
Programme
• CPU-Zeit auf mehrere Benutzer verteilt
• "gleichzeitiger" Zugriff durch mehrere Benutzer
Erstes Time Sharing System am MIT
• CTSS (compatible time sharing system)
• um 1962 auf IBM 709
14
ZHAW, BSy, M. Thaler
Dezember 16
• Wieso funktioniert es ?
- Mensch hat "lange" Reaktionszeiten
- benötigt ca. 2 sec. Rechenzeit pro Minute
- 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
- Schutz des File Systems und Arbeitsspeichers notwendig (mehrere Benutzer)
• 100ms Reaktionszeit gilt als akzeptabel
• CTSS: sehr einfach im Vergleich zu heutigen TS-Systemen
- sehr einfach
Monitor klein
- Jobs immer vollständig in Speicherbereich geladen
- auslagern von suspendierten Jobs nur wenn notwendig
- maximal 32 Benutzer
14
Uni- vs. Multiprogramming vs. Time Sharing
Uniprogrammed Batch System
• ein 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, Speicherverwaltung
Time Sharing System
• gleichzeitige Verarbeitung mehrerer interaktiver Jobs
• benötigt
- Schutz des Filesystems und Arbeitsspeichers
- Mutex (gegenseitiger Ausschluss), z.B. Zugriff auf Drucker
15
ZHAW, BSy, M. Thaler
Dezember 16
15
Frühe Betriebssysteme
Probleme mit
• nichtdeterministischem Programmverhalten
- Resultat der Berechnung abhängig von anderen aktiven
Programmen
• gegenseitigem 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
16
ZHAW, BSy, M. Thaler
Dezember 16
16
Grundkonzepte moderner BS
Lösung Probleme
fünf wesentliche Konzepte
1. Prozesse
2. Scheduling und Ressourcenverwaltung
3. Datenmangement
- Speicherverwaltung
- File-Systeme
4. Schutz und -Sicherheit
5. System-Architektur
17
ZHAW, BSy, M. Thaler
Dezember 16
17
... Grundkonzepte moderner BS
Prozess
• Programm in Ausführung ... "Sandbox"
Scheduling
• Zuteilung von Rechenleistung
• BS unterhält 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
18
ZHAW, BSy, M. Thaler
Dezember 16
18
... Grundkonzepte moderner BS
Ressourcenverwaltung
• Verwaltung und Zuteilung von Ressourcen
• berücksichtigt
- Fairness
alle Prozesse haben 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
maximaler Durchsatz, minimale Antwortzeit
möglichst viele Benutzer bedienen
19
ZHAW, BSy, M. Thaler
Dezember 16
19
... Grundkonzepte moderner BS
Speicherverwaltung
• 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
- Lösung: z.B. virtueller Speicher
20
ZHAW, BSy, M. Thaler
Dezember 16
• Virtueller Speicher
- (virtueller) Addressraum grösser als physikalischer Adressraum
- Speicherblöcke (pages) im virtuellen Speicher werden auf Blöcke (frames) im
physikalischen Speicher abgebildet
- nur wirklich benötigte pages werden in den Speicher geladen
- Rest auf Disk ausgelagert
20
... Grundkonzepte moderner BS
File-Systeme
• Langzeitspeicherung von Daten auf Sekundärspeicher
• Informationsspeicherung in Files
- Objekte mit Namen (named objects)
- Einheit bezüglich Zugriff und Schutz
• Ablageorganisation der Files
- in Verzeichnissen (directories)
hierarchisch
- Verzeichnisse enthalten Files und Verzeichnisse
• Operationen auf Files
- Erzeugen, Löschen, Öffnen, Schliessen, Lesen, Schreiben,
Erweitern, Kopieren, Umbenennen, etc.
21
ZHAW, BSy, M. Thaler
Dezember 16
21
... Grundkonzepte moderner BS
Schutz und Sicherheit
• Zugriffskontrolle
- Systemzutritt nur für zugelassene bzw. registrierte Nutzer
- keine Zugriff auf nicht freigegebene Ressourcen
• Kontrolle des Informationsflusses
- innerhalb des Systems
- bei Auslieferung an Benutzer
• z.B. Firewalls, ACLs, etc.
Zugriffskontrolle
Ressource
Ressource
Kontrolle des
Informationsflusses
22
ZHAW, BSy, M. Thaler
Dezember 16
22
... Grundkonzepte moderner BS
System-Architektur
• Komplexität von Betriebssystemen
- CTSS, 1963, MIT
- OS/360, 1964, IBM
- Multics, 1975, MIT / Bell Labs
- Win/XP
• Lösungsansatz Schichtenmodell
32‘000 36-Bit Wörter
mehr als 106 Instruktionen
mehr als 20 ·106 Instr.
~30·106 Zeilen Code
Anwenderprogramme
Systemdienste
BS-Funktionen
prozessorunabhängig
Kernel
Hardware-Kontroller
prozessorabhängig
Hardware
23
ZHAW, BSy, M. Thaler
Dezember 16
• Schichtenmodell
- jede Schicht stellt eine Anzahl Funktionen zur Verfügung
- jede Schicht verwendet Funktionen aus der nächst unteren Schicht
- gut definierte Schnittstellen
Schicht kann modifiziert werden, ohne anderen Schichten zu beeinflussen
- Nachteil
Leistungseinbusse (performance loss)
- Vorteil
übersichtliche Struktur
Aufteilung in Teilsysteme
einfacher zu handhaben
• DOS
- Diretkzugriff auf Hardware war möglich
sehr gefährlich
23
Microkernel Architektur
User
Mode
I/O Device Mgmt.
Kernel
Mode
•••
Virtual Memory
IPC
File Server
User
Mode
Gerätetreiber
Filesystem
Client Prozess
Benutzer
Virtual Memory
Primitives Proz. Mgmt.
Microkernel
Kernel
Mode
Hardware
Traditionelle Architektur
Hardware
Micorkernel Architektur
monolithischer Kernel
24
ZHAW, BSy, M. Thaler
Dezember 16
• Traditionelle Betriebssysteme
- nach Schichtenmodell aufgebaut
- Schichten sind umfangreich
- grössere Änderungen in Schicht
ev. Auswirkung auf benachbarte Schichten
• Microkernel Architektur
- nur notwendigste Funktionen im Kernel, abhängig von aktueller Implementation
- restliche Dienste
Prozessen, die im User Mode laufen (Server)
typische ausgelagerte Funktionen: Filesystem, Treiber, Virtual Memory
Manager, Window System, Sicherheitsdienste, etc.
- Kernel: "Kommunikationsplattform zwischen Prozessen"
- Diskussion
zuverlässiger (weniger Code), leicht erweiterbar: neuer Dienst neuer Prozess
einheitliche Schnittstellen: Message Passing zwischen Prozessen
Flexibilität: nur benötigte Dienste laufen (anwendungs-spezifisch)
Portabilität: Kernel klein
schlank
HW-Anbindung klein
leicht geringere Leistung, wegen Interprozesskommunikation
SMPs und verteilte Systeme: Prozesse auf beliebige CPUs verteilbar
Beispiele: Mach (CMU) → Apple , Chorus
24
Virtualisierung
Virtual Machine Monitore (VMM)
• heute oft "Hypervisor" genannt
• ca. 40 Jahr alt: IBM Mainframes
Apps
Apps
Apps
Apps
OS1
OS2
OS3
OS4
Hypervisor Typ 1
HW
CPU Memory Disk Network
Apps
Apps
Apps
Apps
OS2
OS3
OS4
Hypervisor Typ 2
Host BS
HW
CPU Memory Disk Network
Typ 1: kein Host BS
Typ 2: Host BS
25
ZHAW, BSy, M. Thaler
Dezember 16
• IBM seit ca. 40 Jahren virtuelle Maschinen
• In PC-Welt ab 90er Jahren verschiedene Forschungsprojekte
- Disco (Stanford), Xen (Cambridge)
- daraus entstandene kommerzielle Produkte
VMWare, Xen, VirtualBox (Sun, Oracle), Hyper-V (Microsoft), etc.
• Moderne Prozessoren unterstützen zudem Virtualisierung
- notwendig wegen privilegierten Instruktionen und Interrupts
• Type 1 Hypervisor: "bare metal" oder native
- es gibt kein Host Betriebssystem
- Hypervisor beinhaltet Treiber für Ansteuerung der Hardware
• Type 2 Hypervisor: hosted
- Hypervisor setzt auf "vollem" Betriebssystem auf
- nutzt Filesystem und Treiber des Hosts für Hardwarezugriff
- benötigt meist Kernelmodul wegen privilegierten Instruktionen
• Vorteile
- mehrere Betriebssysteme laufen gleichzeitig auf einem Rechner
WEB-Hosting, Cloud-Computing
- ein "Problem" Betriebsystem beeinflusst die Funktionalität nihct
• Nachteile
- etwas langsamer
25
Real-Time Betriebssysteme
Real-Time Systeme
• in reale Umwelt eingebettet
• müssen auf Ereignisse reagieren
• z.B. Prozesssteuerungen, Flugzeugsteuerung, Einspritzung, etc.
Echzeitsysteme: zwei Bedingungen
• das Resultat muss logisch korrekt sein
• das Resultat muss zur richtigen Zeit abgeliefert werden
Beispiele
• Sie geben Gas zum Überholen: der Bordcomputer hat gerade
keine Zeit das Einspritzventil zu öffnen, na ja ...
• Flugzeug im Landeanflug: der Bordcomputer hat gerade
keine Zeit für die Steuerung, ....
26
ZHAW, BSy, M. Thaler
Dezember 16
• Nicht alle RT- Systeme mit so hohen Anforderungen
- z.B. sollte ein Editor Buchstaben innerhalb von 2s auf dem Bildschirm darstellen
- oder, die Bank sollte Buchungen innerhalb einer Woche durchführen
→ Soft RealReal-Time Systeme
• Real-Time Betriebssysteme
- i.A. eine sehr eingeschränkte Funktionalität
meist kein Virtual Memory und Sekundärspeicher oder nur sehr beschränkt:
Programme, etc. in ROM
- unterstützen nur die notwendigsten Funktionen
- sehr hardwarenahe implementiert → bessere Kontrolle über Zeitverhaltens
26
Symmetrisches Multiprocessing
Symmetrischer Multiprozessor (z.B. Multicore, ...)
• alle CPUs gleich
• gemeinsam: Speicher und I/O Subsystem
Scheduling
• BS muss Tasks auf allen CPU's einplanen können
CPU
Cache
Cache
Main
Memory
27
CPU
...
Cache
I/O Subsystem
CPU
ZHAW, BSy, M. Thaler
Dezember 16
• Ein Rechner mit mehreren Prozessoren
- Trend (Normalfall): mehrere CPUs auf einem Chip
- meist Level 1 und 2 Caches pro Prozessor, aber gemeinsamer Level 3 Cache
• Alle CPUs
- arbeiten selbständig
- gleiche Funktionalität, können alle Aufgaben bearbeiten
symmetrisch
- nutzen Hauptspeicher und I/O Geräte gemeinsam
- haben eigenes Cachesystem
Cache: Abbild des Hauptspeichers (einzelne Blöcke)
Cache Coherence Problem
• gleicher Block aus Speicher in mehreren Caches, eine CPU ändert Wort
in Cache
was sehen die anderen CPUs ?
• Lösungen meist auf Hardwareebene
• Echte Parallelität: das BS verteilt Prozesse und Threads auf alle Prozessoren
- für Anwender transparent
• Vorteile
- höhere Leistungsfähigkeit durch zusätzliche CPUs
- Verfügbarkeit: kein Stillstand bei Ausfall einer CPU, nur Leistungsreduktion
gilt für Multicores beschränkt
• Nachteil
- Betriebssystem aufwendiger (speziell Scheduler)
- Datenmanagement aufwendiger
27
Herausforderung bei BS
Tradeoff zwischen
Einfachheit und Leistungsfähigkeit
erste Wahl
Einfachheit
... "ausser es gibt einen überzeugenden Grund zu
glauben, dass akzeptable Leistung nur durch
Komplexität erreicht werden kann"
28
ZHAW, BSy, M. Thaler
Dezember 16
28
... Herausforderungen / Trends
Neue Hardwareentwicklungen
•
•
•
•
•
Multiprozessoren / Multicore-, Many-Core Prozessoren
keine schnelleren Prozessoren
Hochgeschwindigkeitsnetzwerke
grössere Speicher (RAM, Disk, etc.)
64-Bit Architekturen, mit/ohne x86 Instruktionssatz
Neue Softwareanforderungen
•
•
•
•
•
•
29
Mobile Computing
Eingebettete Systeme
Internet of Things
Cloud Computing (Client/Server Anwendungen)
Distributed/Parallel Computing
Multimedia Anwendungen
ZHAW, BSy, M. Thaler
Dezember 16
29