Kapitel 4 Prozessinteraktion

Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Kapitel 4 Prozessinteraktion
4-1
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.1 Einleitung
Arten der Interaktion
Prozesse als Teile komplexer Programmsysteme mŸssen
Daten austauschen
sich aufrufen (bzw. beauftragen)
aufeinander warten
sich auslšsen
sich abstimmen
.... sie mŸssen interagieren.
Prozesse
Kernschnittstelle
Proze§verwaltung
Interaktion
BS-Kern
Operationen zur Prozessinteraktion bilden (neben der Prozessverwaltung) den
zweiten wesentlichen Aufgabenbereich eines Betriebssystemkerns.
4-2
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Begriffsabgrenzung
Prozessinteraktion besitzt einen funktionalen und einen zeitlichen Aspekt:
Wir unterscheiden:
Zeitlicher Aspekt:
Ablaufabstimmung (Koordination, Synchronisation)
Funktionaler Aspekt:
Informationsaustausch
Zwei Formen des Informationsaustauschs:
Kommunikation
Kooperation
(expliziter Datentransport)
(Zugriff auf gem. Daten)
P1
P1
P2
P2
gemeinsamer Teil
D1
Kopieren
D2
D1
(gerichtete Beziehung)
D2
(symmetrische Beziehung)
4-3
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Abbildbarkeit
Die beiden Formen des Informationsaustauschs sind als Konzepte zu
verstehen und sagen noch nichts Ÿber die Implementierung aus.
Insbesondere kann Kommunikation auf Kooperation abgebildet werden und
umgekehrt.
Prozess 2
Prozess 1
Prozess 2
Prozess 1
Kooperation
Kommunikation
Modellebene
Kommunikation
Modellebene
Realisierungsebene
Kooperation
realisiert durch Kommunikation
Kooperation
Realisierungsebene
Kommunikation
realisiert durch Kooperation
4-4
Koordination (zeitliche Abstimmung)
Prozeß P1
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Prozeß P2
Warten (wait)
A
P2 wartet auf Signal von P1
Signalisieren (signal)
B
Programmabschnitt A in Prozess P1 soll vor Programmabschnitt B in
Prozess P2 ausgefŸhrt werden.
In der Operationen Warten wird P2 ggf. solange aufgehalten,
bis P1 die Operationen Signalisieren aufgerufen hat.
4-5
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Interaktionsobjekte
Interaktionen (Koordination, Kooperation, Kommunikation)
manifestieren sich in eigenstŠndigen Objekten
Prozeß
Prozeß
Interaktionsobjekt
Diese Interaktionsobjekte
tragen einen Namen
bestehen aus
- Interaktionsoperationen
- Interaktionsdaten
Operationen
Daten
4-6
Interaktion im tŠglichen Leben
-
Brief
Telegramm
Fax
Paket
Container
Telefon
E-mail
Radio
Schwarzes Brett
Rauchzeichen
Flaggenzeichen
Morsezeichen
Ampelsignale
Kurier
Gestik
Mimik
.... und vieles mehr
4-7
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Beziehungen
An einer Interaktion kšnnen mehr als zwei Prozesse beteiligt sein
1:1- Interaktion
m:n - Interaktion
Ein Prozess kann an mehreren Interaktionen beteiligt sein
1 Interaktionsobjekt
mehrere Interaktionsobjekte
4-8
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Zuordnung
Das Interaktionsobjekt kann
z beim Quellprozess
(Sender)
z beim Zielprozess
(EmpfŠnger)
z zwischen den Prozessen
realisiert sein
4-9
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Zusammenhang
Von den drei Grundformen der Interaktion ist die Koordination die elementarste,
denn sowohl Kommunikation als auch Kooperation benštigen eine zeitliche
Abstimmung zwischen den Interaktionspartnern
Kommunikation
Kommunikation
Kooperation
Kooperation
Koordination
Koordination
Wir werden daher zunŠchst die Koordination behandeln
4-10
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.2 Koordination
Vorbemerkung:
z KoordinationsvorgŠnge kennen wir bereits aus der Diskussion des
Kernausschlusses.
z Wir mŸssen uns also nicht mehr darum kŸmmern, wie
Interaktionsoperationen auf gemeinsame Daten zugreifen, da sie
als Kernoperationen unter gegenseitigem Ausschluss stehen.
z Im folgenden geht es um KoordinationsvorgŠnge au§erhalb des
Kerns, fŸr die wir auf unteilbare Kernoperationen zurŸckgreifen
kšnnen.
4-11
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.2.1 Signalisierung
Bei der Signalisierung soll eine Reihenfolgebeziehung hergestellt werden.
Ein Abschnitt A in einem Prozess P1 soll vor einem Abschnitt B einem Prozess
P2 ausgefŸhrt werden.
Dazu bietet der Kern die Operationen signal und wait an, die eine gemeinsame
binŠre Variable s benutzen
P1
P2
A
signal(s)
wait(s)
B
4-12
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Signalisierung: Beispiel
Aktivität 1
Aktivität 2
Voraussetzung erfüllt?
A
Evtl. verzögern
Erfüllt !
B
Beispiel: Steuerung eines technischen Prozesses:
A:
EinfŸllen von FlŸssigkeit in einen BehŠlter (Ventil offen)
B:
Heizen (Spannung an Heizspirale)
4-13
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Grundform der Signalisierung
In ihrer einfachsten Form kšnnen die Operationen folgenderma§en realisiert werden
signal(s)
wait(s)
set s
no
s set ?
reset s
Dies bedeutet ein aktives Warten an der Signalisierungsvariablen s.
Ist die Wartezeit zu lange, so sollte der Prozessor freigegeben werden:
(Signalisieren mit Wartezustand)
signal(s)
wait(s)
s set ? yes
set s
process waiting ? no
block
deblock process
reset(s)
4-14
Beipiel fŸr Signalisierungsobjekt
kernel module signalization;
export SIGNAL, WAIT;
import DEBLOCK, BLOCK;
var signal_object =
record
S: signal = reset;
//
WP: process = empty
end;
procedure SIGNAL(SO: signal_object);
begin
SO.S := set;
if SO.WP /= empty then
//
DEBLOCK(SO.WP)
//
end;
procedure WAIT(SO: signal_object);
begin
if SO.S = reset then
BLOCK(SO.WP);
//
SO.S := reset
end;
end signalization.
4-15
initialization
a process is waiting
deblock it
wait for signal
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Beipielimplementierung
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module synchronization;
export SYNC;
import DEBLOCK, BLOCK;
var signal_object =
record
S: signal = reset;
// initialization
WP: process = empty
end;
procedure SYNC(SO: signal_object);
begin
if SO.S = reset
// I am first and
then begin
SO.S := set;
// indicate my arrival and
BLOCK(SO.WP); // wait for my partner
end;
else begin
// I am second and
DEBLOCK(SO.WP);// deblock my waiting partner
SO.S:= reset
// and reset the signal for reuse
end
end;
end synchronization.
4-16
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Wechselseitige Synchronisierung
Ein symmetrischer Einsatz der Operationen bewirkt, dass sowohl A1 als
auch A2 ausgefŸhrt sind, bevor B1 oder B2 ausgefŸhrt werden.
P1
P2
A1
signal(s1)
wait(s2)
A2
signal(s2)
wait(s1)
B1
B2
Die Prozesse P1 und P2 synchronisieren sich an dieser Stelle.
Wir kšnnen das Operationspaar als eine Operation sync zusammenfassen:
P1
P2
A1
A2
sync(s)
sync(s)
B1
B2
Da P1 und P2 an dieser Stelle aufeinander warten, spricht man auch von
einem Rendezvous
4-17
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Gruppensignalisierung
An einer Signalisierung kšnnen mehr als zwei Prozesse beteiligt sein:
UND-Signalisieren:
Ein Prozess soll erst weiterlaufen, wenn mehrere
Prozesse ein Signal gesetzt haben
(UND-VerknŸpfung auf Signalisierungsseite)
s
w
s
s
UND-Warten:
Mehrere Prozesse warten auf ein Signal von einem
Prozesse
(UND-VerknŸpfung auf Warteseite)
w
w
s
w
4-18
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
UND-Signalisierung
Die UND-VerknŸpfung kann auch auf beiden Seiten erfolgen:
Alle Prozesse auf der rechten Seite kšnnen erst weiterlaufen,
wenn alle Prozesse auf der linken Seite ihr Signal abgelegt haben
s
w
w
s
s
w
Es gibt also insgesamt die folgenden vier Varianten
¥
Einzel-Einzel-Signalisierung
¥
UND-Einzel-Signalisierung
¥
Einzel-UND-Signalisierung
¥
UND-UND-Signalisierung
4-19
Beispielimplementierung
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module AND:AND-signalization;
export SIGNAL, WAIT;
import DEBLOCK, BLOCK;
var signal_object = record S: array [1..ks] of signal = all reset;
WP: array [1..kw] of process = all empty
end;
procedure AND_SIGNAL(SO: signal_object, q index);
begin
SO.S[q] := set;
if ∀i: SO.S[i]=set & ∀j: SO.WP[j] /= empty then
begin ∀i: SO.S[i]= reset;
∀j: DEBLOCK(SO.WP[j])
end
end;
procedure AND_WAIT(SO: signal_object; p index);
begin
if ∃i SO.S[i] = reset ∨ ∃j/=p: SO.WP[j] = empty
then BLOCK(SO.WP[p]);
else begin ∀i: SO.S[i]= reset;
∀j/=p: DEBLOCK(SO.WP[j])
end;
end;
end signalization.
4-20
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Signalisierung mit StaurŠumen
Die Beziehungen zwischen den Prozessen kšnnen noch vielfŠltiger sein:
n:1
Mehrere Prozesse kšnnen Signale an einem Signalobjekt ablegen.
Ein wartender Prozess kann deblockiert werden,wenn wenigstens ein
Signal vorliegt.
s
w
s
s
1:m
von irgendeinem
Mehrere Prozesse kšnnen an einem Signalobjekt warten.
Wenn ein Signal eintrifft, wird einer (z.B. der erste) deblockiert.
w
s
w
an irgendeinen
w
Beide FŠlle kombiniert ergeben beliebige n:m-Beziehungen
4-21
Signalisierung mit StaurŠumen (2)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Da jetzt hintereinander
z mehrere Signale bzw.
z mehrere wartende Prozesse
anstehen kšnnen, mŸssen wir dafŸr in der Datenstruktur fŸr das Signalobjekt
entsprechende KapazitŠt vorsehen:
KapazitŠt
z genau 1 (wie bisher)
z eine Konstante c (KapazitŠt kann bei Objekterzeugung fest vorgesehen
werden)
z unbegrenzt (KapazitŠt muss u.U. zur Laufzeit beschafft werden)
4-22
Beispielimplementierung
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module m:n-signalization;
export SIGNAL, WAIT;
import DEBLOCK, BLOCK;
var signal_object =
record
S: integer = 0;
// initialization
WP: queue of process = empty
end;
procedure SIGNAL(SO: signal_object);
begin
SO.S := SO.S+1;
if SO.WP /= empty then // a process is waiting
DEBLOCK(SO.WP)
// deblock first of queue
end;
procedure WAIT(SO: signal_object);
begin
if SO.S <= 0 then BLOCK(SO.WP);
// enqueue process
SO.S := SO.S-1;
end;
end m:n-signalization.
4-23
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Achtung: Auseinanderhalten:
Nicht verwechseln !
2:3-Einzel:Einzel-Signalisierung
s
w
w
s
w
1:1-UND2:UND3-Signalisierung
s
w
w
s
w
4-24
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Wechselseitige Synchronisierung fŸr Gruppen
P1
P1
P4
P1
sync(s)
sync(s)
sync(s)
sync(s)
Alle Prozesse synchronisieren sich an einer Stelle
Die Prozesse dŸrfen erst weiterlaufen,
wenn alle anderen Prozesse die Synchronisationsstelle erreicht haben
(Synchronisationsbarriere, Barrierensynchronisation, Gruppenrendezvous)
4-25
Beispielimplementierung
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module barrier-synchronization;
export BARRIER_SYNC;
import DEBLOCK, BLOCK;
var signal_object =
record
NUMBER: integer = m;
// number of processes
COUNT: integer = 0;
WP: queue of process = empty
end;
procedure BARRIER_SYNC(SO: signal_object);
begin
SO.COUNT = SO.COUNT + 1
if SO.COUNT < SO.NUMBER
then BLOCK(SO.WP);
// wait for partner processes
else
begin
while SO.WP /= empty do DEBLOCK(SO.WP);
SO.COUNT = 0
end;
end;
end barrier-synchronization.
4-26
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.2.2 Sperren
Wir betrachten den folgenden Einsatz von Signalisierungsoperationen
P1
P2
s = set
wait(s)
wait(s)
A
B
signal(s)
signal(s)
A und B kšnnen nicht nebenlŠufig ausgefŸhrt werden:
Entweder A vor B oder B vor A, d.h. es findet keine †berlappung in der
AusfŸhrung von A und B statt. Die AusfŸhrungen von A und B schlie§en
sich gegenseitig aus.
Die Signalisierungsoperationen kšnnen also auch dazu verwendet werden,
um kritische Abschnitte (critical section) zu sichern.
4-27
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Sperren
z
ZweckmŠ§igerweise geben wir ihnen dann auch die entsprechenden
Namen: Sperren (lock) und Entsperren (unlock)
Initialisierung: s = reset
lock(s)
unlock(s)
s set ? no
reset s
block
process waiting ? no
set s
deblock process
z Von der Struktur entspricht das lock dem wait und das unlock dem signal.
Anmerkung:
z Im Unterschied zur Formulierung des signal weiter oben wird hier jedoch
die Variable s in einer Schleife abgefragt, um den Fall zu berŸcksichtigen,
dass zwischen dem Deblockieren des auf die Sperre wartenden Prozesses
und dem Setzen der Sperre ein weiterer Prozess die Sperre setzen kšnnte.
4-28
Implementierungsbeispiel Sperre
kernel module locking;
export LOCK, UNLOCK;
import DEBLOCK, BLOCK;
var lock_object =
record
L: lock_variable = reset;
//
WP: queue of process = empty
end;
procedure LOCK(LO: lock_object);
begin
while LO.L = set do
BLOCK(LO.WP);
//
LO.L := set;
end;
procedure UNLOCK(LO: lock_object);
begin
LO.L := reset;
if LO.WP = non_empty then
//
DEBLOCK(LO.WP)
//
end;
end locking.
4-29
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
initialization
enqueue process
a process is waiting
deblock first of queue
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.3 Kanalkonzept
4.3.1 Grundlagen
z
Ein Kanal ist ein Datenobjekt, das die Operationen Senden (send) und
Empfangen (receive) zur VerfŸgung stellt.
Parameter:
z
Name des Kanal(objekt)s (CO)
z
Adresse eines BehŠlters
Sender:
EmpfŠnger:
Adresse der zu verschickenden Nachricht (DatenbehŠlter
sendeseitig, buffer send (Bs). Statt der Adresse kann hier auch
die Nachricht selbst stehen)
Adresse, wohin die empfangene Nachricht geschrieben werden
soll (DatenbehŠlter empfŠngerseitig, buffer receive (Br))
P2
P1
RECEIVE(CO,Dr)
SEND(CO,Ds)
CO
Operationen
Daten
4-30
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
ZeitverhŠltnisse
z
Da Sender und EmpfŠnger ihre Operationen zu beliebigen Zeitpunkten aufrufen
kšnnen, sind zwei FŠlle zu berŸcksichtigen:
1.
Erst Senden, dann Empfangen
2.
Erst Empfangen, dann Senden
z
Wenn die aufrufenden Prozesse in den Operationen nicht aufgehalten (blockiert)
werden sollen, besteht die Notwendigkeit der Zwischenspeicherung im Kanal
z
Sender zuerst:
z
Die Nachricht bzw. ihre Adresse wird im Kanal abgelegt und
kann bei einem nachfolgenden Empfangen abgeholt werden
EmpfŠnger zuerst: Die Adresse des Zielpuffers wird abgelegt, so dass bei einem
nachfolgenden Empfangen die Nachricht dorthin kopiert
werden kann
z
Der Kanal muss entsprechende Variable zur Aufnahme dieser Daten vorsehen
4-31
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
ZeitverhŠltnisse (2)
Sender zuerst:
P1
Erster
P2
RECEIVE(CO,Br)
SEND(CO,Bs)
CO
Bs
Nachricht oder
Adresse Quellbehälter
Ds
Dr
EmpfŠnger zuerst:
P1
P2
SEND(CO,Bs)
RECEIVE(CO,Br)
CO
Br
Ds
4-32
Dr
Adresse Zielbehälter
Erster
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
NachrichtenŸbergabe
WertŸbergabe: Die Nachricht selbst wird im Kanal abgelegt (Zwei KopiervorgŠnge)
Sender
Empfänger
Kanal
ReferenzŸbergabe: Die Adresse der Nachricht wird im Kanal abgelegt (Ein Kopiervorgang)
Sender
Empfänger
Kanal
BehŠlterŸbergabe: Die Teile des Sender-Adressraums, die die Nachricht enthalten, werden
in den Adressraum des EmpfŠngers eingeblendet (Kein Kopieren erforderlich)
Sender
Empfänger
Kanal
4-33
Grundform der Kanalkommunikation
(ReferenzŸbergabe)
SEND(CO,MSG)
RECEIVE(CO,BR)
deposit message MSG at channel
N
address of target
buffer BR available?
copy message to
target buffer
delete message and target
buffer address
deposit address of target
buffer BR at channel
N
message MSG available ?
copy message to
target buffer
delete message and target
buffer address
R
R
4-34
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Beispielimplementierung Kanalgrundform
kernel module Communication; { by reference }
export SEND, RECEIVE;
var channel_object =
record
DS: address = empty;
DR: address = empty
end;
procedure SEND(CO: channel_object; BS: address);
begin
CO.DS := BS;
if CO.DR = nonempty then
begin
CO.DR^ := CO.DS^;
// message transport
CO.DS := empty; CO.DR := empty
end
end;
procedure RECEIVE(CO: channel_object; BR: address);
begin
CO.DR := BR;
if CO.DS = nonempty then
begin
CO.DR^ := CO.DS^;
// message transport }
CO.DS := empty; CO.DR := empty
end
end;
4-35
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.3.2 Koordinierte Kommunikation
z
z
z
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Bisher hatten wir keinerlei zeitliche Abstimmung zwischen Sender und
EmpfŠnger gefordert.
y
Beide rufen ihre jeweilige Operation auf, legen ggf. Daten im Kanal ab,
verlassen die Prozedur und arbeiten weiter, ohne auf den
Kommunikationspartner zu warten.
y
Man nennt dieses Vorgehen asynchron (asynchrones Senden, asynchrones
Empfangen)
HŠufig ist jedoch z.B. der EmpfŠnger dringend auf den Empfang der
Nachricht angewiesen, d.h. er kann erst weiterarbeiten, wenn die Nachricht
eingetroffen ist.
y
Er wird also in der Empfangsoperation so lange aufgehalten (blockiert).
y
Auf diese Weise synchronisiert er sich mit dem Sender (d.h. wartet auf ihn).
y
Man spricht dann von einem synchronen Empfangen.
y
Analog dazu ist auch ein synchrones Senden mšglich, bei dem der Sender
solange blockiert wird, bis die dazugehšrige Empfangsoperation aufgerufen
wird.
Durch Kombination ergeben sich vier Varianten
4-36
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Varianten der Koordination
Ps
Pr
SEND
RECEIVE
Ps
Pr
SEND
RECEIVE
WAIT
SIGNAL
asynchrones
Senden
A:A
asynchrones
Empfangen
asynchrones
Senden
A:S
synchrones
Empfangen
Ps
Pr
Ps
Pr
SEND
RECEIVE
WAIT
SIGNAL
SEND
SIGNAL
WAIT
RECEIVE
SIGNAL
WAIT
synchrones
Senden
S:A
S:S
synchrones
Senden ãRendezvousÒ
asynchrones
Empfangen
4-37
synchrones
Empfangen
Beispielimplementierung A:S-Kanal
kernel module Communication;
export SEND_A, RECEIVE_S;
var channel_object =
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
// A:S-Channel, by value
record
DS: message = empty;
DR: address = empty;
WPR: process = empty
end;
procedure SEND_A(CO: channel_object; BS: message);
begin
CO.DS := BS;
if CO.DR /= empty then begin
CO.DR^ := CO.DS;
// message transport
CO.DS := empty; CO.DR := empty;
DEBLOCK(CO.WPR);
end
end;
procedure RECEIVE_S(CO: channel_object; BR: address);
begin
CO.DR := BR;
if CO.DS = empty then BLOCK(CO.WPR)
else
begin
CO.DR^ := CO.DS; // message transport
CO.DS := empty; CO.DR := empty
end
end;
4-38
Versuchendes Empfangen (Polling, Probing)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Gelegentlich mšchte man nur prŸfen, ob eine Nachricht vorliegt.
Wenn ja, wird sie entgegengenommen (kopiert), wenn nein, geschieht nichts.
kernel module communication; // A:V-channel, trying receive
export SEND_A, RECEIVE_T;
var channel_object =
record
DS: message = empty;
end;
procedure SEND_A(CO: channel_object; BS: message);
begin
CO.DS := BS;
end;
procedure RECEIVE_T(CO: channel_object; BR: address);
begin
if CO.DS /= empty then
begin
BR^ := CO.DS;
// message transport
CO.DS := leer;
end
end;
4-39
Umlenkendes Empfangen
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Idee:
z
Nach erfolgreicher NachrichtenŸbermittlung wird der
Kommunikationspartner unterbrochen und auf ein spezielles
ProgrammstŸck umgelenkt.
DurchfŸhrung:
z
Der zuerst kommende Prozess legt neben der BehŠlteradresse eine
Umlenkadresse ab.
z
Bei Eintreffen des Partners wird die Nachricht kopiert und der Prozess auf
die angegebene Adresse umgelenkt
(€nlich den sogenannten Òactive messagesÓ)
4-40
Beispielimplementierung (Unterbr. Empf.)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module Communication; // A:I-channel, interrupting receive
export SEND_A, RECEIVE_I; import INTERRUPT;
var channelobject =
record
DS: message = empty;
DR: address = empty;
IPR: record P: process = empty; A: address = empty end // target instruction
end;
procedure SEND_A(CO: channel_object; BS: message);
begin
CO.DS := BS;
if CO.DR /= empty then
begin
CO.DR^ := CO.DS;
//message transport
CO.DS := empty; CO.DR := empty;
INTERRUPT(CO.IPR.P, CO.IPR.A) // SW-interrupt causes IPR.P to jump to IPR.A
end
end;
procedure RECEIVE_I(CO:channel_object; BR:address; LI:address);
begin
CO.DR := BR;
CO.IPR.P := my_PID; CO.IPR.A := LI; // deposit target address
if CO.DS /= empty
then begin
CO.DR^ := CO.DS;
//message transport
CO.DS := empty; CO.DR := empty
INTERRUPT(my_PID, LI)
// SW-interrupt causes jump to address CO.IPR.A
end
end;
end Communication.
4-41
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.3.3 KapazitŠt
z
Bisher kann ein Kanal genau eine Nachricht bzw. einen ÒEmpfangswunschÓ
speichern.
z
WŸnschenswert:
Beispiel:
FŠhigkeit, mehrere Nachrichten zu ÒpuffernÓ
Mehrere Prozesse senden an einen zentralen ÒServer-ProzessÓ
P
P
S
n:1-Kanal
P
E
S
S
z.B. zentraler Server
4-42
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Empfangsseitige KapazitŠt
WŸnschenswert: FŠhigkeit, mehrere EmpfangswŸnsche zu ÒpuffernÓ
Beispiel:
Server besteht aus mehreren replizierten Prozessen,
die Ÿber einen gemeinsamen Kanal adressiert werden.
P
1:n-Kanal
E
E
E
S
z.B. replizierter Server
4-43
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Datenstrukturen
z
z
Zu diesem Zweck mŸssen die Datenstrukturen entsprechend erweitert werden.
Im Falle eines n:n/S:S-Kanals (beliebig viele Sender, beliebig viele EmpfŠnger,
synchrones Senden und Empfangen) bedeutet dies beispielsweise
y
y
y
y
z
Warteschlange fŸr wartende Senderprozesse
Warteschlange fŸr gespeicherte Nachrichten
Warteschlange fŸr wartende EmpfŠngerprozesse
Warteschlange fŸr gespeicherte BehŠlteradressen
Die Frage nach der KanalkapazitŠt beeinflusst die Effizienz und Semantik der
Operationen:
y
y
y
unbegrenzt KapazitŠt:
erfordert dynamische Speicherverwaltung innerhalb der Kommunikationsop.:
Speicherplatz muss angefordert und freigegeben werden
y
y
begrenzte KapazitŠt:
erfordert Mechanismen bei Ò†berlaufÓ
y
Mšglichkeiten:
x
†berschreiben
x
Abweisung der Operation
x
Blockierung des Aufrufers, bis KapazitŠt frei wird
4-44
Beispielimplementierung
kernel module communication;
//
n:n/A:S-Channel
export SEND_A, RECEIVE_S;
import ALLOCATE, RELEASE, INSERT, REMOVE, BLOCK, DEBLOCK;
var channelobject =
record
QDS: queue of message = empty;
QPR: queue of process = empty;
QDR: queue of address = empty
end;
var POOL: set of buffer;
procedure SEND_A(CO: channelobject; BS: message);
var N: message;
begin
ALLOCATE(POOL,N);
N := BS;
INSERT(CO.QDS,N);
if CO.QPR /= empty then DEBLOCK(CO.QPR)
end;
procedure RECEIVE_S(CO: channelobject; BR: address);
var N: message; A: address;
begin
INSERT(CO.QDR,BR);
while CO.QDS = empty do BLOCK(CO.QPR);
REMOVE(CO.QDS,N);
REMOVE(CO.QDR,A);
A^ := N;
RELEASE(POOL,N)
end;
end n:n/A:S-Channel.
4-45
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.3.4 Physische Zuordnung
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
z
Ein Kanal ist zunŠchst ein eigenstŠndiges Kommunikationsobjekt, das
unabhŠngig von irgendwelchen Sendern und EmpfŠngern existieren kann.
z
Es ist jedoch gelegentlich sinnvoll, ein Kommunikationsobjekt fest einem
Prozess zuzuordnen.
z
Dies kann sendeseitig oder empfangsseitig erfolgen:
y
Besitzt ein Prozess einen Kanal, in dem er alle seine ausgehenden Nachrichten
ablegt, so spricht man von einem Ausgangstor.
y
Besitzt ein Prozess einen Kanal, in dem alle seine eingehenden Nachrichten
ablegt werden, so spricht man von einem Eingangstor (port).
z
Ports sind die in modernen Betriebssystemen am meisten verbreiteten
Kommunikationsobjekte.
z
Eingangstore sind n:1-KanŠle, Ausgangstore 1:n-KanŠle.
4-46
Bindung von Kommunikationsobjekten an Prozesse
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Keine Bindung
„Kanal“
Prozeß
Bindung an Sender
n:n
Prozeß
„Ausgangstor“
Prozeß
Prozeß 1:n
Bindung an EmpfŠnger
„Eingangstor“, port
Prozeß
n:1 Prozeß
4-47
4.3.5 Gruppenkommunikation
z
z
z
z
z
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Obwohl sendeseitig und empfangsseitig mehrere Prozesse beteiligt sein
konnten, handelte es sich um Einzelkommunikationen in dem Sinn, dass
jeweils ein Sender eine Nachricht an einen EmpfŠnger schickte.
Es gibt jedoch hŠufig Situationen, in denen ein Prozess identische
Nachrichten an viele (multicast) oder alle Prozesse (broadcast) schicken
mšchte.
Symmetrisch dazu gibt es FŠlle, in denen viele Prozesse an einen
EmpfŠnger (Teil)nachrichten senden, die als Zusammenfassung die
eigentliche Nachricht bilden (combine).
Man spricht dann von Gruppenkommunikation (im Gegensatz zur
Einzelkommunikation)
Dadaurch ergeben sich folgende Varianten
y
Einzel-Einzel-Kanal
y
Einzel-Gruppen-Kanal (broadcast, multicast, Òone-to-many-communicationÓ)
y
Gruppen-Einzel-Kanal (combine, Òmany-to-one-communicationÓ)
y
Gruppen-Gruppen-Kanal (all-to-all-broadcast, Òmany-to-many-communicationÓ
(wie bisher, Òone-to-one-communicationÓ)
4-48
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Gruppenkommunikation (schematisch)
z
Empfangsseitige Gruppe: Nachricht geht an mehrere
E
S
Vervielfältigung
E
:
E
z
Sendeseitige Gruppe: Mehrere Nachrichten werden kombiniert
S
Zusammenfassung
S
E
:
S
4-49
Gruppenkommunikation (schematisch)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
WŠhrend die VervielfŠltigung semantisch eindeutig ist (es werden Kopien der
Nachricht versendet), muss die Art der Kombination festgelegt werden
(Operationsparameter).
TatsŠchlich gibt es die verschiedensten Variationen (Beispiele):
z Konkatenation:
„a“
„a5k“
„5“
concat
„k“
z
z
Logische VerknŸpfung:
Arithmetische VerknŸpfung:
„true
“
„true“
e“
„fals
&
„false“
Σ
„12“
„5“
„3“
„4“
4-50
Beispielimplementierung (mit EmpfŠnger-Rendezvous)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module group_communication
// 1:1/G:G/A:S-channel;
export G_SEND_A, G_RECEIVE_S; import BLOCK, DEBLOCK;
var channel_object = record
QDS: array[1..ks] of message = all empty;
QDR: array[1..kr] of address = all empty;
QPR: array[1..kr] of process = all empty
end;
procedure G_SEND_A(CO: channel_object; ps: index; BS: message);
begin CO.QDS[ps] := BS;
if ∀i: CO.QDS[i] /= empty ∧ ∀j: CO.QPR[j] /= empty then
begin
∀j: CO.QDR[j] := CO.QDS[];
∀j: CO.QDR[j] := empty;
∀i: CO.QDS[i] := empty;
∀j: DEBLOCK(CO.QPR[j])
end
end;
procedure G_RECEIVE_S(CO: channel_object; pr: index; BR: address);
begin
CO.QDR[pr] := BR;
if ∃i:CO.QDS[i]=empty v ∃j/=pr:CO.QPR[j]=empty then BLOCK(CO.QPR[pr])
else begin
∀j: CO.QDR[j] := CO.QDS[];
∀j: CO.QDR[j] := empty;
∀i: CO.QDS[i] := empty;
∀j/=pr: DEBLOCK(CO.QPR[j])
end
end;
end 1:1/G:G/A:S-channel
4-51
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.4 Kooperation
Kooperation tritt auf, wenn mehrere Prozesse auf dieselben Daten zugreifen.
Um Fehler und Inkonsistenzen zu vermeiden, mŸssen die Zugriffe koordiniert sein.
Beispiel:
Listenoperation ÒEinfŸgenÓ, aufgelšst in Einzelschritte
(a)
(b)
(c)
(d)
(e)
In den Situationen c) und d) ist die Listenstruktur inkonsistent.
Ein parallel zugreifender Prozess sŠhe eine fehlerhafte Datenstruktur.
4-52
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Sperren
z
z
z
Kooperation von Prozessen auf gemeinsamen Daten fŠllt offensichtlich mit
dem Problem des kritischen Abschnitts bzw. des gegenseitigen
Ausschlusses zusammen, das uns ja schon bei der Kernsperre begegnet
ist.
Dabei ist ein kritischer Abschnitt eine Operationsfolge, bei der ein
nebenlŠufiger Zugriff oder eine verzahnte AusfŸhrung zu Fehlern fŸhren
kann.
Zur Sicherung kritischer Abschnitte kšnnen wir die weiter oben
eingefŸhrten Sperroperationen einsetzen:
P2
P1
LOCK(S)
LOCK(S)
Krit. Abschnitt
UNLOCK(S)
UNLOCK(S)
4-53
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Beispiel
z
z
z
Man stelle sich zwei Prozesse vor, die eine ZŠhlervariable inkrementieren
bzw. dekrementieren.
Man kšnnte daraus ein Kooperationsobjekt machen.
Ist das Objekt im Kern realisiert, so wird die Sicherung des kritischen
Abschnitts durch die Kernsperre implizit vorgenommen:
kernel module shared_counter;
export increment, decrement;
var counter_object =
record
C: integer = 0
end;
procedure increment(CO: counter_object);
CO.C := CO.C +1;
procedure decrement(CO: counter_object);
CO.C := CO.C -1;
end shared_counter;
4-54
Implementierung au§erhalb des Kerns
module shared_counter; // outside kernel
export increment, decrement;
var counter_object =
record
C: integer = 0
end;
var LO: lock_object;
procedure increment(CO: counter_object);
begin
LOCK(LO);
CO.C := CO.C +1;
UNLOCK(LO);
end;
procedure decrement(CO: counter_object);
begin
LOCK(LO);
CO.C := CO.C -1;
UNLOCK(LO);
end;
end shared_counter;
4-55
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Monitor
z
Ein solches Objekt, das den gegenseitigen Ausschluss sicherstellt, ohne
dass der Programmierer explizit Sperroperationen einfŸgt, hei§t Monitor.
z
Ein Monitor ist ein Objekt, bestehend aus Prozeduren und Datenstrukturen,
das zu jedem Zeitpunkt nur von einem Prozess benutzt werden darf.
LOCK(S)
LOCK(S)
LOCK(S)
Prozeduren
UNLOCK(S)
UNLOCK(S)
UNLOCK(S)
Sperrvariable
Kooperationsdaten
4-56
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Beispiel Monitor
z
z
Das obige Beispiel einer Kooperation auf einer ZŠhlervariable wŸrde als
Monitor folgenderma§en zu formulieren sein.
Das Monitorkonzept wŸrde vom Kern bereitgestellt und wŸrde automatisch
das Setzen von Sperren durchfŸhren
monitor module shared_counter; // outside kernel
export increment, decrement;
var counter_object =
record
C: integer = 0
end;
procedure increment(CO: counter_object);
begin
CO.C := CO.C +1;
end;
procedure decrement(CO: counter_object);
begin
CO.C := CO.C -1;
end;
end shared_counter;
4-57
Anzahlbegrenzte Kooperation
z
z
z
z
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Ein Kooperationsabschnitt ist also dadurch gekennzeichnet, dass sich zu
einem Zeitpunkt genau ein Prozess Òdarin aufhŠltÓ.
Dieses Prinzip kann man erweitern, indem man andere KapazitŠten als Ò1Ó
festsetzt.
Man kann sowohl fŸr die Zahl der ÒdurchgelassenenÓ als auch fŸr die Zahl
der wartenden Prozesse Obergrenzen vorsehen:
y
1
y
c>1
konstant
y
n
beliebig
GrŸnde, die Anzahl der Prozesse in einem bestimmten Bereich zu
begrenzen:
y
Platzmangel
y
Leistungsabfall
4-58
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Anzahlbegrenzte Kooperation (2)
FŸr diesen Zweck mŸssen die Sperroperationen etwas modifiziert
werden:
capacity_lock
count < upper_bound ?
capacity_unlock
yes
count = count - 1
process waiting ? no
block
deblock
count = count + 1
4-59
Beispiel Anzahlbegrenzte Kooperation
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module capacity_locking;
export C_LOCK, C_UNLOCK;
import DEBLOCK, BLOCK;
var c_lock_object =
record
UB: integer = c;
// upper bound
COUNT: integer = 0;
// process counter
WP: queue of process = empty
end;
procedure C_LOCK(LO: lock_object);
begin
while LO.COUNT = UB do
BLOCK(LO.WP);
// enqueue process
LO.COUNT := LO.COUNT+1;
end;
procedure C_UNLOCK(LO: lock_object);
begin
LO.COUNT := LO.COUNT-1;
if LO.WP /= empty then
// a process is waiting
DEBLOCK(LO.WP)
// deblock first of queue
end;
end capacity_locking.
4-60
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Mehrsortenkooperation
Beispiel: Leser-Schreiber-Kooperation (Reader-Writer-Problem)
z Nicht alle Prozesse greifen schreibend auf die gemeinsamen Daten zu.
Einige lesen nur.
z Lesezugriffe sind unkritisch
z In dem Kooperationsabschnitt dŸrfen sich daher
y
entweder 1 Schreiber
y
oder beliebig viele Leser aufhalten
Verallgemeinerung:
z Es gebe k Sorten von Prozessen. Im Kooperationsabschnitt dŸrfen sich
y
c1
Prozesse der Sorte 1
und/oder
y
c2
Prozesse der Sorte 2
und/oder
y
y
z
É
ck
Prozesse der Sorte k
aufhalten
Das Leser-Schreiber-Problem ist dann ein Spezialfall mit k=2, c1=1 und
c2 = ∞
4-61
Leser-Schreiber-Kooperation (Schreibervorrang)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module reader/writer-cooperation
exort LOCK, UNLOCK; import DEBLOCK, BLOCK;
var lock_object record
R_COUNT: integer = 0;
// counts readers
WRP: queue of process = empty;
// waiting reader processes
W_COUNT: integer = 0;
// counts writers
WWP: queue of process = empty;
// waiting writer processes
end;
procedure LOCK(LO:lock_object; type:{R,W})
begin
if type = R
then
begin
while
LO.W_COUNT>0 or LO.WWP /= empty do BLOCK(LO.WRP)
LO.R_COUNT:=LO.R_COUNT+1;
end;
else
begin
while LO.W_COUNT>0 or LO.R_COUNT>0 do BLOCK(LO.WWP)
LO.W_COUNT:=LO.W_COUNT+1;
end;
end;
procedure UNLOCK(LO:lock_object; type:{R,W})
begin
if type = R then
begin
LO.R_COUNT:=LO.R_COUNT-1;
if LO.R_COUNT=0 and LO.WWP /= empty then DEBLOCK(LO.WWP)
end;
else
begin
LO.W_COUNT:=LO.W_COUNT-1;
if LO.W_COUNT=0 and LO.WWP /= empty then DEBLOCK(LO.WWP)
else while LO.WRP /= empty do DEBLOCK(LO.WRP)
end;
end; end reader/writer-cooperation.
4-62
Leser-Schreiber-Kooperation (Leservorrang)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
kernel module reader/writer-cooperation
exort LOCK, UNLOCK; import DEBLOCK, BLOCK;
var lock_object record
R_COUNT: integer = 0;
// counts readers
WRP: queue of process = empty; // waiting reader processes
W_COUNT: integer = 0;
// counts writers
WWP: queue of process = empty; // waiting writer processes
end;
procedure LOCK(LO:lock_object; type:{R,W})
begin
if type = R then begin
while LO.W_COUNT>0 do BLOCK(LO.WRP)
LO.R_COUNT:=LO.R_COUNT+1;
end;
else begin
while LO.W_COUNT>0 or LO.R_COUNT>0 do BLOCK(LO.WWP)
LO.W_COUNT:=LO.W_COUNT+1;
end;
end;
procedure UNLOCK(LO:lock_object; type:{R,W})
begin
if type = R then begin LO.R_COUNT:=LO.R_COUNT-1;
if LO.R_COUNT=0 and LO.WWP /= empty then DEBLOCK(LO.WWP)
end;
else begin LO.W_COUNT:=LO.W_COUNT-1;
if LO.W_COUNT=0 and LO.WRP /= empty
then while LO.WRP /= empty do DEBLOCK(LO.WRP)
else if LO.WWP /= 0 then DEBLOCK(LO.WRP)
end;
end; end reader/writer-cooperation.
4-63
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Semaphore
z
z
z
z
Sperrobjekte zur Sicherung kritischer Abschnitte sind in der
Betriebssystemliteratur auch unter dem Begriff Semaphor bekannt.
EingefŸhrt ca 1965 von E.W. Dijkstra ist ein Semaphor ursprŸnglich eine
ZŠhlsperre S, deren Operationen P(S) und V(S) statt LOCK(S) und
UNLOCK(S) genannt wurden.
y
P und V sind Operationen, deren Unteilbarkeit sichergestellt ist.
y
P (entspr. lock) dekrementiert einen ZŠhler, V (entspr. unlock) inkrementiert
diesen ZŠhler. (Daher verwendet man manchmal auch die Bezeichner UP(S)
und DOWN(S))
Semaphore gibt es in verschiedenen Varianten
y
aktives Warten / Blockieren
y
ZŠhler / binŠre Variable
y
Initialisierung mit 0 / mit einem Wert k > 0
Sie kšnnen auch fŸr einfache Varianten der Betriebsmittelverwaltung
eingesetzt werden
4-64
Beispielimplementierung Semaphor
kernel module semaphore_synchronization;
export P, V;
import DEBLOCK, BLOCK;
var semaphore =
record
C: integer = 1;
// process counter
// C=1: ÔfreeÕ, C<=0: occupied
// if C<0 : |C| is the number of
// waiting processes
WP: queue of process = empty
end;
procedure P(S: semaphore);
begin
S.C := S.C-1;
if S.C < 0 then BLOCK(S.WP);
end;
procedure V(S: semaphore);
begin
S.C := S.C+1;
if S.C 0 then
DEBLOCK(S.WP)
end;
end semaphore.
4-65
// enqueue process
// deblock first of queue
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Bemerkung
z
z
z
Die Sammlung von Interaktionsmechanismen ist als Vorrat zu verstehen,
aus dem je nach Einsatzgebiet des Betriebssystems eine Teilmenge zur
VerfŸgung gestellt werden kann.
In einem Betriebssystem mŸssen nicht alle mšglichen Varianten angeboten
werden.
Aber man sollte den Programmierern schon eine ausreichende
Wahlmšglichkeit lassen.
Kernschnittstelle
1:n-UND-Signalisierung
Monitore
1:1-Kanäle
Leser-Schreiber-Kooperation
Synchronisationsbarriere
Sperren
m:n-Kanäle
Rendezvous-Synchronisat
4-66
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
4.5 Beispiele
Koordinations- und Kooperationsoperationen in Windows NT
NT kennt vier verschiedene Synchronisationsobjekte: semaphore, event,
mutex, critical section.
z
Semaphore: Wird mit einer positiven Zahl initialisiert und im Sinne einer
anzahlbegrenzenden Kooperation (Capacity Lock) zur
Betriebsmittelverwaltung verwendet.
y Mit CreateSemaphore() wird das Objekt erzeugt und kann nach
OpenSemaphore() benutzt werden
y Mit einer Warteoperation wie WaitForSingleObject() (entspricht POperation) wird der ZŠhlerwert dekrementiert und mit
ReleaseSemaphore() (entspricht V-Operation) inkrementiert.
y Wenn der ZŠhler den Wert 0 erreicht hat, wirkt die Warteoperation
blockierend.
y Semaphore kšnnen adressraumŸbergreifend eingesetzt werden, (d.h.
zwischen Threads unterschiedlicher Prozesse)
4-67
Koordinations- und Kooperationsoperationen in Windows NT
z
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Event
y Wird zur Signalisierung eingesetzt
y Auch hier wird ein Synchronsiationsobjekt mit CreateEvent() erzeugt
und kann nach OpenEvent benutzt werden.
y SetEvent() entspricht dem signal, und fŸr wait kšnnen die allgemeinen
Wartefunktionen in NT wie WaitForSingleObject() eingesetzt werden.
y Ein ResetEvent() erlaubt das explizite RŸcksetzen des Signals.
y Normalerweise arbeitet der Event als Gruppensignalisierung, d.h. durch
ein Signal werden alle wartenden Threads deblockiert.
y Wird bei der Event-Erzeugung jedoch die AutoReset-Option verwendet,
so lšst ein Signal nur einen Thread aus der Warteschlange (wie bei der
Einzelsignalisierung)
4-68
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Koordinations- und Kooperationsoperationen in Windows NT
z
Mutex
y Ein Mutex dient dem gegenseitigen Ausschluss.
y Nach CreateMutex() und OpenMutex() kann mit einer Warteoperation
(z.B. WaitForSingleObject() ) der kritische Abschnitt betreten werden.
y Bei Verlassen des kritischen Abschnitts wird die Sperre mit
ReleaseMutex() wieder freigegeben.
y Ein Mutex kann von beliebigen Threads im System benutzt werden
z
Critical Section
y Ein Critical-Section-Objekt ist eine vereinfachte und effizientere
Variante
y des Mutex speziell fŸr den gegenseitigen Ausschluss zwischen
Prozessen im selben Adressraum (d.h. Threads im selben Prozess)
y Mit InitializeCriticalSection() angelegt, wird der kritische Bereich Ÿber
EnterCriticalSection() betreten und mit LeaveCriticalSection() wieder
verlassen
4-69
Koordination und Kooperation im POSIX-Standard
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
FŸr Pthreads stehen mehrere Synchronsiationsobjekte zur VerfŸgung
z Mutex: Ein Mutex dient dem gegenseitigen Ausschluss.
z
y
pthread_mutex_init()
initialisiert ein Mutex-Objekt
y
pthread_mutex_lock()
wird beim Betreten des krit. Abschnitts
aufgerufen und blockiert den Aufrufer, falls
belegt
y
pthread_mutex_trylock()
ist die nichtblockierende Variante: Falls frei,
wird belegt; Falls belegt, wird mit
entsprechendem Hinweis zurŸckgekehrt
y
pthread_mutex_unlock()
beim Verlassen es kritischen Abschnitts
Cond : Eine Condition-Variable dient der Signalisierung
y
pthread_cond_wait()
blockiert, falls Signal nicht gesetzt
y
pthread_cond_timedwait()
zusŠtzlich mit Fristablauf (time-out)
y
pthread_cond_signal()
setzt das Signal und deblockiert den
ÒvorderstenÓ Thread (PrioritŠt bzw. FCFS)
y
pthread_cons_broadcast()
setzt Signal und deblockiert alle wartenden
Prozesse
ZusŠtzlich gibt es noch Mehrsortenkooperation (Reader/Writer-Locks)
4-70
Kommunikation in Unix und Windows NT (Auswahl)
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Spezieller 1:1-Kanal fŸr kontinuierlichen, gerichteten Zeichenstrom
“xyz..“
Pipe
“xyz..“
Prozeß A
z
z
z
z
Prozeß B
Die Pipe hat eine begrenzte KapazitŠt
Ist die Pipe voll, so wird ein sendender (schreibender) Prozess blockiert
Ist die Pipe leer, so wird ein empfangender (lesender) Prozess blockiert
Nur lokaler Mechanismus zwischen genau zwei Prozessen
4-71
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Sockets (Unix, Windows NT)
Sockets sind Endpunkte einer Duplex-Verbindung
send
recv
send
recv
Prozeß A
Prozeß B
Socket
z
z
z
z
Socket
Ein Socket kann von mehreren Prozessen benutzt werden
Verschiedene Socket-Typen werden angeboten
y stream socket
verbindungsorientiert
y datagram socket paketorientiert
y raw socket
Durchgriff auf zugrundeliegende Protokolle
Einsatz vor allem zur nichtlokalen Kommunikation (verteilte Systeme)
Blockierend (synchron) oder nichtblockierend (asynchron)
4-72
Betriebssysteme
© H.-U. Hei§
UniversitŠt Paderborn
Sockets (2)
bind()
/ Portnummer
/ zuordnen
listen()
/ Warten auf
/ Verbindungs
/ -wunsch
socket() / Erzeugen
accept() / Verbindung
/ aufbauen
connect() / Verbindung
/ aufbauen
read()
recv()
/ Lesen
/ Empfangen
write()
send()
/ Schreiben
/ Senden
write()
send()
/ Schreiben
/ Senden
read()
recv()
/ Lesen
/ Empfangen
close()
/ Schlie§en
close()
/ Schlie§en
4-73
Client-Prozess
Server-Prozess
socket() / Erzeugen