Betriebssysteme I WS 2017/18. Prof. Dr. Dirk Müller. 10 Kommunikation

Transkript

1 Betriebssysteme I 10 Kommunikation WS 2017/18 Prof. Dr. Dirk Müller

2 WS 2017/18 2/35 Überblick Einführung Klassifikation Kommunikation über eine Datei Kommunikation über eine Pipe Synchronisation durch Signale ausgewählte weitere Ansätze Zusammenfassung

3 WS 2017/18 3/35 Einführung Def.: Kommunikation ist die Übertragung von Daten zwischen Aktivitäten. meist mit Synchronisation (zeitlicher Koordination) Fachbegriff: Interprozesskommunikation (engl. interprocess communication, IPC) viele verschiedene Mechanismen, historisch gewachsen Teilnehmer (mindestens zwei Aktivitäten) benötigen gemeinsam genutzte Ressource Identifikation (Teilnehmer ist da und lebt) bzw. Authentisierung (Nachrichten stammen von diesem Teilnehmer und wurden nicht verändert) der Teilnehmer erforderlich

4 WS 2017/18 4/35 Dateien, Signale, Pipes Sockets, Mailslots Beispiele gemeinsam genutzter Speicher (Shared Memory) Nachrichten, Mailboxen speichereingeblendete Dateien (Memory-mapped File) Semaphore entfernter Prozeduraufruf (Remote Procedure Call, RPC) Clipboard dynamischer Datenaustausch (Dynamic Data Exchange, DDE) Component Object Model (COM)

5 WS 2017/18 5/35 Fragen zur Einteilung und Ziele nur lokal oder verteilt homogen oder heterogen bzgl. der beteiligten Betriebssysteme explizite Auswahl der Teilnehmer durch die Nutzer der Aktivitäten oder implizite Auswahl durch die Aktivitäten selbst allgemein oder spezifisch bzgl. der unterstützten Anwendungen (z. B. Copy & Paste als sehr allgemeine Form) zeitkritisch oder nicht (Overhead) GUI- oder Konsolenanwendung Quelle: [1]

6 WS 2017/18 6/35 Klassifikation Interprozesskommunikation (IPC) Synchronisation Kommunikation speicherbasiert strombasiert nachrichtenbasiert Semaphore Mutexe Monitore Signale Shared Memory Dateien Pipes Stream Sockets Message Passing Message Queues Datagram Sockets

7 WS 2017/18 7/35 Kommunikationsbeziehungen Anzahl der Teilnehmer auf Sender- und Empfängerseite 1-zu-1 1-zu-m n-zu-1 n-zu-m Richtung (Gleichzeitigkeit von Hin- und Rückkanal) unidirektional bidirektional weitere Aspekte lokale vs. entfernte Kommunikation direkte vs. indirekte Kommunikation synchrone vs. asynchrone Kommunikation

8 WS 2017/18 8/35 Synchrone und asynchrone Kommunikation Sendeoperation (send) synchron: Der Sender wartet (blockiert), bis der Empfänger das Datum entgegengenommen hat (implizite Quittung). asynchron: Der Sender setzt nach dem Senden einer Nachricht sofort seine Arbeit fort ( No-Wait-Send, Fire and Forget ). Beispiel: Telegramm Empfangsoperation (receive) synchron: Die Empfangsoperation blockiert den Empfänger so lange, bis das Datum eintrifft. blocking read, synchronous receive asynchron: Der Empfänger liest das Datum, falls etwas empfangen wurde und arbeitet anschließend weiter, auch wenn nichts empfangen wurde. non-blocking read, asynchronous receive beide Seiten synchron: Rendezvous

9 WS 2017/18 9/35 Synchrone vs. asynchrone Operationen synchrone Operationen direkte Zustellung der Daten (ohne Zwischenspeicher) implizite Empfangsbestätigung i. Allg. einfacher zu programmieren standardmäßig arbeiten Kommunikationsoperationen in UNIX/Linux synchron asynchrone Operationen Daten müssen zwischengespeichert werden Vorteil: wenn ein kommunizierender Prozess abbricht, dann wird der Partner nicht unendlich blockiert kein Deadlock (gegenseitige Blockierung infolge fehlerhafter Programmierung) möglich Benachrichtigung des Empfängers u. U. kompliziert; explizite Bestätigung (Acknowledgment) nötig

10 WS 2017/18 10/35 Verbindungsorientierte und verbindungslose Kommunikation verbindungslos nur 1 Phase: Datenübertragung z. B.: Telegramm, User Datagram Protocol (UDP), Internet Protocol (IP), Signal verbindungsorientiert 3 Phasen Aufbau der Verbindung Datenübertragung Abbau der Verbindung Beispiele (analoges) Telefon Transmission Control Protocol (TCP) Pipe

11 WS 2017/18 11/35 Verbindungsarten Unicast 1-zu-1-, also Punkt-zu-Punkt-Verbindung Direktverbindung genau 2 Teilnehmer Multicast 1-zu-m-Verbindung genau 1 Sender mehrere Empfänger, aber nicht alle: Gruppenruf Broadcast 1-zu-m-Verbindung genau 1 Sender alle Empfänger, z. B. eines Subnetzes

12 WS 2017/18 12/35 Kommunikation über eine Datei ältester IPC-Mechanismus Sender schreibt Daten in Datei Empfänger liest Daten aus Datei nachteilig: zweimaliger Zugriff auf Massenspeicher Aber es gibt auch Dateisysteme im RAM. nachteilig: überlappender Zugriff durch Sender und Empfänger, also Synchronisation nötig Lösung: Sperren der Datei (file locking), z. B. mittels lockf() als Schnittstelle zu fcntl() Problem: Sperren setzt Wohlverhalten voraus Gefahr des Aussperrens anderer Interessenten

13 Kommunikation über eine Pipe ( Röhre ) int pipe(int filedes[2]); liefert Feld von zwei Dateideskriptoren zurück (jeweils einer zum Lesen und zum Schreiben) Zugriff wie auf eine Datei: read(), write(), close() kein open(): implizit in pipe() mit enthalten kein lseek(): führt zur Fehlermeldung ESPIPE fd is associated with a pipe, socket, or FIFO. Kommunikationskanal: Byte-Strom kein Konzept von Nachrichtengrenzen Datenübertragung innerhalb eines Prozesses sinnlos?! Woher weiß der Empfänger, dass die Pipe existiert? benannte Pipe aka FIFO (First In First Out) mkfifo() und open() statt pipe() Dirk Müller: Betriebssysteme I WS 2017/18 13/35

14 WS 2017/18 14/35 Erstellung einer Pipe close() close()

15 Eigenschaften einer Pipe unter Linux stets unidirektional für bidirektionale Übertragung unter Linux zwei Pipes nötig manche Systeme unterstützen bidirektionale Pipes, aber kein Verlass darauf (Portabilität, POSIX verlangt nur unidirektionale) keine Synchronisation beim Schreiben Daten werden im Kern gepuffert Schreiboperationen, die weniger als PIPE_BUF (aktuell 4096 B unter Linux, vgl. /usr/include/limits.h) Daten umfassen, müssen atomar erfolgen. Kapazität früher 4096 B, seit sogar B seit Standardgröße 64 KB, flexibel bis 1 MB keine persistente Ressource, verschwindet nach dem letzten close() nur zwischen verwandten Prozessen möglich aber: benannte Pipe (FIFO) zwischen beliebigen Prozessen Dirk Müller: Betriebssysteme I WS 2017/18 15/35

16 Pipe: problematische Situationen Lesen von einer eröffneten Pipe, die keine Daten enthält, blockiert. Wird danach die Schreibseite geschlossen, kehrt read() mit dem Resultat 0 zurück. Leseoperation aus Pipe mit ungültigem Dateideskriptor liefert Fehler: EBADF fd is not a valid file descriptor or is not open for reading. Leseoperation aus Pipe, die nach Schreibvorgang geschlossen wurde: liefert zunächst Daten, dann 0 als Resultat, also EOF Schreiboperation auf Pipe, deren Leseseite geschlossen ist, liefert Signal SIGPIPE an den schreibenden Prozess Prozess(e) enden mit eröffneter Pipe: Dateideskriptoren werden bei Prozessbeendigung automatisch geschlossen Dirk Müller: Betriebssysteme I WS 2017/18 16/35

17 WS 2017/18 17/35 Anwendung: Pipe-Operator in der Shell Syntax: <Sender> <Empfänger> häufig Leerzeichen davor und danach zur besseren Lesbarkeit Semantik: Verknüpfung der stdout des Senders mit der stdin des Empfängers Beispiel ls -la head -n10 zeigt die (alphabetisch, da Std.-Sortierung bei ls) ersten 7 Dateien im akt. Verzeichnis an (und insgesamt <Blöcke>,. und..) äquivalente IPC über eine (temporäre) Datei ls -la > mytmp head -n10 < mytmp rm mytmp Löschen der temporären Datei als Abschluss head -n10 mytmp würde auch funktionieren eigentlich vorher noch Test auf Existenz der Datei, um nichts zu überschreiben

18 Signale einfaches Mittel zur Synchronisation zwischen Prozessen bzw. BS und Prozessen Übermittlung einer Ganzzahl, ohne dass ein Prozess aktiv beteiligt ist (Betriebssystem als Postbote) typische verfügbare Anzahl: 32 oder 64 in etwa als ein Software-Interrupt anzusehen auf der BS-Kernel-Ebene, nicht auf der CPU-Ebene Generierung Zustellung Behandlung jedes Signal mit Nummer, Name, Default-Aktion nur symbolischer Wert (Name) sichert Portabilität Liste mittels kill -l anzeigen lassen meist (aber nicht immer) keine Nutzdatenübertragung Verwandtschaft der Partner ist nicht nötig, aber Rechte Dirk Müller: Betriebssysteme I WS 2017/18 18/35

19 WS 2017/18 19/35 Signale: Prinzipieller Ablauf 1. Sende-Prozess generiert ein Signal 2. System stellt das Signal dem Empfänger-Prozess zu 3. falls Empfänger Signalhandler installiert hat: Aufruf des Signalhandlers (asynchron zur Programmausführung) 4. falls kein Signalhandler installiert: Ausführung der Default-Aktion

20 WS 2017/18 20/35 Default-Aktionen Term Abbruch des Prozesses Ign Ignorieren des Signals Core Abbruch des Prozesses und schreiben eines Coredumps (Speicherauszugs) auf die Festplatte Stop Anhalten des Prozesses Cont Fortsetzen des Prozesses nachdem er angehalten wurde Quelle: [2]

21 POSIX-Signale (Auswahl) Name Wert Default-Aktion Semantik bzw. Trigger SIGHUP 1 Abbruch Beenden aller Proz. im Terminal (Hangup) SIGINT 2 Abbruch <Ctrl>+<C> SIGILL 4 Coredump illegale Instruktion SIGKILL 9 Abbruch sofortiges (unsauberes) Beenden SIGSEGV 11 Coredump Segmentierungsfehler SIGPIPE 13 Abbruch Schreiben in eine ungeöffnete Pipe SIGTERM 15 Abbruch sauberes Beenden SIGCHLD 20,17,18 Ignorieren Statusänderung eines Sohn-Prozesses SIGSTOP 17,19,23 Stopp Anhalten des Prozesses SIGTSTP 18,20,24 Stopp <Ctrl>+<Z> SIGCONT 19,18,25 Fortsetzen Fortsetzen eines angehaltenen Prozesses Quelle: [2] Dirk Müller: Betriebssysteme I WS 2017/18 21/35

22 WS 2017/18 22/35 Senden von Signalen: von der Kommandozeile und per Tastatur Bash-Beispiele kill -9 $$ Selbstmord kill -9 $! Kindermord SIGTERM wird bei fehlender Angabe eines Signals angenommen Tastatur SIGINT <Ctrl>+<C> SIGQUIT <Ctrl>+<4> oder <Ctrl>+<\> SIGTSTP <Ctrl>+<Z>

23 WS 2017/18 23/35 signalhandler.sh #!/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 nichts anhaben."' SIGQUIT echo "Entering loop" while true do echo -n done exit 0 Handler wird asynchron angesprungen, ausgeführt, und es wird am Unterbrechungspunkt fortgesetzt. Handler darf nur (externe) Kommandos enthalten, keine Bash-Instruktionen.

24 WS 2017/18 24/35 Signale in C: Senden und Auslösen #include <signal.h> int kill(pid_t pid, int sig); Senden eines Signals an einen Prozess vor dem Senden Prüfung, ob Rechte für die Signalübermittlung vorliegen Spezifikation des Signals über Name oder Nummer pid == -1 bedeutet, dass das Signal an alle Prozesse geschickt wird, für die der Benutzer das entsprechende Recht hat. Vorsicht! künstliche Signalauslösung im eigenen Prozess raise(sig); als Kurzform für kill(getpid(), sig); kill(-1, 9) ist zwar kurz, aber gefährlich.

25 WS 2017/18 25/35 Behandlung eines Signals beim Empfänger nichtabfangbares Signal (SIGKILL, SIGSTOP) Die zugeordnete Aktion, also Abbruch bzw. Stopp, wird ausgeführt. abfangbares Signal: falls kein Signalhandler installiert: zugeordnete Default-Aktion aus der Menge {Abbruch, Stopp, Ignorieren, Coredump, Fortsetzen} ausführen falls entsprechender Handler installiert: Handler wird (asynchron zur Programmausführung) aufgerufen. Anmerkung Ein abfangbares Signal kann auch ignoriert werden, entspricht dann einem leeren Handler.

26 WS 2017/18 26/35 Signale in C: Handler installieren #include <signal.h> typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler); Signal und Handler werden (als Funktionszeiger) übergeben anstelle eines konkreten Handlers auch möglich SIG_IGN Signal wird ignoriert SIG_DFL Default-Aktion wird (wieder) eingerichtet Rückgabe SIG_ERR im Fehlerfall ansonsten Zeiger auf den Handler SIGKILL und SIGSTOP nicht abfangbar, Verhalten bleibt also immer bei entsprechender Default-Aktion

27 signalhandler.c #include <signal.h> #include <stdio.h> #include <stdlib.h> long inc = 1; static void ctrl_c_handler(int c) { inc *= -1; } Trigger ist <Ctrl>+<C> auf der Tastatur, da das Signal SIGINT abgefangen wird. sehr kurzer Handler int main() { long count; } if (signal(sigint, ctrl_c_handler) == SIG_ERR) { perror("signal"); exit(exit_failure); } // output count continuously for (count=0;;count+=inc) { printf("%08li\n", count); } return EXIT_SUCCESS; ändert nur das Vorzeichen des Inkrements Wechsel zwischen Inkrement und Dekrement Effekt: Wechsel zwischen Hoch- und Runterzählen Dirk Müller: Betriebssysteme I WS 2017/18 27/35

28 #include <signal.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> static void alarm_handler(int c) { printf("alarm!\n"); } alarm() und pause() int main() { if (signal(sigalrm, alarm_handler) == SIG_ERR) { perror("signal"); exit(exit_failure); } alarm(10); pause(); return EXIT_SUCCESS; } Merke: Erst Wecker stellen, dann sich schlafen legen! #include <unistd.h> unsigned int alarm(unsigned int seconds); int pause(void); alarm() stellt Kurzzeitwecker so, dass er in seconds s das Signal SIGALRM im Prozess auslöst. pause() kehrt erst zurück, wenn Signal empfangen. Dirk Müller: Betriebssysteme I WS 2017/18 28/35

29 Timing-Problem mit traditionellen Signalen (Race Condition) #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> int flag = 0; static void handler(int c) { flag = 1; } int main() { signal(sigint, handler); while (flag == 0) { } raise(sigint); pause(); <Ctrl>+<C> simuliert printf("flag = %d\n", flag); return EXIT_SUCCESS; Ziel: Signal soll ignoriert, aber mittels flag protokolliert werden läuft fast immer korrekt bei Signalzustellung nach (flag == 0), aber vor pause(): Warten auf weiteres Signal => verlorenes Signal! Grund: nicht atomar sigsuspend() nutzen! Quellen: } [2][3][4] trotzdem nicht erreicht Dirk Müller: Betriebssysteme I WS 2017/18 29/35

30 WS 2017/18 30/35 Nachteile traditioneller Signale unzuverlässig, auch die neueren POSIX reliable signals bei Einrichtung mit signal() können verloren gehen (Timing-Probleme) können nicht verzögert (blockiert) werden also keine vollständige Kontrolle keine Nutzdatenübertragung keine Priorisierung keine Speicherung (in Warteschlangen) POSIX real-time signals können dies alles. modernere, aber kompliziertere Signalbehandlung mit sigaction(), sigprocmask(), sigsuspend(), sigqueue() etc. Quellen: [2][3]

31 Gemeinsam genutzter Speicher (Shared Memory) Idee: Kommunikation über gemeinsamen Speicher keine implizite Synchronisation (!) ohne Adressräume problemlos implementierbar bei virtuellem Speicher Funktionen des BS nötig Anlegen des Segmentes Einblenden in beide Adressräume (Datenübertragung) Ausblenden aus allen Adressräumen Zerstören des Segments Zugriff auf gemeinsam genutzten Speicher über Zeiger und überlagerte Datenstrukturen (=> effizient) kein Systemruf nötig UNIX: shmget(), shmat(), shmdt(), shmctl(), ipcrm() Segmente i. d. R. persistent (überleben den Prozess) Dirk Müller: Betriebssysteme I WS 2017/18 31/35

32 WS 2017/18 32/35 Nachrichtenaustausch (Message Passing) Prinzip 1. Sender konstruiert Nachricht und trägt diese in einen Puffer ein 2. Sender ruft Funktion send() 3. Nachricht wird durch das System transportiert 4. Empfänger ruft Funktion receive(), der er einen Puffer übergibt, in den die Nachricht kopiert wird Analogie: Briefsendung

33 WS 2017/18 33/35 Nachrichtenaustausch (Message Passing) Diskussion notwendig, wenn kein gemeinsamer Speicher existiert (z. B. in verteilten Systemen) jedoch auch mit gemeinsamem Speicher möglich (z. B. lokal unter UNIX/Linux) zwei grundlegende Operationen: send(), receive() synchrone und asynchrone Operation möglich Beispiele Message Passing Interface (MPI) Nachrichtenwarteschlangen POSIX: msgrcv(), msgsnd() etc. Mailboxes Mailslots

34 WS 2017/18 34/35 Zusammenfassung Kommunikation als Übertragung von Daten zwischen Aktivitäten, meist mit Synchronisation verbunden Dateien speicherbasiert: einfach, aber langsam und Synchronisation mittels Sperren nötig, Wohlverhalten nötig Pipes strombasiert: schnell und flexibel, atomares Schreiben möglich; nur zwischen verwandten Prozessen Signale zur Synchronisation Verwandtschaft nicht nötig, aber Rechte müssen vorliegen in traditioneller Form keine Nutzdaten in traditioneller Form mit signal() unzuverlässig auch Zeitsignale (Wecker) mit alarm() und pause() möglich fast alle Signale (außer SIGKILL und SIGSTOP) abfangbar Handler über das Setzen von Funktionspointern einzurichten

35 WS 2017/18 35/35 Literatur [1] Microsoft MSDN, > Develop > Desktop technologies > System Services > Interprocess Communications (Windows), 2016, Download am , [2] SIGNAL(7), Linux Programmer's Manual, Download am , [3] Baris Simsek: Signale, 2005, Download am , [4] Damian Pietras: Linux Programming Blog, All about Linux signals, , Download am ,