Vorlesung Betriebssysteme I Thema 6: Kommunikation Robert Baumgartl 15. Dezember 2020

(1)

Vorlesung Betriebssysteme I

Thema 6: Kommunikation

Robert Baumgartl

15. Dezember 2020

(2)

Einige Gedanken

Kommunikation = Übertragung von Informationen zwischen Aktivitäten

I meist mit Synchronisation (d. h., zeitlicher Koordination) verbunden

I Synonym:Inter Process Communication(IPC) I Vielzahl an Mechanismen, „historisch gewachsen“

I Teilnehmer benötigen gemeinsam genutzte Ressource I Identifikation/Authentisierung der Teilnehmer erforderlich

2 / 38

(3)

Beispiele für IPC-Mechanismen (Auswahl)

I Datei I Pipe I Signal

I benannte Pipe (FIFO) I Socket

I gemeinsam genutzer Speicher (Shared Memory) I Nachrichten

I Mailboxen

I speichereingeblendete Datei (memory-mapped File) I entfernter Prozeduraufruf (Remote Procedure Call) I Clipboard

I . . .

(4)

Kategorisierung von IPC-Mechanismen

Interprozeßkommunikation (IPC)

Synchronisation Kommunikation

speicherbasiert strombasiert nachrichtenbasiert Semaphore Signale

Shared Memory Pipe Named Pipe

Message Passing Message Queue

4 / 38

(5)

Kommunikationsbeziehungen

Anzahl der Teilnehmer:

I 1:1 I 1:m I n:1 I n:m

Gleichzeitigkeit von Hin- und Rückkanal:

I unidirektional I bidirektional weitere Aspekte:

I lokale vs. entfernte Kommunikation I direkte vs. indirekte Kommunikation

(6)

Synchrone und Asynchrone Kommunikation

Sendeoperation (Send)

I synchron: Sender wartet (blockiert), bis Empfänger die Information entgegengenommen hat (implizite Quittung) I asynchron: Sender setzt nach dem Senden einer

Nachricht sofort seine Arbeit fort („No-Wait-Send“, „Fire and Forget“); Beispiel: Telegramm

Empfangsoperation (Receive)

I synchron: Die Empfangsoperation blockiert den Empfänger so lange, bis Information eintrifft.

I asynchron: Empfänger liest Information, falls empfangen wurde und arbeitet anschließend weiter, auch wenn nichts empfangen wurde

6 / 38

(7)

Synchrone vs. Asynchrone Operationen

synchrone Operationen:

I direkte Zustellung der Informationen (ohne Zwischenspeicher)

I implizite Empfangsbestätigung I i. a. einfacher zu programmieren

I standardmäßig arbeiten Kommunikationsoperationen in Unix synchron

asynchron:

I Nachricht muss zwischengespeichert werden

I Vorteil: wenn ein kommunizierender Prozess abbricht, dann wird der Partner nicht unendlich blockiert

I keinDeadlockmöglich (gegenseitige Blockierung infolge fehlerhafter Programmierung)

I Benachrichtigung des Empfängers u. U. kompliziert

(8)

Verbindungsorientierte und verbindungslose Kommunikation

verbindungsorientiert verbindungslos

3 Phasen: 1 Phase:

Ablauf Aufbau der Verbindung

Datenübertragung Datenübertragung Abbau der Verbindung

(analoges) Telefon Telegramm

Beispiele TCP IP

Pipe Signal

8 / 38

(9)

Verbindungsarten

Unicast Punkt-zu-Punkt-Verbindung, Direktverbindung, 2 Teilnehmer

Multicast 1 Sender, mehrere (aber nicht alle) Empfänger, Gruppenruf

Broadcast 1 Sender, alle Empfänger (z. B. eines Subnetzes)

(10)

Kommunikation über Datei

I ältester IPC-Mechanismus I Sender schreibt Daten in Datei I Empfänger liest Daten aus Datei

I nachteilig: zweimaliger Zugriff auf Massenspeicher I aber: es gibt auch Dateisysteme im RAM

I nachteilig: überlappender Zugriff durch Sender und Empfänger

I Lösung: Sperren der Datei (File Locking), z. B. mittels lockf()

I Beispiel:filelock.c(extern)

I Problem: Sperren setzt Wohlverhalten voraus

10 / 38

(11)

Kommunikation mittels Pipe („Röhre“)

int pipe(int filedes[2]);

I liefert Feld von 2 Dateideskriptoren zurück (einer zum Lesen, einer zum Schreiben)

I Zugriff wie auf eine Datei (read(),write(),close()), jedoch keinopen(),lseek()

I Datenübertragung innerhalb eines Prozesses sinnlos?!

I Woher weiß Empfänger, dass die Pipe existiert?

(12)

Vorgehensweise

1. Prozess ruftpipe()→Pipe wird durch BS angelegt.

2. Prozess ruftfork()(Deskriptoren werden vererbt!).

3. Jeder Prozess schließt einen seiner Deskriptoren.

(Verständigung erfolgt)

4. Datenübertragung mittelsread()bzw.write()

5. Beide Prozesse rufenclose()→Pipe wird nach zweitem close()durch BS vernichtet

12 / 38

(13)

Veranschaulichung der Pipe-Erstellung

R W

fd[0] fd[1]

R W

fd[0] fd[1]

1

2

3

W R

4 fork()

fd[1] fd[0]

π π

1 2

W

fd[1]

fd[0]

R

Daten

(14)

Eigenschaften der Pipe

I stets unidirektional (→für bidirektionale Übertragung 2 Pipes nötig)

I keine Synchronisation beim Schreiben (Daten werden im Kern gepuffert)

I Schreiboperationen, die weniger alsPIPE_BUF¹Daten umfassen, müssenatomar(in einem Rutsch) erfolgen.

I keine persistente Ressource (verschwindet nach letztem close())

I nur zwischen verwandten Prozessen möglich!

1Linux gegenwärtig: 4096 Bytes; vgl.limits.h

14 / 38

(15)

Pipe: problematische Situationen

I Lesen von einer eröffneten Pipe, die keine Daten enthält, blockiert. Wird danach die Schreibseite geschlossen, kehrt read()mit Resultat 0 zurück.

I Leseoperation aus Pipe mit ungültigem Filedeskriptor – liefert Fehler EBADF (Bad File Descriptor)

I Leseoperation aus Pipe, die nach Schreibvorgang geschlossen wurde – liefert zunächst Daten, dann 0 als Resultat=b End of File (EOF)

I Schreiboperation auf Pipe, deren Leseseite geschlossen – liefert SignalSIGPIPEan schreibenden Prozess

I Prozess(e) enden mit eröffneter Pipe – Filedeskriptoren werden bei Prozessbeendigung automatisch geschlossen Literatur:man 7 pipe

(16)

Anwendungsbeispiel

Pipe-Operator (‘|’) der Shell zur Verknüpfung vonstdoutdes Senders mitstdindes Empfängers:

robge@ipaetz2:~$ du | sort -n -r | less

Beispiel 2:simplepipe.c(extern)

16 / 38

(17)

Putting it all together: popen()

FILE *popen(const char *cmd, const char *type);

I legt eine Pipe an, forkt den rufenden Prozess und ruft im Kind eine Shell auf, diecmdausführt

I Resultat: Zeiger auf I/O-Strom, der

I mitstdinvoncmdverbunden ist, wenntype == "w"

oder

I mitstdoutvoncmdverbunden ist, wenntype == "r".

I Lese- oder Schreiboperation geschehen also mit Pipe, die mit ge-fork()-tem Prozesscmdverbunden ist

I muss mitpclose()geschlossen werden I erleichtert Kommunikation C-Programm↔

Shellkommando Beispiel:popen.c(extern)

(18)

Signale

I Mittel zur Signalisierung zwischen Prozessen bzw. BS und Prozessen

I Übermittlung einer Information, ohne dass Prozessaktiv beteiligt

I Ursprung: UNIX

I Generierung→Zustellung→Behandlung (Reaktion auf Signal)

I jedes Signal hat Nummer, Name, Defaultaktion I meist (aber nicht immer) keine Datenübertragung I Verwandschaft der Partner ist nicht notwendig

18 / 38

(19)

Signale – Prinzipieller Ablauf

1. Sende-Prozess generiert ein Signal

2. System stellt das Signal dem Empfänger-Prozess zu 3. Wenn Empfänger Signalhandler installiert hat→Aufruf

des Signalhandlers (asynchron zur Programmausführung) 4. Wenn kein Signalhandler installiert→Ausführung der

Default-Aktion (z. B. Abbruch, Ignorieren)

(20)

Signale unter Unix (Übersicht)

Name Def.-Aktion Semantik

SIGHUP Abbruch Verbindung beendet (Hangup) SIGINT Abbruch CTRL-C von der Tastatur

SIGILL Abbruch Illegale Instruktion SIGKILL Abbruch Sofortige Beendigung SIGSEGV Coredump Segmentation Violation

SIGPIPE Abbruch Schreiben in ungeöffnete Pipe SIGCHLD Ignoriert Kind-Prozess beendet

SIGSTOP Stop Anhalten des Prozesses SIGTSTP Stop CTRL-Z von der Tastatur

SIGCONT Fortsetzen eines angehaltenen Prozesses Tabelle:Auswahl von Signalen nach POSIX

vollständige Übersicht:man 7 signal

20 / 38

(21)

Senden von Signalen an der Kommandozeile

Senden mit dem (externen) Kommandokill:

robge@hadrian:~$ while true ; do echo -n; done &

[1] 6578

robge@hadrian:~$ kill -SIGQUIT 6578

[1]+ Verlassen while true; do echo -n;

done

Generierung bestimmter Signale auch mit der Tastatur möglich:

Signal erzeugende Tastaturkombination SIGINT Ctrl-C

SIGQUIT Ctrl-4 oder Ctrl-\

SIGTSTP Ctrl-Z

(22)

Signale in der Bash

Einrichtung eines Signalhandlers mittelstrap

#!/bin/bash

trap "echo CTRL-C gedrÃ¹₄ckt. Na fein." SIGINT trap "echo CTRL-Z gedrÃ¹₄ckt. Mach ruhig weiter so."

SIGTSTP

trap "echo Auch SIGQUIT kann mir nix anhaben."

SIGQUIT

echo Entering loop

while true ; do echo -n ; done

Handler wird

I (asynchron) angesprungen, I ausgeführt, und

I es wird am Unterbrechungspunkt fortgesetzt.

Handler darf nur (externe) Kommandos enthalten, keine Bash-Instruktionen.

22 / 38

(23)

Noch ein Bash-Beispiel

laufschrift.c(extern) Probieren Sie:

robge@hadrian:~$ ps x | grep "./laufschrift"

5341 pts/5 S+ 0:00 ./laufschrift 5343 pts/0 S+ 0:00 grep ./laufschrift robge@hadrian:~$ kill -SIGSTOP 5341

robge@hadrian:~$ kill -SIGCONT 5341 robge@hadrian:~$ kill -SIGSTOP 5341 usw.

(24)

Signale in C – Teil 1: Senden

int kill(pid_t pid, int sig);

I sendet das durchsigspezifizierte Signal an Prozess mit PIDpid

I Zuvor wird geprüft, ob der ausführende Nutzer dazu berechtigt ist.

I Spezifikation des Signals: SIGHUP, SIGQUIT, SIGKILL usw., vgl. Headerdateibits/signum.h

I wennpid == -1, dann wird das betreffende Signal an jedenProzess geschickt, für den der Nutzer dieses Recht hat (Vorsicht!)

24 / 38

(25)

Was passiert nun bei Zustellung eines Signals?

Behandlung bei Zustellung:

I nichtabfangbares Signal (KILL, STOP)→zugeordnete Aktion {Abbruch, Stop} wird ausgeführt

I abfangbares Signal: wenn kein Signalhandler installiert→ Default-Aktion {Abbruch, Stop, Ignorieren} ausgeführt I wenn entsprechenderHandlerinstalliert→Handler wird

(asynchron zur Programmausführung) aufgerufen Anmerkungen:

I abfangbares Signal kann auch ignoriert werden

(26)

Signale in C – Teil 2: Installation eines Signalhandlers

void (*signal(int signum, void (*handler)(int)))(int);

fieses Konstrukt; Analyse:

I signal()ist ein Systemruf I übernimmt 2 Parameter:

I signum– Nummer des Signals, für das ein Handler installiert werden soll

I handler– Zeiger auf eine Funktion, die einen Integer übernimmt und nichts zurückliefert

I Rückgabewert: Zeiger auf eine Funktion, die einen Integer übernimmt und nichts zurückliefert (genauso wie

handler())

26 / 38

(27)

Was bedeutet das?

I Handler ist die Funktion, die angesprungen wird, sobald das entsprechende Signal zugestellt wird

I Parameter des Handlers ist die (konkrete) Nummer des Signals, da es jederzeit möglich ist, einen Handler für verschiedene Signale zu installieren

I Resultat:

I SIG_ERRbei Fehler

I ansonsten Zeiger auf den vorherigen Handler I Anstatt des Handlers kann auch übergeben werden:

I SIG_IGN→Signal soll ignoriert werden I SIG_DFL→Default-Aktion wird eingestellt.

(28)

Beispiel 1: Handler für SIGINT (Ctrl-C)

#include<stdio.h>

#include<stdlib.h>

#include<unistd.h>

#include<signal.h>

longinc = 1;

voidctrl_c_handler (intc) {

inc = ( (inc==1) ? -1 : 1);

return;

}

intmain(void) {

longcount;

sig_t ret;

ret = signal(SIGINT, (sig_t) &ctrl_c_handler);

if(ret == SIG_ERR) { perror("signal");

exit(EXIT_FAILURE);

}

/* output count continuously */

for(count=0; ; count+=inc) { printf("%08li\n", count);

}

exit(EXIT_SUCCESS);

}

(signalhandler.c)

28 / 38

(29)

Weitere Beispiele zu Signalen

I Signal bei Ende eines Kindprozesses:sigchld.c(extern) I Redefinition des Handlers im Handler:catch_ctrl_c.c

(extern)

I Selbstabbruch nach definierter Zeitspanne:alarm.c (extern)

(30)

Zwischenfazit: Signale unter POSIX

4 „klassische“ Funktionen:

I kill() I signal()

I pause()- wartet (passiv) auf ein Signal

I alarm()- definiert eine Zeitspanne, bisSIGALRM zugestellt wird („Der Wecker klingelt.“)

30 / 38

(31)

Nachteile und Unzulänglichkeiten von Signalen

I unzuverlässig

I keine Nutzdatenübertragung I keine Priorisierung

I keine Speicherung (in Warteschlange)

modernere (aber kompliziertere) Signalbehandlung:

sigaction(),sigprocmask()& Co.

(32)

Gemeinsam genutzter Speicher (Shared Memory)

I Idee: Kommunikation über gemeinsamen Speicher I keine implizite Synchronisation (!)

I ohne Adressräume problemlos implementierbar I bei virtuellem Speicher Funktionen des BS nötig:

I Anlegen des Segmentes

I Einblenden in beide Adressräume I (Datenübertragung)

I Ausblenden aus allen Adressräumen I Zerstören des Segments

I Zugriff auf gemeinsam genutzten Speicher über Zeiger, überlagerte Datenstrukturen (→effizient), kein Systemruf nötig

I UNIX:shmget(),shmat(),shmdt(),shmctl() I Segmente sind i.a. persistent (überleben den anlegenden

Prozess)

32 / 38

(33)

Nachrichtenaustausch (Message Passing)

Prinzip

1. Sender konstruiert Nachricht und trägt diese in einen Puffer ein

2. Sender ruft Funktionsend()

3. Nachricht wird durch das System transportiert

4. Empfänger ruft Funktionreceive(), der er einen Puffer übergibt, in den die Nachricht kopiert wird

Analogie: Briefsendung

(34)

Nachrichtenaustausch (Message Passing)

Diskussion

I notwendig, wenn kein gemeinsamer Speicher existiert (z. B. in verteilten Systemen)

I jedoch auch mit gemeinsamem Speicher möglich (z. B. Unix)

I zwei grundlegende Operationen:send(),receive() I synchrone und asynchrone Operation möglich

Beispiele:

I Message Passing Interface (MPI)

I Nachrichtenwarteschlangen POSIX (msgrcv(), msgsnd()usw.)

34 / 38

(35)

Synchroner und asynchroner Nachrichtenaustausch

π₁ π₂

send()

receive()

π₁ π₂ π₁ π₂

Zeit

receive()

send()

receive()

I. II. III.

Abbildung:I./II. – blockierend, III. nichtblockierend (asynchron)

(36)

Kommunikation über Sockets

. . . in der LV „Rechnernetze“

36 / 38

(37)

Was haben wir gelernt?

1. Was sind IPC-Mechanismen?

2. ausführlich kennengelernt:

I Datenaustausch mittels Datei I die „klassische“ Unix-Pipe I Signale (zumindest in der Bash) 3. kurz angerissen

I Shared Memory I Message Passing 4. nicht behandelt

I Sockets I named Pipes

(38)

Testfragen

1. Beschreiben Sie den Ablauf bei der Zustellung eines Signals!

2. Was ist der Unterschied zwischen synchronem und asynchronem Senden beim Message Passing?

3. Entwerfen Sie ein C-Programm, das einen Sohn erzeugt und diesem mittels einer Pipe eine Nachricht zukommen lässt!

4. Welchen Kommunikationsmechanismus würden Sie einsetzen, wenn Sie Daten übertragen müssen und die Teilnehmer nicht verwandt sind?

5. Was ist einpersistenterKommunikationsmechanismus?

38 / 38