© H.-U. Hei§, Uni Paderborn

2 Prozesse und ihre Interaktion 2.1 Prozesse Die Abarbeitung von Programmen ist in Prozessen organisiert. Ein Prozess besteht im wesentlichen aus ¥ einem StŸck Programmcode ¥ einem oder mehrerer Datenbereichen, auf die er zugreift ¥ dem aktuellen Zustand der Bearbeitung Ein Prozess ist reprŠsentiert durch einen Prozesskontrollblock (PCB), der alle relevante Information enthŠlt, z.B.: ¥

Prozesscharakteristika: - Prozesskennung, Name des Programms

¥

Zustandsinformation - BefehlszŠhler, Stapelzeiger, Registerinhalte

¥

Verwaltungsdaten: - PrioritŠt, Rechte, Statistikdaten 2-1

© H.-U. Hei§, Uni Paderborn

Prozessumschalten Zu einem Zeitpunkt existieren in einem Betriebssystem in der Regel viele Prozesse. Ein Prozess, der gerade durch den Prozessor bearbeitet wird, hei§t rechnend (running). Es kann in einem Rechner hšchstens soviele rechnende Prozesse geben wie Prozessoren vorhanden sind. Um einen anderen Prozess zu bearbeiten, muss umgeschaltet werden: ¥

die Zustandsinformation (BefehlszŠhler, Stapelzeiger, Rechenregister) des rechnenden Prozesses wird in seinen Prozesskontrollblock (PCB) gerettet.

¥

danach wird die Zustandsinformation des neuen Prozesses in den Prozessor geladen.

Das Umschalten kann ¥

freiwillig erfolgen (rechnender Prozess gibt den Prozessor auf)

¥

erzwungen werden (ausgelšst durch eine HW-Unterbrechung wird der rechnende Prozess verdrŠngt (preemption)) 2-2

© H.-U. Hei§, Uni Paderborn

Umschalten Prozeß P1

Betriebssystem-Kern

Zustand von P1 aus Prozessor in PCB retten Zustand von P2 aus PCB in Prozessor laden

Zustand von P2 aus Prozessor in PCB retten Zustand von P1 aus PCB in Prozessor laden

2-3

Prozeß P2

© H.-U. Hei§, Uni Paderborn

Blockieren ¥

Ein Prozess, der durch Aufgabe oder VerdrŠngung den Prozessor verlŠsst, kann jederzeit wieder zugeordnet werden.

¥

Prozesse, die auf eine erneute Zuordnung zum Prozessor warten, hei§en bereit (ready)

¥

Aus dieser Menge wird beim Umschalten ein neuer Prozess ausgewŠhlt (Scheduling-Strategie)

¥

In vielen FŠllen kann ein Prozess jedoch erst fortgesetzt werden, wenn ein bestimmtes Ereignis eingetreten ist (z.B. Ende eine E/A-Vorgangs). Er wird solange blockiert. Erst nach Eintritt des Ereignisses, auf das er wartet, wird er wieder in Menge der bereiten Prozesse Ÿbernommen. Der BS-Kern stellt dazu die Operationen Blockieren und Deblockieren zur VerfŸgung.

2-4

© H.-U. Hei§, Uni Paderborn

ProzesszustŠnde Dadurch ergeben sich die folgenden ProzesszustŠnde. FŸr die ZustandsŸbergŠnge gibt es entsprechende Operationen des BS-Kerns.

Wartend (waiting, blocked) BLOCKIEREN

DEBLOCKIEREN AUFGEBEN

Bereit (ready)

Aktiv

Rechnend (running)

ZUORDNEN

2-5

© H.-U. Hei§, Uni Paderborn

Erweiterung des Zustandsdiagramms Diese drei ZustŠnde kšnnen zu einem Zustand aktiv zusammengefasst werden. Aktive Prozesse besitzen (au§er dem Prozessor) die zum Ablauf erforderlichen Betriebsmittel (z.B. Programm ist in den Hauptspeicher geladen, Datenbereiche sind zugeordnet) Es ist jedoch mšglich, dass Prozesse zwar existieren (es gibt einen Prozesskontrollblock), jedoch z.B. kein Hauptspeicher zur VerfŸgung steht (noch nicht zugeordnet oder wieder entzogen). Solche Prozesse sind existent, aber nicht aktiv. Schlie§lich ist noch die Erzeugung bzw. Lšschung eines Prozesses (d.h. seines Prozesskontrollblocks) vorzusehen . Dadurch ergibt sich die folgende ErgŠnzung der ProzesszustŠnde und ZustandsŸbergŠnge:

2-6

© H.-U. Hei§, Uni Paderborn

VollstŠndiges Prozesszustandsdiagramm

Wartend (waiting, blocked) BLOCKIEREN

DEBLOCKIEREN LÖSCHEN

DEAKTIVIEREN

AUFGEBEN

Nichtaktiv

Nichtexistient

Bereit (ready)

AKTIVIEREN

ERZEUGEN Existent

Rechnend (running)

ZUORDNEN Aktiv

2-7

© H.-U. Hei§, Uni Paderborn

Implementierung Die existenten Prozesse (d.h. ihre Kontrollblšcke, PCBs) werden vom BS-Kern in speziellen Datenstrukturen verwaltet (z.B. verkettete Listen). Ihr Zustand wird entweder im jeweiligen Kontrollblock vermerkt, oder es werden fŸr die einzelnen ZustŠnde spezielle Datenstrukturen unterhalten. †blich ist beispielsweise eine Liste (Warteschlange) der bereiten Prozesse (Bereitliste, ready queue). Operationen zum Zustandswechsel von Prozessen bestehen dann hŠufig darin, dass ein PCB aus einer verketteten Liste entfernt und in eine anderere eingefŸgt wird. Bei den wartenden Prozessen kann fŸr jedes Ereignis, auf das gewartet wird, ein entsprechender Warteraum (Liste von PCBs) eingerichtet werden.

2-8

© H.-U. Hei§, Uni Paderborn

Beispiel: Umschalten zwischen Prozessen mit PrioritŠtsstrategie

Neuankömmling bzw. verdrängter Prozeß

Nächster Einordnen gemäß Priorität

Bereitliste (Prozeßkontrollblöcke)

Prozessoren

2-9

© H.-U. Hei§, Uni Paderborn

Prozesse und AdressrŠume Moderne Prozessoren ermšglichen nicht nur relative Adressierung (Basisregister), sondern stellen eine Speicherabbildungsfunktion (memory management unit, MMU) zur VerfŸgung. Damit kšnnen (beliebig) viele logische AdressrŠume gebildet werden, die automatisch auf den physikalischen Speicher abgebildet werden. Dadurch sind die AdressrŠume gegenseitig geschŸtzt. GrundsŠtzlich sind AdressrŠume unabhŠngig von Prozessen zu sehen. Zwar benštigt jeder Prozess zu jedem Zeitpunkt einen Adressraum, ansonsten sind aber verschiedene Beziehungen mšglich: ¥ ¥ ¥

Ein Prozess wechselt zwischen mehreren AdressrŠumen Ein Prozess besitzt genau einen Adressraum Mehrere Prozesse teilen sich einen Adressraum

2-10

© H.-U. Hei§, Uni Paderborn

Beispiele fŸr die Zuordnung von AdressrŠumen zu Prozessen

Adreßraum

Prozeß, bestehend aus Programmcode Daten

Mehrere Prozesse im selben AR

Jeder Prozess im eigenen AR 2-11

© H.-U. Hei§, Uni Paderborn

Hinweis BezŸglich der Terminologie in der einschlŠgigen Literatur ist Vorsicht geboten: Ein Prozess (process, task) wird hŠufig im Sinne eines Unix-Prozesses verstanden als ein Prozess mit einem eigenen Adressraum. Da ein Umschalten eines solchen Prozesses mit einem (relativ aufwendigen) Adressraumwechsel verbunden ist, nennt man einen Unix-artigen Prozess auch Schwergewichtsprozess (heavyweight process) Die meisten neueren Betriebssysteme ( auch neuere UNIX-Varianten) bieten dagegen die Mšglichkeit an, mehrere Prozesse in einem gemeinsamen Adressraum ablaufen zu lassen. Man nennt sie Leichtgewichtsprozesse (lightweight process) oder Threads. In modernen Unix-Varianten (z.B. Solaris) gibt es daher einerseits die ursprŸnglichen UnixProzesse (tasks), die aber aus vielen Threads bestehen kšnnen. Der Unix-Prozess degeneriert dadurch zu einer Art Ablaufumgebung der Threads. FŸr eine Gruppe von Threads im selben Adressraum finden sich auch die Begriffe Team (System V) oder Actor (Chorus) Der hier in der Vorlesung verwendete Prozessbegriff deckt sich mit dem des Thread. 2-12

© H.-U. Hei§, Uni Paderborn

2.2 Interaktion zwischen Prozessen 2.2.1 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. 2-13

© H.-U. Hei§, Uni 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 ( = expliziter Datenstransport) P1

Kooperation ( = Zugriff auf gemeinsame Daten) P1

P2

P2 gemeinsamer Teil

D1

Kopieren

D2

D1

D2

(symmetrische Beziehung)

(gerichtete Beziehung) 2-14

© H.-U. Hei§, Uni Paderborn

Konzeptueller Charakter der beiden Formen 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. Prozeß 1

Prozeß 2

Prozeß 2

Prozeß 1

Kooperation

Kommunikation

Modellebene

Kommunikation

Modellebene Kooperation

Realisierungsebene

Kooperation realisiert durch Kommunikation

Realisierungsebene

Kommunikation realisiert durch Kooperation

2-15

© H.-U. Hei§, Uni Paderborn

Koordination (zeitliche Abstimmung) Prozeß P1

A

Prozeß P2 Warten (wait) 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 (wait) wird P2 ggf. solange aufgehalten, bis P1 die Operationen Signalisieren (signal) aufgerufen hat. Nach Ablauf beider Operationen wird das Signal zurŸckgesetzt (d.h. das Signal wird ãverbrauchtÒ) 2-16

© H.-U. Hei§, Uni Paderborn

Kooperation Kooperation tritt auf, wenn mehrere Prozesse auf dieselben Daten zugreifen. Um Fehler und Inkonsistenzen zu vermeiden, mŸssen die Zugriffe koordiniert sein. Beispiel: Zwei Prozesse P1 und P2 inkrementieren eine gemeinsame Variable s. Der Ablauf beider Prozesse wŸrde demnach den Wert der Variablen um 2 erhšhen. Aufgelšst in Maschinenbefehle kšnnte sich in einem Einprozessorsystem mit VerdrŠngung (oder auch in einem Mehrprozessorsystem) eine Befehlsfolge ergeben, bei der eine Erhšhung verlorengeht: P1

P2

Speicherzelle s s=4

load s P1

P2

s := s+1

s := s+1

Die beiden Prozesse

load s add 1 store s add 1 store s

s=5 s=5

Eine AusfŸhrung der beiden Prozesse 2-17

© H.-U. Hei§, Uni Paderborn

Noch ein 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. 2-18

© H.-U. Hei§, Uni Paderborn

Kritische Abschnitte Es gibt offensichtlich Operationsfolgen, bei denen ein nebenlŠufiger Zugriff oder eine verzahnte AusfŸhrung zu Fehlern fŸhrt. Man nennt eine solche Folge einen kritischen Abschnitt (critical section). Kritische Abschnitte sind unter gegenseitigem Ausschluss (mutual exclusion) auszufŸhren. Dazu gibt es das Operationspaar Sperren (lock) und Entsperren (unlock) als spezielle Form der Koordination Lock(L)

PrŸft, ob die binŠre Sperrvariable L gesetzt ist (L= 1) Falls ja, wird der aufrufende Prozess in der Operationen solange aufgehalten (z.B. blockiert), bis L zurŸckgesetzt ist (L = 0). Dann wird L gesetzt und der Prozess fortgesetzt.

Unlock(L)

Setzt die Sperrvariable L zurŸck (L = 0) und deblockiert ggf. einen blockierten Prozess

2-19

© H.-U. Hei§, Uni Paderborn

Kritische Abschnitte Ein kritischer Abschnitt gesichert durch Sperroperationen P1

P2

LOCK(L)

LOCK(L)

Krit. Abschnitt UNLOCK(L)

UNLOCK(L)

Anmerkung: Um die Datenstrukturen des BS-Kerns zu sichern, wird hŠufig der gesamte BS-Kern als kritischer Abschnitt realisiert. Bei Aufruf einer Kernoperation erwirbt der Prozess die sogenannte Kernsperre, so dass kein weiterer Prozess den Kern betreten kann. 2-20

© H.-U. Hei§, Uni 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 2-21

© H.-U. Hei§, Uni Paderborn

2.2.2 Das Kanalkonzept (Kommunikation) 2.2.2.1 Grundlagen Ein Kanal ist ein Datenobjekt, das die Operationen Senden (send) und Empfangen (receive) zur VerfŸgung stellt. Parameter: ¥

Name des Kanal(objekt)s (CO)

¥

Adresse eines BehŠlters Sender: Adresse der zu verschickenden Nachricht (QuellbehŠlter BS) (Statt der Adresse kann hier auch die Nachricht selbst stehen) EmpfŠnger: Adresse, wohin die empfangene Nachricht geschrieben werden soll (ZielbehŠlter BR) P1

P2

SEND(CO,BS)

RECEIVE(CO,BR)

CO

Operationen Daten 2-22

© H.-U. Hei§, Uni Paderborn

ZeitverhŠltnisse Da Sender und EmpfŠnger ihre Operationen zu beliebigen Zeitpunkten aufrufen kšnnen, sind zwei FŠlle zu berŸcksichtigen: 1. 2.

Erst Senden, dann Empfangen Erst Empfangen, dann Senden

Wenn die aufrufenden Prozesse in den Operationen nicht aufgehalten (blockiert) werden sollen, besteht die Notwendigkeit der Zwischenspeicherung im Kanal Sender zuerst:

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 Senden die Nachricht dorthin kopiert werden

kann

Der Kanal muss entsprechende Variable zur Aufnahme dieser Daten vorsehen

2-23

© H.-U. Hei§, Uni Paderborn

Wirkung der Reihenfolge der Operationen 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

2-24

Dr

Adresse Zielbehälter

Erster

© H.-U. Hei§, Uni Paderborn

Varianten der 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 Adressraum des EmpfŠngers eingeblendet (Kein Kopieren erford.) Sender

Empfänger Kanal

2-25

in den

© H.-U. Hei§, Uni Paderborn

Grundform der Kommunikation (Variante WertŸbergabe)

SEND(CO,MSG)

RECEIVE(CO,BR)

deposit message MSG at channel N

deposit address of target buffer BR at channel

address of target buffer BR available?

message MSG available ?

copy message to target buffer

copy message to target buffer

delete message and target buffer address

delete message and target buffer address

R

R

2-26

N

© H.-U. Hei§, Uni Paderborn

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;

2-27

© H.-U. Hei§, Uni Paderborn

2.2.2.2 Koordinierte Kommunikation Bisher hatten wir keinerlei zeitliche Abstimmung zwischen Sender und EmpfŠnger gefordert. ¥

Beide rufen ihre jeweilige Operation auf, legen ggf. Daten im Kanal ab, verlassen die Prozedur und arbeiten weiter, ohne auf den Kommunikationspartner zu warten.

¥ 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. ¥

Er wird also in der Empfangsoperation so lange aufgehalten (blockiert).

¥

Auf diese Weise synchronisiert er sich mit dem Sender (d.h. wartet auf ihn).

¥

Man spricht dann von einem synchronen Empfangen.

¥ 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 2-28

© H.-U. Hei§, Uni Paderborn

Koordinationsvarianten der Kommunikation Pq

Pz

Pq

SENDEN

EMPFANGEN

SENDEN

Pz EMPFANGEN

SIGNAL

A:A

WARTEN

A:S

asynchrones Senden

asynchrones Empfangen

asynchrones Senden

synchrones Empfangen

Pq

Pz

Pq

Pz

SENDEN

EMPFANGEN

WARTEN

SIGNAL

SENDEN SIGNAL WARTEN

EMPFANGEN SIGNAL WARTEN

synchrones Senden

S:A

S:S asynchrones Empfangen

synchrones Senden

synchrones Empfangen „Rendezvous“

2-29

© H.-U. Hei§, Uni Paderborn

Implementierungsbeispiel kernel module Communication; { A:S-Channel, by value} export SEND_A, RECEIVE_S; var channel_object = 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;

2-30

© H.-U. Hei§, Uni Paderborn

Variante: Versuchendes Senden bzw. Empfangen (polling, probing) Gelegentlich mšchte man nur prŸfen, ob eine Nachricht vorliegt. Wenn ja, wird sie entgegengenommen (kopiert), wenn nein, geschieht nichts. kernel module communication; export SEND_A, RECEIVE_T;

(A:T-channel, trying receive)

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; 2-31

© H.-U. Hei§, Uni Paderborn

Weitere Variante: Umlenkendes Senden bzw. Empfangen Idee: Nach erfolgreicher NachrichtenŸbermittlung wird der Kommunikationspartner unterbrochen und auf ein spezielles ProgrammstŸck umgelenkt.

DurchfŸhrung: ¥ Der zuerst kommende Prozess legt neben der BehŠlteradresse eine Umlenkadresse ab. ¥

Bei Eintreffen des Partners wird die Nachricht kopiert und der Prozess auf die angegebene Adresse umgelenkt

(€nlich den sogenannten ãactive messagesÒ)

2-32

© H.-U. Hei§, Uni Paderborn

kernel module Communication; 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 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) 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; if CO.DS empty then begin CO.DR^ := CO.DS;{message transport} CO.DS := empty; CO.DR := empty INTERRUPT(my_PID, LI) end end; end Communication.

2-33

© H.-U. Hei§, Uni Paderborn

2.2.2.3 KapazitŠt Bisher kann ein Kanal genau eine Nachricht bzw. einen ãEmpfangswunschÒ speichern. WŸnschenswert: FŠhigkeit, mehrere Nachrichten zu ãpuffernÒ Beispiel:

Mehrere Prozesse senden an einen zentralen ãServer-ProzessÒ P P

S

n:1-Kanal

P

E

S S

z.B. zentraler Server

2-34

© H.-U. Hei§, Uni 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

Datenstrukturen und ihre KapazitŠt 2-35

© H.-U. Hei§, Uni Paderborn

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 ¥ ¥ ¥ ¥

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: ¥

unbegrenzt KapazitŠt: erfordert dynamische Speicherverwaltung innerhalb der Kommunikationsoperationen: Speicherplatz muss angefordert und freigegeben werden

¥

begrenzte KapazitŠt: erfordert Mechanismen bei ã†berlaufÒ Mšglichkeiten: ¥ †berschreiben ¥ Abweisung der Operation ¥ Blockierung des Aufrufers, bis KapazitŠt frei wird

2-36

© H.-U. Hei§, Uni Paderborn

Beispiel kernel module n:n/A:S-Channel; export SEND_A, RECEIVE_S; import ALLOCATE, RELEASE, INSERT, REMOVE, BLOCK, DEBLOCK; var channelobjekt = 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: channelobjekt; 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: channel_objekt; 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. 2-37

© H.-U. Hei§, Uni Paderborn

2.2.2.4 Physische Zuordnung Ein Kanal ist zunŠchst ein eigenstŠndiges Kommunikationsobjekt, das unabhŠngig von irgendwelchen Sendern und EmpfŠngern existieren kann. Es ist jedoch gelegentlich sinnvoll, ein Kommunikationsobjekt fest einem Prozess zuzuordnen. Dies kann sendeseitig oder empfangsseitig erfolgen: ¥

Besitzt ein Prozess einen Kanal, in dem er alle seine ausgehenden Nachrichten ablegt, so spricht man von einem Ausgangstor.

¥ Besitzt ein Prozess einen Kanal, in dem alle seine eingehenden Nachrichten abgelegt werden, so spricht man von einem Eingangstor (port). Ports sind die in modernen Betriebssystemen am meisten verbreiteten Kommunikationsobjekte. Eingangstore sind n:1-KanŠle, Ausgangstore 1:n-KanŠle. 2-38

© H.-U. Hei§, Uni Paderborn

Bindung von Kommunikationsobjekten an Prozessen keine Bindung „Kanal“ Prozeß

n:n

Prozeß

Bindung an Sender „Ausgangstor“ Prozeß

Prozeß 1:n

Bindung an EmpfŠnger „Eingangstor“, port Prozeß

n:1 Prozeß 2-39

© H.-U. Hei§, Uni Paderborn

2.2.2.5 Gruppenkommunikation 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 ¥ ¥ ¥ ¥

Einzel-Einzel-Kanal Einzel-Gruppen-Kanal Gruppen-Einzel-Kanal Gruppen-Gruppen-Kanal

(wie bisher, ãone-to-one-communicationÒ) (broadcast, multicast, ãone-to-many-communicationÒ) (combine, ãmany-to-one-communicationÒ) (all-to-all-broadcast, ãmany-to-many-communicationÒ

2-40

© H.-U. Hei§, Uni Paderborn

Gruppenkommunikation (schematisch) Empfangsseitige Gruppe: Nachricht geht an mehrere E Vervielfältigung

S

E : E Sendeseitige Gruppe: Mehrere Nachrichten werden kombiniert S Zusammenfassung S

E :

S 2-41

© H.-U. Hei§, Uni Paderborn

Art der Zusammenfassung 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): ¥

Konkatenation: „a“ „5“

concat

„a5k“

„k“ ¥

Logische VerknŸpfung:

„true

“ „true“ e“ „fals ¥

&

„false“

Σ

„12“

Arithmetische VerknŸpfung: „5“ „3“ „4“ 2-42

© H.-U. Hei§, Uni Paderborn

Beispiel fŸr Implementierung (mit EmpfŠnger-Rendezvous) kernel module 1:1/G:G/A:S-channel; export G_SEND_A, G_RECEIVE_S; import BLOCK, DEBLOCK; var channel_object = record QDS: array[1..kq] of message = all empty; QDR: array[1..kz] of address = all empty; QPR: array[1..kz] 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 ∨ ∃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 2-43