04_Prozesskommunikation

Question 1

Kommunikation

Erzeuger-Verbraucher-Problem

Answer 1

• 1 Programm produziert Daten -> von anderen Programm weiterverarbeitet (verbraucht) -> Speicher für diese Daten nur temporär -> keine Probleme, wenn beide gleich schnell arbeiten
• Probleme, weil Laufzeit nicht vorhersehbar:
  
  • Erzeuger produziert langsamer als Verbraucher verarbeitet
  • Erzeuger produziert schneller, als Verbraucher verarbeiten kann
• Empfänger hält Daten nur so lange vor, bis an Verbraucher übergeben -> genutzten Speicher für nächste Daten verwenden
• Verbraucher hat Empfangspuffer, um empfangene Daten zwischen zu speichern
  
  • leerer Puffer: Empfänger muss warten (busy waiting, polling) oder blockiert werden (sleep waiting
• Problem der Datenkonsistenz: sind empfangene Daten korrekt/vollständig? -> von Korrektheit ausgegangen, Vollständigkeit durch Mechanismen

Question 2

Prozesskommunikation

Kommunikationsmöglichkeiten

Answer 2

• Pipes
• Message Queues
• Shares Memory
• (Semaphore - Koordination, kein Nachrichtenaustausch)
• Signale (Prozess nicht explizit auf Nachricht wartend)

Question 3

Prozesskommunikation

Pipes

Answer 3

• Kommunikationskanal zwischen Prozessen
• Systempuffer, in den eine Anwendung wie in eine Datei etwas hineinschreiben kann, bis vorgegebener Füllgrad erreicht ist
• Zweck: weiterer Prozess kann lesend öffnen und versuchen, aus Pipe zu lesen
  
  • Pipe voll: Prozess A1 im Aufruf angehalten (wie bei Systemaufruf)
  • Pipe leer: lesende Prozess A2 auf Leseaufruf angehalten
  • wieder Platz: Schreibprozess wird fortgesetzt
• Prozesse sind synchronisiert, ohne Rechnerzeit zu belasten
• unstrukturierter Datenstrom: Anwendungen müssen selbst für Vollständigkeit sorgen
  
  • unstrukturiert: so viel Bytes wie ich will, so oft wie ich will

Question 4

Prozesskommunikation

Unnamed + Named Pipes

Answer 4

Unnamed Pipes

• bei eng verwandten Prozessen (Vererbung)
• mit fork() erzeugte Prozesse erben alle Ressourcen des Vaters -> auch offene Dateien
• Vater erzeugt mit pipe() eine unnamed Pipe mit 2 Dateideskriptoren -> 1 Lesen + 1 Schreiben
• Nutzung: Schreiber (z.B. Vater) liest Lesedeskriptor, Leser (Sohn) schließt Schreibdeskriptor

Named Pipes

• Pseudodatei mit Namen im Dateisystem
• für Prozesse ohne enges Verwandtschaftsverhältnis (keine gemeinsamen Ressourcen)
• kann von allen mit nötigen Rechten lesend und schreibend benutzt werden
• Nutzung durch >2 Prozesse möglich

Question 5

Prozesskommunikation

Message Queues

Answer 5

• strukturiert: Nachricht statt Datenstrom (festes Ende + feste Länge)
• mit einem Aufruf geschrieben und mit einem Aufruf gelesen -> als Ganzes!
• Nachrichten variabler Länge, die vom Sender bestimmt wird
• im BS gesendet
• in Warteschalnge in Reihenfolge des Eintreffens sortiert
• Typ-Kennung: Empfänger kann Nachrichten eines bestimmten Typs beim Lesen herausfiltern
• Benutzung durch mehrere Prozesse möglich

Question 6

Prozesskommunikation

Shared Memory

Answer 6

• durch virtuelle Adressierung
• durch Systemaufrufe in PT eines Prozesses teilweise selbe Seitennummern (real page) wie bei anderen Prozess eintragen -> bei Zugriff auch physikalisch selbe Adressen im Hauptspeicher angesprochen
• Situation wie bei Threads! (Race Conditions) -> Zugriff muss koordiniert werden

Question 7

Prozesskommunikation(-Koordination)

Semaphore

Answer 7

• wenn Prozesse sich um begrenzte Ressourcen bewerben
• Zähler im Kernel (üblicherweise mit 0 belegt)
• Aufruf von Prozess -> Zähler dekrementiert + Prozess als Inhaber des Semaphors gekennzeichnet
• Wert <0: Semaphore ist belegt
  
  • aufrufender Prozess wird auf wartend gesetzt
• Abgabe des Semaphors: Zähler inkrementiert
  
  • nächste wartende Prozess des Semaphor wird bereit gesetzt und Besitz des Semaphor übertragen
• alle Prozesse, die Semaphor (= Zugriff auf Betriebsmittel) wollen, erhalten der Reihe nach Besitz dieser Ressource
• Semaphore mit Initialisierung mit 1: gegenseitiger Ausschluss (mutex = mutual exclusion) -> max. 1 Thread o. Prozess sollte sich aufhalten, um Race-Conditions zu vermeiden

Question 8

Prozesskommunikation

Signale

Answer 8

• Problem: wenn Prozess nicht explizit auf Nachricht wartet, erreicht ihn auch keine -> bei fehlerhaften Programmzweig nicht abrupt Beenden sondern wichtige Daten noch speichern
• Lösung: Signale = synchrone oder asynchrone Ereignisse
  
  • von außen oder aus dem Prozess selbst heraus ausgelöst
  • bewirken Unterbrechung auf Prozessebene
  • Softwaredarstellung von Hardwarefunktionen
• Prozess verhält sich wie bei Abarbeitung einer Interruptroutine -> in eigenem Adressraum

Question 9

Prozesskommunikation

Signale: Beispiele

Answer 9

• ctrl-c = SIGINT = meist Abbruch des Prozesses (asynchron = kann jederzeit gesendet werden)
• Division durch 0: Hardwareinterrupt durch CPU -> Exception an BS -> Anwendung angehalten durch Exception = SIGFPE („Signal Floating Point Exception“ - synchron zum Divisionsbefehl)

Question 10

Prozesskommunikation

Realisierung des Signalempfangs

Answer 10

• Bibliotheken u.a. zur Signalbehandlung im Anwendungscode
• Routinen im Adressraum des Empfängers lokalisiert -> von BS aufgerufen bevor Prozess fortgeführt wird
• Prozess angehalten im normalen Ablauf seines Codes + Routine außerhalb dieses Normalablaufs ausgeführt
• Prozess kann, selbst wenn er fehlerhaft abläuft, dennoch geöffnete Dateien sichern und schließen und sich danach erst geordnet selbst beendet

Question 11

Prozesskommunikation

auffangbare und nicht auffangbare Signale

Answer 11

Signal maskieren = keinen Handler installieren, BS soll Signal verwerfen/ignorieren