Untersuchungen zur Implementierung von verteilten Prozesssystemen auf der Grundlage der Distributed Processes

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 23 – 06/1982

Gerhard Kunze

Untersuchungen zur Implementierung von verteilten Prozesssystemen auf der

Grundlage der Distributed Processes

TttU\

02 - -

H k

^{'1 J}

,<<i'ith

/';;, .\;CC11.,r;,,, I ·•.·'.:; J(~ ,,,~_ •

. ::" ~':1 1,:.."7;~

i1 . . ^~

\ \ ! : • HAGEN •):

:s:. ~/.

·r4

_{,:.r{' ..::,~}}

^S:f

·-1tu1~?7

UNTERSUCHUNGEN ZUR IMPLEMENTIERUNG VON VERTEILTEN PROZESSYSTEMEN AUF DER GRUNDLAGE DER DISTRIBUTED PROCESSES

G. Kunze

- 4 -

i N HALTS VER z·E ICH NI S

---

1 EINLEITUNG

1.1 PROBLEMSTELLUNG

1.2 STANr DER WISSENSCHAFT 1.3 ZIF.LSBTZONG

2 DP: EINB NICHTSEQUENTIELLE PROGhM~IBRMETHODIK 2.1 DAS PRINZIP

2.2 PROZFSSZUSTÄNDE UND tlBLRGANGSFUNKTlONEN II~BS DP 2.2.1 PROZESSZUSTÄNDE

2.2.2 UBERGANGSFUNKTIOHEN

Seite

6

b

14 1?

19 21

2 .3 GC / GR: DIE NICHTDETEBMINI.STISCliEN AIHiEISONGßN LEJ.i DP 23

2.3.1 NICHTDETERMINISTISCHE PROGRAliHELEMENTE 2.3.2 SEMANTISCHE BEDEUTUNG DER GC UND GR

2.4 DATENTYPEN UND DETERMINISTISCHE PROGRAMMELEMENTE 2.4.1 DATENTJPEN

2.4.2 DETEBMINlSTlSCHE PROGRAMMELEäENT~

2.5 PROZEDUREN

ra

^DP~

25

33 33 33 35

2.5.1 ALLGEMEINES PROZ:E:DURKOt.~-- _ 35

2.5.2 NICBTREKURSIVE PROZEDUREN 37

2.5.3 LEISTUNGSDEFIZIT, OVERHEAD UND SYSTE~VERKLEMMUNGEN q0

2.6 ZUSAaMENFASSUNG ₄₅

3 VORAUSSE'1:ZUHGEN FbR DIE IMI'LRl'lEliTIERONG ElHES DPS 3.1 KOMMUNIKATION UND SYNCHRONISATION

3 .2 PROZ 'E:SSW ARTESCHI-A.NGF:N UND Pf.:CZ ESSNU'l'ZU NGSRECRTB 3.3 PROZESSARBEITSFÄHIGKEIT

3.4 PEOZESSVERWALTRB 3.5 INTERROPTSYSTEM

3.6 PBOZESSINTERNR PROZRDURAUFROFZ 3.7 EXTERNE PROZEDURAUFRUFE

Seite

51

60 64 66 68 3.7.1 PBOZEDURAOFBOFE OHNE aKTUELLE PAP.AMETEEwERTtlBEhGABE 69 3.7.2 PROZEDURAO~RUPE MIT EINSEITIGER AKTUELLER

PABAMETJfäiERTtlBEBGABE 72

3.7.3 PROZEDURAUFRUFE BIT ~ECHSELSEITIGER AKTUELLER

PARAMETERW~RTUBERGAEE 76

3.7.4 PROZEDURADFROFFOLGEH 77

3. 7 .5 GESCHUTZTE UlWEISUNGSFOLGEN 81

3.7.6 KONSISTENZ. 90

4 STRUKTUR FINES DP-RECBHERS

4.1 ARCHITEKTUR EINES DP-RECHNEF.S -KOMMUNIKATION

4.2.1 ABSTRAKTE MASCHINEN UND VERTEILTE SYSTEME ij.2.2 FUNKTIOhEN DER M1-MASCHIHE

4.2.3 FUNKTIONEN DER MO-MASCHINE 4.3 SCHLUSSBEMERKUNG

5 ANHANG

5.1

5.3

FORMALE SYNTAKTISCHE PiWZESSDBP'INITION IN Bll.F BEISPIELE

LITERATUF.VERZEICHNIS

92 93 96 96 100 104 105

106 1u6

11'+

127

- 6 -

1 EINLEITUNG

1.1 PROBLEttSTELLUNG

Betrachtet man die Rechnerentwicklung in den zurückliegenäen zweieinhalb bis ärei Jahrzehnten, so war diese durch •ctie ·

Verfeinerung und Weiterentwicklung des v~n-i!umann-Re~~ners . . bestimmt. Die Leistungssteigerung, die mit d~~sem Arc~itkturprinz1p erreicht werden konnte war zum einen durch aie Verfeinerung aer Architektur und zum an~eren durch d1e Einführung neuer Technologien bestim111t.

Virtueller Speicher, direkte Speicherzugriffe, Cache, Speicher- verschränkunq, I/O-Kanäle, I/O-Prozessoren, aultiprozessoren,

übergreifende ~peicher-, Leitwerk- und Prozessoroperationen und die Einführung hochintegrierter bipolarer Verarbeitungselemen~e half~n zwar den Flaschenhals, äer durch äie serielle Verarbeitung von Instruktionen und Daten entsteht, temporär durchlässiger zu machen, doch beseitigen konnten sie ihn nicht.

Die Struktur der Programme, die auf einem solchen System ablaufen, ist notwendigerweise striJct sequentiell, d.h. alle Prog:ramm-

anweisungen werden in einer vorgeschriebenen zeitlichen Reihenfolge ausgeführt. Diese Eigenschaft führt dazu, daß viele Probleme, wie Festkörpersimulation, astrophysikalische Berechnungen, Bildver- arbeitung mit hoher Auflösung usw., hinsichtlich.ihrer Berechen- barkeit als ungelöst betrachtet werden müssen, da die heute angebotene Rechenleistung auch von Großrechensystemen um Größen- ordnungen zu klein ist.

Angesichts der architektonischen und physikalischen Grenzen des realisierten von-Neumann-Rechners bleibt die höolichkeit ues

Ausweichens auf parallelverarbeitende Strukturen, u~ so die Leistung von Datenverarbeitungsanlagen wesentlich zu steigern.

Nach mehreren hundert Jahren sequentieller Mathematik, ca. 50 Jahren sequentiellen Algorithmenentvurfs und etwa 25 Jahreü sequentieller Programmierung bedeutet dies nicht nur .Entvurt einer neÜen Rechner- architektur, sondern auch die Abkehr von gewohnten Denkmechanismen und Anschauungsformen.

Obwohl die meisten Vorgän9e der uns u•gebenden realen welt und deren Probleme und Fragestellungen ihrem Ursprung nach parallel sind,

ber~itet es dem aenschen Unbehagen, diese als solche anzunehmen, da sie sich seiner seg·uentiellen Vorstellungskraft entziehen.

Die Abbildung paralleler Vorgänge auf Rechenanlagen setzt neben einer ver!nderten RechnerarchiteKtur höhere Programmiersprachen

voraus, die es ermöglichen, parallele Vorgange mit eim:achen Mitteln a~f diese zu übertragen. Programme, aie in solchen Sprachen abgefaßt sind, werden deshalb als nichtsequentiell bezeichnet, da ihre

Au~fü~ung an keine starre Zc~tliche r.eihentolge gebunden ist. Als Beispiele fnr solche Programmiersprachen sind zu nennen: concurrent Pascai, Mesa, Modula, Chill, CSP, CSSA und Distributed ?rocesses, die Pate standen bei der Formulierung von Aaa, mit der versucht wird eine 0niversalsprache zur Entwicklung von (nichtsequentiellen)

Programmen zu formulieren.

1.2 STAND DER WISSENSCHAFT

Nichtsequentielle Programroe sind im allgemeinen an veneilte

Fechnersysteme gebunden, deren Ziel es ist, durch einen hchen Grad an Paralleli tä.t innerhalb ei.ües aus (möglichst) vielen a.utonom arbeitenden Einheiten bestehenden Systems, ein ~aximu~ an Leistung zu erreichen. BILD l zeigt den Unterschied zwischen der

von-Neumann-Rechnerarchitektur und einer vert~ilten Rechner- architektur. Die zwischen den einzelnen Ele~enten vorhandenen

Steuer- und Datenpfade sind nur angedeutet und äer tlb~rsichtlichkeit wegen nur exemplarisch eingezeichnet.

Die heute bekannten Sprachkonzepte zur parallelen Programmierung bauen auf Rechnerarchitekturen auf, die mehrere Prozessoren

gleichzeitig besitzen, die auf geDieinsamen oder getrennten Speichern operieren. Dabei zeigt sich, daß die für die Entwicklung von

Betriebssystemen bekannten Struktürierungsmethoüen sich auch

tur

die Beschreibung der in einem solchen System ablaufenden parallelen

Aktivitäten eignen. so kann ein verteiltes System als ein System kooperierender Prozesse beschrieben werden, das folgende

Eigenschaften besitzt:

*

jeder Prozeß bildet eine logische Einheit;

*

einheitliche Schnittstellen ges~atten es dem Benutzer, seine Problemlösungen in einem einzigen Programm für das gesamte

Meh~rechner- bzw. Mehrprozessorsystem zu tor~ulieren, unanhangig von der aktuellen Konfiguration;

*

die Kommunikation zwischen den einzelnen f•rozessen wird sprachlich durch den expliziten Austausch von Nachrichten oder durch

prozedurale Zugriffe erreicht;

*

die Synchronisation zwischen den ·frozessen, die iID Bahmen des parallelen Programmgescheh~ns die von der Autgabenstellung her not wendigen zeitlichen Folger ela.tionen erzeugt, kann sowohl direkt durch Angabe bestimmter SynchronisationsfunktioJLen als auch

implizit durch die Einbettung in die Kommunikationsfunktionen erfolgen.

Die meisten nichtsequent1ellen Sprachkonzepte lehnen sich in ihrem algorithmischen Teil stark an bestehende sequentielle Sprach-

definitionen wie Algol oder Pascal an. Daneben enthalte~ einige Sprachen auch Konzepte zuc Modularisierung von Programmen (Module in Modula (WIB 77a) und (iIR 77b), Package in Ada (DOD 79)).

Zwingend für alle ist abec·die Forderuns, Ausdrücke zur Verfügung 2u stellen, die (pseudo-) paralleles Arbeiten per Programm erlauben

(Task in Ada und PEAttL, Prozesse in Modula und Concurrent Pascal).

Eine· wichtige Aufgabe ist deshalb die Synchronisation der parailelen Berechnungen (Semaphore in Algol 68 (WIJ 6"9) und I-EARL (KFK 71), Signale in Modula und Concurrent Pascal) und die Koordinierung

konkurrierender Prozesse beim Zugriff auf gemeinsame t-a ten (Monitore in Concurrent Pascal, Interface ~o&ule in Moäula, Rencezvous in

Ada) •

-8-

Unterbrechungseingänge

Ausgabeprozessor

Eingabeprozessor ----AUSGABEGERÄTE

EINGABEGERÄTE i.---~EXTERNER SPEICHER

a I E rwe ite rte- von-Neumann-Rechnerare hite ktur

E/A-

SCHNITTSTELLE

ElA-GERÄTE

SPEICHER

PROZESSOR

•••

SPEICHER~~ E/A-

SCHNITTSTELLE

PROZESSOR E /A GERA.TE

VERB INOUNGSNETZ WERK

b) Verteilte Rechnerarchitektur

BILD 1

Eine nichtsequentielle Programmiersprache wirQ darum wesentlich danach zu bewerten sein, wie einfach und mächti~ ihre Koordinations- und syr.chronisationsfunktionen sind, um aamit eine ttb€rsichtliche Darstellungsform für Prozeßsysteme aut einer höheren Sprachebene zu ermöglichen.

Dem :C:ntwurf von geeigneten Sprachkonzepter1 fta· n.ichtsequenti.elle Programmiersprachen kommt deshalb eine immer größere Bedeutung zu.

Die in aen letzten fünf bis sechs Jahren vorgestell teL Konzepte und Bntwttrfe unterscheiden sich dabei zum Teil wesentlich in äer Art und Reise, wie die Kommunikation und Synchronisation zwisch~n parallel ablaufenden Prozessen abgewickelt wird una auf welcher Ebene ünd in welchem Umfang die dazu benötigten sprachlichen Hilfs•ittel

bereitgestellt werden.

Die wohl primitivsten und ältesten synchronisationshitismittel sind Dijkstras Semaphore ((DIJ 68a) und (DIJ 68b)). Sie gestatten es, einen gemeinsamen Datenbereich fUr mehrere Prozesse zu definieren

(kritischer Abschnitt) und die darauf arbeitenden Prozesse durch wechselseitigen Ausschluß zu synchronisieren. PFARL (KFK 77) ist ein Beispiel für deren Integration in eine Programmiersprache.

Eine ffeiterentvicklung stellt das von Hoare (HOA 74) eiLgefuhrte und von Brinch Hansen in Concurrent Fascai integrierte aonitorkonzept dar. Die Vorteile der Monitore gegenüber den Semaphoren liegen dabei in der Softwarestrulctur, die klarer und weniger fehlerhaft ist. Der zu treibende Implementierungsaufwand i s t dabei für beide durchaus vergleichbar ( (NEH 80), (LIMa 76)). Der Grundgeaanke, dei: zu den

~onitoren ftthrte, basiert auf der Vorstellung, alle Zugriffs-

funktionen mjt den dazugehörenden Daten eines kritischen ibscnnittes in einer logischen Einheit zusammenzufassen, um so eine saubere und ßbersichtliche Softwarestruktur zu erhalten. Als nützlich erwies sich bei der Monitornotation die Class-Schreibweise aus Simula 67

(DAH 66). Grundsätzlich hat sich beim Umgang mit honitoren gezeigt, daß

*

wegen des Zieles einer maximalen Parallelität in eine•

Prozeßsystem die Monitore nur die zur Prozeßsynchronisation unbedingt notwendigen Anweisungen enthalten dfirfen,

*

alle Anweisungen, die kein Exklusiv.i:·echt verlanyen, in die beteiligten Prozesse zu verlagern sind.

Mit Concurrent Pascal ( (BitI 75a) , (BRI 75b) ) wurde zum ei:st~n:mal eine vollständig formulierte und - was besonäecs wichtig ist - implementierte nichtsequentielle Programmiersprache definiert. In

"The Architecture of Concurrent Progra11s¹¹ (BB I 77) werden gleich drei ko~plette syste11e vorgestellt.

- 10 -

Brinch P.ansen verallgemeinert hier das Konzept der uate~typen aus Wirths Pascal (wIR 71) noch einmal, wenäet es auf Anweisungen an unü paßt das Monitorkonzept in ein allgemeines SprachkoLzept ein.

concurrent Pascal kann für sich in Anspruch nehmen, eine &chte Implementierungssprache zu -sein.

Die Einftthrung von aktiven Datentypen (Prozeß, Monitor, Class) und deren Eigenschaft, passive Datentypen verandern zu können, aber dabei selbst invariant zu sein, gestattet es, nichtsequentielle Programme klar und übersichtlich zu formulieren.

Durch die Verw~naung von ~onitoren als Kommunikations~ittel zwischen Prozessen i~t Concurrent Pascal auf das schmale Anwen~un9sspeKtrum von auf gemeinsamen Speichern arbeitenden Prozessen (Prozessoren) beschränkt. Dadurch können .l'rozesse nur mit~inander Nachrichten austauschen, wenn sie sich aüch einen gemeinsamen Speicher teilen.

Eine solche Einschränkung kann natürlich für verteilte Systeme; die (flberwiegend) getrennte Speicher besitzen, nicht hingenommen werden.

Dies roag wohl die Hauptursache dafür ge~esen sein, ~aß Brinch Bansen auf die Idee kam, ein monitorloses Sprachkonzept zu entwickeln, das auf dem bewährten Prozedur- und Prozeßkonzept vcn Concurrent Pascal aufbaut. Er liefert so auch eine echte Alternative zu den

nachrichtenorientierten SprachKonzepten, deren Kommunikation auf einem expliziten Nachrichtenaustausch zwischen den ko~munizierenden Prozessen beruht. Als Hauptvertreter wäre hier das cs~-Konzept von Hoare (HOA 78) zu nennen, an das verschiedene Konzepte wie etwa CSSA

(FRV 81) angelehnt sind.

Diese Alternative heißt Distributed Processes (Abkürzung fttr Distributed Processes: DP).

DF sind aktive Datentypen, die

*

passive Datentypen enthalten,

*

Zugriffsfunktioneü auf diesen· Datentypen bereitstellen,

*

Zugriffsrechte auf die passiven tatentypen global ouer gar nicht vergeben,

*

aktiv ihre eigenen passiven Datentypen cder äie ttbex globale Zugriffsrechte zugänglichen passiven Datentypen anderer Prozesse verändern, selbst aber invariant sind,

*

mit anderen ~rozessen gemeinsame oaer getrennte Speicherbereiche besitzen.

Die DP gestatten es, durch Prozedu:i:aurrufe l'rozeßk.ommr.nikation

direkt zwischen Prozessen zu treiben, die sowohl cetr€::Ilnte als auch gemeinsame Speicher besitzen können. L>adurch fällt das an gemeinsame Speicher gebundene Strukturmei::.kmal Monitor zur i\.oordinierung und Synchronisierung von Prozessen aus Concurrent Pascal weg una öffnet das Konzept für die Anwendung auf verteilte Syste~e.

Sie stellen so die konsequente ieiterentwicklung des Monitor-

konzeptes dar, da Monitoraufrufe fttr aie Zeit ihres Aufrufes durch einen Prozeß ohnehin nur als unteilbare Aktionen des auf:i:ufenden Prozesses zu verstehen sind, und oestatten es dadurch, reiner&

Synchronisationsfunktionen zu formulieren. Damit·können die DP klar gegen alle bisherigen Konzepte fU:i: nichtsequentielle ~prachen

abgegrenzt werden: ·

*

Semaphore:

Gestatten eine primitive Synchronisation durch wechselseitigen Ausschluß beim Zugriff auf gemeinsame Variablen;

*

Concurrent Pascal:

Erlaubt den Mehrprozeß (-prozessor-) betrieb von Prozessen, die sich ge~einsame Speicherbereiche teilen und sich durch Monitore koordinieren und synchronisieren;

• Modula:

Erlaubt den Mehrprogrammbetrieb auf eine1ri Ein-Prozessor_-system;

*

DP:

Erlauben den Mehrprozeß (-prozessor-) betrieb mit getrennten und gemeinsamen Speicherbereichen.

Nachrichtenorientierte Konzepte sind aufgrund ihrer alldf:-rsa.ctigei.

Struktur in diesem Zusammenhang nicht relevant. Außercem zeigt sich im Umgang mit den verschiedenen Sprachkonzepten, daß aus der Sicht des Anwenders die prozedura~e Interprozeßkommunikation vorteil- hafter ist, da die zugrundeliegenä.e Semantik weseittlic;h einfacher ist als die der nachrichtenorientierten Syste•e, wodurch vor allem die Programmierung an Sicherheit gewinnt.

BILD 2 zeigt ansch~ulich aie unterschiedliche Struktur aes Semaphor-, ~onitor- und DP-Konzeptes.

SEMAPHOR- KONZEPT

PROZESS A

. . .

-12-

PROZESS B

. . .

P(sema) P(sema)

{Zugriffsfunktion F1 } - - -....

--il

GLOBALE OATEN

i...1---

{Zugriffsfunktion F2}

V(sema) V(sema)

. . .

MONITOR - KONZEPT

PROZESS A

• •

•

{ Prozeduraufruf Fl}

.

_•

.

GLOBALE DATEN PROZEDUR Fl PROZEDUR F2

DISTRIBUTED PROCESSES-KONZEPT

PROZESS A

.

• _•

[PROZEDUR Fl]

[PROZEDUR F3]

• •

.

_{. /}

{ Prozeduraufru f F

4}

• •

.

BILD 2

. . .

PROZESS B

• •

•

{Prozeduraufruf

F2}

•

.

•

PROZESS B

• •

•

[PROZEDUR.

[PROZEDUR

• •

. .

F

2]

F

4]

{Prozeduraufruf F3}

• •

.

1.3 ZIELSETZUNG

Die nachfolgenäe Arbeit soll die informelle Sprachbeschreibung der DP ~traffen, Nachteile ö.es .Konzepts aufzeigen und falls möglich diese durch Restriktionen oder E~weiterungen ausr~men,

Inkonsistenzen beseitigen un~ letztendlich zu einem Sprachkern führen, der für eine Implementierung geeignet ist, falls die

hardwaremäßigen Voraussetzungen bereitgestellt werden. Dabei stehen besonders praxisbezogene Aspekte im Vordergrund, da die DP wie

Concurrent Pascal aus der Praxis heraus entwickelt wurden.

Im Kapitel 2 wird das Prinzip der DP vorgestellt und vertiefend behandelt.

Das bedeutet im einzelnen, daß die in (BRI 16a) vorgeser,ene Sprachstruktur (ohne zunächst konkret auf eine mögliche

Implementierbarkeit einzugehen) so dargestellt wird, daß ein klares syntaKtisches und sewantisches Bild der ·sprache entsteht.

Gleichzeitig werden möglichst umfassend alle Randbedingungen herausgearbeitet, die in Blickrichtung auf eine Realisierung des Konzeptes eine Rolle spielen.

um

diesen beiden Zielen Rechnung zu tragen, ist es notwendig, die recht informelle Darstellung in (BRI 78a) durch eine formale zu ersetzen.

Daneben wird untersucht, welche M&ngel und Nachtetle sich aus der Konzeption ergeben, um daraus Schlüsse fßr einen geeigneten

Implementierungsvorschlag zu ziehen.

Aufbauend auf Kapitel 2 wird in Kapitel 3 auf die wesentlichen

Probleme eingegangen, die sich im Hinblick auf eine I~plementierung ergeben.

Kapitel 4 geht dann näher auf die BechnerarchiteKtur eines Systems ein, auf dem Df implementiert werden können, und behandelt einige wichtige Betriebssystemaspekte.

Kapitel 5 stellt den Anhang aer Arbeit car, in dem eine syntaktische Definition der Sprache angegeben wird.

Es soll dabei nicht Sinn und Zweck der Arbeit sein, vollständig ausformulierte Programme anzugeben, sondern sie soll vielmehr Strukturen aufzeigen, die auch in Blickrichtung auf eine

Implementierung des nichtsequentiellen Teiles von Ada eine wesentliche Rolle spielen können.

11s0 eine Arbeit wird eigentlich nie fertig; man muß sie für fertig

erklären, wenn man nach 2.ei t und Umständen das M ^i5g liehe getan hat. ¹¹ Johann Wolfgang von Goethe

- 14 -

2 DP: EINE NICHTSEQUENTIELLE PP.OGRA~MIERI1ETHODIK 2.1 DAS PiINZIP

Ein paralleles und verteiltes Programwsystem besteht aus einer nbeliebigen" Anzahl einzelner Prozesse„ die getrelillte un<1/oder gemeinsame Speicherbereiche besitzen können. Jede~ im System

definierten Prozeß wird umkehrbar eindeutig ein eigener Frozessor zugeordnet, d.h. auf jedem Prozessor läuft genau ein Frczeß (und immer nur dieser) ab. Diese Einschränkung trägt dem Umstand

·Rechnung, daß bei Echtzeitanwendungen, ffir die uas Konzept bestimmt ist, die Forderungen nach

*

Rechtzeitigkeit: Ergebnisdaten lllüssen. zu bestim111ten Zeitpunkten abgerufen werden, und die aus Eingabedaten gewonnenen Ergebnisse mttssen innerhalb einer bestimmten Zeitspanne verffigbar sein, und

*

Gleichzeitigkeit: Echtzeitrechensysteme müsse~ auf parallel sich abspielende Vorgänge in ihre-r ¹¹on:welt¹¹ reagieren, d.h. sie Jllüssen Datenver.lmUpfungsaufgaben so lösen, daß sie nach auHen als

qleichzei tig ablaufend erscheinen f.ßEISPIEL: Im Störungstall entstehen häufig mehrere Unterbrechungswttnscbe gleichzeitig.), erfüllt ·werden. Ein reales System, das mit DP im Echtzeitbetrieb arbeiten soll, muß mit den direkt angeschlossenen Vorgängen

schritthaltend arbeiten und sich den Abläufen ihrer externen Umgebung anpassen.

Durch die umkehrba"r eindeuti9e Zuordnung Prozeß zu Prozessor möchte man erreichen, aaß Interrupts mit dem Ziel einer Proz&ßverdrängung ttberflttssig werden. Dazu muß dann für jedes Ereignis, das durch das Echtzeitsystem erfaßt werden muß, ein eigener Prozeß detiniert

werden. Dabei wird bewußt der Nachteil in Kauf geLommen, daß bei der Nichtaktivierung eines Prozesses auch der dem Prozeß zu~eordnete Prozessor untätig ist.

Es werden folgende Konventionen getroffen:

a) Es gibt keine 9emeinsa111en Variablen zwischen den Prozessen.

Jeder Prozeß kann nur auf seine eigenen, in ihm aefinierten Variablen zugreifen.

b) Ein Prozeß kann seine eigsnen oder die in einem anderen Prozeß desselben Systems definierten Prozeduren aufrufen.

c) Parallel ablaufende Prozesse werden durch besondere sprachliche Konstruktionen, den guarded commands (kurz: GC) und guarded regions (kurz: GR), synchronisiert bzw. wickeln über diese ihre Kommunikation untereinander ab.

d) Rekursive Prozeduraufrufe sind nicht zulässig.

e) Jeder Prozeß wird entweder exklusiv durch seine Frczeß-

ablaufsteue~ung oder durch eine von außen erfolgte Frozedur- anforderung genutzt, oder er befindet sich in einem Warte- zustand.

BILD 3 zeigt blockartig den Aufbau der DP nach· (Blil 18a). Die

Schlüsselworte und Begrenzungszeichen, die zum Sprachumfang gehören, sind dabei fett hervorgehoben.

Ein Prozeß besteht aus einem Vereinbarungsteil tür die zum ~rozeß gehörenden (als global anzusehenden) Prozeduren, dem Deklaration.s- teil und der Prozeßablaufsteuerung.

Die Prozeßablaufsteueruna bestimmt die selbständ.icren Prozeß- aktiv itäten, während die-Prozeduren 'unein~eschränkt zur freien VerfO.gung sowohl der zum selben Prozessystem gehöi:enden DP als auch aer prozeßeigenen Ablaufsteuerung stehen.

Im Deklarationsteil der prozeßglobalen Variablen werden alle

Variablen, die innerhalb des Prozesses allgemein zugänglich sind, definiert.

Die Variablen, die lediglich innerhalb einer Prozedur gUltig sind, werden nur im Deklarationsteil· der jeweiligen Prozedur aufgef uhrt.

Der Initialisierungsteil dient zur Anfangswertbelegung der prozeBglobalen Variablen.

Cl) Cl) ...

u

C CC Q..

C w 1--:::::, CD CC ,-.

Cl)

ci

PROCESS

PROC

~

-

...

1--Cl) Cl z

:::::, CC <

m z

ü:i CC

PROC

...

>

CC :::::, C ...

N C CC A..

1

C,

BEGIN

z :::::, CC ...

:::::,

...

1--cn

....

:::::, .

<(

~

~ cn cn ...

N

C

END

CC Q..

- lö -

< Prozeßname ) .

₁

Deklarationsteil der prozeßglobalen Variablen

( Prozedurname ) t

^{C (}

formale Eingabeparameterliste ) #

( formale Ausgabeparameterliste)

J

J.;

Deklarationsteil der prozedurlokalen V,uiablen

BEGIN

^{(• Prozedur • 1} .

Prozedurkörper

END

( • Prozedur •)

( Prozedurname) {

C

(formale Eingabeparameterliste) #

<formale Ausgabeparameterliste)

J }

i

• •

•

• •

•

.

1

<•

Prozeßablaufsteuerung •l

Initialisierung der prozeßglobalen Variablen

Körper der Prozeßablaufsteuerung

(• Prozeßablaufsteuerung •l

BILD 3

~-2 PROZESSZUSTÄNDE UNL ~BERGANGSFUNKTIOii~N EINES Dt'

Die in einem DP-System (kurz: D~S) definierten DP kennen zwei prinzipiell verschiedene Arbeitsweisen:

Eine durch den Prozeß selbst verursachte (interne} und &ine von außerhalb des Prozesses angestoßene (externe) Arbeitsweise. Brinch Hansen nennt diese unterschiedlichen Arbeitsweisen die beiden

Operationen eines Prozesses.

Wird ein Prozeß gestartet, so beginnt er mit aer Abarbeitung des Initialisierungsteiles und fährt danach in der frozeßablaufsteuerung

(siehe BILD 3) fort. In dieser internen Acbeitsweise bleibt der Prozeß, bis er entweder diese Anweisungsfolge aurchlaufen hat, oder durch eine GR in der weiteren Abarbeitung der Prozeßabl~ufsteuerung verzögert wird. In beide:~ Fällen (beendigung unä Verzogerung) wird·

die Prozeßablaufsteuerung verlassen und der Prozeß zur externen Nutzung freigegeben.

Bei einer von außen angestoßenen Prozeßarbeitsweise wird eine

innerhalb eines Prozesses vereinbarte Prozedur durch einen anderen, im DPS definierten Prozeß a.utgerufen. Dadurch Kann ~in beliebiger Prozeß Prozeduren, die sich in einem anäeren zum selben DFS

gehörenden Prozeß befinden, nutzen.

Die Prozeßablaufsteuerung und die durch einen externe~ Prozedur- aufruf veranlaßte Prozedurabarbeitung sind von außen nicht unter- brechbar (betrachtet man einen beliebigen Prozeß, z.B~ Prozeß A, so bilden alle anderen DP, die zum selben DPS geboren wie Prozeß A, seine äußere Prozeßumgeoung. Der räumliche Begritf naußen" bezieht sich somit immer auf d.iese, den Prozeß A umgebeL.de P:rozeßhttlle).

Der Prozeß wird in jeder der beiden Arbeitsweisen exklusiv genutzt.

Ein Wechsel in der Prozeßarbeitsweise ist sowohl bei der Prozeß- ablaufsteuerung als auch bei der von außen angestoßenen Prozedur- a.barbeitung nur durch deren Beendigung· oder deren VerzögeI.ung durch eine GR möglich.

Ein einmal gestarteter Prozeß terminiert nie, d.h. er befindet sich immer exklusiv entweder in der internen oder externen Arbeitsweise.

Sicher muß man die Frage stellen, warum hier keine dynamische Prozeßerzeugung bzw. -beendigung möglich ist. Als Ant~ort sei

Brinch Hansen zitiert, er schreibt in (BBI

rl),

Seite 26: ¹¹Dyna1rric process deletion certainly complicates the ~eaning ano implementation of a programming language considerably. And since i t seems tobe

unnecessary in many real-time applications, i t is probably wise to e:x:clude i t altogether.n

BILD 4 zeigt den Prozeßzustandsgraphen mit den dazugehör~nden ttbergangsfunktionen, wie sie sich zwangsläufig aus de~

beschriebenen Prozeßarbeitsweisen ergeben.

-18 -

deblockieren

blockieren

., C

C> C C

C a, a,

:m ^~

...

C 1: ^C

...

_:; ^a, a, 0 ^C a,

J:J ::, ^~

>

...

_"'

~ u

~

zuordnen

Ü

Prozeßzustand -Prozeßübergang

BILD 4

2.~.1 PROZESSZUSTÄNDE

DEFINIER'l'

Anfangszustand äes Prozesses.

INTERM

Nach der Initialisierung des Prozesses (start) beginnt die

eigentliche Abarbeitung der Prozeßablaufsteurung. Sie wirl entweder zu Ende geführt (alle zur Prozeßablaufsteuerung g~°'lörenden

Anweisungen sind abgearbeitet), oder sie wird aurch eine GR in ihrer weiteren Ausführung verzögert. In beiaen Fällen wira aer Prozeß zur freien Verfügung fttr von außen kommende Prozeduraufrufe gestellt.

WARTEN

In diesem Zustand ist der Prozeß bereit, von einem anderen Prozeß Prozedurabarbeitungswünsche entgegenzunehmen. Er kehrt in diesen Zustand nach der Abarbeitung der aufgerufenen Prozedur zurück.

Prozesse, die über keine Prozeßablaufsteuerung veL~ügen, sonäern lediglich eine gewisse Anzahl von Variablen mit den dazugehörenden Zugriffsfunktionen (realisiert durch frozeduren) verwalten, gehen nach der Initialisierung sofort in den zusta.nd WAl(J:EN über. Die Werte dieser Variablen können nur durch einen von außen.kommenden Prozeduraufruf verändert werden.

E:X.TERN

Wird eine Prozedur aufgrund der Anforderung eines anderen zum selben DPS gehörenden DP ausgeführt, so wird sie exkiusiv und von außen nicht unterbrechbar abgearbeitet. Dies garantiert der Prozeßzustand EXTERN. Wird diese Prozedur während ihrer Ausführung durch eine GR verzögert, so geht der Prozeß, in dem die Prozedur definiert ist, sofo~t in den Zustand iARTFN über. Durch diese Prozeßfreigabe

werden die Voraussetzungen fttr weitere von außen kommende Prozedur- aufruie oder die Fortsetzung der !-rozeßablaufsteuerung geschaften.

Im Ve~lauf der Prozeßablaufsteuerung oder eines anderen externen Prozeduraufrufes kennen die ~erte der Variablen, die in den

Boole•schen Ausdrücken der GR enthalten sind, so veräfidsrt werden, daß nach der Beendigung oder Verzögerung der Prozeßablaufsteuerung bzw. der Prozedurabarbeitung mit der ursprünglich verzögerten

Prozedu~ausftthrung fortgefahren werden kann. Ist aie Proz&ß-

ablaufsteuerung eines Frozess~ bereits beendet, so können lediglich noch die im Prozeß definierten Prozeduren als Folge von außen

kommender Prozeduraufrufe genutzt werden. Der Prozeß wird danL nur noch zwischen den Zuständen ~ARTEN, EXTERN und, falls nötig,

BLOCKIERT EXTERN alternieren.

BLOCKIEBT INTERN

Die Behandlung (geschachtelter) e:x.teruer Irvz&duraufruf e, ä. .h. der Aufruf von Prozeduren, die in einem anderen Prozeß aessclben DPS definiert sind, aus dem Zustand I?ITERN neraus, erford~rt vom

- 20 -

Betriebssystem besondere Maßnahmen, die spätex: noch eingehend.er behandelt werden (Analogie: Nested Monitor Calls (LIS?7)). vorab soll folgendes genügen: Erfolgt ein externer Frozeäuraufrut, so wira der aufrufende Prozeß solange blockiert, bis mit riex: Abarbeitung der aufgerufenen Prozedu:c begonne~ werden kann und diese vollständig durchlaufen ist. Während dieses Zustandes besteht keille

Möglichkeit, den blockierten Prozeß etwa durch einen von außeu kommenden Prozeduraufruf zu nutzen.

BLOCKIERT EXTERN

Der Aufruf einer externen Prozedur aus dem Zustand EXTERN heraus führt in diesen Zustand. Seine Beschre.ibung entspricht der a.es Zustandes BLOCKIERT INTERN.

STOP

Das DP-Konzept gestattet es, per Programm eine nichtdeterministische Abarbeitung der DP zuzulassen (Näheres später). Unter anderem wird dazu das GC "if" zur Verfügung gestellt (siehe (tIJ 75)). Wird bei der Abarbeitung dieser Anweisung festgestellt, äaB keine der in ihr enthaltenen Bedingungen erfttllt ist, so wird das gesamte DPS oaer

bei Bedarf auch nur der einzelne Prozeß atgehalten. Das DPS besitzt dadurch Kontrollmechanismen, die es ihm gestatten, beim Eintreten

fbzw. Nichteintreten) gewisser Ereignisse das gesamte lautende Programmode~ auch nur Teile (einzelne Prozesse) anzuhalten, je nachdem, welche Maßnahmen abhängig von der Progra~mstruktur

notwendig werden. Auf die weiteren Konsequenzen, die ein solcher Abbruch zwangsläufig mit sich bringt, g~ht Brinch Hansen nicht ein.

auch bleibt offen, welche Art des Abbruches watn zu wählen ist, ti.h.

in welchem Fall nur ein Prozeß unä wann das gesamte DiS. angehalten werden muß. Dieser Unterschied muß.deshalb nachfolgend eingehend untersucht werden.

BEISPIEL 5 : Resource Scheduler aus (BBI 7ßa), Seite 937.

process resource;

var free:boolean;

proc reguest;

begin

when free=true : free:=false end end;

proc release;

begin

if free=false : free:=true end

(* AnhaLten des Prozesses, wsnn ein berei~s freies Betriebsmittel nochmals freigegeben werden soll.*)

end;

begin

free:=true end.

2.2.2 tlBERGlNGSFUNKTIONEN

starten

Bewirkt den S~art des·Prozesses, d.h. es wiid mit der Abarbeitung des Initialisierungsteiles, der auch leer sein kann, begonnen. Bei Prozessen mit einer Ablaufsteuerung wird mit cter:en Abarbeitung fortgefahren (INTERN). Fehlt diese Jedoch in einem Prozeß, so wird anschließend die Ubergangsfunktion "beenden" ausgeführt.

beenden

Sind alle Anweisungen der Prozeßablaufsteuerung vcllständig abgearbeitet, so steht der Prozeß nur noch externen Prozedur- aufrufen zur Verfügung.

verdrängen

Rird die Prozeßablaufsteuerung oder eine von außen angestoßeLe

Prozed.urabarbeitung durch eine GR verzögert, so wird der Prozeß zur Nutzung fttr weitere exte:t:ne Prozeduraufrufe f:t:eigegeben. Die

Verzögerung. einet: durch externen Prozedu.rautruf genutzten Prozedur ist nicht _gleichzusetzen mit ihrer Beendigung, trotz des erzwungenen Zustandswechsels.

zuordnen

Wurden die liierte der Variablen einzelner Bedingungen t::-:iner GR, die die Prozeßablaufsteuerung bzw. eine von außen verursachte

Prozedurabarbeitung bisher an der weiteren Ausftthrung hinderte, so veränäert, daß eine Fortsetzung möglich ist, so bewirkt diese

Funktion, daß der Prozeß mit der Abarbeitung der Prozf:J3-

ablaufsteuerung bzw. einer von außen angestoßenen (und verzögerten) Prozeüurabarbeitung fortfahren kann.

Die Ausführung der Prozeßablaufsteuerung und eine durch externen Aufruf angestoßene Prozedurabarbeitung sind dabei völlig gleich- berechtigt, d.h. es gibt keine Vorrangregelung bei der Zuteilung des Prozessors.

- 22 -

2nfordern

Soll eine Prozedur des Prozesses äurch einen externen Prozeduraufruf genutzt werden, so veranlaßt aiese r·unktion die dazu notwendigen organisatorischen Maßnahmen.

freigeben

Ist eine von außen veranlarlte Prozedurabarbeitung beendet, so wird der Prozeß zur weiteren Futzung zur Verfßgung gestellt.

blockieren

Ruft die Frozeßablaufsteuerung oder eine extern genutzte Prozedur eine in einem anderen Frozeß aefinierte Prozedur auf, so muß sie auf deren Beendigung wart~n. Es genUgt nicnt, daß äer aufgerufene externe Prozeß durch eine GR bedingt verzögert wird unä als Folge davon der entsprechende Prozeß in den zustand WARTEN übergeht.

d.eblockieren

Ist die aufgerufene externe Prozedur beendet, so kehrt äer aufrufende Prozeß in den zustand INTERN bzw. EX'.t"ERN zurück.

anhalten

Ist bei der Abarbeitung der if-Anweisung keine der in ihr enthaltenen Bedinqunge·n ertüllt, so bricht diese Funktion die

Abarbeitung des Prozesses ab und führt ihn in den zustand STOP über.

Je nachdem, in welcher Umgebung der Prozeßabbruch erfolgte, muß das gesamte laufende DPS oder nur der einzelne Prozeß erneut gestartet werden. Ein Neustart des DPS ist sicherlich immer dann notwendig, wenz;. die Fehlersituation es nicht mehr gestattet, aas oi:,s korrekt weiter ablaufen zu lassen.

2.3 GC / GR : DIE NICHTDETER~INISTISC&EN ANWEISUNGEN DER DP 2.3.1 NICHTDETERMINISTISCHE PROGRAMMELEMENTE

Seit man in der Informatik begonnen hat, sich intEnsiv Gedanken über die Natur paralleler Prozesse zu ~achen und diese auf Rechenanlagen abbildet, stellt sich immer mehr die Notwendigkeit heraus, nicht- detet.minierte Arbeitsweisen i.m Programm bewuß"t 2.uzulassen. Es i.st zwar nach wie vor möglich, jedes einzelne Programm für sich statisch als eine sequentielle Anweisungsfolge niederzuschreiben und so

seinen Aufbau darzustellen. sein Ablauf hingegen ist aber bereits in dieser ~hase der Programmerstellung nicht mehr vorhersagbar: ßr ist nichtdeterminiert.

Diese Programmiermethodik unterscheidet sich von der rein

sequentiellen Programmierung dadurch, daß Entscheidungsschritte in einer wohldefinierten Weise offen gelassen werden, um diese der ausführenden äaschine zu ii.berlassen (Scheduling-Strategie) oder um sich erst zu einem späteren Zeitpunkt festlsgen zu müssen.

Andererseits muß man ein Programm aber als determiniert bezeichnen, wenn es bei d.enselben Eingabedaten und unte:i: "beliebigenn Zeit- bedingungen stets dieselben äefinierten Endzustande erreicht.

Fordert man neben dem parallelen Ausfßhrungscharakter der Prozesse deren Ablauffähigkeit auf verteilten Systemen, so erx:eicht man durch die im Programm enthaltenen nichtdeterministischen Ausführungs-

schritte die notwendige Flexibilität, um die volle LeistuLgsbreite des Systems auszunutzen.

Dijkstra (DIJ 75) hat als erster 1975 solche non-determinisms

(guarded commands) vorgeschlagen: Aus einer Men~e von Möglichkeiten wird ~abei beliebig eine ausgewählt und zur Ausführung gebracht. Die in einem DPS verwendbaren nichtdeterm1nistischen Anweisungen sind die guarded comma~ds (kurz: GC) und die guaräed regions (kurz: GR).

Die GR unterscheiden sich vo~ den GC durch die Fähigkeit, eine

Prozedurausftthrung oder die Prozeßablaufsteuerung bis zum Eintreten bestimmter Ereignisse verzögern zu können.

An dieser Stelle muß nun kurz etwas zu der in der Literatur verwendeten Terminologie bezüglich der nichtdeterministischen Anweisungen gesagt werden:

Dijkstra schreibt in (DIJ 75), Seite 454, ^%U den GC:

nNote that a guarded command by itself is not a state~ent: i t is a component of a guarded co11111and set from which sta.tements can be constructed.n

Konseguenterw~ise folgt Seite 453 daraus:

" guarded-commands = guard

-->

9uaräed-list ".

- 24 -

Brinch Hansen hingegen schreibt in (BRI 7~a), Seite 935, flber die GC:

" Non-determinism will be controlled by two kinds of statements calleci. guardea commands and guaraed regions •¹¹

So ergibt sich auf derselben seite:

n The guarded commands have t:he f olloll"ing .s ynta:x: an d s,eaning:

if :S1 do B1

: S 1 : S 1

I I

B2 : S2 B2: S~

...

^end

...

^end"·

Während bei Dijkstra die GC Teile einer Menge sind, deren Elemente ihrerseits Teil einer Afiweisung sind, werden tei Brinch liansen die if- und da-Anweisung zusall'menfassend als GC .bezeichnet.

Der GC-Begriff steht so einmal für die Möglichkeit einer alte:rnativen Auswahl, während er zum anderen die i f - und d.o- Anweisung unter einem gemeinsamen Oberbegriff zusammenfaßt.

Neben diesen hier beschriebenen Anwendungen finöet der Begrixf Kommando bekanntlich auf der Ebene der Kontrollsprachen eine weitverbreitete Verwendung. Bine Abarbeitungsanweisung innerhalb eines Programms wird hingegen meistens als Anweisung b~zeichnet.

Bei einigen Programmiersprachen (JOSS, BASIC, APL) siLd Teile aer Steuersprache als S~bset in diese integriert. Aber auch dann ist es, der einheitlichen Sprechweise wegen, sinvoll, nur die

Produktionsrichtung

statement = command

unä nicht deren Umkehrung zuzulassen.

Wird im folgenden von GC gesprochen, so ist das die Abkurzung für guarde.d command statements.

Analog verhält es sich mit den GR, fUr die es bisher kein Äguivalent in der Literatur gibt. Der Begriff GR soll als Abkürzung tür guarded region statements stehen.

Die Syntax der nichtdeterministischen Anweisungen, dargestellt in Backus-Naur-Form, ist dem Anhang (Kapitel 5.1) zu entnehmen.

Beachte: Im Anhang steht die metasprachliche Bezeichnung guarded command für die Sprachkonstruktion

guard n:n guarded-list

2.3.2 SE~ANTISCHE EEDEOTUNG DER GC UND GR i f - A n w e i s u n g ~C)

Die if-Anweisung dient der Beschr€ibung von Alternativen, unter denen der Prozeß genau eine auswählen und zur Ausführung_ bringen kann.

Liefert eine oder liefern fflehrere der in der if-Anweisung enthaltenen 5edingungen (guards), qie mit Hilfe Boole•scher

Ausdrucke beschrieben werden, den 'rfert ntrue", so wird beliebig aus der Menge der zu diesen Bedingungen gehörenden Anweisungsfolgen

(guarded lists) eine ausgesucht und zur A.usführung gebracht.

Der Einfachheit halber wird im folgenäen nur noch von erfüllten bzw.

nicht erfüllten Bedingungen gesprochen, je nachdem, ob aie

entsprechenden Boole•schen Ausdrücke die iierte 11truen bzw. "talse11 liefern.

Nach der Abarbeitung dieser geschützten Anweisungsfolge wird mit der n~chsten Anweisung fortgefah:i::en, äie auf die if-Anweisung folgt.

Ist zu Beginn der Abarbeitung der if-Anweis-ung keine öer in ihr enthaltenen Bedingungen erfüllt, so wird der Prozeß, in dem die hnweisung steht, angehalten (Näheres folgt).

BILD 10 a) zeigt die graphische Darstellung äe~ if-Anweisung.

BEISPIEL 6 : Anwendung des if-Statements.

if X> 10: a :=-b I y

<

5 : b := a end

Ist etwa x

=

^{11 und y}

=

4, so haben die Eoole'scheu Ausdrücke x

>

10 und l < 5 den Wert ¹¹true^{11 •} welche der Anweisungen a := b oder b := a ausgeführt wird, hängt von der Art ufid Weise ab, wie der ausfßhrende Rechner solche Anweisungen abai:beitet. Für den Anwender darf die Reihenfolge keine Rolle spielen.

d O - An W e i S U n g (GC)

Die do-Anweisung ist eine Wiederholunqsanweisung. Die Anzahl der Schleifendurchgänge hängt davon ab, wie lange es Bedingungen in der Anweisung gibt, die den wert ¹¹true¹¹ liefern.

Analog der if-Anweisung wird aus der Menge der erfüllten Bedingungen beliebig eine, der zu dieser Menge gehörenden geschützten Anweisungsfolgen, ausgesucht unu zu:i:: Ausfuhrung gebracht.

- 2b -

Dieser Vorgang wiederholt sich so oft, wie es EtüinguLgtn gibc, die den iiert "truen liefern. t.,s Jtann also auch sein, ä.aß keine Anweisung ausgefuhrt werden kann, wenn nämlich zu Beginn der AbtirLeitung keine Eedingunq erfttllt war. In beinen Fällen wird in der Prozeß-

abarbeitung mit der unmittelbar auf die da-Anweisung folgenden Anweisung fortgefahren.

BILD 10 b) zeigt die graphische Darstellung der do-Anweisung.

BEISPIEL 7 : Anwendung der ao-Anweisu~g

do b = ^{1 • :} z := z + 1; read (b) l b = eoln : skip end.

Solange b = • • (Space) ist, wird aer Zählerz um eins erhoht.

Ist b jedoch end of line (eoln) ,· felgt eine leere änweisung (skip), und die da-Anweisung ist beendet.

Ist aber zu Beginn der Abarbeitung b weder• • noch eoln, so wird sofort die nächstfolgende knweisung ausgeführt.

w h e n - A n w e i s u n g (GR)

---

Der Prozeß sucht sich beliebig aus der Menge aer Beclingungen, die den Wert 11truen liefern, eine

zu

diesen bedingu:r..gen gehörende

geschützte Anweisungsfolge aus und bringt sie zur Ausführung. Nach der erfolgten Abarbeitung der geschßtzten Anweisungsfelge ist die Anweisung abgearbeitet.

Ist dagegen bei Beginn de:c Abarbeitung keine Bedingung erfüllt, so wird die Abarbeitung der when-Anweisung zurückgestellt und der Prozeß fnr andere Aktivitäten feigegeben. Die weitere Abarbeitung der when-Anweisung kann erst dann erfolgen, wenn ^im Verlauf der nachfolgenden Prozeßausführuug mindestens eine ihrer Bedingungen aen wert ntruen liefert.

BILD 10 ^c) zeigt die dazugehörende graphische Dar&tellung.

BEISPIEL 8 : Anwendung der when-Anweisung

when s

<=

^{1 :} s

:=

s - ¹ I s = O : s := 1 end

Ist zu Beginn keine der Bedingungen s

<=

^{1 bzw.} s

=

O erfüllt, so wird die Abarbeitung ~er Anweisung solange zurnckgestellt, bis mindestens eine Bedingung den \iert ntruett liefert.

c y c 1 e - A n w e i s u n g (GR)

Die Boole•schen Ausdrucke dieser Anweisung wer:aen in einer endlosen Schleife ständig auf den wert "true11 getestet, und aus der !'lenge der Bedingungen, die den we:rt ¹¹tr:uen lieferu, wir<l beliebig eine der dazugehörenden geschützten Anweisungsfolgen ausgesucht und zur Ausfßhrun~ gebracht.

Ist zu einem beliebigen Zeitpunkt der AusfUhrung der ianweisung keine der Bedingungen erfüllt, so wird die weitere Abarbeitung der cycle- Anweisung zurückgestellt und der Prozeß fur andere Aktivitäten frei~egeben.

Die Anweisung wird erst dann wieder ausführbar, wenn l..li Verlauf der Prozeßabarbeitung die Werte de:r Variablen de:r Boole¹schen Ausdrücke von mindestens einer P.eö.ingung der Anweisung so verändert worden sind, daß die Bedingung bei einer erneuten Berechnung den wert 11truen liefert.

BILD 10 d) zeigt die dazugehörende Darstellung.

BEISPIEL 9 : Anwendung der cycle-Anweisung

cycle insert = true : k := ^k + 1 ; insert := false ena

Liefert die Variable insert den iert ¹¹truen, so wird der Zähler k

um

eins erhöht und insert auf nfalse¹¹ gesetzt. Anschließend wird der Prozeß für weitere Aktivitäten feigegeben; in äeren Verlauf insert wieder ntruen gesetzt werden kann.

Bemerkungen zu BILD 10:

Die Darstellung sequentieller Pro9ramme mit Hilfe üormierter Symbole (DIN) ist ein erprobtes und geeignetes Mittel, um einen Program~- aufbau transparent und Obersichtlich zu gestalten. Die in (DIN) festgelegten graphischen Sinnbilder werden wie folgt erweitert:

*

Geschlossene Einfach-Ellipse: Grundsymbol für Ge.

*

Offene Doppel-Ellipse: Grunäsymbol für GB.

Dem nichtdeterministischen Verhalten der beiden Sprachelemente wird graphisch dadurch Rechnung getragen, daß so viele Exor-Kanten

(Exor-Kante: Liefern gleichz~itig mehrere Bedingungen den Wert ntruen, so erfolgt die weitere Prozeßabarbeltung immer nur entlang einer, aus dem Grundsym.ool herausftthrenä.en Kante, die beliebig ausgewählt wird) von äem Grundsymbol ausg~hen, wie Bedingungen in der jeweiligen Anweisung vorhandeu sind. Die die Bedingungen

repräsentierenden Boole•schen Ausc.rücke werden an die jeweilige Exor-Kante geschrieben. Eine Exor-Kan te enciet in der a.er Bedingung zugeordneten geschützten Anweisungsfolge. Das BEISPIEL 11 zeigt eine Anwendung der neu eingeführten graphischen Symbole.

- 2 8 -

B1

S 1 S 2

•••

S n-1 S n S 1 S 2 • • • • S n-1

a) if - Anweisung

b) da-Anweisung

S 1 S 2

•••

^Sn-1 S n

____ T ___ . --~---.,_ _____ _

C) when - Anweisung

d) cycle-Anweisung

B 1 - Bn : Boole'sche Ausdrücke ("': exo r Auswahl S 1 - Sn: Geschützte Anweisungsfolgen

BILD 10

Betrachtet man die Darst.ellungen 1.n BILD 10 etwas genauer, so känn man feststellen, daß die vier nichtdeterministischen Anweisungen auf ein nichtdeterministiscnes Sprachelement reduziert werden können.

Dieses Sprachelement soll ncase (tichtdeterministisches case) genanut werden. Es ist:

1)

non-deterministic-case = nncase oftt

*

(guard

"="

guarded-list ";")*

nfou defaul t-stateme &t -part nena.n default-statement-par-c =

* (

deterministic-statement ¹¹ ;n )

*

( default-function n;n)

( transition-function) default-function

transition-function

= continue / restart / break

= verdrängen

1) Metazeichenerklärung siehe Seite 106.

Die ncase-Anweisung erlaubt die neliebigs Auswahl (exor) und

Abarbeitung einer geschützten Anweisungsfol9e aus der t,enge cier

geschützten Anweisungsfolgen, deren zugeordnete Bedingungen cten wert ntruen liefern.

Der für die nichtdeterruinistischen Anweisungen erzeugte Code ist dann äquivalent den folgenden Programmstücken:

i f - A n w e i s u n g ncase of B1:S1;

B2:S2;

Bn:Sn;

fo default-function end;

w h ^{e n -} A ⁿ w ^e i s u n g x:=true

while x do begin x:=false;

ncase of B1:S1;

B2:S2;

end

Bn:Sn;

fo x:=true;

verdrängen end;

Mit Bi: Eoole•scher Ausdruck,

d o - A n w ^e i s u n 9 x:=true

while x do

ncase of B1:S1;

B2:S2;

Bn:sn;

fo x:=false end;

c y c l ^{e -} A ⁿ w ^e i s ^{u n} g while true do_

ncase of B 1: s 1;

B2:S2;

Bn:Sn;

f o v erdr än c;·e n

end;

S i : Geschützte Anweisungsfolge, l<=i<=n, nEIN

ij'; 1.

- 30 -

iird im folgenden jeaoch von der if-, do-, when- cder cycle- 1\.nweisung gesprochen, so bezieht sich dies aufgrund äer .leürzeren Schreibweise immer auf die ursprüngliche Darstellung aer Anweisungen

in (BRI 78a) • .

BEJSP IEL 11 :

Das nachfolgenäe Programmstück soll die Anwendung der eingeführten graphischen Symbole f O.r die GC und GR zeigen. ^Es erfüllt darüber hinaus keine bestimmte Aufgabe.

a) Schreibweise von ¹¹Links nach Rechts"

if Bl:do B2:when B3:cycle B4:S4 end 1 BS:S5 end 1 Bb:S6 end I B7:S7 I B8:call Prozeßname. Prozedurname end, wobei Bi (l<=i<=S) Boole•sche Au5drficke und Si (l<=i<=7) geschUtzte Anweisunqsfolgen sind.

b) Schreibweise 11strukturiertn if B1:

do B2:

when B3:

end

cycle B4: S4 end I BS : SS

I B6 : S6 end

I B7 : S7 l B8 : call Prozesname. Prozedur~ame end

c) Flußdiagramm

81 88

82 86

83 85

S 7 ^call

Prozeßname • Prozedurname S 5

Der wesentliche semantiscne Unterschied zwischen einer GR und P.inem GC besteht also darin, daß eine GR die Ausführung einer Prozedur oder die Prozeßablaufsteuerung solange verzögern itann, bis durch das Eintreten eines oder mehrerer Ereignisse die Werte aer in der relevanten GR enthaltenen Boole'schen Ausdrücke so verändert weräen, daß eine Fortsetzung der betrachteten GR möglich ist. Diese

Eigenschaft spielt auch eine wichtige Rolle bei der Synchronisation der DP in einem DPS. Im Unterschied zu der exklusiven Nutzung eines Prozesses (Sperrsynchronisation) haben wir es dann mit einer

Ereignissynchronisation zu tun.

Wird ein Prozeß durch eine GR verzögert, so bedeutet dies den sofortigen Abbruch der aktuellen Arbeitsweise und den ttbergang in den zustand iARTEU. Durch diese Zustandsänderung werden die

Voraussetzungen dafür geschaffen, daß in der weiteren Folge der Prozeßausführung die Werte einer oder mehrerer Bedingungen so verändert werden .können, daß die GR (wieder) ausführbar wird.

Diese Eigenschaft hat natürlich sehr weitreichende ~olgen im Hinblick auf eine mögliche Implementierung eines DPS, da

beispielsweise für jede when-Anweisung, die in einer Prozedur

auftritt, die Prozedurabarbeitungswttnsche verwaltet werden mßssen, die durch die GR verzögert wurden.

In diesem Zusammenhang stellt sich die Frage nach der logischen Konsistenz der Daten einer Prozedur, wenn diese durch die

ttbergangsfunktion nverdrängen" ve~lassen wir~, d.h. ob die Daten sich in aem Zustand befinden, der von ihnen aufgrund aer

Programmlogik erwartet wira.

Bei Monitoranwendungen (liOA Jq) kennen folgende VerifiKationsregeln angegeben werden:

*

Intialisierung

*

Prozeduraufruf

*

wait-Operation

. . . . . .

true

9 g

*

signal-Operation: g&B

( initial ) ( proced. ure call )

( b.wait )

g g

g&B

( b.signal ) g

Die logische Konsistenz der lokalen ~onitordaten vira durch die Invariante g und die Beschreibung B der bedingten Variaole b gewl§.hrleistet (siehe dazu (LIS 77), (MEH 80)) • ^'ES wird ^ZU

untersuchen sein, inwieweit es möglich ist, solche Verifi~ations- regeln auch fUr DP anzugeben.

Die if-Anweisung wird sicherlich immer dort eine Anwendung finden, wo es darauf ankommt, daß sich Prozesse gegenseitig ßherwachen, um so prozessuales Fehlverhalten untereinander feststelltn zu können.

Sowohl durch die Einführung ~ichtdeterministischer Sprach-

konstruktionen als auch durch das System beüingt, ist aie Reihen- folge der-zeitlichen Abarbeitung eines Prozesses nach seiner Initialisierung nicht mehr vorhersagbar.

BEISPIEL 12 soll den wichtigen Unterschiea zwischen sys~e~bedingter und per Program~ erzeugter nichtdeterministischer Pro~eßabarneitung zeigen.

- 32 -

BEISPIEL 12:

a) Gegeben sind zwei parallel aüstührtare Prozesse P1 und P2 mit folgenden Teilprozessen:

P1

= {A1,

^{A2, A3} und P2}

^{= {}

^{B1, B2}}

Es steht zur Abarbeitung der Prozesse ein Frozessor zur

Verfügung, der beide Prozesse quasi parallel atarbeiten soll, wobei lediglich die Reihenfolge der Teilprozesse

A1 vor A2 vor A3 und Bl vor B~

einzuhalten ist.

Folgende Abarbeitungsfolgen äer Teilprozesse von P1 und P2 sind auf dem zur Verfflgung stehenden Prozessor n.öglich:

f1 = (A 1, A2, A3, B1, E2) f2 = (A 1, E1, A2, A3, b2) f3 = (A 1, A2, B 1, A3, B2) f4 = (A 1, Bl, E2, A2, A.3)

f5 = (A 1, Bl, A2, B2, A3) f6 = (A 1, A2, E 1, B2, A3)

f7 = (B 1, Al, A2, A3, B2) f8 = (B 1, B2, Al, A2, A3) f9 = (B 1, Al, B2, A2, A3) f10 = tB 1, Al, A2, B2, A3)

Welche der zehn möglichen Abarbeitungsfolgen letztlich realisiert

~ird, hängt von der Abarbeitungsstrategie iffi Gesamtsystem ab, in das P1 und P2 eingebettet sind.

b) Gegeben ist ein Feld F (1 • • n) , in das Zahlenwerte vom Typ integer eingelesen werden. Nach dem Einlesen wird äas Feld in. einer

aufsteigenden Folge sortiert.

Lösung 1: Sequentielles Pascalprogramm program sort;

type feld = array (1 •.• 4) of integer;

var i , j : integer;

help: integer;

F: feld;

begin

for i:=1 to 4 do read (F(i));

for i :=1 to 3 do for j:=1 to 4 do i f F (i)

>

^{F tj) then} begin end.

Lösung 2: DP-Programm program sort;

F: array (~) int;

begin

do F ( 1)

>

^{F (2)}

F (2)

>

^{P' (3)}

F (3)

>

F (4) end

end.

. . _. . .

.

help:=F(i); P(i):=F(j); l"'(j):=help end

F(l) ,F(2) :=F (2) ,F(l) F (2) ,F(3) :=F (3) ,F (2) F (3) ,F (4) :=F (4) ,F (3)

I 1

Das Programm terminiert, wenn keine der Bedingungrn F (i)

>

F(j) mit i>j erfüllt ist. Sind zehrere Bedingungen gleichzeitig er±üllt, so wird beliebig eine äavon ausgesucht una die entsprechenne

Anweisungsfolge nach: zur Ausführung gebracht.

2 .4 DATENTYPEN UND DETERMINISTISCHE PROGRAlit1ELE.t1.ENTE 2 .4 .1 DATENTYPEN

Nach Typ ·una Anzahl ist nur eine beschränkte Menge vo~ D~tentyper.

möglich, gerade so viele, wie für die Eeschreibung der parallelen Aktivitäten innerhalb eines DPS notweudig sind. Der Vollständig- keit halber werden diese Datentypen nachfolgend angegeben (siene auch Anhang 5.1).

T :

Ist vom Typ integer (int), characte:c (chai:·), boolean (bool) oder ein andere beliebiger Datentyp.

array ( n) T:

Die Strukturartarray beschreibt Daten, die aus ein.er gegebenen Anzahl n gleichartiger Komponenten vom Typ T bestehen.

set ( n ) T :

Mit diesem Datentyp wird es möglich, mit Mengen zu op~rieren, genauer gesagt, mit den Elementen der Potenzmenge Ober denn gegebenen Elementen vom Typ T.

seq ( n ) 'I' :

Eine Sequenz oder Datei (File) beschreibt Daten, die aus einer variablen (und potentiell unendlichen) Anzahl n von Komponenten des Typs T bestehen, die in einem externen Speicher abgelegt sind.

2~4.2 DETERMINISTISCHE PBOGRAttMELEMBNTE

Die in einem DP-Konzept zulässigen Anweisungen, die einen deterministischen Ausftthrungscharakter besitzen, sind die

*

for-Anweisung,

*

Assignment-Anweisung,

*

Procedure-Anveisung,

*

Empty-Anweisung.

Die Syntax dieser Befehle ist Anhang ~-1 zu entnehmen.

- 34 -

f o r - A n w e i s u n g for x in y : send

Die for-Anweisung ftthrt fßr jedes Element x des Datenty~s y (= set oder array) die Operation Saus.

Nach (BRI 78a) gilt folgende Einschränkung:

Auf den Datenelementen eines :Peldes kennen durch die Optration s schreibende und lesende Zugriffe, auf äie eines set jedoch nur lesende erfolgen.

Die for-Anweisung wird für die Anwendung auf Felder (y vom Typ array) wie folgt erweitert:

nfor" x n:=n initial-element "··" tinal-element ninn y n:n S nend"

Dadurch besteht die Möglichkeit, sich ~ei Bedarf gezi~lt nur mit Teile~ eines Feldes zu beschäftigen, um so die Ausfßhrungs-

geschwindigkeit zu erhöhen (siehe auch Anhang 5.1).

e ~ p t y - A n w e i s u n g

Die leere Anweisung wiLd durch das wortsymbol s ~ i p aargestellt.

BEISPIEL 13 :

for i in gueue: if rank(i)=>min: skip I end;

rank(i)< min: next:=i; ~ih:= rank Ci) end;

Die Elemente des Feldes rank, deren Index i in que:ue ist, werden mit min verglichen. Bei Bedarf wird min veränaert. min ist mit einem beliebigen Wert >O initialisiert.