Verteilte Simulation: Synchronisationsmechanismen

Transkript

1 Seminar Rechnernetze WS 04/05 Prof. Dr. Peter Martini Verteilte Simulation: Synchronisationsmechanismen von Daniel Schaefer Matr.-Nr Seite 1 von 17

2 Inhalt 1. Einführung..S Diskrete Ereignisgesteuerte Simulation...S Verteilte Simulation.S Synchronisationsmechanismen. S Konservative Mechanismen.S Deadlock-Vermeidung durch Null-Nachrichten...S Deadlock-Erkennung und Wiederherstellung...S Synchrone Ausführung mittels Barrieren.. S Konservativer Zeitfenster-Algorithmus.S Optimistische Mechanismen... S Time Warp. S Lazy Cancellation.. S Lazy Reevaluation. S Optimistische Zeit-Fenster.S Wolf Calls.. S Zusammenfassung..S. 16 Seite 2 von 17

3 1. Einführung Mit einer Simulation wird versucht, das Verhalten eines Systems über einen Zeitraum hinweg anhand von Modellen auf einer Rechneranlage nachzubilden. Das simulierte System wird auch physikalisches System genannt. Bei der Simulation hängt die Anwendbarkeit der Ergebnisse auf die Wirklichkeit stark von der Qualität der Modelle ab. Um eine Simulation durchführen zu können, benötigt man neben einer simulationsspezifischen Zeit auch Status-Variablen, die den Systemzustand beschreiben und Methoden, um den Status verändern zu können. Die Zeiten werden unterschieden zwischen der Simulationszeit, die angibt, welche Zeitspanne des physikalischen Systems simuliert werden soll, und der Rechenzeit, die die eigentliche Ausführungszeit der Simulation angibt. Der Fortschritt der Simulationszeit muss nicht zwangsweise identisch sein mit dem Fortschritt der Rechenzeit ( wall-clock time ). Wenn z.b. ein Arbeitstag an einem Flughafen simuliert werden soll, also die Simulationszeit ein Tag beträgt, so kann dies durchaus in weniger als 24 Stunden geschehen. Man unterscheidet hier zwischen drei Varianten: Bei der real-time execution ist die Simulationszeit identisch mit der Rechenzeit, während bei der scaled real time die Simulationszeit um einen bestimmten Faktor langsamer oder schneller abläuft. Wenn so schnell simuliert werden soll, wie es geht, so spricht man von der as-fast-as-possible Methode. Der Änderungszeitpunkt der Statusvariablen hängt von der Implementierung der Simulation ab. Eine Möglichkeit ist die zeitkontinuierliche Simulation, bei der die Simulationszeit stetig voran schreitet und der Zustand des Modells sich kontinuierlich ändert. Im Folgenden wird aber die diskrete Simulation betrachtet, bei der angenommen wird, dass sich der Zustand lediglich an diskreten Zeitpunkten während der Simulationszeit ändert. Hierbei wird unterschieden zwischen der zeitgesteuerten und der ereignisgesteuerten Simulation. Bei der zeitgesteuerten Simulation kennzeichnet die Beendigung eines Simulationsschrittes einen Zeitpunkt, an dem die Simulationszeit um eine festgelegte Spanne erhöht wird und alle in diesem überbrückten Zeitraum aufgetretenen Änderungen durchgeführt werden. Die zeitgesteuerte Simulation wird z.b. bei Wetterberechnungen verwendet. Kann man aber jeder Zustandsänderung ein spezielles Ereignis zuordnen, so wird oft die ereignisgesteuerte Simulation verwendet. 1.1 Diskrete Ereignisgesteuerte Simulation Bei der ereignisgesteuerten Simulation ändert sich der Zustand eines Systems nur bei Eintreten eines Ereignisses. Grundlage dieser Simulationsart ist die genaue Vorherbestimmung des nächsten Ereignisses zu jedem Zeitpunkt der Simulation. Nach einem Ereignis wird die Simulationszeit auf den Eintrittszeitpunkt des nächsten Ereignisses gesetzt. Realisiert wird dieses Verfahren durch eine Ereignisliste, in der alle Ereignisse mit ihren Eintrittszeiten aufgelistet sind. Wenn ein Ereignis eintritt, wird es aus der Liste entfernt und die mit diesem Ereignis verbundenen Aktivitäten ausgeführt. Dies können z.b. Zustandsänderungen des Systems sein oder aber das Einplanen von neuen Ereignissen in die Liste. Seite 3 von 17

4 Zu beachten ist dabei, dass Ereignisse nur in der Zukunft der momentanen Simulationszeit eingeplant werden können und nur das Ereignis mit minimalem Zeitstempel bearbeitet werden kann. Daraus folgt, dass ein Ereignis zum Zeitpunkt T kein Ereignis mit Zeitstempel kleiner T beeinflussen kann. Die hier vorgestellte sequentielle ereignisgesteuerte Simulationsart ist sehr intuitiv und funktioniert laut Fujimoto in der Praxis relativ zuverlässig. Doch bei zu gleichen Zeitpunkten eingeplanten Ereignissen ( simultane Ereignisse ) kann es Komplikationen geben. Je nachdem, in welcher Reihenfolge die Ereignisse bearbeitet werden, können sich der Simulationsverlauf und das Endergebnis verändern. Eine weitere Schwäche der sequentiellen Simulation ist, dass bei größeren Simulationen die Ausführung auf einem einzigen Rechner schnell an Performance- Grenzen stoßen kann. 1.2 Verteilte Simulation Um die Performance-Schwäche sequentieller Maschinen bei großen Simulationen, wie sie z.b. beim Militär, bei der Forschung oder in der Entwicklung durchgeführt werden, zu umgehen, werden diese Simulationen auf parallelen Rechnersystemen ausgeführt. Dies ist bekannt unter dem Begriff der parallelen diskreten ereignisbasierten Simulation, kurz PDES. Ein einzelnes Simulationsprogramm wird hierbei gleichzeitig auf mehreren Rechnern ausgeführt und die Ergebnisse untereinander mittels Ereignis-Nachrichten kommuniziert. Jeder Rechner erhält in der Simulation einen logischen Prozess und hat seine eigene Ereignisliste zur Verwaltung der Ereignisse. Da durch die Verarbeitung eines Ereignisses nicht nur auf dem verarbeitenden Rechner, sondern auch auf anderen Rechnern neue Ereignisse in die Ereignislisten eingeplant werden können, ist es auch bei den parallelen Systemen wichtig, dass auf allen Rechnern immer das Ereignis mit dem kleinsten Zeitstempel abgearbeitet wird. Würde ein Ereignis A später als ein Ereignis B ausgeführt werden, obwohl A einen kleineren Zeitstempel hat als B, könnte es zu einem so genannten Kausalitätsproblem ( causality error ) führen, wenn Ereignis A Variablen verändert, die für die Verarbeitung von Ereignis B wichtig sind. Es müssen also Einschränkungen bezüglich der Abfolge der Ereignisse in Kauf genommen werden, so dass jeder logische Prozess seine Ereignisse nur in aufsteigender zeitlicher Reihenfolge ausführen darf. Sich daran zu halten ist ausreichend, aber nicht immer notwendig. Ereignisse mit unterschiedlichen Zeitstempeln, die nichts miteinander zu tun haben, können parallel ausgeführt werden, sofern man weiß, dass das eine Ereignis nicht ein weiteres einplant, welches wiederum Einfluss auf das parallel ausgeführte Ereignis hat. Die Synchronisationsmechanismen haben nun dafür zu sorgen, dass die logischen Prozesse untereinander so kommunizieren, dass diese Einschränkungen bezüglich der Ausführreihenfolge eingehalten werden. Die Synchronisation der Rechner kann durch einen globalen Zeitgeber geschehen. Nach jeder Zeiteinheit werden auf allen Rechnern die zu diesem Zeitpunkt geplanten Ereignisse ausgeführt. Dies würde in vielen Fällen keinen Vorteil gegenüber sequentiellen Systemen bieten, da es in der Regel sehr selten Ereignisse gibt, die wirklich zur selben Zeit stattfinden und die dann parallel verarbeitet werden können. Statt einem globalen Zeitgeber käme hier eine asynchrone Synchronisationsmethode in Frage, die die Verarbeitung der Simulation beschleunigt ohne das Paradigma des geringsten Zeitstempels zu verletzen. Die Synchronisation der Rechner mit der Voraussetzung einer schnellen, parallelen Verarbeitung, bei der trotzdem nur das Ereignis mit dem geringsten Zeitstempel verarbeitet werden darf, ist das Hauptproblem der parallelen diskreten ereignisgesteuerten Simulation. Seite 4 von 17

5 Die Simulationsmechanismen haben zu entscheiden, welche Ereignisse ohne Beeinflussung anderer wirklich parallel ausgeführt werden dürfen, also welche Ereignisse sicher sind. Dies ist eine sehr komplexe Angelegenheit, die im Kontrast zu den Vorteilen einer parallelen Verarbeitung steht. 2. Synchronisationsmechanismen In der Einleitung wurden bereits die causality errors erwähnt. Sie treten auf, wenn zwei logisch miteinander verknüpfte Ereignisse in zeitlich umgekehrter Reihenfolge bearbeitet werden, so z.b. wenn an der Supermarktkasse die Produkte erst in die Tüten verpackt und danach erst über den Scanner gezogen werden. Dies ist ein logischer Fehler, der in der falschen zeitlichen Ausführung der Ereignisse seinen Ursprung hat. Es gibt nun zwei grundlegende Mechanismen in der PDES, wie mit diesen causality errors umgegangen wird. Der konservative Ansatz versucht strikt die Möglichkeit zu vermeiden, dass ein Fehler überhaupt auftreten kann. Die optimistischen Ansätze hingegen lassen Kausalitätsfehler erst einmal zu, versuchen aber dann, solche Fehler direkt zu erkennen und gegebenenfalls die Ereignisverarbeitung wieder rückgängig zu machen und die Ereignisse neu zu verarbeiten. 2.1 Konservative Mechanismen Bei der verteilten Verarbeitung ist zu beachten, dass jeder logische Prozess nicht nur die Ereignisse seiner eigenen Liste abarbeiten muss, sondern ebenfalls die Ereignis-Nachrichten, die ihm von anderen logischen Prozessen zugeschickt werden. Ein logischer Prozess, im Folgenden kurz LP genannt, hat für jeden weiteren LP eine eigene Eingangswarteschlange. So müssen ständig die Eingangs-Warteschlangen und die eigene Liste beobachtet werden, damit immer das Ereignis mit dem geringsten Zeitstempel bearbeitet wird. Ein Ereignis E1 mit Zeitstempel T1, dass in der Liste steht, ist nur sicher zu bearbeiten, wenn der logische Prozess eindeutig bestimmen kann, dass in Zukunft keine Ereignis-Nachricht empfangen wird mit einem Zeitstempel kleiner T1. Die logischen Prozesse arbeiten die Ereignisse in aufsteigender Zeitstempelfolge ab und somit haben auch die Ereignis-Nachrichten aufsteigende Zeitstempel. Zur Vereinfachung der Untersuchungen wird nun vielfach angenommen, dass die Nachrichten auch in korrekter Reihenfolge beim anderen LP ankommen, ungeachtet der evtl. gegebenen Netzwerkeigenschaften. So kann ein LP beim Betrachten seiner Eingangswarteschlangen davon ausgehen, dass die darin ganz vorne befindliche Nachricht den geringsten Zeitstempel hat, wodurch ein Vergleich der Zeitstempel möglich und das sichere Ereignis eindeutig wählbar ist. Doch sobald eine Eingangswarteschlange leer ist, kann der LP nicht mehr ein Ereignis als sicher identifizieren, da in diese leere Schlange ja immer noch ein Ereignis mit kleinerem Zeitstempel eintreffen kann. Somit muss der Prozess blocken, d.h. sich erst einmal stilllegen und warten. Wenn nun mehrere LPs, die sich kreisförmig Nachrichten senden, in den geblockten Zustand gehen, so ist die gesamte Verarbeitung in diesem Bereich eingefroren und es kommt zur so genannten Deadlock - Situation, die in der folgenden Abbildung 1 verdeutlicht wird. Seite 5 von 17

6 Die drei LPs erwarten jeweils von einem ihrer benachbarten Prozesse eine Nachricht, die Eingangswarteschlangen sind aber leer. Obwohl in anderen Warteschlangen Ereignis-Nachrichten vorhanden sind, kann die Simulation nicht fortfahren, da eine eindeutige Bestimmung des kleinsten Zeitstempels nicht möglich ist. Abb.1: Deadlock-Situation: JFK wartet auf SFO, SFO wartet auf ORD, der wiederum auf JFK wartet Unter den konservativen Algorithmen gibt es nun verschiedene Ansätze, mit dieser Situation umzugehen Deadlock-Vermeidung durch Null-Nachrichten Eine Deadlock-Situation tritt im Allgemeinen auf, wenn es nur wenige unverarbeitete Ereignis- Nachrichten im Vergleich zu der Anzahl der Links zwischen den LPs gibt. Ein Ansatz, Deadlocks zu vermeiden, ist das Verschicken von sogenannten Null-Nachrichten. Eine Null-Nachricht korrespondiert zu keinem Ereignis des physikalischen Systems. Sie dient nur als Versprechen von LP1 an LP2, dass LP1 keine Nachricht senden wird mit einem Zeitstempel kleiner als dem Zeitstempel dieser Null-Nachricht. Um eine Null-Nachricht verschicken zu können, muss der LP den aktuellen Zeitstempel ermitteln. Durch Kenntnis der momentan niedrigsten Zeit an den Eingangsschlangen und in der Ereignisliste und durch Schätzung der benötigten Abarbeitungszeit eines Ereignisses kann der LP eine Untergrenze der Zeitstempel für alle folgenden Nachrichten ermitteln. Die Null-Nachricht mit dieser Untergrenze als Zeitstempel wird dann an alle angeschlossenen Prozesse geschickt. Die wiederum können auf Basis dieses Zeitstempels von sich aus eine neue Untergrenze ermitteln und diese weiterkommunizieren. Somit ist gewährleistet, dass immer eine Nachricht in der Empfangswarteschlange der LPs ist und entsprechend die Bearbeitung fortgesetzt werden kann, doch es kommt natürlich zu erhöhtem Verkehr im Netz und höherem Verwaltungsaufwand der Ereignislisten. Eine Alternative ist das anforderungsgesteuerte Verschicken der Null-Nachrichten. Wenn ein Prozess bemerkt, dass eine seiner Eingangsschlangen leer wird, fordert er von der Gegenseite eine Nachricht an. Nun kann der Prozess sicher sein, dass entweder eine Null-Nachricht oder evtl. eine Ereignis-Nachricht geschickt wird. Seite 6 von 17

7 Bei der Ermittlung der unteren Grenze für den Zeitstempel der Null-Nachrichten war von einer Schätzung der Abarbeitungszeit die Rede. Dabei spielt hier eine Variable eine Rolle, die als Lookahead -Wert bezeichnet wird. Der Lookahead-Wert L gibt Auskunft darüber, dass ein Prozess zum Zeitpunkt T nur Ereignis- Nachrichten verschicken wird, die mindestens einen Zeitstempel von T+L haben. Dieser Wert L ergibt sich aus der Simulationssituation. Als Beispiel sei hier die Simulation von Flugverkehr genannt. Werden zwei Flughäfen durch LPs dargestellt und es ist bekannt, dass die Flugzeit zwischen diesen Flughäfen drei Stunden beträgt, so haben diese LPs für die Kommunikation untereinander einen Lookahead-Wert von drei. LP1 weiß genau, wenn zum Zeitpunkt T ein Ereignis bearbeitet wird, das durch eine Ereignis-Nachricht eine Landung beim LP2 einplant, so muss diese Landung einen Zeitstempel von mindestens T+3 haben. Somit schickt LP1 eine Null-Nachricht an LP2 mit Zeitstempel T+3. LP2 kann daraufhin alle Ereignisse bis Zeitstempel T+3 bearbeiten und seinerseits neue Null-Nachrichten verschicken. Diese lösen auf der Gegenseite wiederum die Bearbeitung aus und die Simulationszeit schreitet voran. Es ist ersichtlich, dass die Performance des Null-Nachricht-Algorithmus stark von dem Lookahead-Wert abhängt. Je kleiner der Wert, desto mehr Null-Nachrichten müssen verschickt werden, um in der Zeit voranzuschreiten und ein Lookahead-Wert von 0 macht den Algorithmus unbrauchbar, da hier ein endloser Zyklus von Null-Nachrichten mit dem selben Zeitstempel entsteht, wobei kein LP in der Simulationszeit fortschreiten kann. Ein weiterer konservativer Algorithmus, der ebenfalls den Lookahead-Wert benutzt, ist der Algorithmus zur Deadlock-Erkennung und Wiederherstellung der vorherigen Situation Deadlock-Erkennung und Wiederherstellung Im Gegensatz zum vorher vorgestellten Mechanismus arbeitet der nun beschriebene Mechanismus nicht mit Null-Nachrichten und versucht auch nicht, den Deadlock zu vermeiden. Vielmehr wird gestattet, dass es zum Deadlock kommt, es werden aber zwei Mechanismen implementiert, die diese Situation erkennen und danach den Deadlock auflösen. Um den Erkennungsmechanismus zu verstehen, wird die Simulation mit seinen Prozessen als Baum aufgefasst. Es gibt einen Kontroll-Prozess, der die Wurzel des Baumes darstellt. Wenn diese Wurzel des Baumes keine Kinder hat, so ist eine Deadlock-Situation aufgetreten. Der Kontroll-Prozess schickt nun an den logischen Prozess, der das Ereignis mit dem kleinsten Zeitstempel in seiner Liste oder einer seiner Eingangsschlangen gespeichert hat, eine Nachricht, dass dieses Ereignis sicher ist. Der Prozess fängt an zu arbeiten und der Deadlock ist gebrochen. Im Baum wird dieser Prozess nun der Sohn des Kontroll-Prozesses, also ein Blatt im Baum. Die bearbeitete Ereignis-Nachricht erzeugt nun weitere Nachrichten, die zu anderen LPs geschickt werden. Der erste LP wird vom Blatt zum inneren Knoten und alle von ihm mit Ereignis-Nachrichten versorgten LPs werden seine Blätter. So pflanzt sich das fort bis der Baum vollständig ist. Blockt ein Prozess, so benachrichtigt er seinen Vater und entfernt sich aus dem Baum. Wenn der Kontroll-Prozess nun alle Söhne verloren hat und selber zum Blatt wird, weiß er, dass eine globale Deadlock-Situation aufgetreten ist und die Prozedur fängt von vorne an. Für diesen Mechanismus beherbergt jeder LP zwei Variablen die speichern, wie viele Nachrichten von Nachbarn, denen man noch nichts zurück signalisiert hat, eingegangen sind und wie viele Nachrichten man selber an andere gesendet hat. Seite 7 von 17

8 Der Wiederherstellungsprozess wurde in obiger Beschreibung vernachlässigt. Deshalb wird im Folgenden etwas genauer darauf eingegangen. Wie in der Einführung beschrieben, kann man ohne weiteres annehmen, dass das Ereignis mit dem kleinsten Zeitstempel auch sicher ist, da Ereignisse nicht in der Vergangenheit der Simulationszeit eingeplant werden dürfen. Somit muss der Kontroll-Prozess nur das Ereignis mit dem kleinsten Zeitstempel identifizieren, um die Deadlock-Situation zu brechen. Eine Möglichkeit wäre, einen Broadcast an alle LPs zu schicken, um von ihnen den kleinsten Zeitstempel anzufordern. Wenn man sich wieder die Simulation als Baum vorstellt, so schickt der Kontroll-Prozess an seine Söhne die Nachricht, die wiederum an deren Söhne weitergeleitet wird. Ist ein Prozess ein Blatt, so schickt er die Nachricht nicht weiter, sondern antwortet seinem Vater, indem er den kleinsten Zeitstempel zurückgibt. Der Vater vergleicht den empfangenen Zeitstempel mit seinen Ereignissen und gibt wiederum den kleinsten weiter an seinen Vater, bis der Kontroll-Prozess als Wurzel den kleinsten Zeitstempel von jedem Sohn erhält. Der Kontroll-Prozess ermittelt den globalen kleinsten Zeitstempel und schickt die Nachricht an alle LPs, dass die Ereignisse mit diesem Stempel abgearbeitet werden können. Das Aufheben des Deadlocks benötigt also drei Durchgänge, was bei einer großen Anzahl von LPs recht lange dauern kann. Um die darauf folgende Verarbeitung zu beschleunigen kann der Zeitstempel gegebenenfalls mit einem Lookahead versehen werden. Im Gegensatz zum Null-Nachricht-Algorithmus ist es hier zulässig, dass der Lookahead 0 ist. Außerdem wird hier der Zeitstempel des nächsten noch nicht abgearbeiteten Ereignisses genommen und nicht wie vorher nur der Stempel des letzten bereits abgearbeiteten Ereignisses. Der Vorteil dieser Information wird im folgenden kleinen Beispiel deutlich. Angenommen man hat eine Simulation mit mehreren LPs, die jeweils einen Lookahead L= 1 haben. Die Simulation ist in einer Deadlock-Situation, wobei alle LPs bei einer Zeit von 10 geblockt sind. Der nächste noch nicht abgearbeitete Prozess hat einen Zeitstempel von 100. Der Null-Nachricht-Algorithmus würde jetzt immer in Einerschritten bis zum Zeitpunkt T+L voranschreiten und jeweils eine Null-Nachricht verschicken. Es würden also etliche Nachrichten verschickt werden, ehe die Deadlock-Situation aufgehoben ist. Der gerade vorgestellte Deadlock Erkennungs- und Wiederherstellungsalgorithmus hingegen identifiziert sofort das Ereignis mit Zeitstempel 100 als das mit dem kleinsten Zeitstempel und somit als sicher. Das Ereignis wird bearbeitet und der Deadlock ist schnell aufgehoben Synchrone Ausführung mittels Barrieren Im vorherigen Algorithmus wechseln die Prozesse immer zwischen zwei Phasen: a) sichere Ereignisse werden abgearbeitet b) Deadlock Situationen werden aufgelöst. Die nun vorgestellten Algorithmen wechseln auch phasenartig ihr Aufgabengebiet, nur dass im Voraus bestimmt wird, wann der komplette Simulationsprozess anhält und sie nicht darauf warten, dass ein Deadlock entsteht. Um dies zu realisieren, greifen diese Algorithmen auf sogenannte Barrieren zurück. Eine Barriere ist ein definierter Punkt in der wallclock-time, an dem jeder Prozess an einem bestimmten Punkt in der Berechnung ist. Einfacher ausgedrückt muss ein Prozess, der schneller ist als die anderen, an dieser Barriere so lange warten, bis die anderen Prozesse gleichgezogen haben, so dass die nächste Berechnung wieder synchron startet. Eine einfache Möglichkeit wäre, die Si- Seite 8 von 17

9 mulation in einzelne Schritte aufzuteilen. Erst wenn alle LPs Schritt 1 bearbeitet haben, kann gemeinsam mit Schritt 2 begonnen werden. So hat der Algorithmus die Sicherheit, dass kein Ereignis gerade bearbeitet oder geplant wird, während er herauszufinden versucht, ob ein Ereignis sicher ist. Zu unterscheiden wären hier die zentralisierten Barrieren, die Baum-Barrieren und die Schmetterlings-Barrieren. Bei den zentralisierten Barrieren übernimmt ein LP eine globale Kontrollaufgabe, wie in folgender Grafik deutlich wird. Abb.2: Ankunft der log. Prozesse an einer Barriere. LP2 übernimmt Kontrollfunktion Erreicht ein LP die Barriere, so schickt er eine Mitteilung an den Kontroll-LP 2 (roter Pfeil). Sind alle LPs gleichauf, so schickt der Kontroll-LP Mitteilungen an alle, dass mit der Bearbeitung fort gefahren werden kann (schwarze Pfeile). Hierbei ist natürlich der Kontroll-LP ein Flaschenhals, wodurch es zu Verzögerungen kommen kann. Eine Abart wäre, dass beim Erreichen der Barriere eine Broadcast-Nachricht an alle geschickt wird. Wenn jeder LP Nachrichten von den jeweils anderen erhalten hat, kann die Verarbeitung fortgesetzt werden. Hier werden aber verhältnismäßig viele Nachrichten verschickt, was sich auch negativ auf die Leistung auswirkt. Die folgenden zwei Methoden werden hier aus Platzgründen nur kurz skizziert, näheres siehe [Fuj00]. Bei der Baum-Barrieren-Methode wird das Flaschenhalsproblem mittels eines ausbalancierten Baumes gelöst. Jeder Knoten repräsentiert einen Prozess. Erreicht ein LP nun eine Barriere, so schickt er an seinen übergeordneten Knoten eine Nachricht. Ist dieser Vater- Knoten die Wurzel, so sind alle LPs an der Barriere angekommen und eine Startfreigabe kann den umgekehrten Weg zurück zu den Knoten nehmen. Bei dieser Methode werden für N Prozesse 2(N-1) Nachrichten verschickt. Die Schmetterlingsvariante verfolgt einen anderen Ansatz. Jeder LP arbeitet eine Folge von log 2 N Barrieren ab, wobei sich im k-ten Schritt der Prozess i mit dem Prozess j synchronisiert, wobei dessen binäre Darstellungen sich nur in der k-ten Stelle unterscheiden. Betrachten wir dazu den LP Nummer 4, binär > Synchronisation im 1. Schritt mit LP > Synchronisation im 2. Schritt mit LP > Synchronisation im 3. Schritt mit LP Konservativer Zeitfenster-Algorithmus Einen weiteren Mechanismus, der bestimmt, ob ein Ereignis sicher ist, stellt der Zeitfenster- Algorithmus dar. Hierbei wird ein Zeitfenster einer bestimmten Größe festgelegt, dessen untere Grenze das Zeitstempel-Minimum aller noch nicht bearbeiteten Ereignisse ist. Es wird nun innerhalb dieses Zeitfensters geprüft, ob die Ereignisse voneinander abhängen bzw. ob die Ereignisse sicher sind. Wenn alle Ereignisse als sicher identifiziert werden konnten, so dürfen Seite 9 von 17

10 diese Ereignisse parallel ausgeführt werden. Wenn nicht, so erfolgt entweder eine teilweise parallele Verarbeitung oder aber eine nach dem Zeitstempel geordnete. Wenn z.b. der kleinste Zeitstempel 10 ist, das Zeitfenster den Bereich von 10 bis 20 abdeckt und die Simulation derart ist, dass ein Ereignis mit Zeitstempel T ein neues Ereignis nur mit einem Zeitstempel größer T+7 einplanen kann, so braucht ein LP bei seinen benachbarten LPs nur die unbearbeiteten Ereignisse bis zum Zeitstempel T+2 betrachten, da alle weiteren Ereignisse kein Ereignis im Bereich des Zeitfensters einplanen können. Dies verdeutlicht, dass der Betrachtungsbereich eines LPs zur Identifikation eines sicheren Ereignisses stark eingeschränkt wird und sich somit die Performance erhöht. Eine noch zu klärende Frage wäre, welcher Algorithmus benutzt wird, um nun diese Fenstergröße zu bestimmen. Ist das Fenster zu klein, sind unter Umständen zu wenig Ereignisse in diesem Zeitrahmen, die gleichzeitig bearbeitet werden können. Wählt man aber ein zu großes Fenster, so verhält sich der Algorithmus, als würde kein Zeitfenster existieren. Um das Zeitfenster auf eine geeignete Größe zu setzen, bedarf es simulationsspezifischen Wissens, dass entweder vom Programmierer direkt implementiert wird oder durch Beobachten zur Laufzeit der Simulation angepasst wird. 2.2 Optimistische Mechanismen Im Gegensatz zu den konservativen Mechanismen, die darauf ausgelegt sind, jeden causalityerror von Beginn an zu vermeiden, gehen die nun vorgestellten Mechanismen das Problem optimistisch an. Sie versuchen die Fehler nicht zu vermeiden indem sie notfalls die Ereignisse sequentiell abarbeiten, sondern lassen alle Berechnungen erst einmal mit der Einstellung zu, dass alle Ereignisse sicher sind und demnach nichts passieren wird. Sollte aber ein Fehler auftreten, so besitzen diese Mechanismen die Fähigkeit, den Fehler direkt zu entdecken und die Simulation mittels geeigneter Prozeduren zu reparieren. Ein Vorteil dieses Ansatzes ist ganz deutlich, dass dem Simulator erst einmal erlaubt wird, so viel wie möglich parallel zu berechnen und dies auch in Situationen, wo causality errors evtl. auftreten könnten, aber nicht unbedingt müssen. Konservative Mechanismen würden in diesen Situationen sofort den negativen Fall annehmen und deshalb eine längere Laufzeit zur Folge haben. Im Gegensatz zu den konservativen Mechanismen muss bei den optimistischen Algorithmen nicht vorausgesetzt werden, dass die LPs die Ereignis-Nachrichten in zeitlicher Reihenfolge schicken müssen und das Netzwerk die Nachrichten auch in dieser Reihenfolge übertragen muss. Es muss auch vorher nicht spezifiziert werden, welcher LP mit welchem kommuniziert Time Warp Der wohl bekannteste optimistische Mechanismus ist Time Warp. So wie die vorher besprochenen Mechanismen besitzt bei Time Warp jeder LP auch eine Ereignis-Liste, in der die Ereignisse eingeplant sind. Jedoch wird hier nicht explizit geprüft, ob ein Ereignis sicher ist. Die Ereignisse werden einfach abgearbeitet, verweilen danach aber in der Liste anstatt gelöscht zu werden. Des Weiteren kennzeichnet eine lokale Prozess-Zeit immer den Zeitstempel des zuletzt abgearbeiteten Ereignisses. Die Vorgänge innerhalb eines LP werden durch eine sogenannte lokale Kontrolle gesteuert bzw. überwacht. Seite 10 von 17

11 Empfängt ein LP nun eine Ereignis-Nachricht eines anderen LPs, die einen kleineren Zeitstempel hat als die lokale Prozess-Zeit, so erkennt der Prozess das Problem und stoppt sofort die weitere Verarbeitung. Eine solche Nachricht wird auch als Nachzügler ( straggler ) bezeichnet. Das neu zu planende Ereignis wird in die Ereignis-Liste zeitlich eingereiht. Nun wird die Verarbeitung bis zu diesem neuen Ereignis rückgängig gemacht, wobei einem zu Gute kommt, dass die abgearbeiteten Ereignisse wie oben erwähnt nicht aus der Liste gelöscht werden. Im Anschluss daran wird die Verarbeitung inklusive des neuen Ereignisses wiederholt. Der gesamte Vorgang ist in folgender Grafik vereinfacht dargestellt. Abb. 3: Eintreffen einer Nachzügler-Nachricht und Rollback der bearbeiteten Ereignisse Das oben angesprochene Rückgängigmachen behandelt die zwei Aktivitäten, die beim Ausführen eines Ereignisses durchgeführt werden. Zum einem wäre dies das Modifizieren der Status- Variablen und zum anderen das Einplanen von neuen Ereignissen bzw. das Senden von Ereignis-Nachrichten an andere LPs. Befassen wir uns nun mit der Rückgewinnung der Status- Variablen. Hierzu ist es wichtig, dass die Status-Variablen regelmäßig gesichert werden. Als erste Alternative bietet sich an, vor jedem Ereignis alle Statusvariablen zu sichern. Muss nun die Simulation auf den Zeitpunkt T zurückgestellt werden, so braucht man nur den entsprechenden Vektor mit den Status-Variablen zu laden. So ist gewährleistet, dass immer ein schneller Zugriff auf die Variablen besteht, doch der Speicherbedarf ist sehr hoch. Um den Speicherbedarf ein wenig zu minimieren, kann man stattdessen auch in unregelmäßigen Abständen eine Sicherung durchführen. Dies hat nur den Nachteil, dass die Simulation evtl. weiter in die Vergangenheit zurückgesetzt werden muss, als es eigentlich nötig ist. Die zweite Möglichkeit ist das inkrementelle Sichern der Variablen. Das bedeutet, dass nur diejenigen Variablen gesichert werden, die beim momentan bearbeiteten Ereignis verändert werden. Dies spart natürlich viel Platz, doch beim Zurücksetzen der Simulation müssen nacheinander alle Ereignisse durchgegangen werden. Durch diesen Mehraufwand wird deutlich, dass diese Alternative zu bevorzugen ist, wenn wenige Veränderungen auftreten, während die Seite 11 von 17

12 erste Alternative besser ist, wenn bei jeder Ereignisbearbeitung fast alle Variablen verändert werden. Beide Verfahren können aber auch kombiniert werden, was am effektivsten sein kann. Nachdem die Status-Variablen zurückgesetzt sind, muss nun noch das Senden der Ereignis- Nachrichten rückgängig gemacht werden. Dazu speichert ein LP jede gesendete Ereignis- Nachricht als eine sogenannte Negativ-Nachricht, oder auch anti-message, die eine exakte Kopie der Original-Nachricht darstellt, nur mit einem negativen Vorzeichen. Muss nun ein Prozess zurückgesetzt werden, so werden einfach die entsprechenden Negativ-Nachrichten an die benachbarten LPs gesendet. Wie in der Physik mit Materie und Anti-Materie löschen sich beim empfangenden LP die Nachricht und die Negativ-Nachricht aus. Im Einzelnen kann der LP folgendermaßen auf das Eintreffen einer Negativ-Nachricht reagieren: a) Wenn die Ereignis-Nachricht noch nicht verarbeitet worden ist, so werden die positive als auch die negative Nachricht aus der Eingangswarteschlange gelöscht und der Speicherplatz wird freigegeben. b) Wenn die entsprechende Nachricht schon verarbeitet worden ist, so muss der Prozess bis zu diesem Zeitpunkt zurückgerollt werden. Dann können sich die Ereignis- Nachricht und die Negativ-Nachricht gegenseitig auslöschen. Danach kann der LP die Verarbeitung von diesem Zeitpunkt an wieder fortsetzen. Das Zurücksetzen eines Prozesses aufgrund einer Negativ-Nachricht wird auch secondary roll-back genannt. Dieser Vorgang kann sich natürlich über die anderen LPs fortpflanzen, bis der endgültige Zustand erreicht ist. c) Durch ein Netzwerk, was nicht garantieren kann, dass die Nachrichten in der Reihenfolge ankommen, in der sie abgeschickt wurden, kann es somit vorkommen, dass die Negativ-Nachricht vor der Ereignis-Nachricht eintrifft. Hier verhält sich der LP wie bei Möglichkeit a. Sollte nun die Ereignis-Nachricht in der Vergangenheit der lokalen Prozesszeit ankommen, so wird kein Rollback durchgeführt, sondern die Nachricht sofort durch die in der Eingangswarteschlange wartenden Negativ-Nachricht gelöscht. Betrachten wir im Folgenden einen Ausschnitt eines Simulationsprozessdiagramms. Die vier LPs haben zu unterschiedlichen Zeitpunkten geplante Ereignisse, die wiederum weitere Ereignisse einplanen. Da wir für Simulationsprozesse allgemein angenommen haben, dass Ereignisse nur in der Zukunft eingeplant werden dürfen, verläuft der Graph nur von links nach rechts. Der Graph ist also azyklisch. Abb. 4: geplante Ereignisse der LPs dargestellt über der Simulationszeit Seite 12 von 17

13 Ein Rollback bis zum Zeitpunkt T betrifft daher nur Ereignisse mit Zeitstempel größer T, da alle Negativ-Nachrichten einen Zeitstempel größer T haben müssen. Die durch Negativ- Nachrichten ausgelösten Rollbacks verhalten sich dementsprechend genauso. Ebenso ist sichergestellt, dass das Ereignis mit dem kleinsten Zeitstempel im System nie zurückgestellt wird. Sei dieses Ereignis E zum Zeitpunkt P abgearbeitet und resultierend daraus eine Ereignis-Nachricht mit Zeitstempel P+x=T verschickt. T ist auf jeden Fall größer gleich P. Wenn der LP, der diese Nachricht empfängt, dadurch zurückgesetzt werden muss, so bleibt E unberührt davon. Es kann also nicht vorkommen, dass durch einen Rollback eine Simulation bis an den Anfang zurückgesetzt wird. Sie macht also stetig Fortschritte. Die lokale Kontrolle ist ausreichend, um sicherzustellen, dass die Simulation zum selben Ergebnis führt wie eine sequentielle Abarbeitung. Um zwei weitere Probleme kümmert sich die sogenannte globale Kontrolle: Zum einen um die Wiedergewinnung von Speicherplatz, der nicht mehr benötigt wird und zum anderen um die Steuerung der I/O Operationen, die ja nicht wieder zurückgesetzt werden können. Hierfür ist sicherzustellen, dass ab einem bestimmten Zeitpunkt der Simulation kein Rollback mehr geschehen kann, der zurückliegende Ereignisse betrifft, so dass bedenkenlos obige Operationen ausgeführt werden können. Man benötigt also eine untere Zeitgrenze, die sogenannte Global Virtual Time (GVT). Die GVT ist definiert als das Minimum aller Zeitstempel von allen unbearbeiteten und sich in Bearbeitung befindlichen. Alle Ereignisse, Statusvariablen und Nachrichten unterhalb dieser Zeitgrenze können gelöscht werden, so dass der Speicher wieder zur Verfügung steht und die I/O Operationen können ausgeführt werden. Das Löschen nicht mehr benötigter Speicherinhalte wird als fossil collection bezeichnet. Dieser Vorgang kann entweder im Abstand einer gewissen Zeiteinheit durchgeführt werden, indem alle LPs nach besagten Ereignissen und Variablen durchsucht werden und Speicher freigegeben wird, oder aber erst wenn das System zu wenig Speicher hat. Hier bietet sich auch eine on the fly fossil collection an. Jedes Ereignis wird in einer FIFO-Schlange gespeichert und immer wenn Speicher benötigt wird, wird in dieser Schlange überprüft, ob das vorderste Ereignis vor der GVT liegt. Nur der Speicher dieses einen Ereignisses wird dann freigegeben. Das Bestimmen der GVT ist nicht immer einfach, da sich genau zu diesem Zeitpunkt ja noch Nachrichten irgendwo im Netzwerk aufhalten könnten. Dieses Problem heißt transient message problem. Eine Lösung, dieses Problem zu umgehen, wäre z.b. die Bestätigung aller Mails durch ein Acknowledgement. Da es für die Berechnung der GVT nach Fujimoto mehrere Ansätze gibt, wird auf eine weitere Ausführung hier aus Platzgründen verzichtet, ebenso wie eine Vertiefung zum Thema transient messages Lazy Cancellation Erinnern wir uns an das Szenario des Time Warp Mechanismus, dass bei einem Rollback die Verarbeitung sofort auf den Zeitpunkt T zurückgesetzt wird. Die daraus resultierenden Negativ-Nachrichten lösen auf der Empfängerseite auch sofort einen Rollback aus. Diese Vorgehensweise wird als aggressive cancellation bezeichnet. Nun kann es aber vorkommen, dass bei der Neuverarbeitung der Ereignisse unter den neuen Bedingungen trotzdem annähernd die gleichen Ergebnisse erzielt werden und die gleichen Ereignis-Nachrichten erzeugt werden wie vor dem Rollback. Die Wiederausführung des Ereignisses war somit überflüssig. Der Lazy Cancellation -Algorithmus baut auf dem Time Warp auf und versucht dieses Problem zu beheben. Wenn ein Rollback durchgeführt wird, werden nicht Seite 13 von 17

14 direkt Negativ-Nachrichten verschickt. Vielmehr wartet der Algorithmus die Verarbeitung der Ereignisse ab. Erst wenn die Neuverarbeitung ein anderes Ergebnis produziert als vorher, wird das vorherige Ergebnis mittels einer Negativ-Nachricht annulliert und das neue Ergebnis propagiert. Betrachten wir dazu das folgende Beispiel mit den beiden Flughäfen ORD und JFK. Abb.5: Neues Ereignis beeinflusst bisherige Ereignisse nicht In (a) wird ein Ereignis eingeplant, dass um neun Uhr ein Flugzeug in ORD landet und um zehn Uhr Richtung JFK abhebt, wo es um zwölf Uhr ankommt. Es wird also eine Ereignis- Nachricht an JFK geschickt, die den Landezeitpunkt einplant. Wird nun - wie in (b) dargestellt - ein weiteres Ereignis eingeplant, was zeitlich vor der neun Uhr Landung liegt, so würde der Time Warp sofort beim eingeleiteten Rollback eine Negativ-Nachricht an JFK schicken, um die zwölf Uhr Landung zu streichen, obwohl bei der späteren Neuberechnung dieselbe Nachricht generiert wird. Lazy Cancellation hingegen wartet erst einmal die Neuverarbeitung ab und merkt nach dem zehn Uhr Ereignis, dass ja alles beim Alten blieb und somit die zwölf Uhr Nachricht nicht gelöscht werden braucht. Je nach Anwendung wird durch Lazy Cancellation die Performance im Gegensatz zu Time Warp verbessert oder verschlechtert. Der Algorithmus hat einen gewissen Overhead, da bei einem Rollback nach jedem Ereignis erst eine Überprüfung des Ergebnisses stattfindet. Des Weiteren erlaubt Lazy Cancellation, dass durch die Verzögerung sich der Fehler in der Simulation weiter fortpflanzt und dadurch mehr Rollbacks nötig werden. Auf der anderen Seite erlaubt der Algorithmus auch die Verarbeitung in weniger als der critical path execution time, die die minimale Simulationszeit für eine parallele Berechnung darstellt. Dieses Phänomen tritt dadurch auf, dass Berechnungen mit falschem oder annähernd richtigem Eingangswert immer noch ein richtiges Ergebnis liefern können. Wenn z.b. ein Ereignis das Minimum von zwei Variablen A und B ausgeben muss und die Berechnung mit einem falschen Wert für A geschieht, so ist das Ergebnis der Berechnung mit dem richtigen Wert für A genau dasselbe, wenn beide Werte größer als B sind. Experimente in der Praxis deuten darauf hin, dass Lazy Cancellation unter gewissen Umständen wesentlich schneller arbeitet als Time Warp. Seite 14 von 17

15 2.2.3 Lazy Reevaluation Der Lazy Reevaluation -Algorithmus, auch jump forward genannt, arbeitet ähnlich wie Lazy Cancellation, nur dass hier nicht die erzeugten Nachrichten aller bisher abgearbeiteten Ereignisse betrachtet werden. Man betrachtet hier lediglich den Status-Vektor nach der Ausführung einer Nachzügler-Nachricht und vergleicht ihn mit dem Ergebnis vor der Berechnung. Sollten die Ergebnisse der Berechnungen gleich sein, so ist ein Wiederausführen der anderen Ereignisse nicht nötig und der Algorithmus springt wieder in der Simulationszeit vorwärts bis zu dem Zeitpunkt, wo der Rollback angewiesen wurde. Dies bringt einige Vorteile, da das kostenintensive Neuberechnen der Ereignisse unterdrückt wird. Besonders bei simplen Query-Events, die einen Rollback verursachen, aber nicht den Status ändern, kann der Algorithmus von Nutzen sein. Um noch mal auf das Beispiel des Flughafens der vorherigen Seite zurück zu kommen, würde Lazy Reevaluation also aus Abbildung (a) den Statusvektor vor 9 Uhr sich anschauen und mit dem Statusvektor aus (b) nach der Verarbeitung des 8 Uhr Ereignisses vergleichen. Er würde feststellen, dass sich nichts geändert hat und die folgenden Ereignisse überspringen Optimistische Zeit-Fenster Ein weiterer Verbesserungsansatz für den Time Warp Mechanismus ist der Einsatz von sogenannten Zeit-Fenstern, ähnlich denen, die schon bei den konservativen Algorithmen eingesetzt wurden. Hier werden sie eingesetzt, damit sich inkorrekte Berechnungen nicht zu weit in die Zukunft der Simulationszeit fortpflanzen. Realisiert wird der Algorithmus durch die Benutzung eines beweglichen Zeitfensters (im Englischen moving time windows, kurz MTW) mit einer Fensterbreite von W, die auch während der Laufzeit dynamisch angepasst werden kann. Ist T der kleinste Zeitstempel im System, so dürfen alle Ereignisse mit einem Zeitstempel von maximal T+W ausgeführt werden. Leider kann das Zeitfenster nicht unterscheiden, ob es sich um eine normale Berechnung handelt oder ob diese Berechnung auf einem falschen Ausgangswert beruht und somit bei einem Rollback geändert wird. So wird natürlich der Fortschritt von korrekt verlaufenden Berechnungen gehemmt. Des Weiteren steht nicht fest, wie die Größe dieses Fensters festgesetzt werden soll Wolf Calls Um die weite Verbreitung fehlerhafter Berechnungen zu unterbinden wurde auch der Vorschlag unterbreitet, durch Kontroll-Nachrichten die LPs schnell zu informieren, dass irgendwo im System ein Rollback durchgeführt wird und sich dadurch Veränderungen ergeben könnten. Ein offensichtlicher Nachteil besteht nun darin, dass die korrekten Berechnungen weitestgehend eingefroren sind. Ebenso werden evtl. unnötig viele Kontroll-Nachrichten verschickt, da die Anzahl der Prozesse, die benachrichtigt werden in vielen Fällen viel größer ist als die Zahl derer, die wirklich betroffen sind. Seite 15 von 17

16 3. Zusammenfassung In der vorliegenden Seminararbeit haben wir uns mit der parallelen diskreten ereignisgesteuerten Simulation beschäftigt, wobei eine Simulation parallel auf mehreren Prozessoren durchgeführt wird. Hierbei ist eine Synchronisation der Prozesse nötig, da ansonsten kausale Fehler entstehen können. In der PDES gibt es nun zwei Mechanismen, wie mit diesen causality errors umgegangen wird, zum einem die konservativen und zum andern die optimistischen Mechanismen. Ziel der vorgestellten konservativen Algorithmen ist das Einhalten der local causality - Einschränkung, also dass alle Ereignisse in zeitlicher Reihenfolge abgearbeitet werden müssen bzw. nur dann parallel bearbeitet werden, wenn wirklich sichergestellt ist, dass Ereignis 1 keinen Einfluss auf Ereignis 2 hat. Schon beim kleinsten Verdacht müssen beide sequentiell abgearbeitet werden. Somit verhindern die konservativen Algorithmen im Vornherein, dass es zu einer Verletzung dieser Einschränkung kommt. Gute Lookahead-Eigenschaften werden dabei vorausgesetzt, damit wirklich eine parallele Verarbeitung stattfindet. Im schlimmsten Fall erfolgt die gesamte Simulation sequentiell. Dies kann durchaus oft vorkommen, da die Algorithmen sehr pessimistisch handeln und schon beim geringsten Verdacht eine parallele Verarbeitung unterbinden. Die Lookahead-Werte bestimmen maßgeblich die Performance der Simulation. Bei den optimistischen Mechanismen spielt zum einem der Speicherbedarf und der Overhead, der beim Speichern der Statusvektoren entsteht, eine wichtige Rolle beim Analysieren der Performance. Des Weiteren wird diesen Mechanismen nachgesagt, dass sie zu viel Zeit damit verbringen, Rollbacks auszuführen. Besonders wenn die Anwendung relativ zu der Anzahl zur Verfügung stehender Prozessoren wenig Parallelismus enthält, ist ein hoher Grad an Rollbacks während der Simulation unausweichlich. Obwohl die auftretenden Probleme nicht unüberwindbar sind, so sind sie doch in einigen Systemen ohne angemessenen Hardware-Support schwer zu umgehen. Befürworter der konservativen Methode behaupten, dass es zu komplex sei, den Time Warp Mechanismus zu implementieren und zu debuggen. In der Tat kann es sehr zeitraubend sein, einen Time Warp Quellcode zu analysieren, da evtl. komplexe Rollback-Algorithmen nachvollzogen werden müssen. Obwohl der oben vorgestellte Time Warp in seiner Grundform, wenn man die Fehlerbehandlung mal außen vor lässt, nicht sehr komplex ist, könnten unerfahrene Programmierer durch kleine Fehler im Code nur eine ziemlich dürftige Performance erreichen. Alles in allem kann man nicht direkt sagen, ob der konservative oder der optimistische Ansatz ein besseres Ergebnis liefert. Wenn die Simulation einen gewissen Grad an Parallelität hat, so ist mit Sicherheit der Time Warp Mechanismus eine gute Wahl, vorausgesetzt der Overhead durch die Status-Sicherungen hält sich in Grenzen. Wenn die Lookahead-Eigenschaften des Algorithmus gut sind, so ist die Performance der konservativen Mechanismen auch recht gut. Wenn natürlich kaum parallele Berechnungen vorhanden sind und die Lookahead- Eigenschaften auch recht schlecht sind, so bietet keiner der beiden Ansätze eine ansprechende Performance. Nichtsdestotrotz scheint der Time Warp mit einer entsprechenden Hardwareunterstützung für die Status-Sicherungsmechanismen eine gute Allgemeinlösung zu bieten, wie Fujimoto vorschlägt. Seite 16 von 17

17 Quellen [Fuj90] [Fuj00] [Lüt03] Richard M. Fujimoto - Parallel Discrete Event Simulation Communication of the ACM, 1990 Richard M. Fujimoto Parallel and Distributed Simulation Systems Wiley Interscience, 2000 Johannes Lüthi Parallele und verteilte Simulationssysteme Vorlesungsfolien FH Kufstein, 2003 Seite 17 von 17