Kap.

2: Systemarchitektur

2.1 Verteilte Hardware-Architekturen

2.2 Grundbegriffe verteilter Betriebssysteme
2.3 Verteilte Betriebssystemkerne

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-1

2.1 Verteilte Hardware-Architekturen

Begriffsbildung (vgl. Rechnerarchitektur):

• Enge/lose Kopplung:
Zwei Prozessoren heißen eng gekoppelt (tightly coupled), wenn sie
einen gemeinsamen physikalischen Speicher (shared memory)
besitzen. Ansonsten können sie nur durch Nachrichtenaustausch
(message passing) kommunizieren und heißen dann lose gekoppelt.
• Homogenes/heterogenes System:
Sind alle Komponenten eines Systems identisch, so heißt das
System homogen, ansonsten inhomogen oder heterogen.
• Symmetrisches/asymmetrisches System:
Sind alle Komponenten eines Systems gleichwertig in Hinblick auf
ihre Rolle im System, so heißt das System symmetrisch, ansonsten
asymmetrisch.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-2

Klassifikation nach Flynn (1972) 2.1

Charakteristiken:
• Betrachtet werden Instruktions- und Datenströme, auf denen die
Instruktionen arbeiten, als Kennzeichen der Arbeitsweise einer
Rechnerarchitektur:
• SI / MI: Single / Multiple Instruction Streams (Programmzähler)
• SD / MD: Single / Multiple Data Streams
Klassen:
• SISD: Single Instruction Stream / Single Data Stream:
traditionelle Uniprozessor.
• SIMD: Single Instruction Stream / Multiple Data Streams:
Vektorrechner: Parallele Ausführung einer Instruktion auf mehreren
Vektorelementen.
• MISD: Multiple Instruction Streams / Single Data Stream:
wird von den meisten Autoren als leer angesehen.
• MIMD: Multiple Instruction Streams / Multiple Data Streams:
Systeme mit mehreren eng oder lose gekoppelten Prozessoren, parallele
und verteilte Rechensysteme.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-3

MIMD-Klassifikation nach Rashid (1986) 2.1

Charakteristik:
• Unterteilung der Klasse MIMD nach Eigenschaften der Speicherzugriffe.
Klassen:
• UMA (Uniform Memory Access):
– gemeinsamer Adressraum (enge Kopplung).
– Identische Zugriffszeiten aller Prozessoren auf alle Speicherzellen.
• NUMA (Non-Uniform Memory Access):
– gemeinsamer Adressraum (enge Kopplung), aber verteilte
Realisierung des Speichers, dadurch "entfernte" Speicherzugriffe.
– Unterschiedliche Zugriffszeiten auf Speicherzellen abhängig vom
Prozessor.
– auch als Distributed Shared Memory (DSM) bezeichnet.
• NORMA (NO Remote Memory Access):
– kein gemeinsamer Adressraum (lose Kopplung).
© R. Kröger, FH Wiesbaden Verteilte Systeme 2-4
Multiprozessor-/Multicomputer-Systeme 2.1

Multiprozessor-System:
• Ein MIMD-Rechensystem mit eng gekoppelten, identischen
Prozessoren heißt (homogenes) Multiprozessor-System.
• Es kann UMA- oder NUMA-Eigenschaften besitzen.
• Das grundlegende Kommunikationsmodell ist Memory Sharing.
• Hauptaspekt: einfache Programmierbarkeit.

Multicomputer-System:
• Ein MIMD-Rechensystem mit lose gekoppelten, identischen
Prozessoren heißt Multicomputer-System oder Polyprozessor-
System.
• Es besitzt NORMA-Eigenschaften.
• Das grundlegende Kommunikationsmodell ist Message Passing.
• Hauptaspekt: Skalierbarkeit für große Anzahl von Prozessoren.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-5

2.1.1 Multiprozessor-Systeme

UMA / NUMA-Diskussion:
• UMA-Multiprozessorsysteme
– Traditionelle Architektur.
– Unterstützung für kleine bis mittlere Anzahl von Prozessoren
(bis ca. 32-64).
– Basis: intelligentes write back-basiertes Cache-Kohärenz-Protokoll.
• NUMA-Multiprozessorsysteme
– Neuere Architektur.
– Auch als Distributed Shared Memory (DSM)-Systeme bezeichnet.
– Auch ccNUMA bei Herausstellung der Cache-Kohärenz genannt.
– Unterstützung für mittlere bis große Anzahl von Prozessoren
(derzeit 128 - 1024).
– Vorteil: Memory Sharing- Programmiermodell bleibt erhalten, auch wenn
Plazierung der Daten zur Erreichung eines hohen Grades lokaler
Zugriffe wichtig bleibt.
– Existierende Software kann i.w. weiterverwendet werden,
im Gegensatz zu NORMA-Systemen.
© R. Kröger, FH Wiesbaden Verteilte Systeme 2-6
Alternativen für enge Kopplung 2.1.1

Basis für Kopplung zwischen Prozessor- und Speicher-Modulen:

• Bussysteme
– Vgl. Vorlesung Rechnerarchitektur.
– Traditionelle Form.
– Ein Bus besteht aus Adress- und Datenleitungen (z.B. je 32) sowie
aus Kontrolleitungen (ca. 10-30) zur Koordinierung der
Busbenutzung.
– Architektur kann einzelnen Bus oder mehrere parallele oder
hierarchische Busse vorsehen.
– Architektur mit einem Bus ist heute vorherrschender Typ bei
Systemen bis ca. 32-64 Prozessoren.
• Switch-basierte Verbindungsnetzwerke
– Bieten Unterstützung für eine große Zahl von Prozessoren.
– Kreuzschienenverteiler (Crossbar Switch)
– Omega-Netzwerk, Butterfly-Netzwerk, Baumstruktur, ...
© R. Kröger, FH Wiesbaden Verteilte Systeme 2-7
Beispiel 1 2.1.1

1-Bus-basiertes Multiprozessor-System:

Prozessoren P1 P2 Pn
... Schnittstelle des sequentiellen
von-Neumann-Speichers
Caches C1 C2 Cn

Bus

Speicher M1 Mm

• Symmetrische Multiprozessor-Systeme (SMP) mit einem Bus sind heute

der vorherrschende Typ von kommerziellen Rechensystemen.
• Durch 1-Bus-Architektur sind UMA-Eigenschaften gegeben.
• Durch Einführen von Cache-Speichern und intelligente Cache-Kohärenz-
Verfahren kann die Anzahl der sinnvoll betreibbaren Prozessoren an einem
Bus auf ca. 32-64 erhöht werden.
• Beispiele: PC mit 2 Prozessoren, UNIX-Server-Rechner vieler Hersteller mit
i.d.R. bis zu 32 Prozessoren.
© R. Kröger, FH Wiesbaden Verteilte Systeme 2-8
Beispiel 2 2.1.1

Kreuzschienenverteiler-basiertes Multiprozessor-System:

P1
Schalterelement

P2
...

Pn

M1 M2 ... Mn

• Über den Kreuzschienenverteiler (Crossbar Switch) können mehrere

Prozessoren gleichzeitig auf verschiedene Speichermodule zugreifen.
• UMA-Eigenschaften sind gegeben, wenn Schalter gesetzt sind.
• Kreuzschienenverteiler sind teuer und skalieren nicht (n2 Schalter).
Sie werden daher i.d.R. nur für kleine n eingesetzt.
• Beispiele: C.mmP (16x16, CMU, 1971)
© R. Kröger, FH Wiesbaden Verteilte Systeme 2-9
Beispiel 3 2.1.1

Multiprozessor-System mit hierarchischem Bussystem:

globaler Bus

entfernter
P1 K1 Pn Kn Speicherzugriff

lokaler lokaler
Bus ... Bus

lokaler M1 Mn
Speicherzugriff

• Weiterleitung entfernter Speicherzugriffe durch Kommunikationsprozessoren Ki.

• NUMA-Eigenschaften: entfernte Zugriffe dauern länger als lokale.
• Mehr als 2 Stufen in der Bushierarchie sind möglich.
• Beispiel: Cm* (CMU, 1977): 50 Prozessoren, 3-stufiges Bussystem, relative
Performance ca. 1:3:10.
• Bus-basierte NUMA-Systeme finden heute im Hochleistungsbereich Einsatz,
NUMA-Systeme auf Basis von Verbindungsnetzwerken sind ebenfalls üblich.
© R. Kröger, FH Wiesbaden Verteilte Systeme 2-10
2.1.2 Multicomputer-Systeme

• Einfache Konstruktion:
– Rechner = Prozessor mit privatem lokalen Speicher
(Multiprozessor-Knoten möglich).
– Keine entfernten Speicherzugriffe (NORMA).
– Kommunikation durch lose Nachrichten-Kopplung.
– Prinzipielle Architektur:

M1 M2 Mn
Rechner
P1 P2 ... Pn

Netzwerk

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-11

Multicomputer-Systeme (2) 2.1.2

• Eigenschaften:
– Unterstützung für große Anzahl von Rechnern (> 1024).
– Netzwerk kann Verbindungsnetzwerk, LAN, MAN, WAN sein.
– Architektur der traditionellen massiv-parallelen Systeme
(MPP: Massively Parallel Processing).
– Einführung von Message Passing-Programmiermodellen und
Bibliotheken.
– Vermeidung der Cache-Kohärenz-Problematik durch explizite
nachrichtenorientierte Programmierung.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-12

Beispiel 1 2.1.2

LAN-basiertes Rechner-Netz:

M1 M2 Mn
Rechner
P1 P2 ... Pn

LAN

• Rechner sind übliche kommerzielle Workstations ohne Bildschirm.

• Netzwerk ist ein Local-Area-Netzwerk mit 100-10.000 Mbit/sec
Übertragungsrate.
• Beispiel: Rechner-Farm für 3-D Rendering (vgl. Entstehung "Toy Story").

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-13

Beispiel 2 2.1.2

Netzwerk mit Gitter-Topologie:

R11 R12 R13 ... R1n

R21 R22 R23 ... R2n

R31 R32 R33 ... R3n

...
...

...

...
Rn1 Rn2 Rn3 ... Rnn

• Rechner z.B. für Hochleistungs-Gleitpunktarithmetik.

• Parallele numerische Anwendungen z.B. für Wettervorhersage, usw..
• Beispiel: Suprenum-Projekt.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-14

Beispiel 3 2.1.2

Netzwerk mit Hypercube-Struktur:

011 R R 111

010 R R 110

001 R R 101
x2
x3
R R Adresse: x1x2x3
x1
000 100
n=3
• Hypercube = n-dimensionaler Würfel mit 2n Knotenrechnern.
• Einfaches Routing (Adressen von Nachbarn unterscheiden sich an einer Stelle).
• Längster Weg einer Nachricht wächst nur logarithmisch mit Anzahl Knoten.
• Beispiele: Intel Hypercube, NCube: 512/1024 Prozessoren.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-15

2.2 Grundbegriffe verteilter Betriebssysteme

• Das Konzept der engen/losen Kopplung auf Hardware-Ebene

lässt sich auf die Software-Ebene (sowohl Betriebssystemebene
als auch Anwendungsebene) übertragen:
• Enge Kopplung: Zwei Software-Komponenten sollen eng
gekoppelt heißen, wenn sie durch gemeinsame Nutzung von
Betriebsmitteln (Sharing) kommunizieren. Diese können z.B. sein:
– gemeinsam genutzte Speichersegmente
– gemeinsam genutzte typisierte Objekte

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-16

Lose Kopplung 2.2

• Zwei Software-Komponenten sollen lose gekoppelt heißen, wenn

sie durch Nachrichtenaustausch (Message Passing)
kommunizieren (höhere Autonomie der Komponenten).
• Analog existieren auf der Ebene der
Anwendungsprogrammierung entsprechende Paradigmen, die
auf Sharing oder auf Message Passing angelegt sind.
• Prinzipiell können Betriebssysteme so entwickelt werden, dass
sie Unterstützung für diese beiden Programmier-Paradigmen
bieten unabhängig davon, ob die unterlagerte Hardware eng oder
lose gekoppelt ist (Orthogonalität) (vgl. 2.3).

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-17

Verteiltes Programm / Verteiltes System 2.2

• Ein verteiltes Programm besteht aus einer Menge von lose

gekoppelten Software-Komponenten, die (durch
Nachrichtenaustausch) bzgl. einer gemeinsamen Problemlösung
kooperieren.
• Ein verteiltes Programm beinhaltet
– einen verteilten Zustand (in den jeweiligen Software-
Komponenten.
– verteilte Kontrolle/Koordination, um die gemeinsame
Problemlösung zu bewerkstelligen.
• Ein verteiltes Betriebssystem ist ein verteiltes Programm, das
seinen Nutzern eine abstrakte Maschine offeriert, die die
Gesamtheit aller Betriebsmittel eines (lose gekoppelten)
Multicomputer-Systems verwaltet und eine einheitliche Systemsicht
bietet (Single System Image, Virtuelles Einprozessor-System).
• Ein verteiltes System ist ein Rechensystem, das ein verteiltes
Programm ausführt.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-18

Transparenz 2.2

• Transparenz bedeutet, anders als im üblichen Sprachgebrauch,

die Unsichtbarkeit einer Eigenschaft eines Mehrrechner-Systems.
• Übliche Transparenzarten:
– Ortstransparenz: keine Kenntnis des Ortes einer Komponente
notwendig, insbesondere ist der Ort nicht Teil des Namens.
– Zugriffstransparenz: Form des Zugriffs ist unabhängig, ob
Komponente lokal oder entfernt ist.
– Migrationstransparenz: Komponente kann verlagert werden, ohne
dass sich die Schnittstelle zu den Nutzern ändert.
– Replikationstransparenz: Benutzungsschnittstelle ist unabhängig von
der Anzahl der Kopien einer Komponente, Verfügbarkeit als
qualitative Eigenschaft kann verbessert werden.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-19

Transparenz (2) 2.2

• Weitere Transparenzarten:
– Nebenläufigkeitstransparenz: Nebenl. Nutzung von Komponenten so,
als ob diese privat wären, z.B. durch autom. Sperren, vgl.
Datenbanken.
– Parallelitätstransparenz: Automatische Parallelausführung ohne
Hilfestellung des Benutzers (derzeit nicht realistisch).
– Fehlertransparenz: Ein eingetretener Fehlzustand wird an der
Benutzungsstelle nicht sichtbar, sondern durch Redundanz im
unterlagerten System maskiert.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-20

Transparenz (3) 2.2

• Transparenz trägt zur Vereinfachung des Umgangs / der

Programmierung des Systems bei, da der betreffende Aspekt vom
Nutzer des Systems nicht beachtet werden muss.
• Ein verteiltes Betriebssystem sollte möglichst alle angegebenen
Transparenzarten verwirklichen, um eine möglichst einheitliche
Systemsicht zu erreichen.
• Vollkommene verteilte Betriebssysteme, die von allen Aspekten
abstrahieren, existieren derzeit nicht.
• Die Unterstützung einzelner Transparenzarten (z.B. Ortstransparenz)
ist fortgeschritten.

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-21

LOS - NOS - DOS 2.2

• Stufen der Entwicklung können an folgenden BS-

Architekturklassen festgemacht werden:

• LOS (Local Operating System):

übliches Knoten-Betriebssystem ohne Unterstützung für Verteiltheit.
Beispiele:
– IBM MVS,
– UNIX System III,
– DOS, Windows 3.1,
– ...

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-22

LOS - NOS - DOS (2) 2.2

• NOS (Network Operating System):

Betriebssystemerweiterung von ev. verschiedenen LOS' für ein
Multicomputer-System, um gewisse Funktionen bzgl.
– Dateisystem,
– Schutz (Benutzerverwaltung),
– entfernter Programmausführung
systemweit, mehr oder weniger transparent, bereitzustellen.
Beispiele:
– Novell NetWare,
– Windows for Workgroups,
– UNIX Yellow Pages (NIS) und Network File System (NFS)

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-23

LOS - NOS - DOS (3) 2.2

• Prinzipielle Struktur eines Netzwerkbetriebssystems (NOS):

verteilte Anwendung

Anwendungs- Anwendungs-
Komponente Komponente
Nutzer-
Schnittstelle

NOS NOS

LOS LOS

Hardware Hardware

Netzwerk

• Die unterlagerten lokalen Knoten-Betriebssysteme (LOS) können gleich

oder verschieden sein.
• Beispiele:
– Netware Client für DOS, NT, ... ; Netware Server ist spezielles BS.
– NFS Client für UNIX, NT, ...
© R. Kröger, FH Wiesbaden Verteilte Systeme 2-24
LOS - NOS - DOS (4) 2.2

• DOS (Distributed Operating System):

Ein verteiltes Betriebssystem ist ein grundständiges BS, das
– seinen Nutzern eine einheitliche Systemsicht auf ein
Multicomputer-System bietet (s.o.),
– zur Realisierung der Transparenzeigenschaften auf Algorithmen
basiert, die unter verteilter Kontrolle unter Austausch von
Nachrichten ablaufen.
verteilte Anwendung

Anwendungs- Anwendungs-
Komponente Komponente
Single System
Image
Verteiltes Betriebssystem (DOS)

Hardware Hardware

Netzwerk

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-25

2.3 Verteilte Betriebssystemkerne

Überblick:
1. Einleitung
2. Der Mikrokern-Ansatz
3. Abstraktionen eines Mikrokerns
4. Modernes Virtual Memory Management
5. Distributed Shared Memory

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-26

2.3.1 Einleitung

• Monolithische Betriebssystemstruktur

Applikationen
Utilities
system call
interface
Mengen von Moduln für

- Prozeßverwaltung
- Speicherverwaltung
Betriebs- - Prozeßkommunikation
system - Dateisystem
- Pufferverwaltung
- Geräteverwaltung
- Interrupt Handling
- Netzwerkzugang

Hardware

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-27

2.3.2. Der Mikrokern-Ansatz

• Architektur
Applikationen
Utilities

z.B UNIX-Schnittstelle

generische Manager
(Servers, Actors)

Socket UNIX Emulator

File Network Authent.
Manager Process einer
Manager Manager Manager
Manager BS-Schnittstelle
user ... ...
mode System-
programmier-
system Schnittstelle
mode
Mikrokern

Betriebssystem

Hardware

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-28

Beispiel-Systeme 2.3.2

Die wichtigsten:
• Mach 3.0 (Rashid et al, CMU, USA)
• Amoeba (Tanenbaum et al, Uni Amsterdam)
• PEACE (Schröder-Preikschat et al, GMD, Berlin)
• L3, L4 (Liedtke, GMD St. Augustin, Uni Karlsruhe)
• P4 (Sysgo, Mainz)

• Chorus (Chorus Systèmes (Ausgründung aus INRIA, Frankreich; jetzt

Sun, Open Source)
• Windows NT (Microsoft)
• QNX (QNX Systems, USA, für Embedded Systems)

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-29

Vorteil: Erweiterbarkeit 2.3.2

erweitertes Application
Programming Interface UNIX

Network Disk Object Transaction BS-

Manager Manager Manager Manager Emulator

Mikrokern

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-30

Vorteil: Spezialisierbarkeit 2.3.2

• File Server

Network File
Manager Manager

Mikrokern

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-31

Vorteil: Netzwerktransparenz 2.3.2

Disk Network Network Object Transaction

Manager Manager Manager Manager Manager

Mikrokern Mikrokern

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-32

Vorteil: Kompatibilität 2.3.2

• mehrere BS-Schnittstellen

UNIX- DOS- MacOS-

Anwendung Anwendung Anwendung

UNIX DOS MacOS

Emulator Emulator Emulator

Mikrokern

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-33

Erreichung der Binärkompatibilität 2.3.2

• Beispiel: Mach 3.0 Applikations-

adreßraum

redirection
IPC IPC Transparent (Umlenkung)
Shared
Library
generische
Server
BS-
Emulator return
z.B.
File
Server Benutzer-
programm
user
mode

system system call

mode

Mikrokern

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-34

Nachteil: Performance 2.3.2

• "system call" verursacht IPC und Prozessumschaltungen

• Ansätze zur Verbesserung:
– Intelligente Transparent Shared Library
(Caching)
– Konfigurieren von Managern in Kernel Space
(z.B. Amoeba, Chorus)
– HW verbessern: Interadressraum-Aufruf in vier Prozessortakten
(Entwurf SUN)

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-35

2.3.3 Abstraktionen eines Mikrokerns

nahezu identisch bei allen Systemen:

• Tasks (Actors)
• Threads
• Ports
• Messages
• Segments (Memory Objects)

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-36

Mikrokern-Abstraktionen im Zusammenhang 2.3.3

Stelle 1 Stelle 2

Task

Ports
Adreßraum

Message

Region

Threads

Segment

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-37

Struktur des Mikrokerns (Chorus) 2.3.3

IPC Manager
portabel

Real Time Virtual

Executive Memory
Manager
portabel
portabel

maschinen-
Supervisor maschinenabhängig abhängig

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-38

2.3.4 Modernes Virtual Memory Management

• Anforderungen
• Funktionen:
– Bereitstellung von Adressräumen
– Effiziente Mechanismen für Datentransfer zwischen
» Adressraum - Adressraum
» Adressraum - Hintergrundspeicher
– Effizient: Kopieren vermeiden solange möglich
(lazy copying, z.B. copy-on-write)
• Randbedingungen:
– generisches Interface (untersützt Paging und Segmentierung)
– Portable Implementierung

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-39

Modernes Virtual Memory Management (2) 2.3.4

Anwendungen im Betriebssystem:
• Interprozesskommunikation (IPC)
• Shared Memory zwischen Adressräumen
• Adressraumduplikation (z.B. für UNIX fork)
• Unterstützung von File I/O und File Mapping
• "Distributed Shared Memory"

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-40

Beziehung Region - Segment 2.3.4

Mapping
Adreßraum Segment

Region "Fenster"

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-41

Mehrfach-Mapping eines Segments 2.3.4

Adreßraum 1

Segment
Region 1

Fenster 1

Adreßraum 2
Fenster 2

Region 2

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-42

Segment Cache, External Pager 2.3.4

Adreßraum

0
1 v Segment
Region 2
3 v Pager 0
4 v Port 1
Segment
2
Cache
3
IPC 4
5
5
Adreßraum 6
4
3 7
1
2
3 v
Region 4 Reale
5 v Seiten
External
Pager
v Seite Task
present Mikrokern

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-43

Datenstrukturen (Chorus) 2.3.4

(sorted
list dll)
global map
context hashed by:
start address
region cache id
size
offset in segmt
offset in segmt
rights

local cache
region segment id

history
(dll)
back
parent pointer real page or stub
page offset in segmt
local cache (if copy-on-write stub):
real page

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-44

Beispiel: Mach VM 2.3.4

• Unterstützung dünn besetzter Adressräume

• Tasks können Speichersegmente in beliebige Regionen des
virtuellen Speichers einblenden ("mappen") (allocate,
deallocate, protect)
• read/write- und copy-on-write-Sharing von Speichersegmenten
zwischen Tasks
• copy-on-write-basierte Kopieroperationen,
benutzt für IPC, fork, exec, ...
• Benutzer können Hintergrundspeicherobjekte und zugehörige
Manager/Pager definieren
• Strikte Trennung zwischen Maschinen-abhängigem und
-unabhängigem Teil

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-45

2.3.5 Distributed Shared Memory

• Aufhebung der Verteiltheit eines Systems auf der Ebene von

Speicherzugriffen
• Logisches Shared Memory auf einer Multicomputerarchitektur
• Verwendung in vielen neuen Parallelrechnern mit NUMA und
NORMA-Architektur

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-46

Distributed Shared Memory: Funktionsweise 2.3.5

Segment Stelle 0

0
netzweites 1
Shared 2
3 owner
Segment
4
5
pager
0
Region Region

Stelle 1 Stelle 2
0 Pager 0 v
1 v Protokoll 1
2 Local pager pager Local 2
3 v Cache 1 2 Cache 3
4 v 4
5 5 v
4 5
3 0
1
Reale
Reale Seiten
Seiten

© R. Kröger, FH Wiesbaden Verteilte Systeme 2-47