Betriebssysteme Teil 11: Interprozess-Kommunikation

Transkript

1 Betriebssysteme Teil 11: Interprozess-Kommunikation

2 Übersicht Grundbegriffe Shared Memory Pipelines Messages Ports Sockets 2

3 Grundbegriffe Interprocess-Kommunikation = Austausch von Daten über einen Kanal zwischen Prozessen bzw. Threads innerhalb eines Systems Ein Kanal realisiert in der Regel einen Datenstrom in einer Richtung, so dass für eine bidirektionale Verbindung zwei Kanäle erforderlich sind. Schema: T 1 T 2 write() read() T 1 T 2 D 4 D 3 D 2 D 1 Queue 3

4 Einteilung I Interprozess-Kommunikation speicherbasiert strombasiert nachrichtenbasiert Shared Memory Pipe Named Pipe Sockets Messages Signale Exceptions 4

5 Einteilung II Anzahl der Teilnehmer Unicast Multicast Richtung Unidirektional Bidirektional Entfernung der Teilnehmer Im selben Virtuellen Speicher Im selben System Zwischen Systemen 5

6 Shared Memory I Beide Kommunikationspartner befinden sich im selben RAM. Unterscheidung zwischen: (a) Zwei Threads innerhalb eines Prozesses (b) Zwei Prozesse VM = Virtueller per MMU realisierter Adressraum Thread1 Thread2 Prozess1 VM VM Prozess2 Prozess VM 6

7 Shared Memory II mit MMU Prozess1 Prozess2 Code Heap Stack Code Heap Stack Virtueller Speicher Abbildung durch MMU Realer Speicher 7

8 Bemerkungen Die Segmente der Prozesse werden in gleichgroße Seiten (Pages) meist 4 KByte lang aufgeteilt. Die Memory Management Unit (MMU) bildet diese Seiten in beliebiger Anordnung in den RAM ab. Mehrere virtuelle Seiten werden gemeinsam auf denselben Bereich abgebildet; das ist der gemeinsam benutzte Speicher (Shared RAM). 8

9 Producer/Consumer mit Monitoren I Producer Consumer Zirkulärer Puffer Die Producer/Consumer-Mechanismen gehören zu den Standard-Verfahren der Kommunikation zwischen Threads bzw. Prozessen. Producer: In einen freien Bereich werden Daten geschrieben. Dann werden diese vom Producer für den Consumer frei gegeben. Consumer: Die vom Producer geschriebenen Daten werden entnommen. Der nun ausgelesene Bereich wird für den Producer frei gegeben. AVS WS 2015/16 - Teil 6/IPC 9

10 Idee des Zirkulären Puffers I Producer: Der Index in zeigt auf das nächste zu beschreibende Element. Der Producer schreibt dort und erhöht modulo der Größe in. Consumer: Der Index out zeigt auf das nächste zu lesende Element. Der Consumer liest dort und erhöht modulo der Größe out. 10

11 Idee des Zirkulären Puffers II MOD ist der Modulo-Operator, dessen Anwendung dafür sorgt, dass die beiden Indices in und out sich immer innerhalb der erlaubten Array-Grenzen bewegen. Es gibt folgende Bedingungen: 1)Der Puffer ist dann leer, wenn gilt: in = out 2)Der Puffer ist dann voll, wenn gilt: in+1 MOD size = out 3) Wenn beide Bedingungen nicht gelten ist der Puffer gefüllt. Um die Implementierung zu vereinfachen, wird in der Variablen count die Anzahl der belegten Elemente vermerkt. Wenn nur mit in und out gearbeitet wird, dann muss in auf das letzte in die Queue gebrachte Element zeigen und unmittelbar vor dem Hineinbringen eines weiteren Elements erhöht und auf die zweite Bedingung geprüft werden. Statt eines Array mit den langsamen Indizierungen wird häufig mit Pointern in ein Array gearbeitet. 11

12 Producer/Consumer mit Monitoren II Teil 1 MONITOR Buffer { elem[0..size-1] buffer; int count:= 0; int in:= 0, out:= 0; condition NotEmpty, NotFull; PROC write(elem what) { IF count = size THEN waitcond(notfull); FI buffer[in]:= what; in:= (in+1) MOD size; count++; signalcond(notempty); } 12

13 Producer/Consumer mit Monitoren III Teil 2 } elem FUNC read(){ } IF count = 0 THEN waitcond(notempty); FI what:= buffer[out]; out:= (out+1) MOD size; count--; signalcond(notfull); return(what); Dies ist eine typische Ring-Puffer-Lösung zur Interprozesskommunikation. 13

14 Bemerkungen I Es gibt zwei Bedingungsvariablen: NotEmpty symbolisiert die Bedingung, dass der Puffer nicht leer ist, d.h. es ist irgendetwas enthalten NotFull symbolisiert die Bedingung, dass der Puffer nicht vollständig gefüllt ist, d.h. es gibt noch Platz Wenn nun ein Thread etwas in den Puffer schreiben will, muss vorher Platz da sein. Ist der Puffer voll, legt er sich auf das Ereignis, dass mindestens für ein Element Platz ist, schlafen: waitcond(notfull) Wenn ein Thread etwas aus dem Puffer lesen will, muss mindestens ein geschriebener Eintrag vorhanden sein. Wenn nicht, so legt er sich auf das Ereignis schlafen, dass etwas in den Puffer geschrieben wurde: waitcond(notempty) Die entsprechenden Threads, die lesen bzw. schreiben, wecken die wartenden Threads auf: signalcond(notfull) und signalcond(notempty) 14

15 Bemerkungen II Monitore werden mit den vorgestellten Mitteln: p(), v() etc. implementiert. Regeln Kein Thread sollte sich lange in einem Monitor aufhalten. Ein Ausschluss sollte nicht zu lange erfolgen. Schachteln von Monitoren kann zu Deadlocks führen. Threads, die sich in geschachtelten Monitore befinden, sollten höher priorisiert werden, damit sie schneller die Monitore frei geben. 15

16 Dasselbe noch einmal ohne Monitore I CLASS Buffer { elem[0..size-1] buffer; int in:= 0, out:= 0; Semaphore mutex:= 1; Semaphore empty:= size; Semaphore full:= 0; KA PROC write(elem what) { p(empty); p(mutex); buffer[in]:= what; in:= (in+1) MOD size; v(mutex); v(full); } KA= kritischer Abschnitt KA } elem FUNC read(){ p(full); p(mutex); what:= buffer[out]; out:= (out+1) MOD size; v(mutex); v(empty); return(what); } 16

17 Erklärungen Hier werden Integer-Semaphoren verwendet. Die initiale Zahl gibt die Anzahl der Threads an, die den kritischen Abschnitt gleichzeitig betreten dürfen. Bisher hatten wir binäre Semaphoren mit dem initialen Wert von 1 bzw. True. Die eine Semaphore (empty) zählt die freien Bereiche, die andere (full) die belegten Bereiche. Zwei der Semaphoren werden hier zum Zählen der freien Ressourcen benutzt. P() erniedrigt de Zähler, v() erhöht ihn. Ein Prozess wird schlafen gelegt, wenn der Zähler vor dem Erniedrigen 0 ist. Die dritte Semaphore (mutex = mutual exclusion) ist eine binäre Semaphore und erlaubt nur einem Thread die Manipulation der Queue. 17

18 Bewertung Shared Memory Standard-Methode bei der Kommunikation zwischen Threads Sehr effizient (kein Kopieren) Synchronisation liegt in der Hand der Programmier(innen) Quelle vieler Fehler Kein/Kaum Unterstützung durch Compiler/Programmiersprachen Ein falscher Pointer: Tod für alle Threads 18

19 Zusammenfassung des Bisherigen T 1 T 2 write() read() Abstraktion Queue D 4 D 3 D 2 D 1 Die Realisierung wird in einem Abstrakten Datentyp, z.b. einer Klasse, versteckt. Die Queue liegt aber immer noch innerhalb des Virtuellen Speichers der Beteiligten. 19

20 Über das Betriebssystem I T 1 T 2 Prozesse/Threads pipe() write() read() Manager create() destroy() D 4 Queue D 3 D 2 D 1 Betriebssystem Derartige Queues werden Pipes (Pipelines) genannt. In Unix werden diese im Shell mit einem senkrechten Strich ausgedrückt, z.b. "ls more". 20

21 Über das Betriebssystem II Der pipe-syscall erzeugt eine Queue, die mit dem Schließen der Enden (close) wieder zerstört wird. In die Queue wird mit write() geschrieben, aus ihr mit read() gelesen. Beide Operationen sind wartend, in dem Sinne, dass beim read() gewartet wird bis etwas in der Pipe ist, beim write() gewartet wird bis Platz in der Pipe ist. Über Pipes wird üblicherweise zwischen Prozessen kommuniziert, es geht aber auch zwischen Threads eines Prozesses. 21

22 Pipelines über das Dateisystem I T 1 T 2 Prozesse/Threads open() Write write() read() open() Read Manager create() destroy() Queue Queue Queue Betriebssystem Im Dateisystem werden die Queues angelegt und im Kernel realisiert: named pipe genannt 22

23 Pipelines über das Dateisystem II Die Enden einer Pipe haben nun einen Namen, der in die Namen des Dateisystems integriert ist. Damit ist die Existenz einer Pipe unabhängig von der Ausführung eines Prozesses. Pipes liegen im RAM und werden mit Terminieren bzw. Schließen der Verbindung zerstört. Named Pipes werden im Dateisystem angelegt und erst dann zerstört, wenn sie gelöscht werden. Damit realisieren sie allgemeine Schnittstellen zu Prozessen. Die Semantik von Pipes und Named Pipes ist so in Unix- Systemen realisiert. 23

24 Pipelines über das Dateisystem III Client 1 Client 2 write() write() read() Server 1 Client N write() Dateiname pipe Server werden über den Namen einer Queue angesprochen. Aber: die Verbindung zwischen Queue (Pipe) und Server ist lose, d.h. es können ein oder mehrere Server an den Pipe-Ausgang anschließen. Der (Datei-)Name der Pipe ist daher kein Service-Name. 24

25 Feste Verbindung: Port I Client 1 Server 1 Client 2 send() receive() send() Client N send() Portname Port Queue Wenn eine feste Verbindung zwischen Schnittstelle und Server als Schnittstelle zum Server besteht, wird von Ports gesprochen. Das Schreiben in ein Port wird send() und das Lesen receive() genannt. Die ausgetauschten Daten werden Messages (Nachrichten) genannt. 25

26 Feste Verbindung: Port II Dies ist die höchste Abstraktion. Für die Prozesse/Threads ist nicht erkennbar, ob der Partner im selben System oder in einem anderen System liegt. Unter Unix gibt es das Message-Konzept für Kommunikation innerhalb eines Systems in den Varianten der synchronen und asynchronen Kommunikation gibt es das Socket-Konzept für Kommunikation zwischen Systemen, dies geht auch im Spezialfall innerhalb eines Systems 26

27 Sockets Socket = Sockel = Begriff aus dem UNIX-Kernel für Schnittstellen zu anderen Prozessen auf demselben oder fremden Systemen (über ein Netz) Client 1 Server 1 send() receive() Socket TCP/IP-Verbindung Socket Betriebssystem Betriebssystem 27

28 Bewertung Nachrichtenbasierte Kommunikation Standardverfahren bei Kommunikation zwischen Systemen; Alternative Sockets mit offenen Strom Hoher Abstraktionsgrad Passt ins Konzept von Objekt-Orientierten Sprachen wird aber von denen nicht/kaum unterstützt Ineffizient, da fast immer mit Kopieren gearbeitet wird wenn innerhalb des Systems kommuniziert wird Das Beste ist wohl eine nachrichtenbasierte Kommunikation mit Hilfe von Shared Memory, da bei hoher Abstraktion eine hohe Effizienz realisiert wird. 28

29 Synchron und Asynchron I send() Synchron: der Sender wartet solange, bis der Empfänger empfangen hat Asynchron: der Sender setzt seine Nachricht ab und arbeitet weiter; diese wird in einer Queue zwischengespeichert receive() Synchron: der Empfänger wartet solange, bis eine Nachricht für ihn vorhanden ist Asynchron: der Empfänger empfängt eine Nachricht, falls sie da ist, ansonsten arbeitet er weiter. Prinzipiell sind alle vier Kombinationen möglich. Implementiert werden aber nicht unbedingt alle: Meistens ist send() blockierend oder nicht blockierend (no-wait-send), während receive() immer blockierend ist. Bei den asynchronen Varianten ist eine Queue als Zwischenspeicher erforderlich. Synchron und Asynchron betreffen die (zeitliche) Entkopplung. 29

30 Synchron und Asynchron II Synchrone Operationen und blockierend send() und receive() blockieren bis der Partner bereit ist Direkte Kommunikation Keine Zwischenspeicherung der Nachricht notwendig falls innerhalb desselben Systems sich der Partner befindet Implizite Empfangsbestätigung Einfach und schnell Dieses Verfahren wird auch Rendezvous genannt. Blockierend betrifft die Möglichkeit eines Wartens. 30

31 Synchron und Asynchron II Asynchrone Operationen und möglichst nicht blockierend Queue erforderlich Wenn Sender terminiert, entsteht beim Empfänger kein Deadlock Empfangsbestätigung kompliziert Aber! Wenn die Queue voll ist oder kein Speicher für die Nachricht verfügbar ist, ist das asynchrone Senden blockierend. Asynchrone Operationen und nie blockierend Aber! Wenn die Queue voll ist oder kein Speicher für die Nachricht verfügbar ist, scheitert das asynchronen Senden; es könnte dann eine Exception geworfen werden. 31

32 Send-receive-reply I Sender Empfänger receive() send() reply() Rendezvous mit Antwort durch reply(). 32

33 Send-receive-reply II reply() ist die Operation, mit der der Empfänger eine Rückantwort aufgrund einer Nachricht zurückschickt. Da der Speicher für die Nachricht vorhanden ist, kann er auch zur Antwort benutzt werden. Das bedeutet, dass der reply()- Aufrufer bei der Speicher-Allokation meist nicht blockiert. Wenn die Rückantwort dagegen durch ein eigenes send() realisiert wird, dann kann der send()-aufrufer bei der Speicher- Allokation blockieren. 33

34 Nach dieser Anstrengung etwas Entspannung... Schnee, nichts als Schnee soweit das Auge reicht 34