[Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 ||...

11
Kapitel 12 Implement ierungsas pekte Die parallele abstrakte Maschine wurde in Zusammenarbeit mit Herbert Kuchen auf einem Transputersystem in OCCAM implementiert. In diesem Buch werden keine Simulationsergebnisse angegeben, da eine detaillierte Analyse von Simula- tionsHiufen den Rahmen des Buches spreng en wiirde. Der interessierte Leser sei auf [Loogen, Kuchen, Indermark, Damm 89J verwiesen, wo erste Simulationser- gebnisse diesel Implementierung angegeben sind. Wir mochten in diesem Kapitel vielmehr einen kurzen Uberblick iiber die Organisation der Implementierung geben und einige Aspekte diskutieren, die in einer Realisierung der abstrakten Maschine behandelt werden miissen und von denen in der Spezifikation der parallelen Ma- schine zunachst abstrahiert wurde. Eine detaillierte Beschreibung und Analyse der Implementierung findet sich in [Kuchen 89J. 12.1 Zielarchitektur und Implementierungsspra- che Der Transputer ist ein Computer-Chip, der aus einem Prozessor, einem Speicher und einer Anzahl Verbindungen zu Peripheriebausteinen und anderen Transputern besteht. Ein Transputersystem setzt sich aus einer endlichen Anzahl von Transpu- tern, die tiber Verbindungskanale - sogenannte 'Links' - miteinander verbunden sind, zusammen. Die Programmierung eines Transputer oder eines Transputersy- stems erfolgt i.a. in OCCAM. OCCAM ist eine imperative Sprache, in der parallele Prozesse deklariert werden konnen, die tiber Kani:ile in synchronisierter Weise mit- einander kommunizieren. Zur Beschreibung von Parallelitat und Kommunikationen enthalt OCCAM spe- zielle syntaktische Konstrukte. Atomare Prozesse sind R. Loogen, Parallele Implementierung funktionaler Programmiersprachen © Springer-Verlag Berlin Heidelberg 1990

Transcript of [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 ||...

Page 1: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

Kapitel 12

Implement ierungsas pekte

Die parallele abstrakte Maschine wurde in Zusammenarbeit mit Herbert Kuchen auf einem Transputersystem in OCCAM implementiert. In diesem Buch werden keine Simulationsergebnisse angegeben, da eine detaillierte Analyse von Simula­tionsHiufen den Rahmen des Buches spreng en wiirde. Der interessierte Leser sei auf [Loogen, Kuchen, Indermark, Damm 89J verwiesen, wo erste Simulationser­gebnisse diesel Implementierung angegeben sind. Wir mochten in diesem Kapitel vielmehr einen kurzen Uberblick iiber die Organisation der Implementierung geben und einige Aspekte diskutieren, die in einer Realisierung der abstrakten Maschine behandelt werden miissen und von denen in der Spezifikation der parallelen Ma­schine zunachst abstrahiert wurde. Eine detaillierte Beschreibung und Analyse der Implementierung findet sich in [Kuchen 89J.

12.1 Zielarchitektur und Implementierungsspra­che

Der Transputer ist ein Computer-Chip, der aus einem Prozessor, einem Speicher und einer Anzahl Verbindungen zu Peripheriebausteinen und anderen Transputern besteht. Ein Transputersystem setzt sich aus einer endlichen Anzahl von Transpu­tern, die tiber Verbindungskanale - sogenannte 'Links' - miteinander verbunden sind, zusammen. Die Programmierung eines Transputer oder eines Transputersy­stems erfolgt i.a. in OCCAM. OCCAM ist eine imperative Sprache, in der parallele Prozesse deklariert werden konnen, die tiber Kani:ile in synchronisierter Weise mit­einander kommunizieren.

Zur Beschreibung von Parallelitat und Kommunikationen enthalt OCCAM spe­zielle syntaktische Konstrukte. Atomare Prozesse sind

R. Loogen, Parallele Implementierung funktionaler Programmiersprachen© Springer-Verlag Berlin Heidelberg 1990

Page 2: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

12.1. ZIELARCHITEKTUR UND IMPLEMENTIERUNGSSPRACHE 339

• die Wertzuweisung: v:= e

- Zuweisung des Ausdruckswertes e an die Variable v -

und zur Beschreibung der Kommunikation von Prozessen

• das Eingabekommando: c?v

- Eingabe eines Wertes von Kanal c in die Variable v -

• sowie das A usgabekommando: de

- Ausgabe eines Ausduckswertes e auf den Kanal c.

Aus den atomaren Prozessen konnen mittels

• sequentieller Komposition (Schltisselwort SEQ),

• paralleler Komposition (Schlusselwort PAR) und

• konditionalen Kompositionen (Schltisselworte ALT, WHILE, IF)

komplexere Prozesse aufgebaut werden.

Parallele Prozesse konnen nur tiber Kan~ile miteinander kommunizieren. Die Kommunikation ist synchronisiert, d.h. nur wenn sowohl der EingabeprozeB als auch der AusgabeprozeB zur Kommunikation tiber einen Kanal bereit sind, kann die Kommunikation erfolgen.

Diese synchronisierte Form der Kommunikation kann schnell zu 'Deadlock'-Si­tuationen fiihren, in denen zwei parallele Prozesse blockiert sind, da beide auf eine Eingabe warten oder beide zur Ausgabe bereit sind.

Der Transputer wurde speziell zur Ausfiihrung von OccAM-Programmen ent­wickelt. Der Prozessor hat Einrichtungen zur Ein- und Ausgabe von Meldungen, die zur Realisierung der Ein- und Ausgabekommandos von OccAM-Prozessen die­nen. Die synchronisierte Kommunikation ist so organisiert, daB ein ProzeB, der zu einer Kommunikation bereit ist, solange warten muB, bis auch sein Kommuni­kationspartner bereit ist. Wartende Prozesse werden deaktiviert und verbrauchen keine Rechenzeit.

Zur Unterstutzung der Ausfiihrung mehrerer paralleler OCCAM-Prozesse auf einem Transputer besitzt der Prozessor einen Hardware-Scheduler. Es ist also moglich, OccAM-Programme auf einem Transputer zu entwickeln und zu testen

Page 3: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

340 KAPITEL 12. IMPLEMENTIERUNGSASPEKTE

und anschlie:f3end nur durch Vedinderung der Konfigurierung auf einem System mit mehreren Transputem zum Ablauf zu bringen.

Kommunikationen zwischen OccAM-Prozessen auf einem Transputer erfolgen iiber KanaIe, die im Speicherbereich verwirklicht werden. Laufen zwei OCCAM­Prozesse auf verschiedenen Transputem ab, so miissen die Kan~jJe zwischen den beiden Prozessen mittels der 'Hardware-Links' der Transputer implementiert wer­den. Eine Kommunikationsverbindung zwischen Transputem wird aufgebaut, in­dem die 'Links' der Transputer verbunden werden. Da jedes Transputerchip nur eine endliche Anzahl (i.a. 4) von bidirektionalen 'Hardware-Links' besitzt und nur ein OccAM-Kanalpaar auf eine Hardwareverbindungt abgebildet werden kann, sind nicht beliebige Konfigurationen von OCCAM-Prozessen so auf Transputer­systeme abbildbar, daB jeder OccAM-ProzeB auf einem eigenen Transputer zum Ablauf gebracht werden kann.

Diese Ausfiihrungen geben natiirlich nur einen kurzen Einblick in die Organi­sation von Parallelitat und Kommunikation in OccAM/Transputersystemen. Eine Sprachdefinition von OCCAM ist in [INMOS 84] gegeben. Genauere Informatio­nen iiber die Sprache OCCAM und ihre Implementierung auf Transputersystemen finden sich in [May 86a/b]. Fiir eine kurze pragnante EinfUhrung sei der Leser auf [Taylor 86] verwiesen.

12.2 Abbildung der abstrakten Maschine auf ein Transputersystem

Die kurze Beschreibung des OccAM/Transputersystems im letzten Abschnitt zeig­te bereits wesentliche Unterschiede zwischen den Kommunikationsmechanismen des Transputersystems und unserer abstrakten Maschine. In der parallelen Ma­schine arbeiten die autonomen Prozessoreinheiten ohne jegliche Synchronisation. Die Kommunikation erfolgt durch Austausch von Nachrichten -lokal in gemein­samen Speicherbereichen und global iiber verbundene 'Ports', die den Links des Transputers entsprechen. In OCCAM sind gemeinsame Variable (shared varia­bles) fUr parallele Prozesse nicht zugelassen. Die einzige Moglichkeit Informa­tionen zwischen Prozessen auszutauschen ist die synchronisierte Kommunikation. Gemeinsame Speicherbereiche und asynchrone Kommunikationen miissen also in OCCAM mittels spezieller Prozesse, die gemeinsame Speicherbereiche "verwalten" bzw. Nachrichten puffem, simuliert werden.

Ein weiteres Problem stellt die beschrankte Anzahl von Hardware-Links auf einem Transputerchip dar. Zur Zeit haben die Transputerchips nur 4 bidirek­tionale Links, iiber die KanaIe zu anderen Transputerchips aufgebaut werden

t zumindest ohne zusatzliche Software

Page 4: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

12.3. ASYNCHRONER NACHRICHTENAUSTAUSCH 341

konnen. Davon wird auf dem Hauptprozessor ein Link fur die ('Keyboard'-) Ein­und (Bildschirm-) Ausgabe benotigt. Wurde man nun Kommunikations- und Re­duktionseinheiten der verschiedenen Prozessorelemente der parallelen abstrakten Maschine auf verschiedenen Transputern, also wirklich parallel, zum Ablauf brin­gen, so ware zur Kommunikation zwischen den beiden Einheiten mindestens ein weiterer Link belegt. Auf dem Hauptprozessor blieben also nur zwei, auf den ubri­gen Transputerchips drei Links fur die Realisation des Netzwerkes der parallelen Maschine. Auf den Transputern, auf denen die Reduktionseinheit implementiert wurde, blieben zudem drei Links unbelegt.

Aus diesem Grund wird in der gegenwartigen Implementierung ein Prozessor­element der abstrakten Maschine auf einen Transputer abgebildet. Da die OCCAM­

Realisation die Kommunikations- und Reduktionseinheit durch parallele Prozesse beschreibt, sind Testlaufe mit echter Parallelausfuhrung der beiden Einheiten fur eingeschrankte Netzwerkrealisationen trotzdem noch moglich.

12.3 Realisierung des asynchronen N achrichten­austausches

Da in OCCAM nur synchronisierte Kommunikationen moglich sind, muB der Nach­richtenverkehr zwischen den Prozessoreinheiten innerhalb eines Prozessorelementes durch gepufferte Kanale realisiert werden. Ein gepufferter Kanal besteht La. aus einem Eingabekanal, einem PufferprozeB und einem Ausgabekanal:

"/ Eingabekanal

Puffer­prozeB I---~

Ausgabekanal

Die Nachrichtenpufferprozesse treten an die Stelle der Nachrichtenwarteschlan­gen in den gemeinsamen Speicherbereichen der abstrakten Maschine. Damit mog­lichst kein ProzeB auf eine Kommunikation wart en muB und dadurch unnotig blockiert wird, haben die Pufferprozesse eine spezielle dezentrale Struktur.

J eder PufferprozeB besteht aus einer endlichen Anzahl von einelementigen Puf­fern, die parallel arbeiten (siehe Bild 12.1). Die Zugriffskontrolle auf die Puffer

Page 5: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

342 KAPITEL 12. IMPLEMENTIERUNGSASPEKTE

PROC buffer ([n]CHAN OF messages in, out) PAR i=l FOR n

[l .. maxmessagelg] BYTE mes in[i] ? mes out [i] mes

Bild 12.1: OccAM-Programm eines Pufferprozesses

liegt bei den Prozessen, die in den Puffer schreiben bzw. aus dem Puffer lesen, in­dem modulo-Zahler bei jedem Zugriff inkrementiert werden und somit immer auf die nachste verfiigbare Pufferzelle zeigen. Auf diese Weise ist es moglich, "zum gleichen Zeitpunkt" in den Puffer zu schreiben und aus dem Puffer zu lesen.

12.4 N etzwerkrealisierung

Die 'Ports', iiber die die Prozessorelemente der abstrakten parallelen Maschine Nachrichten austauschen, entsprechen den 'Links' der Transputerchips. In der ab­strakten Maschine wurde von der Struktur des Verbindungsnetzwerkes abstrahiert, so daB jedes Prozessorelement mit jedem anderen Prozessorelement eine direkte Verbindung hatte. Eine solche vollstandige Vernetzung aller Prozessorelemente ist bei der Realisierung der Maschine auf dem Transputersystem natiirlich nicht mehr fUr beliebige Prozessoranzahlen moglich. Da aber auf jeden Fall eine 10-gisch vollstandige Verbindung aller Prozessorelemente realisiert werden muB, d.h. jedes Prozessorelement muB mit jedem anderen Nachrichten austauschen konnen, miissen Nachrichten durch das physikalisch vorhandene Netzwerk navigiert wer­den. In der englischen Literatur spricht man yom 'routing of messages '.

Die Navigation von Nachrichten durch das Verbindungsnetzwerk ist Aufgabe des Netzwerkadapters. Die Nachrichten, die durch das Verbindungsnetzwerk ge­sendet werden, sind Netznachrichten, d.h. in ihrer erst en Komponente steht die Nummer des Prozessors, fUr den die Nachricht bestimnit ist. Der Netzwerkadapter kann also anhand dieser Komponente entscheiden, ob eine ankommende Nachricht fUr das Prozessorelement bestimmt ist oder weitergeleitet werden muB. Urn zu entscheiden, an welchen Nachbarprozessor eine zu navigierende Nachricht weiter­geleitet werden muB, benotigt der Netzwerkadapter Informationen iiber das Ver­bindungsnetzwerk. In der momentanen Implementierung der parallelen abstrakten Maschine wird ein sehr einfaches statisches Routing-Schema verwendet.

Jeder Netzwerkadapter hat in einem lokalen Speicher eine Routingtabelle, die zu jedem Prozessorelement die Nummer des Nachbarprozessors angibt, an den die

Page 6: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

12.5. PROZEBVERWALTUNG 343

Nachricht fUr das Prozessorelement weitergeleitet werden solI. Durch die Rou­tingtabelle sollte natiirlich ein kiirzester Weg zwischen je zwei Prozessorelementen festgelegt sein. Die Vorteile dieses einfachen Verfahrens sind seine Effizienz und die Tatsache, dafi alle Nachrichten in der Reihenfolge ihr Ziel erreichen, in der sie geschickt wurden, obwohlletzteres fUr unsere Maschine ohne Relevanz ist.

Nachteile des Verfahrens zeigen sich vor allem bei starker Auslastung der par­allelen Maschine, wenn sehr viele N achrichten zwischen Prozessorelementen aus­getauscht werden, die alle iiber ein- und denselben Weg navigiert werden, was zu einer Uberlastung bestimmter Netzwerkadapter fiihren kann. Ein entscheidener Nachteil ist auBerdem, daB dieses Routing-Schema nicht fehlertolerant ist. Durch defekte Prozessorknoten werden alle Nachrichtenwege, die iiber die defekten Kno­ten fUhren, unterbrochen. Alternative Nachrichtenwege werden nicht erkannt.

Diese Nachteile versucht man durch 'dynamische Routing-Schemata' zu um­gehen, bei denen der Weg einer Nachricht nicht statisch vorbestimmt wird, son­dern dynamisch in Abhangigkeit von der Auslastung und Fehlerfreiheit bestimmt wird. Diese Schemata sind zwar komplexer, garantieren aber eine gleichmaBigere Auslastung des Verbindungsnetzwerkes und unterstiitzen die Fehlertoleranz des Systems. Ein effizientes dynamisches Routing-Schema wurde etwa im Kommuni­kationsprozessor der DOOM-Architektur - einer parallelen Architektur fiir eine objekt-orientierte parallele Sprache - [Odijk 87, Annot, van Twist 87] implemen­tiert.

Damit das Einlesen und Ausgeben von Nachrichten iiber die Links parallel bzw. unabhangig voneinander erfolgen kann, haben wir den Netzwerkadapter durch zwei parallele OccAM-Prozesse realisiert (siehe auch Bild 12.2).

Der sogenannte Netzwerkadapter-ein nimmt Nachrichten iiber die Links in Empfang. Wenn eine Nachricht nicht fUr das Prozessorelement bestimmt ist, wird sie iiber einen gepufferten Kanal an den sogenannten Netzwerkadapter-aus weiter­geleitet. Der Netzwerkadapter-aus iibernimmt die Ausgabe von Nachrichten durch Kommunikation iiber die Links. Er hat einen lokalen Speicher bereich, in dem die 'Routingtabelle' abgelegt ist, mittels der er zu Prozessornummern die Nummer des Links bestimmt, iiber den die Nachricht geleitet werden muB.

Die dezentrale Organisation des Netzwerkadapters verhindert auBerdem die Entstehung von 'deadlocks' auf Grund der synchronisierten Linkkommunikationen.

12.5 Proze6verwalt ung

Bild 12.2 zeigt, daB die Kommunikationseinheit in der OccAM-Realisierung leicht umstrukturiert wurde. Fur die Ein- und Ausgabe von Anfrage-, Aktivierungs- und Antwortnachrichten, die in der abstrakten Maschine vom Kommunikationsprozes­sor jeweils nur weitergeleitet werden, existieren in der Implementierung zusatz-

Page 7: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

344 KAPITEL 12. IMPLEMENTIERUNGSASPEKTE

Netzwerk-

adapter

ein

D Arbeits­modus

Programm­speicher

Netzwerk-

adapter

aus

Routing­tabelle

ProzeB­schlange

Informationstabellen

ProzeBmanager

Reduktionsprozessor

Graph

+ lokale Task-warte-

schlan e

+

Bild 12.2 : OccAM-Realisierung eines Prozessorelementes

K o M M U N I K A T I o N S E I N H E I T

R E D U K T I 0 N S E I N H E I T

Page 8: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

12.5. PROZEBVERWALTUNG 345

liche gepufferte Kanale zwischen Netzwerkadapter und Reduktionseinheit. Die ProzeBverwaltung wird yom sogenannten Prozepmanager tibernommen, an den so­wohl die Reduktionseinheit neu generierte Prozesse als auch der Netzwerkadapter­ein die von anderen Prozessorelementen geschickten ProzeBnachrichten tiber ge­pufferte Kanale weiterleitet.

Die Weitergabe von Prozessen an die Reduktionseinheit erfolgt wie in der ab­strakten Maschine nur, wenn die Reduktionseinheit eine entsprechende Mitteilung an den ProzeBmanager macht. An die Stelle des ProzeBanforderungsflags tritt hier aber eine explizite Arbeitsanfragenachricht.

Die Ubermittlung einer ProzeBnachricht an die Reduktionseinheit kann tiber einen ungepufferten Kanal erfolgen, da die Reduktionseinheit nach Senden der Arbeitsanfragenachricht La. auf die Ubersendung eines Prozesses wartet, also zur Kommunikation bereit ist.

Hauptaufgabe des ProzeBmanagers ist natiirlich die Verteilung von neu gene­rierten Prozessen, und die Kommunikation mit anderen Prozessorelementen zur Erzielung einer moglichst gleichmaBigen Verteilung der Prozesse auf alle Prozes­sorelemente.

In der abstrakten Maschine wurde von Algorithmen, die zur DurchfUhrung dieser Aufgaben verwendet werden, abstrahiert. In der Implementierung muB die ProzeBverteilung nattirlich berticksichtigt werden. Die Untersuchung und Analyse verschiedener ProzeBverteilungsalgorithmen und Verfahren zur Arbeitslastbalan­cierung wird sogar eine der Hauptaufgaben fUr die Zukunft sein.

Ein grobe Klassifikation von ProzeBverteilungsstrategien kann in passive und aktive Strategien vorgenommen werden.

Eine passive Prozepverteilung liegt vor, wenn Prozesse nur auf Anfrage an an­dere Prozessorelemente geschickt werden, d.h. der Prozefimanager schreibt neu er­zeugte Prozesse immer in die ProzeBwarteschlange in seinem lokalen Speicher. Pro­zessorelemente ohne Arbeit oder mit geringer Auslastung haben die Moglichkeit an andere Prozessorelemente Arbeitsanfragenachrichten zu senden, auf die Pro­zessorelemente mit hoher Auslastung mit ProzeBnachrichten antworten konnen.

Eine aktive Prozepverteilung bedeutet, daB der ProzeBmanager aktiv Prozesse an andere Prozessorelemente versenden kann. Die Entscheidung, einen ProzeB an ein anderes Prozessorelement weiterzuleiten, erfolgt allein auf Grund der lokal vor­liegenden Informationen, wie etwa die Lange der ProzeBwarteschlange, die Struk­tur des Prozesses (Art und Lage der Argumente) etc.

N atiirlich lassen sich beide Arten der ProzeBverteilung auch kombinieren. Dies erscheint besonders zweckmaBig, da bei geringer Systemauslastung, die insbeson-

Page 9: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

346 KAPITEL 12. IMPLEMENTIERUNGSASPEKTE

dere zu Beginn und gegen Ende der Gesamtberechnung zu erwarten ist, die ak­tive Taskverteilung vorteilhaft erscheint, wahrend bei hoher Systemauslastung ein passives Schema angebrachter sein konnte. Bei geringer Auslastung wird ein pas­sives Schema auf Grund haufiger Arbeitsanfragen arbeitsloser Prozessorelemente mit einen zu hohen Kommunikationsaufwand verbunden sein. Bei einer hohen Auslastung ist zu erwarten, dafi aIle Prozessorelemente geniigend Arbeit haben, so daB die Auslagerung von Prozessen auf andere Prozessorelemente wenig Sinn macht.

In der momentanen Implementierung wird ein sehr einfaches passives Schema verwendet. Zur Vermeidung hoher Kommunikationskosten durch zwecklose Ar­beitsanfragen bei geringer Systemauslastung, werden weitere Arbeitsanfragen von arbeitslosen Prozessoren, die von allen Nachbarprozessoren negative Antworten auf Arbeitsanfragen erhalten haben, fUr bestimmte Zeitintervalle unterdriickt. Wie bereits gesagt, wird die Untersuchung von Prozefiverteilungsstrategien, die auch von der Organisation des Verbindungsnetzwerkes abhangen, eine wichtige Fortset­zung der hier vorgestellten Arbeit sein. Zum SchluB dieses Kapitels mochten wir noch auf einen Aspekt eingehen, der die Implementierung der Reduktionseinheit betrifft.

12.6 Garbage Collection

In der Spezifikation der Reduktionseinheiten der abstrakten Maschine sind wir von einem unendlichen GraphadreBbereich ausgegangen. Zur Bestimmung freier (noch nicht belegter) Graphadressen wurde ein einfacher Zahler (der Graphzeiger) benutzt, der nach jeder Erzeugung eines neuen Graphknotens inkrementiert wurde und somit immer auf die nachste freie Graphadresse zeigte.

In einer Realisation der abstrakten Maschine steht natiirlich nur ein endlicher Graphadrefibereich zur VerfUgung, so daB eine aufwendigere Speicherverwaltung notwendig ist. Insbesondere miissen Graphknoten, die nicht mehr benotigt wer­den, entdeckt und zum Uberschreiben frei gegeben werden. Man nennt diesen Prozefi i.a. 'Garbage Collection'.

Zur 'Garbage Collection' gibt es im wesentlichen zwei Ansatze: 'mark'- und 'scan'-Algorithmen und die 'reference count'-Methode.

Bei der Verwendung des 'mark and scan' Verfahrens erfolgt die 'Garbage Collec­tion' separat zur Berechnung in zwei Phasen:

• In einer Markierungsphase ('mark') werden aIle von der Wurzel der Berech­nung erreichbaren Speicherzellen (Graphknoten) markiert .

• In einer Suchphase ('scan') werden anschlieBend aIle nicht erreichbaren Spei­cherzellen wieder freigegeben, also etwa einer Liste freier Zellen zugefiigt.

Page 10: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

12.6. GARBAGE COLLECTION 347

In einem rein sequentiellen System muB die Berechnung zur DurchfUhrung des 'mark'- und 'scan'-Algorithmus unterbrochen werden. Fiir parallele Architektu­ren gibt es eine Reihe von Ansatzen, die 'Garbage Collection' mittels 'mark' und 'scan' parallel zur Berechnung ausfiihren zu lassen [Hudak, Keller 82] [Ram, Patel 84]. Diese Verfahren sind aber i.a. sehr kompliziert, da sehr viel Aufwand fUr die Synchronisation der 'Garbage Collection' und der Berechnung getrieben werden mu:B.

Bei der 'reference count' Methode enthalt jede Speicherzelle einen Zahler, der die Anzahl der Verweise auf diese Speicherzelle anzeigt. Beim Kopieren oder Loschen von Zeigern wird der ReJerenzenziihler (reference counter) inkrementiert bzw. dekrementiert. Wird ein Zahler Null, so kann die zugehorige Speicherzelle frei gegeben werden.

Vorteile dieser Methode sind, daB 'Garbage Collection' on-the-flyerfolgt und nicht zu unberechenbaren Unterbrechungen der Berechnung fiihrt und daB Objekte unmittelbar, wenn sie nicht mehr erreichbar sind, frei gegeben. werden.

Ein wesentlicher Nachteil besteht allerdings darin, daB zyklische Strukturen, auf die kein weiterer Verweis existiert, nicht entdeckt werden.

Da die Graphstrukturen, die in unserer parallelen Maschine auftreten keine zy­klischen Teilgraphen enthalten, wird in der Implementierung die 'reference count'­Methode zur Speicherfreigabe benutzt. In der Literatur sind im wesentlichen zwei Ansatze zum Einsatz des 'reference counting' in verteilten Systemen beschrieben [Lermen, Maurer 86], [Bevan 87].

Da das in [Lermen, Maurer 86] beschriebene Verfahren zu viele Restriktio­nen vornimmt und mit einem hohen Kommunikationsaufwand behaftet ist, wurde in der OccAM-Realisation der parallelen abstrakten Maschine die in [Bevan 87] vorgeschlagene Methode benutzt, die wir zum Abschlu:B kurz skizzieren mochten.

Der entscheidende Vorteil des Verfahrens von [Bevan 87] ist, daB zur Verwal­tung globaler Referenzen nur beim Loschen einer Referenz eine entsprechende Nachricht geschickt werden muB. Die wesentliche Idee des Algorithmus besteht darin, Referenzen mit Gewichten zu versehen und einer Speicherzelle als Refe­renzzahler die Summe der Gewichte der Referenzen auf die Speicherzelle zuzuwei­sen.

Beim Kopieren von Zeigern bleibt der Zahler in der Speicherzelle unverandert. Der kopierte Zeiger und die Kopie des Zeigers erhalten lediglich als Gewicht die Halfte des urspriinglichen Gewichtes des kopierten Zeigers. Nur beim Loschen von Zeigern mu:B der Zahler in der Speicherzelle urn das Gewicht des geloschten Zeigers dekrementiert werden. An globale Speicheradressen mu:B in diesem Fall also eine entsprechende N achricht gesendet werden. Hinweise zur Implementierung des Verfahrens sind in [Bevan 87] zu finden.

Page 11: [Informatik-Fachberichte] Parallele Implementierung funktionaler Programmiersprachen Volume 232 || Implementierungsaspekte

348 KAPITEL 12. IMPLEMENTIERUNGSASPEKTE

Damit beenden wir den kurzen Uberblick iiber die Organisation der ImpIe­mentierung der abstrakten Maschine auf einem OccAM/Transputersystem und iiber die verschiedenen Aspekte, von denen in der abstrakten Maschine abstra­hiert wurde, die aber in einer Realisierung behandelt werden miissen und weiterer Studien bediirfen.