Programmierung im Grossen. Vorlesung 15: Konkurrente Objekt- Orientierte Programmierung. Volkan Arslan. Überblick. Bertrand Meyer.

Größe: px

Ab Seite anzeigen:

Download "Programmierung im Grossen. Vorlesung 15: Konkurrente Objekt- Orientierte Programmierung. Volkan Arslan. Überblick. Bertrand Meyer."

Nicolas Gerhardt
vor 6 Jahren
Abrufe

1 1 Programmierung im Grossen Bertrand Meyer 2 Vorlesung 15: Konkurrente Objekt- Orientierte Programmierung Volkan Arslan Überblick 3 Ziel / Motivation Grundlagen des SCOOP Modells Beispiele Zusammenfassung und zukünftige Arbeit 1

2 Ziel 4 Erweitere eine pure streng-typisierte, objektorientierte Sprache (Eiffel, ) mit einer einfachen, allgemeinen, und ausdrucksstarken Concurrency und Verteilungs-Modell ( SCOOP) Das SCOOP Modell 5 Simple Concurrent Object-Oriented Programming Concurrency-Mechanimus auf hohem Niveau Vollständige Benutzung von Verebungs- und anderen objekt-orientierten Techniken Anwbar auf viele physikalische Umgebungen: Multiprozessing, Multithreading, verteilte Programmierung, usw. Objekt-orientierte Berechnung 6 Eine Berechnung auszuführen bedeutet bestimmte Prozessoren zu benutzen um bestimmte Aktionen auf bestimmte Objekte anzuwen. 2

3 Wast macht eine Anwung konkurrent? 7 Prozessor: autonome Kontrollfaden, welcher die sequentielle Ausführung von Anweisungen auf einen oder mehreren Objekten unterstützt Kann implementiert werden als: Computer CPU Prozess Thread AppDomain (.NET) Abbildung von Prozessoren auf Computer- Ressourcen mittels (optionale) Concurrency Control File (CCF) Feature-Aufruf (synchroner Aufruf) 8 Grundlege Schema der O-O Berechnung: Feature-Aufruf x.f (a) x: CLASS_X Feature-Aufruf (synchroner Aufruf) 9 Grundlege Schema der O-O Berechnung: Feature-Aufruf x.f (a) x: CLASS_X 3

4 10 Feature-Aufruf (synchroner Aufruf) 11 Grundlege Schema der O-O Berechnung: Feature-Aufruf x.f (a) x: CLASS_X 12 4

5 Separate Feature-Aufruf (asynchroner Aufruf) 13 Grundlege Schema der O-O Berechnung: Feature-Aufruf x.f (a) x: separate CLASS_X 14 Separate Feature-Aufruf (asynchroner Aufruf) 15 Grundlege Schema der O-O Berechnung: Feature-Aufruf x.f (a) x: separate CLASS_X 5

6 Zugriffskontroll-Methode 16 Ziel einer separaten Aufruf muss formales Argument der umschliesen Routine sein: store (b: separate BUFFER [G]; value: G) is -- Store value into b. b.put (value) Um exklusiven Zugriff auf ein separates Objekt zu erhalten, benutze es als Argument eines Aufrufs: buffer: separate BUFFER [INTEGER] create buffer store (buffer, 10) Von Vor-Bedingungen zur Warte- Bedingungen Verträge in Eiffel store (b: BUFFER [G]; value: G) is -- Store value into b. require not b.is_full value /= void b.put (value) ensure not b.is_empty... store (buffer, 10) 17 Wenn b separat ist, wird die Vor-Bedingung zu Warte-Bedingung (anstatt von Korrektheits- Bedingung) Von Vor-Bedingungen zur Warte- Bedingungen Verträge in Eiffel store (b: separate BUFFER [G]; value: G) is -- Store value into b. require not b.is_full value /= void b.put (value) ensure not b.is_empty... store (buffer, 10) 18 Wenn b separat ist, wird die Vor-Bedingung zu Warte-Bedingung (anstatt Korrektheits- Bedingung) 6

7 Synchronisierung 19 Kein spezieller Mechanismus notwig für ein Klient um nach einen separaten Aufruf mit dem Lieferanten wieder zu synchronisieren. Der Klient wird nur dann warten, wenn es notwig ist: x: separate X y: separate Y x.f x.g (a) y.f value := x.some_query if value > 10 then This mechanism is called wait by necessity. Synchronisierung 20 Kein spezieller Mechanismus notwig für ein Klient um nach einen separaten Aufruf mit dem Lieferanten wieder zu synchronisieren. Der Klient wird nur dann warten, wenn es notwig ist: x: separate X y: separate Y x.f x.g (a) y.f value := x.some_query if value > 10 then Wait here Dieser Mechanismus wird wait by necessity genannt. Synchronisierung 21 Kein spezieller Mechanismus notwig für ein Klient um nach einen separaten Aufruf mit dem Lieferanten wieder zu synchronisieren. Der Klient wird nur dann warten, wenn es notwig ist: x: separate X y: separate Y x.f x.g (a) y.f value := x.some_query if value > 10 then Wait here Dieser Mechanismus wird wait by necessity genannt. 7

8 CCF Abbildung von Prozessoren auf physikalische Resourcen 22 Lokalisierung der Prozessoren muss nicht währ der Kompilierungs-Zeitpunkt spezifiziert werden On the fly Spezifikation mittels Concurrency Control File (CCF) creation system "wirth" (4): "c:\prog\appl1\appl1.dll" "einstein" (2): "c:\prog\appl2\appl2.dll" "Current" (5): "c:\prog\appl3\appl3.exe" external Database_handler: "albert_schweitzer" port 9000 ATM_handler: "max_frisch" port 8001 default port: 8001; instance: 10 CCF Abbildung von Prozessoren auf physikalische Resourcen 23 Lokalisierung der Prozessoren muss nicht währ der Kompilierungs-Zeitpunkt spezifiziert werden On the fly Spezifikation mittels Concurrency Control File (CCF) creation system "Current": "c:\prog\appl1\appl1.exe" external Database_handler: "daimler_benz" port 9000 ATM_handler: "duerer" port 8001 default port: 8001; instance: 10 Zwei-Schichten Architektur von SCOOP 24 SCOOP kann auf verschiedenen Umgebungen implementiert werden SCOOP Plattformunabhangig.NET.NET Compact Framework POSIX Threads 8

9 Beispiel: Begrenzte Pufferspeicher 25 separate class BOUNDED_BUFFER [G] inherit BOUNDED_QUEUE [G] Beispiel: Begrenzte Pufferspeicher 26 indexing description: "Encapsulation of access to bounded buffers" class BUFFER_ACCESS [G] feature -- Element change put (q: BOUNDED_BUFFER [G]; x: G) is -- Insert x into q, waiting if necessary until there is room. require not q.full q.put (x) ensure not q.empty Beispiel: Begrenzte Pufferspeicher 27 remove (q: BOUNDED_BUFFER [G]) is -- Remove an element from q, waiting if necessary -- until there is such an element require not q.empty q.remove ensure not q.full feature -- Access item (q: BOUNDED_BUFFER [G]): G is -- Oldest element not yet consumed require not q.empty Result := q.item -- class BUFFER_ACCESS [G] 9

10 Beispiel: Begrenzte Pufferspeicher 28 Verwung der begrentzen Pufferspeicher buffer_access: BUFFER_ACCESS [INTEGER] bounded_buffer: BOUNDED_BUFFER [INTEGER] create buffer_access create bounded_buffer buffer_access.put (bounded_buffer, 25) buffer_access.put (my_bounded_buffer, 50) buffer_result := buffer_acces.item (bounded_buffer) Beispiel: Speise Philosophen 29 separate class PHILOSOPHER inherit GENERAL_PHILOSOPHER PROCESS rename setup as getup undefine getup feature {BUTLER} step is -- Perform a philosopher s tasks. think eat (left, right) eat (l, r: separate FORK) is -- Eat, having grabbed l and r. -- class PHILOSOPHER Klasse PROCESS 30 indexing description: "The most general notion of process" deferred class PROCESS feature -- Status report over: BOOLEAN is -- Must execution terminate now? deferred feature -- Basic operations setup is -- Prepare to execute process operations (default: nothing). step is -- Execute basic process operations. deferred 10

11 Klasse PROCESS (Forts.) 31 wrapup is -- Execute termination operations (default: nothing). feature -- Process behavior live is -- Perform process lifecycle. from setup until over loop step wrapup -- class PROCESS Klasse GENERAL_PHILOSOPHER 32 class GENERAL_PHILOSOPHER create make feature -- Initialization make (l, r: separate FORK) is -- Define l as left and r as right forks. left := l right := r feature {NONE} -- Implementation left: separate FORK right: separate FORK Klasse GENERAL_PHILOSOPHER (Forts.) 33 getup is -- Take any necessary initialization action. think is -- Any appropriate action or lack thereof -- class GENERAL_PHILOSOPHER class FORK 11

12 Klasse BUTLER 34 class BUTLER create make feature count: INTEGER -- The number of both philosophers and forks launch is -- Start a full session. local i: INTEGER from i := 1 until i > count loop launch_one i) i := i + 1 Klasse BUTLER (Forts.) 35 feature -- {NONE} launch_one (p: PHILOSOPHER) is -- Let one philosopher start his actual life. p.live participants: ARRAY [PHILOSOPHER] cutlery: ARRAY [FORK] feature {NONE} -- Initialization make (n: INTEGER) is -- Initialize a session with n philosophers. require n >= 0 count := n create participants.make (1, count) create cutlery.make (1, count) make_philosophers ensure count = n Klasse BUTLER (Forts.) 36 make_philosophers is -- Set up philosophers. local i: INTEGER p: PHILOSOPHER left, right: FORK from i := 1 until i > count loop left := i right := \\ count) + 1) create p.make (left, right) participants.put (p, i) i := i + 1 invariant count >= 0 participants.count = count cutlery.count = count -- class BUTLER 12

13 Weitere Beispiele in SCOOP 37 Aufzugs-Beispiel Produzent-Konsument Beispiel (basiert auf begrenzte Pufferspeicher) Matrix-Multiplikations-Beispiel Distanz Vektor Routing Beispiel Santa-Klaus Beispiel Zusammenfassung 38 SCOOP Modell ist einfach, jech mächtig Vollständige Concurrency (konkurrente und verteilte Programmierung) Vollständige Benutzung der objekt-orientierten Techniken Ein Schlüsselwort: separate Basiert auf Design by Contract Mehrere Plattformen und Architekturen Zukünftige Arbeit und Forschungsrichtungen: Verklemmungs-Vermeidung Erweiterung der Zugriffskontroll-Methode Beweisen von SCOOP Anwungen Erweiterung von SCOOP zur Unterstützung von Echzeit- Programmierung Referenzen 39 SCOOP Webseite: Vorlesung: Concurrent Object-Oriented Programming Studentenprojekte: Zahlreiche Semester und Diplomarbeiten in SCOOP vorhanden Unser Aufenthaltsort: RZ J3 (Clausiusstr. 59) 5 Projekt-Mitglieder (3 Doktoranden, ein Post- Doktorand, Prof. Meyer) 13

14 40 Ende Vorlesung 15 14

Ähnliche Dokumente

Chair of Software Engineering. Bezieher SUBSCRIBERS Ereignis Erzeuger (zb GUI) Chair of Software Engineering. Save_file ROUTINE

Chair of Software Engineering. Bezieher SUBSCRIBERS Ereignis Erzeuger (zb GUI) Chair of Software Engineering. Save_file ROUTINE 1 2 Letzte Aktualisierung: 27. Mai 2004 Programmierung im Grossen Vorlesung 13: Ereignis-Gesteuertes Design Bertrand Meyer Ereignis-gesteuerte Programmierung 3 Vermeiden von glue code 4 Verbreiter PUBLISHERS