Einleitung

• Zwei Handlungen sind sequentiell zueinander, wenn die eine die andere voraussetzt; sonst sind sie konkurrent (nebenläufig).
  Beispiel
  • Kaffee kochen, Kaffe trinken: sequentiell
  • Kaffee trinken, Kuchen essen: konkurrent
• Sequentielle Handlungen müssen seriell (hintereinander) ausgeführt werden, konkurrente Handlungen können parallel (zeitlich überlappt) ausgeführt werden.

Also: Konkurrent = potentiell parallel

D.h. Abstraktion von tatsächlicher Ausführungsweise, die in Abhängigkeit von pragmatischen Zwecken und technischen Gegebenheiten verschiedene Formen annehmen kann.

Technische Gegebenheiten

• 1 Prozessor (,,Ausführer``),
• 1 Prozessor + Hilfsprozessoren (z.B. für I/O),
• mehrere Prozessoren mit gemeinsamen Speicher,
• mehrere Prozessoren ohne gemeinsamen Speicher (insbesondere ,,verteilte`` Ausführung mit relativ zeitaufwendiger Kommunikation über Netze).

Ausführungsmodi

• Parallel: ,,echt parallel``
• Serialisiert
• Willkürliche Verzahnung (,,interleaving``) wenn zerlegbar in Teil-Handlungen : ,,pseudo-parallel``; verbreitet im 1-Prozessor-Fall, dabei Strategie nötig (Betriebssystem) wie z.B. ,,round robin`` (Zeitscheibenverfahren); die Strategie der Prozessorzuteilung sollte fair sein (schwieriger Begriff, von uns nicht detailiert betrachtet; nicht notwendig: Jeder kriegt gleich viel Prozessorzeit, aber: Keiner wird unendlich benachteiligt, also eher qualitative als quantitative Perspektive).

Konkurrente Programme, konkurrentes Programmieren

Übliche Programme sind sequentiell, Reihenfolge durch übliche Semantik (z.B. Folge von Anweisungen, getrennt durch ,,;``, oder rechte/linke Seite von Zuweisung) festgelegt.

Typisch organisiert als:
Kollektion von Prozessen (tasks, aktive Objekte) mit eigenen Daten und Handlungen und Kontrollfluß; Prozeß in sich sequentiell, aber konkurrent (überwiegend, s. u.) zu anderen.

Das Problem dann:

Interaktion von Prozessen

• in Kooperation zur Bewältigung einer gemeinsamen Aufgabe.
• in Konkurrenz um gemeinsame Betriebsmittel.

Nicht verwechseln:

• ,,Konkurrent`` (engl: concurrent) = nebenläufig, potentiell parallel
• ,,Konkurrenz`` (engl: competition) = Wettbewerb

Das erfordert:

• Synchronisation, z.B. Zustand erreicht, Betriebsmittel frei, gemeinsamer Start, ...
• Kommunikation, z.B. Austausch von Zwischenergebnissen

Synchronisation ist keine Frage von gemeinsamer Zeit, also von Intervallänge, Dauer, u.ä., sondern einer der Logik; Zeitfehler (,,race conditions``) entstehen, wenn der konkurrente Programmierer sich darauf verläßt, daß Handlung A schneller fertig wird als Handlung B: Das mag stimmen, aber beim nächsten Betriebssystem-Release, der nächsten Hardware-Aufrüstung ungültig werden ...

Zwecke, Anwendungsbereiche

1. Zeitgewinn (oder Steigerung der behandelbaren Problemgröße),
2. Problemadäquate (logische Struktur, technischer Kontext) Systemstruktur,

Wir verfolgen Ziel 2!

Ziel 1: vgl. VL ,,Paralleles Rechnen``; setzt echte Parallelität voraus; typisch: Feinkörnige Parallelität mit großer Regelmäßigkeit, spezielle Algorithmen, spezielle Programmiermodelle (z.B. PRAM-, Datenfluß ...) und Rechnerarchitekturen (massiv parallele Rechner nach SIMD und MIMD Prinzip);

Klassisches Anwendungsfeld: z.B. Numerik für physik.-technische Aufgaben wie Wettervorhersage oder Bildverarbeitung.

Beispiele/Anwendungsgebiete für konkurrentes Programmieren

• Informationsverarbeitung in Stufen (Fließbandprinzip), vgl. Unix pipes
• Benutzer-(Dialog-) und Anwendungssysteme
• Mehrbenutzersysteme
• Verteilte Transaktionen in Datenhaltungssystemen
• Allg. Client-Server-Systeme
• Betriebssysteme
• Rechnernetze, Telematik
• Eingebettete (,,embedded``) Systeme, Echtzeitsysteme

Betriebssysteme
= historisch das Gebiet der Entwicklung konkurrenten Programmierens

Eingebettete Systeme
= Software kontolliert technische Prozesse z.B. Fahrzeugsteuerung, Flugüberwachung ...

Technisches System enthält ,,natürliche`` Parallelität (z.B. Flugzeug = Höhenruder, Seitenruder ...) die abgebildet wird auf konkurrente Softwarekomponenten.

• Wenn die Temperatur im Heizkessel ein vorgegebenes Intervall nach unten (oben) verläßt, wird der Brenner ein- (aus-)geschaltet;
• Wenn die Temperatur im Gebäude ein vorgegebenes Intervall nach unten (oben) verläßt, wird die Umwälzpumpe ein- (aus-)geschaltet;
• Alle diese Aktivitäten werden ausführlich auf dem Monitor des Hausmeisters angezeigt.

Klar:
Softwarelösung sollte reales System widerspiegeln, also aus 3 Komponenten ,,Kessel``, ,,Haus`` und ,,Monitor`` bestehen, die die offensichtlichen Verantwortlichkeiten und Kollaborationen haben:

Lösung mit passiven Objekten

control =

Actual := Kessel_Sensor.Read;

if Actual < Low then

Brenner.On;

Monitor.Write(Clock, Actual, ön");

elsif Actual > High then

Brenner.Off;

Monitor.Write(Clock, Actual, öff");

end if;

Control =
wie oben

und Hauptschleife (,,cyclic executive``):

loop

Kessel.Control;

Haus.Control;

end loop;

Kritik

• Beide Aktivitäten werden mit derselben Häufigkeit (Rate) ausgeführt; aber möglicherweise sinnvoll, verschiedene oder sogar dynamisch änderbare Raten einzuführen (z.B. Kessel genauer überwachen, wenn Brenner angeschaltet ist); diese Forderung ist nur sehr schwer in die Schleifenkonstruktion aufzunehmen!
• Fehler in einer Komponente wirkt auf andere Komponente, z.B. Aufruf von Haus.control terminiert nicht und Kessel eingeschaltet Bumm!
• Schwierig, weitere Aktivitäten in das Programm zu integrieren.

Konkurrente Lösung mit aktiven Objekten (Prozessen)

process Kessel_Control is

Low: Temperature := ...;

High: Temperature := ...;

Actual: Temperature;






begin

loop

Actual := ...;

if Actual < Low then

            ...                - wie oben!

end loop;

end process;






process Haus_Control is

   ...                       - wie Kessel

end process;

start Kessel_Control;

start Haus_Control;

Kritik

• Aufnahme von delay-statements (Verzögerungen) in die Schleife zur Herstellung der gewünschten Wiederholrate; bei 1-Prozessor-time-slicing: Unschärfen unvermeidbar ( später)
• Monitor ist jetzt konkurrent genutzte Ressource, aber verwandtes Schreiben erfordert vermutlich exklusiven Besitz
  spezielles Protokoll nötig, um Chaos zu vermeiden; evtl. Pufferung von Output, um Wartezeiten zu vermeiden.
  

(Protokoll: Vereinbarung über Form (Parameter u.ä.) und Reihenfolge von Operationsaufrufen an Schnittstellen von Objekten ...)

• Grundsätzlich 2 Vorgehensweisen bei konkurrenter Programmierung möglich:
  • sequentielle Programmiersprache plus Dienste eines geeigneten Betriebssystems
  • Konkurrente Programmiersprache

  Unentschieden: Vor- und Nachteile (z.B. Portabilität, Effizienz) beider Vorgehensweisen.
  Einigermaßen klar: Variante 2 sorgt für besser les- und wartbare Programme!

  Wir wählen deshalb Variante 2!

• Es gibt mehrere Sprachen für konkurrente Programmierung, mit unterschiedlichen Mitteln, zum Teil nur akademisch, z.B. Modula (und Pascal Varianten), CHILL, Mesa, CSP, occam, PEARL, LINDA, Ada ...

  Wir nehmen Ada95

  • Relativ wichtig in der Praxis auf diesem Gebiet, vor allem für ,,eingebettete Systeme``,
  • Unterstützt OOP und verteilte Ausführung (Ada95!),
  • Implementierung für gebräuchliche Maschinen/BS (auch PC/Windows95) vorhanden und frei zugänglich (GNAT),
  • Im Haus gelehrt und benutzt.
• Plan der Vorlesung
  • Falls nötig: Kurze Einführung in Ada,
  • Grundprobleme, Lösungen und Konzepte konkurrenter Programmierung,
  • Ada-spezifische Mittel (tasks, rendezvous, protected objects) und ihr Gebrauch,
  • Soweit Zeit reicht: Einblicke in Themen wie real time programming, conncurrency & objects, distributed computing.

Literatur

Skriptum

Kopien dieser Folien schritthaltend mit VL,

Zu Ada

• J. Barnes: ,,Programming in Ada95``, 1996
• J. Skanskolm: ,,Ada from the Beginning``, 2nd ed, 1994
• Website: http://www.adahome.com/, http://www.epfl.ch/Ada/

Wichtigste Quellen zur VL

• M. Ben-Ari: ,,Principles of Concurrent Programming``, 1982
• A. Burns, A. Wellings: ,,Concurrency in Ada``, 1995

Andere Quellen zu Concurrency

• G. R. Andrews: ,,Concurrent Programming``, 1991
• J. Bacon: ,,Concurrent Systems``, 1993
• C.A.R. Hoare: ,,Communcating Sequential Processes``, 1985
• A. Skipo: ,,Concurrent Programming``, 1989
• O. Whiddett: ,,Conncurrent Programming for Software Engineers``, 1987
• T. Axford: ,,Concurrent Programming``, 1989