Programmierung von. Parallelrechnern. Speicher WS 1995/96. Heinz Kredel, Akitoshi Yoshida. Rechenzentrum Universitat Mannheim RUM 46/96

Transkript

1 Programmierung von Parallelrechnern mit gemeinsamem und verteiltem Speicher Programmierpraktikum WS 1995/96 Heinz Kredel, Akitoshi Yoshida Rechenzentrum Universitat Mannheim RUM 46/96

2 Vorwort Das folgende Skript ist aus einer Ausarbeitung von Teilen eines Programmierpraktikums an dem KSR1 Parallelrechner in Mannheim im Wintersemester 1993/94 entstanden. Er umfat hauptsachlich die Pthread und PVM Bibliotheken und Konzepte fur die Programmierung von Parallelrechnern. In dieser Fassung vom Wintersemester 1995/95 wurden diverse Fehler verbessert und die meisten Programmbeispiele werden nun in C++ angegeben. Zu dem FORTRAN, KAP und Optimierungsteil des Praktikums gibt es ein Script vom LRZ Munchen. Fur die Benutzung der Visualisierungstools und der Compiler mussen wir auf die entsprechenden man pages und auf das info System verweisen. Im Anhang benden sich kurze Hinweise zu der Benutzung der Compiler und Auistungen der wichtigsten Header Dateien, Denition Moduln und der verfugbaren Pthread und PVM Funktionen, sowie ein Index. Dieser Text bendet sich auch auf dem FTP Server des RUM ftp.uni-mannheim.de in dem Verzeichniss pub/info/rumdoc in der Datei rum4696.ps.z. Die Beispielprogramme benden sich auf der KSR1 (suparum) in dem Verzeichniss /home/sw/ppkurs. Verbesserungsvorschlage und Fehlerhinweise nehmen wir dankbar entgegen. Wir sind unter der Adresse zuerreichen. Die erste Version des Skripts wurde von Frau Schnell erstellt. Diese Fassung des Skriptes wurde von Christoph Kuhmunch uberarbeitet, der auch mehrere Modula-2 Beispiele nach C++ portiert hat. Mannheim, 24. Mai 1996 Heinz Kredel 1

3 Inhaltsverzeichnis 1 Einleitung 5 2 Shared Memory Computer Nebenlauge Ausfuhrung : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Atomare Bestandteile und Synchronisation : : : : : : : : : : : : : : : : : : : : : : : : : : Annahmen zum Prozessormodell : : : : : : : : : : : : : : : : : : : : : : : : : : : : Explizite Synchronisation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Interferenz : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Programmeigenschaften : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11 3 POSIX threads Threads und Prozesse : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Allgemeines Benutzungsschema : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Uberblick uber die Pthreads : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Header Dateien und Denition Moduln : : : : : : : : : : : : : : : : : : : : : : : : Erzeugung und Beendigung von Pthreads : : : : : : : : : : : : : : : : : : : : : : : : : : : Losung in C++ : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Losung in Modula-2 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Losung in FORTRAN : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Beginn und Ende von Mutual exclusion : : : : : : : : : : : : : : : : : : : : : : : : : : : : Bedingungsvariablen und Mutual exclusion : : : : : : : : : : : : : : : : : : : : : : : : : : Semaphore : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Semaphoren Implementierung : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Barriers mit Semaphoren : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : await mit Semaphoren : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Das Bounded Buer Problem : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 33 4 Distributed Memory Computer Kanale, Senden und Empfangen : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Programmeigenschaften : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Nachrichtenaustausch bei gemeinsamem Speicher : : : : : : : : : : : : : : : : : : : : : : : 41 2

4 5 PVM Parallel Virtual Machine Uberblick uber PVM und die Message Passing Routinen : : : : : : : : : : : : : : : : : : : Denition und Erzeugung von Kanalen : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Packen und Versenden : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Empfangen und Entpacken : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Produzenten Konsumenten Beispiel : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Verteilte Semaphore : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Logische Uhren : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : User und Helper Pthread : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 59 A Benutzung der Compiler 67 A.1 C : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 67 A.2 C++ : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 67 A.3 Modula-2 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 68 A.4 FORTRAN : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 68 A.5 KAP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 68 A.6 PVM : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 69 A.7 Makeles : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 69 B Header Dateien und Denition Moduln 71 B.1 Thread Denition Modul : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 71 B.2 Pthread Denition Modul : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 72 B.3 PVM C Header Datei : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 76 B.4 PVM Denition Modul : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 82 B.5 Header-Datei ERROR.h : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 87 B.6 Header-Datei TYPES.h : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 88 B.7 Header-Datei sema.h : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 88 C Verzeichnis der POSIX thread Funktionen 90 C.1 POSIX threads : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 90 C.2 Mach threads : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 95 Index 96 3

5 Tabellenverzeichnis 2.1 Matrix Multiplikation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Prozesse und Threads : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Ringpuer : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Funktionsschema von PVM : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Request Message Queue : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 59 4

6 Kapitel 1 Einleitung Die Hardware Entwicklung der letzten Jahre und Jahrzehnte hat die Unterstutzung von Timesharing Betriebssystemen, Vektorrechner, Multiprozessor Rechner und Netzwerke von Workstations und PCs gebracht. Eine Konsequenz dieser Entwicklung war es, da nun verschiedene (Berechnungs-) Aufgaben gleichzeitig bzw. nebeneinander bearbeitet werden konnen. Gleichzeitig wurde Software entwickelt, um die gleichzeitige Bearbeitung auszudrucken: Erzeugen und Anstoen von Aufgaben Koordinierung der Ressourcen Synchronisierung des Zugris auf Ressourcen Wir wollen in diesem Kurs eine kompakte Notation (Sprachkonstrukte) zur parallelen Programmierung einfuhren, zusammen mit einer Diskussion der wichtigsten damit verbundenen Probleme (atomare Aktionen, warten auf Bedingungen, Interferenz, Deadlock, Scheduling). Danach besprechen wir die Umsetzung der Sprachkonstrukte mit Pthreads. Im zweiten Teil werden wir eine kompakte Notation zum Nachrichtenaustausch einfuhren und danach die Umsetzung der Sprachkonstrukte mit PVM (Parallel Virtual Machine) besprechen. Voraussetzungen In den Programm Beipielen setzen wir Kenntnisse in einer Programmiersprache (C, C++, Modula-2, FORTRAN) voraus. Literatur Als weiterfuhrende und erganzende Literatur sind die folgenden Bucher zu empfehlen. 1. G.R. Andrews: Concurrent programming: Principles and Practice, Benjamin / Cummings, USA. 2. M. Ben-Ari, Grundlagen der Parallel-Programmierung, Hanser, engl. Principles of Concurrent Programming, Prentice / Hall Int., London, Th. Braunl: Parallele Programmierung, Vieweg,

7 4. M. Brehm, (ed.), E. Hahn, H-D. Steinhofer, Ch. Schaller, R. Schumacher, Nutzung des Parallelrechners SNI-KSR1, LRZMunchen, Erhaltlich von ftp.lrz-muenchen.de in pub/comp/platforms/ksr, Datei ksr-umdruck. 5. M. Brehm, W. Kratzer, Ch. Schaller, Optimierung und Parallelisierung auf dem Parallelrechner SNI-KSR1, LRZ Munchen, Erhaltlich von ftp.lrz-muenchen.de in pub/comp/platforms/ksr, Datei par_guide.ps.z oder 6. Geist et. al.: PVM 3.3 Usersguide, OakRidge,USA. 7. Brinch Hansen: Konstruktion von Mehrproze-programmen, Oldenburg, engl. The Architecture of Concurent Programms, 8. Kendall Square Research: KSR1 C and FORTRAN Programming Manuals, Waltham, USA. 9. A. Schill: DCE Das OSF Distributed Computing Environment, Einfuhrung und Grundlagen, Springer, Heidelberg, A.S. Tanenbaum: Modern Operating Systems, Prentice-Hall, USA. 11. Zobel, Hogenkamp: Konzepte der parallelen Programmierung, Teubner Stuttgart,

8 Kapitel 2 Shared Memory Computer Sequentielle Programme werden in Modula-2, C oder C++ notiert. 2.1 Nebenlauge Ausfuhrung Parallele oder nebenlauge (concurrent) Ausfuhrung von Programm-Satements S 1 bis S n bzw. der Statement-Sequenz S (i) wird durch bzw. con S 1 ::: S n end con i := 1 to n do S (i) end notiert. Dabei werden die Bestandteile der S i bzw. S (i) uberlappend ausgefuhrt. Das con Statement terminiert, wenn alle S i bzw. S (i) Statements terminiert sind. Im folgenden Beispiel werden die Variablen x und y zuerst initialisiert und dann nebenlaug um 1 incrementiert, bevor ihre Summe an z zugewiesen wird. x := 0 y := 0 con x := x +1 y := y +1end z := x + y Variablen, die auerhalb von con deklariert werden, sind global, Variablen, die innerhalb voncon deklariert werden, sind lokal zu dem jeweiligen sequentiellen Programmteil (auch wenn sie den gleichen Namen haben). Eine dritte Art von Variablen sind sogenante private Variablen, die global sind zu den parallelen Programmteilen, die aber in jedem parallelen Programmteilen verschieden sind. Beispiel: Matrix Multiplikation Es seien A B C jeweils n n Matrizen, gesucht ist das Produkt C := A B. Die Matrix C = fc ij g berechnet sich nach der Vorschrift c ij = P n k=1 a ikb kj i j =1 ::: n. Stellt man die Matrixelemente x ij durch die Arrayelemente x[i j] dar, so ergibt sich der Algorithmus in Tabelle

9 con i := 1 to n do con j := 1 to n do VAR s: REAL s := 0:0. for k := 1 to n do s := s + a[i k] b[k j] end. c[i j] :=s end. end Tabelle 2.1: Matrix Multiplikation 2.2 Atomare Bestandteile und Synchronisation Um unerwunschte Uberlappungen zu vermeiden, ist es erforderlich, Programmteile gegenseitig auszuschlieen (mutual exclusion) und gegebenenfalls die Abarbeitungsschritte aufeinander abzustimmen (condition synchronization). Zum Beispiel kann in dem Programmstuck y := 0 z := 0 con x := y + z begin y := 1 z := 2 end end der Wert von x nach der Ausfuhrung 0, 1, 2 oder 3 sein! Die Grund dafur liegt darin, da eine Zuweisung (in der Regel) als eine Folge von `load register' und `store register' Maschinenoperationen implementiert ist. x:=y+z y:=1 z:=2 konnte z.b. durch die folgenden Maschineninstruktionen implementiert sein. load y load imediate 1 load z store y add y, z load imediate 2 store x store z Der Wert in der Variablen z hangt somit von der zeitlichen Versetzung der beiden Instruktionssequenzen ab. Dieses Beispiel fuhrt uns zu der Denition von elementaren oder atomaren Programmteilen. Denition: Ein Programmteil heit Atomare Aktion falls kein Zwischenschritt, kein Zwischenergebnis und kein Zwischenzustand in einem anderen Proze sichtbar ist. Notation: atomic S 1 ::: S n end Bezeichnung: Atomarer Bereich: Bereich innerhalb einer atomaren Aktion. Kritischer Bereich: auch fur atomarer Bereich. Beispiel: Programmlauf auf der KSR1 Programmlauf in einem Interpreter von obigem Beispiel mit und ohne atomic. In den Beispielen werden jeweils die Variablen x und y um 1 bzw. um 2 incrementiert und die Summe x+y wird der Variablen z zugewiesen. 8

10 VAR x, y, z, i: ANY. BEGIN x:=0 y:=0 z:=0 END. i:=0. WHILE i < 50 DO i:=i+1 CON z:=x+y x:=x+1 y:=y+2 END CLOUT("x=") IWRITE(x) CLOUT(", y=") IWRITE(y) CLOUT(", z=") IWRITE(z) BLINES(0) END. Output: x=1, y=2, z=3 x=2, y=4, z=3 x=3, y=6, z=8 x=4, y=8, z=9 x=5, y=10, z=12 x=6, y=12, z=15 x=7, y=14, z=18... Ohne atomic treten alle moglichen Werte auf. In der ersten Zeile zeigt z=3, da sowohl x als auch y incrementiert wurden bevor die Summe x+y gebildet wurde. In der zweiten Zeile zeigt z=3, da die Summe x+y gebildet wurde bevor x oder y incrementiert wurden. In der dritten Zeile zeigt z=8, da zuerst y incrementiert wurde, dann die Summe x+y gebildet wurde und danach erst x incrementiert wurde. i:=0. WHILE i < 50 DO i:=i+1 BEGIN x:=0 y:=0 z:=0 END CON ATOMIC z:=x+y END ATOMIC x:=x+1 y:=y+2 END END CLOUT("x=") IWRITE(x) CLOUT(", y=") IWRITE(y) CLOUT(", z=") IWRITE(z) BLINES(0) END. Output: x=1, y=2, z=0 x=1, y=2, z=0 x=1, y=2, z=0 x=1, y=2, z=0 x=1, y=2, z=0 x=1, y=2, z=3 x=1, y=2, z=0 x=1, y=2, z=0 x=1, y=2, z=3 x=1, y=2, z=0... Mit atomic treten nur noch zwei mogliche Werte auf. In der ersten bis funften Zeile zeigt z=0, da die Summe x+y gebildet wurde bevor x als auch y incrementiert wurden. In der sechsten Zeile zeigt z=3, da die Summe x+y gebildet wurde nachdem x und y incrementiert wurden Annahmen zum Prozessormodell In den meisten Registerbasierten CPU's sind die elementaren Maschinenoperationen oft atomar. Genauer werden wir folgende Annahmen machen. 1. Die Werte der Grunddatentypen (INTEGER, REAL,...) werden als atomare Programmteile geladen bzw. geschrieben. 9

11 2. Werte werden in Register geladen, dann dort bearbeitet und schlielich wieder gespeichert. 3. Jeder Proze hat seinen eigenen Registersatz. (realisiert durch eigene Prozessoren, verschiedene Registersatze oder Kontextswitch). 4. Zwischenergebnisse werden im lokalen Speicher gehalten (eigene Register oder eigener Stack) Diese Annahmen sind oft bei CPU's mit parallelen Ausfuhrungseinheiten fur Berechnungen und Adressdekodierungen nicht erfullt, aber es ist sichergestellt, da das die obigen Annahmen aus Programmsicht erfullt sind. Zum Beispiel auf der KSR1 gilt folgendes: das Laden von Werten in ein Register setzt sich z.b. zusammen aus einem Adreberechnungsschritt und dem eigentlichen Ladeschritt. Diese Operationen werden durch Pipelining uberlappt und es ist nur sichergestellt, da Werte, wenn sie benotigt werden, sich am richtigen Ort benden. Allerdings ist der globale virtuelle Speicher atomar, das heit, nur ein Prozessor kann auf eine Speicherstelle schreiben, erst danach konnen beliebig viele Prozessoren wieder diese Speicherstelle lesen. Fur die Programmierung von Parallelrechnern ergeben sich somit folgende Konsequenzen: 1. Keine Annahmen uber den zeitlichen Ablauf der Operationen machen! Alle Abhangigkeiten explizit abwarten. 2. Falls in einem Programmteil keine globalen Variablen gelesen oder geschrieben werden, ist der Programmteil atomar. 3. Falls bei der Auswertung eines Ausdrucks eine einzige globale Variable nur einmal gelesen oder geschrieben wird, ist die Auswertung atomar. 4. Die Zuweisung zu einer lokalen Variablen x := expr ist atomar, falls die Auswertung von expr atomar ist. 5. Die Zuweisung zu einer globalen Variablen x := expr ist atomar, falls die Auswertung von expr nur lokale Variablen benotigt oder die enthaltenen globalen Variablen nicht von einem anderen Proze beschrieben werden. Zum Beispiel sind die Auswertungen in der Matrix Multiplikation atomar, da die Elemente der Matrizen A und B nur gelesen werden, die Variable s jeweils lokal deklariert ist und die Elemente der Matrix C nur einmal geschrieben werden. 2.3 Explizite Synchronisation Falls explizite Synchronisation erforderlich ist, kann das await Statement verwendet werden. Notation: await B [then S 1 ::: S n ] end Das await Statement ist per Denition ein atomarer Programmteil, das heit, wir konnten ausfuhrlich schreiben atomic await B [then S 1 ::: S n ] end end. 10

12 Der Boolesche Ausdruck B bezeichnet die (Verzogerungs-)bedingung, die erfullt sein mu, bevor die Statements S 1 ::: S n ausgefuhrt werden. Die Ausfuhrung von await mu als atomar verlangt werden, damit in den Variablen, von denen B abhangt, keine Anderungen wahrend der Ausfuhrung der S i sichtbar sind. Insbesondere ist B wahrend der gesammten Ausfuhrung der S i wahr. Das await Statement ist sehr machtig, da B ein beliebiger Ausdruck sein kann, der von dem Zustand vieler Prozesse abhangen kann. Das heit await ist nur sehr aufwendig implementierbar und in der vollen Allgemeinheit nicht ezient. (Eine Implementierung wurde Unterstutzung des Betriebssystems und des Compilers erfordern.) Beispiel: await s>0 then s := s ; 1 end atomic if B then s := s +1end end Interferenz Falls Programmteile nicht atomar sind, konnen die Programmzustande in anderen Prozessen den Zustand in einem Proze beeinussen. Dieses Verhalten nennt man Interferenz. Das Ziel ist es diese Beeinuung zu vermeiden oder die wechselseitigen Beeinussungen zu synchronisieren. Moglichkeiten zur Vermeidung von Interferenz: Wahl von disjunkten Variablen () lokale und private Variablen). Modikation von globalen Variablen nur in atomaren Programmabschnitten. z.b. atomic s global := s global + s local end. Datenduplikation Explizite Synchronisation mit await Statement. z.b. falls zur Ausfuhrung von S die Bedingung B erfullt sein mu: await B then S end. Einfuhrung von Hilfsvariablen, um die Reihenfolge der Zustande zu charakterisieren. (Hilfsvariablen nur mit Zuweisung.) Programmeigenschaften Um uber die Korrektheit von Programmen zu diskutieren, benutzt man die Begrie \Sicherheit" und \Lebendigkeit". Ein Programm ist Sicher, falls keine schlechten (fehlerhaften) Zustande eintreten konnen. Ein Programm ist Lebendig, falls irgendwann alle gewunchten Zustande eintreten. Bei sequentiellen Programmen haben diese Eigenschaften folgende Bedeutung. Sicherheit: partielle Korrektheit, Lebendigkeit: Terminierung. Bei parallelen Programmen kommen folgende Bedingungen hinzu. Sicherheit: keine Interferenz in kritischen Bereichen (mutual exclusion), keine Verklemmung (Deadlock-Freiheit). Lebendigkeit: jeder Programmteil erhalt eine `faire' Chance ausgefuhrt zu werden (fair scheduling). Ein Korrektheitsbeweis fur ein paralleles Programm setzt sich dann zusammen aus Korrektheitsbeweisen fur die sequentiellen Abschnitte (partielle Korrektheit und Terminierung) sowie aus Beweisen fur Interferenz-Freiheit und Deadlock-Freiheit von nebenlaugen Abschnitten, sowie Beweisen fur Fairness des benutzten oder implementierten Schedulings. 11

13 Sicherheit Der Beweis von deadlock-freiheit kann durch Techniken erfolgen, wie sie z.b. in dem Buch von Andrews beschrieben sind. Wenn etwa BAD ein Pradikat bezeichnet, das einen deadlock charakterisiert, so konnte man zeigen, da fur alle Bedingungen (Preconditions) in allen Programmteilen c: c =) :BAD. Womit dann bewiesen ware, da die Bedingung BAD nicht eintreten konnte, das Programm also deadlock frei ware. Eine andere Technik benutzt eine Invariante I, die in allen Programmteilen gilt und zeigt I =) :BAD. Wodurch dann ebenfalls sichergestellt ist, da BAD nicht eintreten kann. Ist das nicht moglich, kann eventuell noch durch sogenanntes exclusion of congurations (u.u. durch explizites await) sichergestellt werden, da keine Interferenz auftritt. Lebendigkeit Bei den Scheduling Strategien werden folgende Begrie unterschieden 1. unconditionally fair for atomic actions. 2. weak fair, unconditionally fair und bei await werden die Bedingungen auch einmal wahr. 3. strong fair, unconditionally fair und bei await werden die Bedingungen unendlich oft wahr. Zur Verdeutlichung der Strategien betrachten wir einige Beispiele. VAR cout: boolean cont:=true con while cont do (* nothing *) end cont:=false end Bei `unconditional fair scheduling' wird auch das Statement cont:=false einmal ausgefuhrt, wodurch dann die while Schleife beendet wird und das con Statement terminiert. Ein unconditional fair scheduling ist z.b. durch round robin Verfahren einfach realisierbar. VAR cont, try: boolean cont:=true try:=false con while cont do try:=true try:=false end await try then cont:=false end end Bei `weak fair scheduling' folgt u.u. keine Terminierung, denn das await Statement wird zwar unendlich oft ausgefuhrt, aber es ist nicht sichergestellt, da in diesem Moment try den Wert true hat. In diesem Fall wird cont nie auf false gesetzt und das while Statement terminiert nicht. Nur bei `strong fair scheduling' folgt die Terminierung, da dann garantiert wird, da das await Statement unendlich oft ausgefuhrt wird und die Bedingung auch unendlich oft den Wert true annimmt. Wie man 12

14 sieht, kann das nur der Fall sein, wenn das await Statement genau zwichen den Statements try:=true und try:=false ausgefuhrt wird. Die Bestimmung dieses Zeitpunkts ist aber nur nach eingehender Analyse des Programmtextes moglich und kann praktisch nicht vom Betriebssystem und dem Laufzeitsystem durchgefuhrt werden. (Ist z.b. nur mit FIFO Queues in Spezialfallen realisierbar.) Eine letzte Lebendigkeitseigenschaft ist der sogenannte live lock. Dabei tut jeder nicht terminierte Proze etwas, aber ohne die Arbeit voranzubringen. Aufgaben Aufgabe 1 Betrachte das Programm VAR u v w x: INTEGER u := 0 v := 1 w := 2 con x := u + v + w u := 3 v := 4 w := 5 end Wieviele Werte kann x annehmen? (unter den obigen Annahmen zum Prozessormodell). Aufgabe 2 Produzenten-Konsumenten Kopierprogramm. Kopiere zwei Vektoren a und b der Lange n 0 mit zwei nebenlaugen Prozessen mit Hilfe eines gemeinsamen Puers `buf'. Mit anderen Worten implementiere buf := a[i], b[i] := buf, fur i von 1 bis n. Losungsvorschlag: VAR buf, p c: INTEGER p := 0 c := 0 con producer consumer end wobei producer: VAR a[1::n] INTEGER while p<ndo await p = c end buf := a[p +1] p := p +1end consumer: VAR b[1::n] INTEGER while c<ndo await p>cend b[c + 1] := buf c := c +1end Ist das Programm deadlock frei? Wenn ja, warum? Hinweis: Zeige, da die Bedingung p c eine Invariante des Programms ist. Zeige dann, da nur die sich ausschlieenden Falle (p = c) und(p > c)moglich sind. 13

15 Kapitel 3 POSIX threads In diesem Kapitel wollen wir die entwickelten Sprachkonstrukte mit POSIX threads implementieren. Die POSIX threads Bibliothek ist enthalten in OSF DCE (Open Software Foundation, Distributed Computing Environment). POSIX bedeutet Portable Operating System IX, ein Standardisierungskomitee von IEEE. POSIX threads sind z.t. implementiert auf Mach (threads) oder auch OS/2 und Windows NT. Wichtig fur eine eziente Implementierung von Threads ist, da threads schon vom Betriebssystem bereitgestellt werden und nicht aufgesetzt sind. 3.1 Threads und Prozesse Threads werden manchmal als \leichtgewichtige" Prozesse bezeichnet, was aber das Konzept nicht genau trit, da es sich bei Threads und Prozessen eigentlich um orthogonale Konzepte handelt: Prozesse \besitzen" und kontrollieren externe Ressourcen (alles auerhalb der CPU, d.h. die processing resource) und Threads \besitzen" und kontrollieren die CPU. Eine Gegenuberstellung von Prozessen und Threads zeigt Tabelle 3.1. Prozesse Adreraum virtueller Anteil am Hauptspeicher globale Variablen synchronisat. Var. oene Dateien Kind-Prozesse Timer Signals Abrechnungsinformation Threads Programmzahler PC Stack Registersatz Kind-Threads Zustandsinformation Tabelle 3.1: Prozesse und Threads Wie Prozesse konnen sich Threads in folgenden Zustanden benden: running blocked der thread wird gerade ausgefuhrt, der thread wartet auf etwas, 14

16 ready terminated der thread ist bereit zur Ausfuhrung der thread ist beendet Allgemeines Benutzungsschema Als allgemeines Benutzungsschema werden in Prozessen diverse Operationen in einer Schleife abgearbeitet. Bei Threads werden meist verschiedene Threads gestartet, die dann diverse Operationen ausfuhren. Prozesse: repeat lese Datei bearbeite Datei until fertig Threads: var buffer, start lese thread start Arbeits thread wait thread termination Anstelle des Lesens einer Datei kommen auch diverse andere langsame Operationen in Frage, z.b. RPC Remote Procedure Call Socket communication, Message Passing Pipe I/O Terminal I/O Hauptspeicher Zugrie. Auch auf Maschinen mit nur einer CPU konnen Threads mit Erfolg eingesetzt werden. Bei 20 Benutzern pro Maschine sind Prozesse gut brauchbar und der Prozessor ist meist ausgelastet. Wenn ein Benutzer von einer Datei liet, kann ein anderer Rechenoperationen durchfuhren. Aber wenn nur noch 1 Benutzer pro Maschine vorhanden ist, ist der Prozessor nicht mehr ausgelastet wenn von einer Datei gelesen wird. Durch den Einsatz von Threads kann man auch hier den Durchsatz erhohen. Daher gewinnt auch bei 1 Prozessormaschinen das Threadkonzept und ihre Programmierung standig an Bedeutung. 3.2 Uberblick uber die Pthreads Die DCE Pthread Software deniert etwa 51 Bibliotheksroutinen. Auf dem KSR1 Rechner besteht die Pthread Software aus etwa 127 Bibliotheksroutinen und C-Preprozessor Makros zusatzlich gibtesnoch etwa 25 Betriebssystemroutinen, die die zugrundeliegenden Mach threads implementieren. Ein Verzeichniss aller Pthread und MACH thread Funktionen auf der KSR1 bendet sich im Anhang C. Im wesentlichen besprechen wir drei Gruppen von Routinen: 1. con... end: Erzeugung und Beendung von pthreads: pthread_create, pthread_join, (pthread_exit, pthread_detach) 2. atomic... end: Begin und Ende von mutual exclusion: pthread_mutex_init, pthread_mutex_lock, pthread_mutex_unlock,(pthread_mutex_trylock) 3. await cond... end: Bedingungsvariablen pthread_cond_init, pthread_cond_wait, pthread_cond_signal (pthread_cond_broadcast) 15

17 Pthreads, Mutexe und Bedingungsvariablen verfugen uber eine ganze Reihe von sogenannten Attributen: bei Pthreads sind das z.b.: Stack Size Priority Scheduling Strategie bei Mutexen z.b.: spinlimit: busy wait befor block und bei Bedingungsvariablen z.b.: div. Flags. Diese Attribute konnen mit weiteren Routinen erzeugt und modiziert werden. Eine letzte Gruppe von Funktionen dient dem Scheduling von Pthreads: pthread_getproc, liefert den Prozessor auf dem der Pthread lauft. pthread_getthread, liefert den zum Pthread zugehorigen Mach thread. pthread_move, verschiebt oder binded einen Pthread zu oder auf einen Prozessor. pthread_procsetinfo, liefert Informationen uber verfugbare Prozessoren Header Dateien und Denition Moduln Bei der Programmierung mit Pthreads werden in C und in C++ Header-Dateien verwendet, in denen die Datentypen und Funktionen der Pthread Bibliothek deniert sind. Die Datei heit pthread.h und mu in jedem C bzw. C++ Programm mit include angesprochen werden. #include <pthread.h> Bei Modula-2 Programmen werden die Denitionen aus dem pthread.md Modul verwendet. Z.B. FROM pthread IMPORT... Das pthread.md Modul ist im Anhang B aufgelistet. 3.3 Erzeugung und Beendigung von Pthreads Im folgenden wollen wir das con S 1 ::: S n end Sprachkonstrukt implementieren. Zur Verfugung stehen uns die Pthread-Funktionen create und join mit den folgenden Spezikationen: 16

18 int pthread_create (pthread_t *thread, pthread_attr_t attr, pthread_func start_routine, void *arg) Erzeugen eines neuen Pthreads. int pthread_join (pthread_t thread, void **status) Warten auf die Beendigung des angegebenen Pthreads. Die Datentypen pthread_t und pthread_attr_t sowie die Funktionen werden im pthread.h Header-File deklariert. Die start-routine mu eine einparametrige Funktion sein: typedef void *(*pthread_func)(void *) Als Attribut kann man ein default-attribut verwenden, das ebenfalls in pthread.h deklariert wird. pthread_attr_t pthread_attr_default und schon initialisiert ist. Nur falls man spezielle Eigenschaften der Pthreads haben mochte, mu man sich diese Attribute mit den entsprechenden Funktionen selbst erzeugen. pthread_create nimmt als Eingabe ein Attribut attr, eine Prozedur start_routine und einen Pointer auf einen Parameter arg, der der start_routine beim Aufruf ubergeben wird. pthread_create hat als Ausgabe einen Pthread Identikator thread, (der z.b. in join wieder gebraucht wird) und einen Error code als Funktionswert vom Typ int (=32 bit int). pthread_join nimmt als Eingabe den entsprechenden Pthread Identikator thread und liefert in status den Funktionswert der start_routine zuruck. Der Funktionswert von pthread_join ist wieder ein Error code. Falls die Aufrufe erfolgreich sind, wird als Error code 0 zuruckgegeben, sonst ein Wert < 0. Die Semantik von e= pthread_create (t, a, f, x) e= pthread_join (t, y) ist somit gleich der Semantik von y= f(x) falls f keine globalen Variablen verwendet oder nur dieser eine Pthread erzeugt wird. Zur Implementierung des con Sprachkonstruktes mussen wir nur noch die Statements S i (Si) in Prozeduren Pi packen. void *Pi (void *i) { Si RETURN NULL Damit ist con S 1 ::: S n end 17

19 e=pthread_create (t1, a, P1, x)... e=pthread_create (tn, a, Pn, x) e=pthread_join (t1, y)... e=pthread_join (tn, y) Wobei t1,..., tn als Variablen vom Typ pthread_t deklariert werden mussen und x und y vom Typ (void *). Aufgabe 3 Implementierung des Programms aus Aufgabe 1. Wir geben im folgenden ausfurlich eine Losung in C++, in Modula-2 und in FORTRAN an. Bei den weiteren Aufgaben werden wir uns allerdings wieder nur auf die Diskussion der Losungen in einer Programmiersprache beschranken Losung in C++ Das C++ Programm ist wie folgt. Die Variablen u, v, w, x werden global deklariert. Die Statements x := u + v + w, u := 3, v := 4 und w := 5 werden in den Funktionen P1, P2, P3, P4 abgearbeitet. Im Hauptprogramm main werden dann die Pthread Variablen deklariert pthread_t t1, t2, t3, t4 und mit pthread_create wird dann die Ausfuhrung der 4 Funktionen angestoen. Anschliessend wird mit pthread_join auf die Beendigung der 4 Funktionen gewartet und danach werden die Werte der Variablen mit cout angezeigt. #include <iostream.h> #include <pthread.h> int x, u, v, w void *P1 (void * arg) { x = u + v + w return arg void *P2 (void * arg) { u = 3 return arg void *P3 (void * arg) { v = 4 return arg void *P4 (void * arg) { w = 5 return arg int main() { 18

20 pthread_t t1, t2, t3, t4 long int i1, i2, i3, i4 void *o1, *o2, *o3, *o4 i1 = 1 i2 = 2 i3 = 3 i4 =4 int i = 0 int e while (i < 10) { i++ u = 0 v = 1 w = 2 e = pthread_create(&t1, pthread_attr_default, P1, &i1) e = pthread_create(&t2, pthread_attr_default, P2, &i2) e = pthread_create(&t3, pthread_attr_default, P3, &i3) e = pthread_create(&t4, pthread_attr_default, P4, &i4) e = pthread_join(t1, &o1) e = pthread_join(t2, &o2) e = pthread_join(t3, &o3) e = pthread_join(t4, &o4) cout << " u = " << u cout << " v = " << v cout << " w = " << w cout << " x = " << x cout << "\n" return 0 Das Programm wird mit compiliert und mit >CC ppauf3.c -o ppauf3 -para >ppauf3 ausgefuhrt. Die Ausgabe konnte etwa wie folgt aussehen. Die Ausgabe x = 3, in der ersten Zeile, zeigt, da die Summe u + v + wvor den Zuweisungen an die Variablen berechnet wurde. Die Ausgabe x = 9, in der zweiten Zeile, zeigt, da zu erst die Zuweisungen an v und w ausgefuhrt wurden, dann die Summe u + v + w berechnet wurde und schliesslich die Zuweisung an u ausgefuhrt wurde. Die Ausgabe x = 12, in der dritten Zeile, zeigt, da zu erst alle Zuweisungen an u, v und w ausgefuhrt wurden und dann erst die Summe u + v + w berechnet wurde. u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 9 u = 3 v = 4 w = 5 x = 12 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 12 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = Losung in Modula-2 Das Modula-2 Programm ist wie folgt. Wie im C++ Programm werden die Variablen u, v, w, x global deklariert. Ebenso werden die Statements x := u + v + w, u := 3, v := 4und w := 5 in den Funktionen P1, P2, P3, P4 abgearbeitet. Im Hauptprogramm tuwas werden dann die Pthread Variablen mit 19

21 VAR t1, t2, t3, t4: pthread_t deklariert und mit pthread_create wird dann die Ausfuhrung der 4 Funktionen angestoen. Anschliessend wird mit pthread_join auf die Beendigung der 4 Funktionen gewartet und danach werden die Werte der Varaiblen mit WriteLong angezeigt. MODULE ppauf3 FROM SYSTEM IMPORT ADDRESS FROM pthread IMPORT pthread_t, attr_default, pthread_create, pthread_join FROM StdIO IMPORT WriteS, WriteLong, WriteNl, WriteFlush VAR u, v, w, x: INTEGER PROCEDURE P1(VAR arg: ADDRESS): ADDRESS (* statement 1. *) BEGIN (*1*) x:=u+v+w RETURN( arg ) (*9*) END P1 PROCEDURE P2(VAR arg: ADDRESS): ADDRESS (* statement 2. *) BEGIN (*1*) u:=3 RETURN( arg ) (*9*) END P2 PROCEDURE P3(VAR arg: ADDRESS): ADDRESS (* statement 3. *) BEGIN (*1*) v:=4 RETURN( arg ) (*9*) END P3 PROCEDURE P4(VAR arg: ADDRESS): ADDRESS (* statement 4. *) BEGIN (*1*) w:=5 RETURN( arg ) (*9*) END P4 PROCEDURE tuwas (* wie der name schon sagt. *) VAR t1, t2, t3, t4: pthread_t i1, i2, i3, i4: INTEGER o1, o2, o3, o4: INTEGER BEGIN (*1*) (*initialize*) i1:=1 i2:=2 i3:=3 i4:=4 u:=0 v:=1 w:=2 (*2*) (*start procedures *) IF pthread_create(t1,attr_default,p1,i1) < 0 THEN END IF pthread_create(t2,attr_default,p2,i2) < 0 THEN END IF pthread_create(t3,attr_default,p3,i3) < 0 THEN END IF pthread_create(t4,attr_default,p4,i4) < 0 THEN END (*3*) (*collect procedures *) IF pthread_join(t1,o1) < 0 THEN (*...*) END IF pthread_join(t2,o2) < 0 THEN END IF pthread_join(t3,o3) < 0 THEN END IF pthread_join(t4,o4) < 0 THEN END (*4*) (*finalize*) WriteS(" u = ") WriteLong(u,0) WriteS(" v = ") WriteLong(v,0) WriteS(" w = ") WriteLong(w,0) 20

22 WriteS(" x = ") WriteLong(x,0) WriteNl WriteFlush (*9*) END tuwas VAR i: INTEGER BEGIN FOR i:=1 TO 10 DO tuwas END END ppauf3. Das Programm wird mit compiliert und mit >make ppauf3 :mtc ppauf3.mi :cc ppauf3.c -para >ppauf3 ausgefuhrt. Das zugehorige Makefile bendet sich im Anhang. Die Ausgabe konnte etwa wie folgt aussehen. Die Ausgabe x = 3, in der ersten Zeile, zeigt, da die Summe u + v + w vor den Zuweisungen an die Variablen berechnet wurde. Die Ausgabe x = 9, in der zweiten Zeile, zeigt, da zu erst die Zuweisungen an v und w ausgefuhrt wurden, dann die Summe u + v + w berechnet wurde und schliesslich die Zuweisung an u ausgefuhrt wurde. Die Ausgabe x = 6, in der dritten Zeile, zeigt, da zu erst die Zuweisung an u ausgefuhrt wurde und dann die Summe u + v + w berechnet wurde. Anschlieed wurden die Zuweisungen an v und w ausgefuhrt. u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 9 u = 3 v = 4 w = 5 x = 6 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = Losung in FORTRAN Das FORTRAN Programm ist wie folgt. Wie im C++ und im Modula-2 Programm werden die Variablen u, v, w, x global deklariert, das bedeutet, da sie in einem common-block abgelegt werden. Die Statements x = u + v + w, u = 3, v = 4 und w = 5 werden in den (externen) Funktionen if1, if2, if3, if4 abgearbeitet (siehe weiter unten). Die default-attribute fur die Pthreads werden aus dem externen common-block pthread_defaults genommen. Im Hauptprogramm werden die Pthread Variablen it1, it2, it3, it4 als Integer deklariert. In einer do-loop wird dann 10 mal mit pthread_create die Ausfuhrung der 4 Funktionen angestoen und mit pthread_join auf die Beendigung der 4 Funktionen gewartet. Anschlieend werden dann die Werte der Varaiblen mit print* angezeigt. program ppauf3 integer i1, i2, i3, i4, istat, i, it1, it2, it3, it4, X ij, iad, imd, icd, ibd, u, v, w, x common /data/ u, v, w, x common /pthread_defaults/iad, imd, icd, ibd external if1, if2, if3, if4 21

23 do 10 i=1,10 u=0 v=1 w=2 call pthread_create(it1,iad,if1,i1,istat) if (istat.ne. 0) print*, 'istat= ',istat call pthread_create(it2,iad,if2,i2,istat) if (istat.ne. 0) print*, 'istat= ',istat call pthread_create(it3,iad,if3,i3,istat) if (istat.ne. 0) print*, 'istat= ',istat call pthread_create(it4,iad,if4,i4,istat) if (istat.ne. 0) print*, 'istat= ',istat call pthread_join(it1,ij,istat) if (istat.ne. 0) print*, 'istat= ',istat call pthread_join(it2,ij,istat) if (istat.ne. 0) print*, 'istat= ',istat call pthread_join(it3,ij,istat) if (istat.ne. 0) print*, 'istat= ',istat call pthread_join(it4,ij,istat) if (istat.ne. 0) print*, 'istat= ',istat print*, 'u = ',u, 'v = ',v, 'w = ',w, 'x = ',x 10 continue end Die Statement-Funktionen werden hier als externe Funktionen deklariert und sind z.b. in der Datei ppauf3sub.f enthalten. integer function if1(iarg) integer iarg, u, v, w, x common /data/u, v, w, x x=u+v+w return end integer function if2(iarg) integer iarg, u, v, w, x common /data/u, v, w, x u=3 return end integer function if3(iarg) integer iarg, u, v, w, x common /data/u, v, w, x v=4 return end integer function if4(iarg) integer iarg, u, v, w, x common /data/u, v, w, x w=5 return end Das Programm wird mit f77 -u -para -o a3 ppauf3.f ppauf3sub.f compiliert und mit 22

24 >a3 ausgefuhrt. Die Ausgabe konnte etwa wie folgt aussehen. Die Ausgabe x = 3, in der ersten Zeile, zeigt, da die Summe u + v + w vor den Zuweisungen an die Variablen berechnet wurde. Die Ausgabe x = 12, in der zweiten Zeile, zeigt, da zu erst die Zuweisungen an u, v und w ausgefuhrt wurden und dann die Summe u + v + w berechnet wurde. Die Ausgabe x = 6, in der dritten Zeile, zeigt, da zu erst die Zuweisung an u ausgefuhrt wurde und dann die Summe u + v + w berechnet wurde. Anschlieed wurden die Zuweisungen an v und w ausgefuhrt. u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 12 u = 3 v = 4 w = 5 x = 6 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 Damit ist die Besprechung der Losungen der Aufgabe in den Programmiersprachen C++, Modula-2 und FORTRAN beendet. Im Folgenden werden wir nur wieder eine Sprache verwenden. 3.4 Beginn und Ende von Mutual exclusion Im folgenden wollen wir das Sprachkonstrukt atomic S 1 ::: S n end implementieren. Zur Verfugung stehen uns die Pthread-Funktionen lock und unlock mit den folgenden Spezikationen: int pthread_mutex_lock (pthread_mutex_t* mux) locken eines mutexes. int pthread_mutex_unlock(pthread_mutex_t* mux) unlocken eines mutexes. int pthread_mutex_init (pthread_mutex_t* mux, pthread_mutexattr_t attr) Initialisierung eines mutex mit gew. Attributen. Die Datentypen pthread_mutex_t und pthread_mutexattr_t sowie die Funktionen werden im Header File pthread.h deklariert. Als Attribut kann man ein default-attribut verwenden. pthread_mutexattr_t pthread_mutexattr_default und schon initialisiert ist. Nur falls man spezielle Eigenschaften der Mutexe haben mochte, mu man sich diese Attribute mit den entsprechenden Funktionen selbst erzeugen. Im Gegensatz zu Pthreads mussen Mutexe vor der Benutzung initialisiert werden. Mutexe dienen der Serialisierung des Zugangs verschiedener Pthreads zu atomaren Bereichen. lock beginnt einen atomaren Bereich und unlock verlat den atomaren Bereich. Falls ein Pthread sich in einem 23

25 atomaren Bereich bendet (zwischen lock und unlock) wird ein anderer Pthread, der einen lock verlangt, blockiert. Nach Ausfuhrung von unlock erhalt genau ein anderer Pthread, der auf einen lock wartet, den lock. Welcher das ist, wird vom Betriebssystem festgelegt. Falls die Aufrufe erfolgreich sind, wird als Error code 0 zuruckgegeben, sonst ein Wert < 0. Im Gegensatz zu unserer ursprunglichen Denition vom atomaren Bereich, bieten die Mutexe die Freiheit, verschiedene kritische Bereiche zu denieren, die sich uberlappen konnen. Einem atomaren Bereich (in der ursprunglichen Denition) entsprache die Verwendung von genau einem Mutex fur alle kritischen Bereiche. Bei der Implementierung des atomic Sprachkonstrukts haben wir somit die Freiheit, verschiedene Mutexe zu verwenden und somit verschiedene kritische Bereiche zu denieren. Damit ist atomic S 1 ::: S n end pthread_mutex_t globalmux e= pthread_mutex_init (&globalmux, pthread_mutexattr_default) e= pthread_mutex_lock (&globalmux) S1... Sn e= pthread_mutex_unlock(&globalmux) Diese Implementierung ist allerdings nicht ganz korrekt, z.b. mute als con z := x + y atomic x := 1 y := 2 end end con atomic z := x + y end atomic x := 1 y := 2 end end implementiert werden, damit die Zwischenzustande wirklich nicht sichtbar sind. Wichtig: Bei der Implementierung besteht also zusatzlich die Aufgabe, den auszuschlieenden Gegenpart zu identizieren und mit dem Mutex auszuschlieen. Aufgabe 4 Implementiere das folgende Program mit Hilfe von Mutexen. u := 0 v := 1 w := 2 con atomic x := u + v + w end atomic u := 3 v := 4 w := 5 end end Losungsvorschlag in C++. Die Statements werden hier auf die zwei Funktionen P1 und P2 aufgeteilt. Innerhalb dieser Funktionen erfolgt jeweils ein lock bevor das Statement ausgefuhrt wird. Und nach der Ausfuhrung wird der lock wieder freigegeben. Im Hauptprogramm wird (nach den Deklarationen) zu erst der Mutex mux initialisiert und dann werden wie schon bekannt, die Pthreads gestartet. Nach der Beendigung der Pthreads werden dann wieder die Ergebnisse ausgegeben. #include <iostream.h> #include <pthread.h> int x, u, v, w pthread_mutex_t mux void *P1 (void * arg) { int e e = pthread_mutex_lock(&mux) 24

26 x = u + v + w e = pthread_mutex_unlock(&mux) return arg void *P2 (void * arg) { int e e = pthread_mutex_lock(&mux) u = 3 v = 4 w = 5 e = pthread_mutex_unlock(&mux) return arg int main() { pthread_t t1, t2 long int i1, i2 void *o1, *o2 i1 = 1 i2 = 2 int i = 0 int e e = pthread_mutex_init(&mux, pthread_mutexattr_default) while (i < 10) { i++ u = 0 v = 1 w = 2 e = pthread_create(&t1, pthread_attr_default, P1, &i1) e = pthread_create(&t2, pthread_attr_default, P2, &i2) e = pthread_join(t1, &o1) e = pthread_join(t2, &o2) cout << " u = " << u cout << " v = " << v cout << " w = " << w cout << " x = " << x cout << "\n" return 0 Die Ausgabe konnte etwa wie folgt aussehen. Es kommen jetzt nur die beiden Werte x = 3und x = 12 vor. Die Ausgabe x = 3zeigt, da die Summe u + v + wvor den Zuweisungen an die Variablen berechnet wurde. Die Ausgabe x = 12 zeigt, da zu erst die Zuweisungen an die Variablen ausgefuhrt wurden und dann die Summe u + v + w berechnet wurde. u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 12 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 12 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 12 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 u = 3 v = 4 w = 5 x = 3 25

27 Aufgabe 5 Summiere die Elemente eines Arrays mit drei parallel arbeitenden Funktionen. Benutze eine globale Variable sum, die am Ende die Summe enthalten soll. D.h. implementiere VAR A: ARRAY [1..m] OF INTEGER s global : INTEGER (* Initialisiere A *) s global := 0 con S(1) S(2) S(3) end print(s global ) Wobei S(i) VAR s local : INTEGER b e j: INTEGER s local := 0 b := b m c(i ; 1) e := b m ci 3 if i =3then e := m end for j := b to e do s local := s local + A[j] end atomic s global := s global + s local end Losungsvorschlag in C++. Der Programmteil S(i) wird von der Funktion sfunc ausgefuhrt. In sfunc werden zunachst die Arbeitsbereiche (abangig von i) bestimmt (Berechnung von e und b). Dann wird lokal die Summe uber den entsprechenden Bereich gebildet und anschliessend (mit lock auf den Mutex pmt) die lokale Summe zu der globalen Summe hinzuaddiert. Im Hauptprogramm wird zunachst der Mutex pmt und das Array a initialisiert (mit Bildung einer Kontrollsumme). Dann werden 7 Pthreads gestartet (in dem Feld ia wird der Arbeitsindex i mitgeteilt) und wieder auf ihre Beendigung gewartet. #include <iostream.h> #include <pthread.h> const int ANZ_PTHREADS=7 const wsize=2000 long int a[wsize] long int sum=0 long int xsum=0 pthread_mutex_t pmt pthread_t pt[anz_pthreads] void *sfunc(void *arg) { long int lsum=0 long int j, b, e, i =*((long int *)arg) b=(wsize/anz_pthreads)*(i-1) e=(wsize/anz_pthreads)*i if (i==anz_pthreads) e=wsize cout << " i=" << i << " b=" << b << " e=" << e << "\n" for ( j=b j<e j++) lsum+=a[j] pthread_mutex_lock(&pmt) sum+=lsum pthread_mutex_unlock(&pmt) return arg main(){ void* return_pointer[anz_pthreads] long int ia[anz_pthreads] long int j, l pthread_mutex_init(&pmt,pthread_mutexattr_default) for ( j=0 j<wsize j++) { a[j]=j xsum+=j 26

28 for ( l=0 l<anz_pthreads l++) { ia[l]=l+1 pthread_create(&pt[l], pthread_attr_default, sfunc, (void *) &ia[l]) for ( l=0 l<anz_pthreads l++) { pthread_join(pt[l], &return_pointer[l]) cout << "Summe ist " << sum << "\n" cout << "Summe soll " << xsum << "\n" return 0 Die Ausgabe konnte etwa wie folgt aussehen. Die Anzeige von i = zeigt, da die Arbeitsschritte in der Reihenfolge und 5 begonnen wurden. Das Ergebnis ist wie erwartet. i=1 b=0 e=285 i=4 b=855 e=1140 i=3 b=570 e=855 i=2 b=285 e=570 i=6 b=1425 e=1710 i=7 b=1710 e=2000 i=5 b=1140 e=1425 Summe ist Summe soll Bedingungsvariablen und Mutual exclusion Zur Implementierung des letzten Sprachkonstrukts await B then S 1 ::: S n end benotigen wir einige Vorbereitungen. Zur Verfugung stehen uns die Pthread-Funktionen wait und signal mit den folgenden Spezikationen: int pthread_cond_wait (pthread_cond_t* cond, pthread_mutex_t* mutex) Warten auf eine Bedingung bez. eines Mutexes. int pthread_cond_signal(pthread_cond_t* cond) Signalisieren einer Bedingung. int pthread_cond_init (pthread_cond_t* cond, pthread_condattr_t attr) Initialisieren einer Bedingungsvariablen. int pthread_cond_broadcast (pthread_cond_t* cond) Signalisieren einer Bedingung an alle wartenden Pthreads. Die Datentypen pthread_cond_t und pthread_condattr_t sowie die Funktionen sind im Header File pthread.h deklariert. Als Attribut kann man ein default-attribut, verwenden 27

29 pthread_condattr_t pthread_condattr_default das schon initialisiert ist. Nur falls man spezielle Eigenschaften der Bedingungsvariablen haben mochte, mu man sich diese Attribute mit den entsprechenden Funktionen selbst erzeugen. Die Bedingungsvariablen mussen wie Mutexe vor der Benutzung initialisiert werden. Falls die Funktionsaufrufe erfolgreich sind, wird als Error code 0 zuruckgegeben, sonst ein Wert < 0. Eine Variante von wait ist das `timed wait', bei dem eine Zeit mit angegeben wird, wie lange maximal auf das Eintreten einer Bedingung gewartet werden soll. Bedingungsvariablen dienen dazu, den Eintritt bestimmter Bedingungen abzuwarten bzw. die Erfullung oder den Eintritt einer Bedingung anzuzeigen. Bedingungsvariablen sind an Mutexe gekoppelt. Beim Warten auf eine Bedingung wird gleichzeitig der lock auf den gekoppelten Mutex freigegeben (zuvor mu naturlich ein lock auf diesen Mutex erfolgt sein). Umgekehrt sollte vor dem Signal auf die Bedingung ein unlock auf den gekoppelten Mutex erfolgen, damit nach dem wait auch der lock auf den Mutex wieder vorhanden ist. Ist kein unlock vor dem signal erfolgt, wartet wait wieder bis der lock auf den Mutex moglich ist. Das Problem bei der Implementierung des await-statements ist, da die Bedingung ein beliebiger Boolescher Ausdruck sein darf, wir aber nur eine Boolesche Variable zur Verfugung haben. Die Grundidee bei der Losung ist zunachst fur jede semantisch verschiedene Bedingung eine eigene Bedingungsvariable einzufuhren und dann den Test, ob die Bedingung wahr ist an alle (wichtigen) Stellen im Programm zu verlegen, an denen die Bedingung wahr geworden sein konnte und dort, falls ja, mit signal (oder broadcast) den Eintritt der Bedingung zu signalisieren. Damit ergibt sich das folgende Schema: await B then S 1 ::: S n end // globale Variablen: pthread_mutex_t globalmux pthread_cont_t condb /* init */ e= pthread_mutex_init (globalmux, pthread_mutexattr_default) e= pthread_cond_init (condb, pthread_condattr_default) /* waiter */ e= pthread_mutex_lock (globalmux) while (! B) e= pthread_cond_wait (condb, globalmux) S1... Sn e= pthread_mutex_unlock(globalmux) /* tester */ // B koennte wahr werden if (B) pthread_cond_signal(condb) Diese Losung ist allerdings nicht vollstandig, da z.b. signal vor wait ausgefuhrt werden konnte, was den einen Pthread auf immer blockieren wurde (sogenannte \lost signals"). Eine Losung zu diesem Problem werden wir im nachsten Abschnitt besprechen. 3.6 Semaphore Um die Verwendung von Mutexen und Bedingungsvariablen deutlicher zu machen, wollen wir eine allgemeinere Variante von Mutexen besprechen und implementieren. Dieses allgemeinere Konzept sind die sog. Semaphoren (Signalmasten, Leuchtturme), die im Gegensatz zu Mutexen nicht nur die Zustande blocked und unblocked einnehmen konnen, sondern beliebig viele (abzahlbar viele). Semaphoren wurden zuerst entwickelt, um das Problem der \lost signals" zu losen. Es gibt zwei Operationen `P' und `V' auf Semaphoren `sem': 28

30 P(sem): entspricht dem lock bei Mutexen, wobei mitgezahlt wird, der wievielte lock-versuch es ist. V(sem): entspricht dem unlock bei Mutexen, wobei ebenfalls mitgezahlt wird, wieviele unlocks stattgefunden haben. Es wird sichergestellt, da die Anzahl der locks der Anzahl der unlocks plus ein Initialisierungswert ist. #P #V + init: Das Zahlen der P- und V-Operationen kann mit einer Variablen s #V + init ; #P und der Bedingung s 0 erledigt werden. Damit erhalten wir folgende (abstrakte) Implementierung der Operationen: P(sem): await s>0 then s := s ; 1 end V(sem): atomic s := s +1end Man sieht, da jetzt keine V-Operation (signal) verloren geht: auch wenn V vor P ausgefuhrt wird, ist sichergestellt, da P ohne weitere Verzogerung beendet wird. Ein Spezialfall der Semaphoren sind die Mutexe, die wir schon kennen. Sie sind sog. binare Semaphoren, bei denen der Zahler s nur die Werte 0 und 1 annimmt. Mutexe werden meist als P(bin): await b>0 then b := b ; 1 end V(bin): atomic b := b +1end implementiert, was zu den \lost signals" fuhrt. Die korrekte Fassung fur V ware V(bin): await b<1 then b := b +1end Ein Problem bei der Implementierung von V(sem) bleibt naturlich, da s in der Regel als Integer nur Werte bis 2 31 bzw annehmen kann. Korrekterweise mute daher auch hier die Implementierung von V(sem) sein V(sem): await s<2 31 then s := s +1end. Die Implementierung von Semaphoren mit Hilfe von Mutexen und Bedingungsvariablen gibt uns auch ein erstes Beispiel, wie das allgemeine await Statement zu implementieren ist. Implementierungsskizze: P(sem): lock(sem.mux) WHILE sem.s <= 0 DO "waiting:=true" wait(sem.pos, sem.mux) END DEC(sem.s) unlock(sem.mux): V(sem): lock(sem.mux): INC(sem.s) IF some are waiting THEN signal(sem.pos) END unlock(sem.mux) Das Prinzip zur Implementierung von await wird an diesem Beispiel auch deutlich: aus \await s>0..." wird IF not (s>0) THEN wait(sem.pos)... 29