diff --git a/2-2-msg.tex b/2-2-msg.tex index dc93358..f330e65 100644 --- a/2-2-msg.tex +++ b/2-2-msg.tex @@ -1 +1,101 @@ -\subsection{Message Passing} \ No newline at end of file +\subsection{Nachrichtengekoppelte Programmiermodelle (Message Passing)} +\subsubsection{Klassiches Send/Receive} +\begin{itemize} + \item explizite Kommunikationsaufrufe auf beiden Seiten notwendig + \item synchron und asynchron möglich + \item Ablauf: \begin{enumerate} + \item Sender $\rightarrow$ Empfänger: Sendewunsch mit Länge der Nachricht + \item Empfänger $\rightarrow$ Sender: Empfangsbereitschaft + \item Sender $\rightarrow$ Empfänger: Daten + \item Empfänger $\rightarrow$ Sender: Empfangsbestätigung(en) + \end{enumerate} + \item bei synchroner Variante keine Überlappung von Kommunikation und Berechnung möglich + \item Adressierung beim Sender: Knoten, Port, Prozess + \item Pufferung beim Sender für Daten bis zum ersten Aufruf von \texttt{receive} + \item Flusskontrolle zur Verhinderung des Überlaufens der Empfangspuffer + \item Empfänger blockiert in der Regel, aber auch \texttt{poll} implementierbar + \item Warten auf bestimmte Sender/Pakettypen auf Empfängerseite +\end{itemize} +\subsubsection{erweitertes Send/Receive} +\begin{itemize} + \item Modell einer virtuellen Maschine aus logischen Knoten + \item Unterstützung von Gruppenoperationen wie \texttt{broadcast}, Barrieren, Verteilen und Einsammeln von Daten an alle Knoten oder kleinere Knotengruppen +\end{itemize} +\subsubsection[Shared Memory]{(virtueller) gemeinsamer Speicher (Shared Memory [SHM])} +\begin{itemize} + \item implizite Kommunikationsaufrufe auf Senderseite ausreichend + \item anderweitige Synchronisation in Anwendung für geordnete und konsistente Zugriffe notwendig + \item empfängerseitig müssen Threads zur Zugriffsbearbeitung vorgehalten werden + \item evtl. Pufferung für eingehende Zugriffe bei Sperre notwendig + \item Cache-Konsistenz-Protokoll elementar für Performance und Komfort +\end{itemize} +\subsubsection[Remote Procedure Call]{Methodenfernaufruf (Remote Procedure Call [RPC])} +\begin{itemize} + \item explizite Kommunikationsaufrufe auf Senderseite notwendig + \item synchron und asynchron möglich + \item häufig nur Beschreibung der Schnittstelle, Compiler generiert dann Code für Aufrufer und Aufgerufenen + \item empfängerseitig müssen Threads zur Ausführung der übergebenen Funktion vorgehalten werden + \item Versenden von Pointern nur durch spezielle Maßnahmen möglich + \item in Java häufig \begriff{Remote Method Invocation} (RMI): \begin{itemize} + \item Proxy-Objekte für objektorientierte Programmiersprachen notwendig: \begin{itemize} + \item Aufrufer verwendet \begriff{Stub}, der Aufrufe weiterleitet + \item Aufgerufener stellt \begriff{Skeleton}, das Aufrufe annimmt und jeweilige Implementierungen aufruft, bereit + \item Umsetzung durch Markierung der Ursprungsklassen + \item Namensauflösung durch \texttt{rmiregistry}-Hintergrundprozess + \end{itemize} + \item Serialisierung und Kodierung der Funktionsargumente und -rückgabewerte notwendig: \begin{itemize} + \item primitive Datentypen: Bit/Byte-Repräsentation + \item entfernte Objekte: Erzeugung passender Stub-Instanzen + \item serialisierbare Objekte (durch \enquote{Implementierung} des Marker-Interfaces \texttt{Serializable}): \enquote{call-by-value} mit Kopien + \item sonstiges: Fehler + \end{itemize} + \item Auch Serialisierung von Typinformationen notwendig: \begin{itemize} + \item Übertragung des einer Klasse zugrundeliegenden Bytecodes + \end{itemize} + \item besonderer Aufwand bei Serialisierung von Objektgraphen: \begin{itemize} + \item rekursive, \begriff{tiefe Kopie} des gesamten Graphen + \item Vergebung eindeutiger Objekt-IDs zur Vermeidung von Endlosrekursion bei Zyklen notwendig + \end{itemize} + \item Probleme bei maschinenübergreifender Synchronisation mit Sprachprimitiven (\texttt{synchronized}) durch Wechsel der Prozessidentität + \item Speicherbereinigung: \begin{itemize} + \item Bedingungen für Bereinigung: kein lokaler Zeiger sowie keine Remote-Zeiger mehr auf das Objekt vorhanden + \item Verwendung von \texttt{WeakReferences} durch \texttt{rmiregistry}: Garbage Collector kann Objekte, die ausschließlich über \texttt{WeakReference}s erreichbar sind, entsorgen + \item Verwendung von \text{finalize()} auf Aufruferseite: Bei Entfernung des Objekts durch den GC wird \enquote{unreferenced}-Nachricht an den Server geschickt + \item periodische \enquote{Keep Alive}-Nachrichten an Server, damit Remote-Objekt weiterhin als referenziert gezählt wird + \end{itemize} + \item Performance bei häufiger Kommunikation mangelhaft durch schwergewichtiges Protokoll und teures Serialisieren + \end{itemize} + \item \begriff{Common Object Request Broker Architecture} (CORBA): \begin{itemize} + \item standardisierte, sprachunabhängige \begriff{Interface Definition Language} + \item \begriff{Object Request Broker} als Netzwerk/Leitungsprotokoll + \item Bereitstellung eines Namensdienstes + \end{itemize} +\end{itemize} +\subsubsection{Active Messages} +\begin{itemize} + \item explizite, einseitige Kommunikationsaufrufe notwendig + \item Paketheader enthält Adresse/Index der für den Paketinhalt auszuführenden Behandlungsfunktion + \item vergleichbar mit Signalen + \item Behandlungsroutine liest Paketdaten aus dem Netzwerk und fügt sie direkt in die Datenstrukturen der Anwendung ein + \item Empfängerseite muss gegen Unterbrechung durch Behandlungsfunktion synchronisieren + \item zweiter Ansatz mit erweitertem Modell: \begin{itemize} + \item Quittierung der Aufrufe wie bei RPC + \item nur ein Prozess kann zu einer Zeit in einem Knoten kommunizieren + \item mehrprozessfähig + \item markenbasierte Flusskontrolle + \item Datentransfer durch \begriff{Programmed Input/Output} (PIO) und \begriff{Direct Memory Access} (DMA) + \item Behebung von Netzwerkfehlern durch Behaltung einer Kopie der Daten auf Senderseite bis erfolgreiche quittiert wurde + \item dynamische Wegewahl bei Topologie-Änderung (\enquote{Source Routing}) + \end{itemize} + \item hohe Performance durch \begin{itemize} + \item Zero-Copy: Mapping der Sende- und Empfangspuffer in Adressbereich der Anwendung, Netzwerkkarte liest direkt + \item weitgehende Eliminations von OS-Overhead + \end{itemize} +\end{itemize} +\subsubsection{Bulk Synchronous Parallel} +\begin{itemize} + \item Gliederung eines Programmes in \begriff{Supersteps}, in denen jeder Knoten unabhängig rechnet und Kommunikation anstößt, durch Synchronisationsbarrieren + \item Empfang wird bei Ende eines Supersteps garantiert + \item Effizienz des Synchronisationsmechanismus wichtig: z.B. per Baum + \item Größe der Supersteps wichtig +\end{itemize}