PACL-Zusammenfassung/2-2-msg.tex

\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}