Kapitel 3.6-3.7

• Eine Nachricht entsteht logisch dadurch, dass ein Prozess eine Sendeoperation aufruft

• Verbrauchbarkeit: Nachrichten existieren nicht, bevor sie ein Prozess sendet , und sie sind nach ihrem Empfang in der Regel nicht mehr vorhanden

• Ziel der Nachricht (Prozess, Knoten oder Kommunikationskanal)

• Nachrichtennummer zur Identifikation der Nachricht

• Speicherbereich , dessen Inhalt in der Nachricht verschickt werden soll (meist durch Angabe eines Zeigers auf eine Variable, die als Sendepuffer

  dient)

• Anzahl und Datentyp der einzelnen Datenelemente im Sendepuffer, die verschickt werden sollen ( -> Berechnung der konkreten Nachrichtenlänge)

• Sequentialitätsbeziehung: Nachricht kann erst empfangen werden, wenn sie vorher gesendet wurde ( implizite Synchronisation)

Asynchron

• Prozess wird bis zum Empfang der Nachricht nicht blockiert

Synchron

• Sendender Prozess wird so lange blockiert, bis er eine Empfangsbestätigung erhält

Gepuffert

• Inhalt der Nachricht wird aus dem Sendepuffer im Anwenderprogramm in einen Systempuffer kopiert

Ungepuffert

• Inhalt der Nachricht wird sogleich auf das Verbindungsnetz geschickt

• Kein Kopieren notwendig, daher schneller -> häufig verwendet

Nichtblockierend

• Stößt das Verschicken der Nachricht an und gibt die Kontrolle sofort zurück an den nächsten Befehl des sendenden Prozesses

• Nachrichtenversand wird meist von Spezialhardware durchgeführt, welche parallel zum Prozessor arbeiten kann, d.h. Prozess kann schon die nächsten Anweisung ausführen, während die Übertragung einer langen Nachricht noch nicht abgeschlossen ist

• Problem: Unabsichtliches Überschreiben des Sendepuffers, der gerade noch verschickt wird, ist möglich

Blockierend

• Es wird gewartet bis die zu verschickende Nachricht aus dem Sendepuffer vollständig ausgelesen (und damit versendet) ist

Empfangen einer Nachricht

• konsumierend (zerstörend, destructive ) oder

• konservierend (non destructive

Üblicherweise

• Empfangsoperation synchron -> versetzt den sie ausführenden Prozess

• so lange in einen Wartezustand, bis für ihn eine Nachricht eingetroffen ist

Prozess erhält durch Ausführen der Empfangsoperation entweder die Antwort, dass keine Nachricht vorliegt und er fährt dann in seiner Ausführung fort, oder er erhält die Nachricht selbst

• Synchron: Sender und Empfänger verwenden synchrone Sende und Empfangsoperationen

• Asynchron: Mindestens einer der an der Kommunikation beteiligten Sende oder Empfangspartner verwendet eine asynchrone Sende oder Empfangsoperation -> Puffer notwendig

Direkte Benennung

• In einer Kommunikationsanweisung wird der Prozessname zur Bezeichnung von Sender und Empfänger verwendet

Briefkasten

• Ein mehreren Prozessen namentlich bekannter, globaler Speicherplatz , in den diese Prozesse Nachrichten durch Senden ablegen und durch Empfangen wieder herausnehmen können

Port (Pforte)

• Einen Kommunikationskanal, dessen Name wie der eines Briefkastens global bekannt ist, der jedoch an einen bestimmten Prozess gebunden ist

• Nur in ein Kommunikationsrichtung nutzbar i.G.z . Briefkasten

• Ausgangspunkt: Ports werden lokal in Prozessen vereinbart

• Getrennt von den Prozessen wird mit einer connect Anweisung angegeben, wie die Ports miteinander verbunden werden sollen

Bisher datenorientierte Kommunikation, aber auch aktionsorientierte Kommunikation möglich!

• Grundschema einer aktionsorientierten Kommunikation ist Auftraggeber/Auftragnehmer Client/Server --)Modell

  • Auftraggeber ( client ) sendet die Aufforderung zur Diensterbringung, die ein

  • Auftragnehmer ( server ) empfängt

  • Auftragnehmer führt die gewünschte Aktivität durch, währenddessen wartet der Auftraggeber auf eine Rückmeldung

  • Auftragnehmer sendet die Rückmeldung, gegebenenfalls zusammen mit errechneten Daten, sobald er den Dienst erbracht hat

  • Dann kann der Auftraggeber weiterarbeiten

Ausführender Prozess hat ebenfalls Einfluss, welche Prozedur er aufruft Wenn beide Prozesse bereit sind, treffen sie sich zur Ausführung einer Prozedur; danach gehen sie wieder getrennte Weg

Parallele Programmstruktur

• Von der parallelen Programmiersprache oder der parallelen Programmierschnittstelle vorgegebene Programmschemata

• Programmschemata bedingen zur Laufzeit jeweils auch die (dynamische) Ablaufstruktur

Beispiel Programmstruktur:

Zu Beginn eines parallelen Codeteils werden entsprechend viele fork Operationen durchgeführt, um die parallelen Threads T2 bis T_n zu erzeugen

• Diese arbeiten unabhängig weiter und erreichen an ihrem Ende eine join Operation zur Synchronisation mit T 1 und Terminierung des Threads

Nachteil

• Bedarf Aufwand zur Erzeugung der Threads

• Vermeidung des Aufwandes zur Erzeugung der Threads

• Nur einmal beim Programmstart werden entsprechend viele

• Kontrollfäden/Prozess erzeugt und terminieren alle gemeinsam am Ende des Programmlaufs.

• Sequentielle Codeteile werden von allen Prozessen ausgeführt

• Jeder Prozess führt einen eigenen parallelen Programmteil aus

Verknüpfung von fork join und SPMD

• Vermeidung des hohen Aufwands zur mehrfachen Generierung und Zerstörung von Kontrollfäden bei fork join

• Unterbinden des mehrfachen, untätige Abarbeitens von sequentiellem Code bei SPMD

Neue Kontrollfäden werde erzeugt, wenn sie das erste Mal benötigt werden

• Am Ende paralleler Codeteile werden Kontrollfäden in „ idle “ versetzt -> sequentieller Code wird nur einmal ausgeführt