102 lines
6.4 KiB
TeX
102 lines
6.4 KiB
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 Behalten einer Kopie der Daten auf Senderseite bis erfolgreich 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 und schreibt direkt per DMA
|
|
\item weitgehende Elimination 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}
|