OpenMP. Marco Nielinger. Westfälische Wilhelms-Universität Münster. Ausarbeitung. im Rahmen des Seminars Parallele Programmierung im SS03

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung OpenMP im Rahmen des Seminars Parallele Programmierung im SS03 Marco Nielinger Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Dipl.-Wirt.Inform. Roger Müller Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Westfälische Wilhelms-Universität Münster Inhaltsverzeichnis 1 Einleitung Prozesse und Threads Das Prozessmodell Das Threadmodell Grundlagen Ausführungsmodelle für Threads Der POSIX Standard und PThreads OpenMP Grundlagen Steuerung der parallelen Abarbeitung Der parallele Bereich Die parallele Schleife Nichtiterative parallele Bereiche Einmalige Ausführung Thread Anzahl Koordination von Threads Notwendigkeit der Koordination von Threads Kritischer Bereich Barrieren Atomare Operationen Konsistente Sicht auf gemeinsame Datenstrukturen Die Master-Direktive Reduktionsoperationen Lock-Mechanismen Zusammenfassung und Fazit Literaturverzeichnis...21

3 Kapitel 1: Einleitung 1 Einleitung OpenMP steht für Open specifications for Multi Processing. Es ist eine Spezifikation von Übersetzerdirektiven, Bibliotheksfunktionen und Umgebungsvariablen, die mit dem Ziel entworfen wurde, einen einheitlichen Standard für die Programmierung von Parallelrechnern mit gemeinsamem Adressraum zur Verfügung zu stellen (aus [RR]). OpenMP wird von vielen Soft- und Hardwareherstellern wie z.b. Intel, Sun und Compaq unterstützt und ist kurz davor, ein IEEE Standard zu werden. OpenMP stellt Schnittstellen für C, C++ und FORTRAN zur Verfügung. Es bietet dem Programmierer die Möglichkeit, auf einem abstrakteren Niveau als z.b. mit dem POSIX Standard Programme, die parallele Threads beinhalten, zu entwickeln. Meist wird OpenMP im wissenschaftlichen Umfeld z.b. für komplexe Matrizenberechnungen eingesetzt. Um die Funktionsweise von OpenMP verstehen zu können, sind Vorkenntnisse über Prozesse und Threads nötig. In Kapitel 2 werden deshalb deren Arbeitsweise und verschiedene Ausführungsmodelle (vor allem für Threads) erläutert. Am Ende des zweiten Kapitels wird auf den POSIX Standard eingegangen, um die Unterschiede zwischen OpenMP und POSIX-Threads aufzuzeigen. Eine ausführlichere Beschreibung von Threads und Prozessen findet sich in [TA]. In Kapitel 3 folgt dann eine Beschreibung der wichtigsten Eigenschaften, Direktiven, Funktionsweisen und Koordinationsmöglichkeiten von OpenMP. Zunächst wird in Kapitel 3.1 eine grundlegende Beschreibung über die Arbeitsweise von OpenMP gegeben. Danach folgt in Kapitel 3.2 eine Abhandlung der wichtigsten Direktiven, Parameter, Laufzeitfunktionen und Laufzeitvariablen zur Steuerung der parallelen Bearbeitung bevor in Kapitel 3.3 auf die Koordinationsmechanismen eingegangen wird. Für ein genaueres Verständnis kann in [RR], [RC] oder auf [WS], wo auch die Spezifikationen zum download angeboten werden, nachgelesen werden. Die Beispiele 1, 4 und 5 wurden aus [TU], die Beispiele 2, 3 und 6 aus [RR] und das Beispiel 7 aus [SP] mit jeweils leichten Änderungen übernommen. 1

4 2 Prozesse und Threads 2.1 Das Prozessmodell Moderne Computer sind in der Regel Multitaskingsysteme. Es können also mehrere Aufgaben parallel abgearbeitet werden. Das zugrunde liegende Konstrukt dieser Systeme ist das Prozessmodell. Ein Prozess ist ein Programm in Ausführung. Damit ist nicht nur der reine Programmcode gemeint, sondern auch die Daten des Programms, der aktuelle Befehlszähler, der Laufzeitstack und alle weiteren zur Ausführung des Programms erforderlichen Informationen. In Multitasking-Betriebssystemen wird der Prozessor (bei Ein-Prozessor-Systemen) bzw. werden die Prozessoren (bei Mehr-Prozessor-Systemen) den Prozessen zugeteilt. Wie dies genau geschieht, hängt vom Scheduling-Verfahren des Betriebssystems ab. Bei einem Kontextwechsel, also dem Suspendieren eines gerade laufenden Prozesses und dem Aktivieren eines rechenbereiten Prozesses, muss der Zustand des zu suspendierenden Prozesses gesichert werden. Der aktuelle Befehlszähler, die Registerinhalte, der Laufzeitstack usw. werden gespeichert, damit der Prozess bei erneuter Aktivierung an der Stelle weiterarbeiten kann, wo er unterbrochen wurde. Da jeder Prozess einen eigenen Adressraum hat und somit zwei oder mehrere Prozesse keine gemeinsamen Variablen haben können, findet eine Interprozesskommunikation häufig über aufwendige Sockets statt. Dieser Nachteil und die Tatsache, dass das Erzeugen und Verwalten von Prozessen mit großem Adressraum sehr zeitaufwendig ist, führte dazu, dass das Prozessmodell zum Threadmodell erweitert wurde. 2.2 Das Threadmodell Grundlagen Das in Kapitel 2.1 kurz skizzierte Prozessmodell hat den Nachteil, dass ein Prozess jeweils nur einen Ausführungsfaden hat. Im Threadmodell besitzt jeder Prozess nun mehrere Ausführungsfäden; die so genannten Threads. Der Vorteil von Threads ist, dass sich nun mehrere Threads eines Prozesses den Adressraum des Prozesses teilen und sich somit eine sehr viel schnellere 2

5 Kommunikation untereinander über gemeinsame Variablen realisieren lässt. Außerdem ist das Erzeugen und Verwalten von Threads wesentlich schneller, weil sie leichter sind als Prozesse. Es ist zwar auch nötig, einen Befehlszähler, einen Laufzeitstack und die Belegung der Register pro Thread zu speichern, aber es ist nun nicht mehr erforderlich, zum Beispiel geöffnete Dateien mitzuverwalten, weil diese prozessspezifisch sind. Ein weiterer Vorteil gegenüber dem reinen Prozessmodell ist, dass nun mehrere Threads eines Prozesses auf einem Mehr-Prozessor-System gleichzeitig auf verschiedenen Prozessoren arbeiten können Ausführungsmodelle für Threads Threads können auf Benutzerebene oder auf Betriebssystemebene realisiert werden. Bei Threads auf Benutzerebene weiß das Betriebssystem nichts von den Threads und verwaltet weiterhin nur Prozesse. Ein Laufzeitsystem bzw. Bibliotheks-Scheduler verwaltet die Threads eines Benutzerprozesses. Der Vorteil von Benutzerlevel-Threads ist, dass bei einem Threadwechsel durch das Laufzeitsystem bzw. den Bibliotheks- Scheduler kein Einsprung in den Kern nötig ist. Der große Nachteil von Benutzerlevel- Threads ist allerdings, dass bei einem blockierenden Thread, der zum Beispiel auf I/O wartet, der gesamte Prozess suspendiert wird, obwohl vielleicht ein anderer Thread des Prozesses rechenbereit ist. Betriebssysteme mit Betriebssystem-Threads unterstützen im Gegensatz zu den Benutzerlevel-Threads die Threadverwaltung. Das Betriebsystem verwaltet also nicht mehr die Prozesse sondern die Threads selber. Der Vorteil hierbei ist, dass nun nicht mehr der gesamte Prozess blockiert wird, wenn ein Thread blockiert. Nur der Thread selbst ist blockiert und das Betriebssystem kann einen rechenbereiten Thread desselben Prozesses aktivieren. Das ist mit viel weniger Overhead verbunden als ein ganzer Prozesswechsel. Der größte Nachteil ist allerdings, dass für jeden Threadwechsel ein zeitaufwendiger Einsprung in den Betriebssystemkern notwendig ist. Um die Vorteile dieser beiden Verfahren zu vereinen, wird häufig ein zweistufiges Verfahren (Abbildung 1) benutzt. Hierbei werden die Benutzer-Threads durch den Bibliotheks-Scheduler auf Betriebssystem-Threads abgebildet. Die Stärke dieser Vorgehensweise liegt darin, dass der Programmierer von der eigentlichen Anzahl der Betriebssystem-Threads abstrahieren und sein Programm mit der für die Aufgabe optimalen Anzahl an Benutzer-Threads schreiben kann. Die Anzahl der Betriebssystem- 3

6 Threads wird aber nicht von ihm beeinflusst, so dass das Betriebssystem eine möglichst effiziente Verteilung der Betriebssystem-Threads auf die vorhandenen CPUs gewährleistet. Abbildung 1 N:M-Modell Der POSIX Standard und PThreads Mit Thread Bibliotheken, die auf dem POSIX Standard beruhen, lassen sich die so genannten PThreads (POSIX-Threads) verwalten. Hierbei hat man als Programmierer die Möglichkeit, mit vordefinierten Funktionen PThreads zu erzeugen und zu koordinieren. Durch die gemeinsamen Variablen, die Threads eines Prozesses haben, können Race Conditions auftreten und Inkonsistenzen entstehen. Daher muss mit Hilfe von Mutexen, Bedingungs- und Lock-Variablen gearbeitet werden, um diesem Problem entgegen zu wirken. Auf Race Conditions wird auch noch in Kapitel näher eingegangen. Wichtig für diese Ausarbeitung ist nicht die genaue Funktionsweise von PThreads. Sie sollen nur erwähnt werden, um den Unterschied zwischen dem POSIX Standard und dem OpenMP Ansatz zu verstehen: PThreads werden direkt durch Befehle wie pthread_create, pthread_join usw. gesteuert und z.b. durch Mutexe koordiniert während die OpenMP Schnittstelle auf einem abstrakteren Niveau ansetzt und dort zum Beispiel die Erzeugung und die Synchronisation der einzelnen Threads implizit erfolgt. 4

7 3 OpenMP 3.1 Grundlagen OpenMP basiert auf parallel arbeitenden Threads, die nach einem fork-join-prinzip erzeugt werden. Es ist ein Master-Slave Modell. D.h., dass ein so genannter Master- Thread so lange das Programm sequentiell abarbeitet bis das erste Mal ein parallel- Konstrukt (siehe Kapitel 3.2.1) aufgerufen wird. Daraufhin erzeugt der Master-Thread ein Team von Threads und dieses Team, dem auch der Master selbst angehört, bearbeitet den im parallel-konstrukt angegebenen Bereich. Am Ende eines solchen parallel-konstrukts werden die Threads synchronisiert und alle Threads bis auf den Master werden beendet. In Abbildung 2 ist das fork-join-prinzip anschaulich dargestellt. Abbildung 2 - Das Fork-Join-Prinzip Es gibt zwei verschiedene Ausführungsweisen: Bei der Ersten wird das im parallel- Konstrukt angegebene Programmstück von allen Threads im SPMD Stil bearbeitet. SPMD steht für Single Program Multiple Data und bedeutet, dass dasselbe Programm von jedem Thread des Teams mit eventuell unterschiedlichen privaten Variablen ausgeführt wird. Genauer erläutert wird das SPMD Prinzip auch noch in Kapitel Bei der zweiten Möglichkeit wird die Arbeit innerhalb des parallel-konstruktes mit Hilfe anderer OpenMP Konstrukte verteilt. Das beste Beispiel hierfür ist die for- Direktive, die genauer in Kapitel behandelt wird. Obwohl OpenMP auf einer abstrakteren Ebene ansetzt als der POSIX Standard, ist auch hier der Programmierer für ein korrekt arbeitendes Programm verantwortlich. Das heißt, dass OpenMP keine Programmierfehler abfängt was ja auch eigentlich selbstverständlich sein sollte. 5

8 Im Folgenden wird auf spezielle OpenMP Direktiven eingegangen, die mit Beispielen in der Programmiersprache C erläutert werden. Die OpenMP Spezifikationen für C++ und FORTRAN werden auf als download angeboten. 3.2 Steuerung der parallelen Abarbeitung Der parallele Bereich Die meisten Übersetzer Direktiven von OpenMP werden in C und C++ mit Hilfe der dafür vorgesehenen #pragma-direktiven eingebunden und müssen in einer eigenen Programmzeile stehen. Um die OpenMP-Direktiven zu verwenden, muss per #include-befehl die Datei omp.h eingebunden werden: #include <omp.h> Die wichtigste Direktive in OpenMP ist der parallele Bereich. Sie hat die Form #pragma omp parallel <liste_der_parameter> <Anweisungsblock> und bewirkt, dass der angegebene Anweisungsblock parallel ausgeführt wird. Wenn der Master-Thread an dem parallelen Bereich ankommt, erzeugt er ein Team von Threads und dieses Team bearbeitet den Anweisungsblock im SPMD Stil mit eventuell unterschiedlichen privaten Variablen. Der Parameter private(<liste_der_variablen>) bestimmt, welche Variablen privat sind. Das heißt, dass eine uninitialisierte Kopie dieser Variablen für jeden Thread des Teams angelegt wird, die nur dieser Thread als globale Variable lesen und beschreiben kann. Dieses Konstrukt ermöglicht eine Abarbeitung im SPMD Stil, da jeder Thread das gleiche Programmfragment mit unterschiedlichen privaten Variablen ausführt. Die gemeinsamen Variablen, die im gemeinsamen Adressraum der Threads liegen und somit von allen Threads verändert werden können, werden mit Hilfe des Parameters shared(<liste_der_variablen>) angegeben. Außerdem hat man die Möglichkeit mit dem Parameter default(shared) festzulegen, dass alle bis auf die explizit im private()-parameter angegebenen Variablen den Threads des Teams gemeinsam sind. 6

9 Die Angabe default(none) bewirkt, dass jede im Anweisungsblock verwendete Variable explizit in dem private()- oder dem shared()-parameter aufgeführt sein muss. Am Beispiel 1 soll die Funktionsweise des parallelen Bereichs erläutert werden: #include <omp.h> main() int nthreads, tid; #pragma omp parallel private(tid) shared(nthreads) tid = omp_get_thread_num(); printf( Hello World from Thread = %d\n, tid); if (tid == 0) nthreads = omp_get_num_threads(); printf( Number of threads = %d\n, nthreads); Mit der ersten Zeile wird - wie bereits oben erwähnt - die Datei omp.h eingebunden, um auf die OpenMP-Direktiven zugreifen zu können. In der main()-methode werden zuerst die Variablen nthreads und tid deklariert. Danach folgt der parallele Bereich: Zunächst erfolgt die Erzeugung des Thread-Teams, von denen jeder Thread eine uninitialisierte Kopie der Variablen tid bekommt. nthreads ist von allen Threads zugreif- und manipulierbar. Der Anweisungsblock in den geschweiften Klammern wird nun von jedem Thread des Teams im SPMD Stil ausgeführt: Jeder Thread liest mit Hilfe der OpenMP Funktion omp_get_thread_num() seine Thread ID aus und schreibt sie in die Variable tid. Dann wird eine Zeile auf den Bildschirm ausgegeben, in der diese ID auftaucht. Wenn die Thread ID gleich 0 ist (=> es ist der Master-Thread), wird mit der Funktion omp_get_num_threads() die Anzahl der Threads des Teams in die gemeinsame Variable nthreads geschrieben und in einer zusätzlichen Zeile auf den Bildschirm ausgegeben. Am Ende des parallelen Bereichs, werden die Threads implizit synchronisiert und alle Threads bis auf den Master werden beendet. An diesem ersten Beispiel kann man auch gut erkennen, was mit impliziter Thread- Steuerung gemeint ist. Man benötigt bei OpenMP keine speziellen Befehle, um Threads 7

10 zu erzeugen, zu synchronisieren und zu beenden. All das wird implizit durch die parallel-direktive erledigt. In einem parallelen Bereich können ein bzw. mehrere weitere parallele Bereiche geschachtelt werden. Allerdings wird per Default der innere parallele Bereich nur von einem Team, dem nur der Thread angehört, der die äußere parallel-direktive ausführt, bearbeitet. Dieser Default kann umgangen werden, indem man mit der Bibliotheksfunktion void omp_set_nested(int nested) mit nested!= 0 angibt, dass jeder Thread des Teams für den äußeren Bereich ein weiteres Team für den inneren Bereich erzeugen soll. Wie man die genaue Anzahl der Threads beeinflusst, wird in Kapitel behandelt Die parallele Schleife OpenMP bietet nicht nur Konstrukte für die SPMD Bearbeitung eines Programms, sondern stellt auch innerhalb eines parallelen Bereichs Direktiven für die Verteilung der Aufgaben auf die einzelnen Threads zur Verfügung. Die wichtigste Direktive zur Verteilung der Arbeit ist die parallele Schleife bzw. die for-direktive mit der Syntax: #pragma omp for <liste_der_parameter> for (i = lower_bound;i <operator> upper_bound;incr_expr) <Schleifenrumpf> Hierbei stehen die Schleifenvariable i, der Ausdruck lower_bound und der Ausdruck upper_bound für Integer Variablen, die im Schleifenrumpf nicht verändert werden dürfen. <operator> ist ein Vergleichsoperator (z.b.: <, >, >=, <=) und incr_expr beschreibt die Veränderung der Schleifenvariablen i nach einer Iteration (z.b.: i++, i--, i += incr, etc..). Die Schleifenvariable i ist implizit eine private Variable für die Threads des Teams, damit die einzelnen Iterationen unabhängig voneinander und auch in einer eventuell anderen Reihenfolge durch die Threads abgearbeitet werden können. Z.B. könnte die dritte Iteration vor der Ersten bearbeitet werden. Man muss darauf achten, dass nur for-schleifen verwendet werden, bei denen die Anzahl der Iterationen schon beim Betreten der Schleife bestimmt werden kann und bei denen die einzelnen Iterationen unabhängig voneinander sind. Deshalb dürfen die Variablen i, lower_bound und upper_bound auch nicht im Schleifenrumpf 8

11 verändert werden. Wenn diese Bedingungen nicht eingehalten werden, ist eine Aufteilung auf die Threads (wenn die Anzahl der Iterationen vom Schleifenrumpf abhängt und nicht im Voraus bestimmt werden kann) oder eine korrekte Abarbeitung (wenn die Iterationen nicht unabhängig voneinander sind) nicht möglich. Mit Hilfe des schedule-parameters hat der Programmierer die Möglichkeit das Aufteilen der Iterationen auf die Threads zu beeinflussen. Mit der Angabe schedule(static, block_size) werden Iterationsblöcke der Größe block_size statisch auf die Threads verteilt. Für den Fall, dass block_size nicht angegeben wurde, werden ungefähr gleichgroße Blöcke an alle Threads gegeben. Der Parameter schedule(dynamic, block_size) hat in etwa dieselbe Wirkung. Der Unterschied ist, dass die Blöcke nun dynamisch zugeteilt werden. Erst wenn also ein Block der Größe block_size bearbeitet wurde, wird der nächste Block dynamisch an einen Thread gegeben, während bei der statischen Zuteilung schon beim Schleifenbeginn feststeht, welche Blöcke von welchen Threads bearbeitet werden. Wenn keine Blockgröße angegeben wird, werden dynamisch einzelne Iterationen verteilt. Eine weitere Form des schedule-parameters ist schedule(guided, block_size). Bei dieser Methode wird bei block_size = 1 jedem Thread ein Block der Größe Anzahl _ unbearbeiteter _ Iterationen Anzahl _ Threads zugeteilt. Die Anzahl der zugeteilten Blöcke nimmt also im Zeitverlauf ab. Bei block_size = k > 1 nimmt die Anzahl der zu verteilenden Blöcke exponentiell zu k ab. Wenn keine Blockgröße angegeben wird, wird als Default-Wert 1 genommen. schedule(runtime) legt fest, dass das Aufteilen der Iterationen zur Laufzeit festgelegt wird. Das heißt, dass vor dem Start des Programms die Umgebungsvariable OMP_SCHEDULE z.b. mit der Angabe setenv OMP_SCHEDULE dynamic, 3 oder setenv OMP_SCHEDULE static gesetzt wird und dann der in der Umgebungsvariablen stehende Scheduling-Algorithmus verwendet wird. Am Ende einer parallelen Schleife werden die Threads synchronisiert und die Anweisungen, die im parallelen Bereich nach der parallelen Schleife stehen, werden erst ausgeführt, wenn die Schleife von allen Threads des Teams beendet wurde. Wenn man als weiteren Parameter der parallelen Schleife nowait angibt, wird diese Synchronisation unterbunden und die Threads, die die Schleife beendet haben, arbeiten weiter, ohne auf Threads, die sich noch in der Schleife befinden, zu warten. Beispiel 2 soll die Funktionsweise der for-direktive erläutern: 9

12 #include <omp.h> double MA[100[100], MB[100][100], MC[100][100]; int i, row, col, size = 100; int main() read_input(ma, MB); #pragma omp parallel shared(ma;mb;mc;size) private(row,col,i) #pragma omp for schedule(static) for (row = 0;row < size; row++) for (col = 0;col < size;col++) MC[row][col] = 0.0; #pragma omp for schedule(static) for (row = 0;row < size;row++) for (col = 0;col < size;col++) for (i = 0; i < size;i++) MC[row][col] = MA[row][i] * MB[i][col]; In diesem Beispiel wird eine Matrix-Multiplikation (MA * MB = MC) durchgeführt. In der main-methode wird die parallele Arbeit mit einer parallel-direktive, die als private Variablen row, col, i und als gemeinsame Variablen MA, MB, MC und size deklariert, begonnen. Ein Team von Threads wird erzeugt, das in der ersten parallelen Schleife zunächst einfach nur alle Einträge der Ergebnismatrix MC auf 0 setzt. Hierbei übernimmt jeweils ein Thread eine Zeile (row) der Ergebnismatrix, da jede aufzuteilende Iteration der for-direktive einer Zeile der Ergebnismatrix entspricht. Die Iterationen der inneren for-schleife, bei der die Spalten abgearbeitet werden, werden nicht aufgeteilt, da diese eine normale for-schleife und keine for-direktive ist. In der zweiten parallelen Schleife werden die Einträge der Ergebnismatrix berechnet, wobei auch hier wieder jeweils eine komplette Zeile von einem Thread bearbeitet wird. Bei beiden for-direktiven wird ein statisches Scheduling (siehe oben) verwendet. Es ist nicht möglich, parallele Schleifen direkt ineinander zu schachteln. Um dies zu tun, muss innerhalb der äußeren parallelen Schleife ein weiterer paralleler Bereich gestartet werden, in den man die innere parallele Schleife schreiben kann. Beispiel 3 beinhaltet eine solche Schachtelung: 10

13 include <omp.h> double MA[100][100], MB[100][100], MC[100][100]; int i, row, col, size = 100; int main() read_input(ma, MB); void omp_set_nested(1); #pragma omp parallel private(row,col,i) #pragma omp for schedule(static) for (row = 0;row < size;row++) #pragma omp parallel shared(ma,mb,mc,size) #pragma omp for schedule(static) for (col = 0;col < size;col++) MC[row][col] = 0.0; for (i = 0;i < size;i++) MC[row][col]=MA[row][i]*MB[i][col]; Im Grunde wird dieselbe Multiplikation durchgeführt wie in Beispiel 2. Der Unterschied ist, dass jetzt nicht mehr ganze Zeilen von einem Thread berechnet werden, sondern jeder Eintrag der Ergebnismatrix von einem anderen Thread berechnet werden kann. Mit der Bibliotheksfunktion void omp_set_nested(1) wird zunächst ermöglicht, dass im inneren parallelen Bereich Teams erzeugt werden können, die aus mehr als nur einem Thread bestehen. Dann wird beim Betreten des äußeren parallelen Bereichs ein Team erzeugt, dessen Threads sich in der ersten for-direktive die Zeilen der Ergebnismatrix aufteilen. Für den inneren parallelen Bereich und damit auch die innere parallele Schleife erzeugt jeder Thread des Teams ein weiteres Team von Threads ( Baumstruktur), das sich die Berechnungen für die einzelnen Einträge der Ergebnismatrix-Zeile aufteilt. Für den Fall, dass man in einem parallelen Bereich nichts außer einer parallelen Schleife benutzen möchte, kann die verkürzte Schreibweise #pragma omp parallel for <liste_der_parameter> for (i = lower_bound; i <operator> upper_bound; incr_expr) <Schleifenrumpf> 11

14 verwendet werden. Dabei stehen in <liste_der_parameter> die Parameter der eigentlich anzugebenden parallel- und for-direktive zusammen Nichtiterative parallele Bereiche OpenMP stellt mit der sections-direktive die Möglichkeit zur Verfügung, nicht nur Iterationen (wie bei der for-direktive) sondern auch nichtiterative Bereiche unter den Threads aufzuteilen. Die Schreibweise ist: #pragma omp sections <liste_der_parameter> #pragma omp section <Anweisungsblock1> #pragma omp section <Anweisungsblock2> Jede Sektion, die innerhalb des sections-blockes angegeben ist, wird von nur einem Thread bearbeitet. Da die Sektionen unabhängig vo neinander sind, kann diese Bearbeitung parallel erfolgen. Am Ende einer sections-direktive findet auch wieder eine implizite Synchronisation statt, die mit dem Parameter nowait vermieden werden kann. Beispiel 4 veranschaulicht die Verwendung der sections-direktive: #include <omp.h> #define N 1000 main() int i; float a[n], b[n],c[n]; for (i = 0; i < N; i++) a[i] = b[i] = i * 1.0; #pragma omp parallel shared(a,b,c) private(i) #pragma omp sections nowait #pragma omp section for (i = 0;i < N/2;i++) c[i] = a[i] + b[i]; #pragma omp section for (i = N/2;i < N;i++) c[i] = a[i] + b[i]; 12

15 Hier wird eine Addition von Vektor a und Vektor b berechnet. Mit Hilfe der sections-direktive wird diese Berechnung auf zwei Threads verteilt. Ein Thread übernimmt die ersten 500 Additionen während ein anderer Thread die nächsten 500 Additionen evtl. parallel durchführt. Für den Fall, dass weniger Sektionen als Threads vorhanden sind, bleiben einige Threads untätig und für den Fall, dass weniger Threads als Sektionen vorhanden sind, bearbeiten einige Threads mehrere Sektionen. Wenn in einem parallelen Bereich nur Sektionen verwendet werden sollen, kann die verkürzte Schreibweise #pragma omp parallel sections <liste_der_parameter> #pragma omp section <Anweisungsblock1> #pragma omp section <Anweisungsblock2> benutzt werden Einmalige Ausführung Innerhalb der parallelen Bereiche werden Anweisungen, die nicht innerhalb einer anderen Direktive stehen, von allen Threads des Teams im SPMD Stil bearbeitet. OpenMP bietet natürlich auch ein Konstrukt, mit dem es möglich ist, einen Anweisungsblock von nur einem Thread ausführen zu lassen. Die single-direktive mit der Schreibweise #pragma omp single <liste_der_parameter> <Anweisungsblock> bewirkt, dass der Anweisungsblock innerhalb der single-direktive nur von genau einem Thread ausgeführt wird. Auch bei dieser Direktive kann man mit dem Parameter nowait eine implizite Synchronisation vermeiden Thread Anzahl Um die Anzahl der Threads, die in einem parallelen Bereich erzeugt werden, zu beeinflussen, bietet OpenMP mehrere Laufzeitfunktionen an. Die Funktion void omp_set_dynamic(int dynamic_threads) muss außerhalb eines parallelen Bereichs aufgerufen werden und bewirkt mit der Angabe 13

16 dynamic_threads!= 0, dass die Anzahl der Threads dynamisch an die Systemgegebenheiten angepasst wird. Dies hat gegenüber den PThreads den Vorteil, dass sich der Programmierer nicht darum kümmern muss, wieviele Threads maximal vom Betriebssystem verwaltet werden können. Das Laufzeitsystem achtet also darauf, dass die maximale Anzahl nicht überschritten wird. Bei dynamic_threads = 0 wird diese dynamische Anpassung ausgeschaltet und das Laufzeitsystem verwendet für parallele Bereiche die derzeit eingestellte Anzahl an Threads. Mit int omp_get_dynamic(void) kann abgerufen werden, ob zur Zeit eine dynamische (=0) oder eine statische (!=0) Anpassung aktiviert ist. Die Laufzeitfunktion void omp_set_num_threads(int num_threads) ermöglicht, die genaue Anzahl von Threads einzustellen. Bei einer statischen Anpassung, beschreibt num_threads dann die Anzahl der Threads, die für die nachfolgenden parallelen Bereiche erzeugt werden sollen. Bei einer statischen Anpassung, wird mit num_threads die maximale Anzahl von Threads festgelegt, die dynamisch erzeugt werden können. Der Aufruf void omp_set_nested(int nested) wurde schon in den vorangegangenen Kapiteln vorgestellt und stellt ein, ob ein geschachtelter paralleler Bereich sequentiell (nested = 0), also nur von einem Thread, oder parallel (nested!= 0), also mit einem Team von Threads, ausgeführt wird. Mit der Funktion int omp_get_nested(void) kann der aktuelle Status für die Behandlung von geschachtelten parallelen Bereichen abgefragt werden. Der Wert 0 steht hierbei wie oben für eine sequentielle und ein Wert!= 0 für eine parallele Behandlung der geschachtelten Bereiche. 3.3 Koordination von Threads Notwendigkeit der Koordination von Threads Bei der Programmierung mit mehreren Threads können so genannte Race Conditions auftreten. Diese entstehen dadurch, dass die eigentlichen Maschinenbefehle, die Threads auslösen, nicht unbedingt in der Reihenfolge ausgeführt werden, wie es im Programmcode der Hochsprache steht. Deshalb können beim Beschreiben von gemeinsamen Variablen (im Beispiel ist es x = 0) Inkonsistenzen entstehen. 14

17 Ein Beispiel für solch eine Race Condition ist die Inkrementierung einer gemeinsamen Variablen durch zwei Threads. Die Maschinenbefehle die ausgeführt werden sind: 1. Thread1 liest den Wert der Variablen ins Register A 2. Thread2 liest den Wert der Variablen ins Register B 3. Thread1 inkrementiert den Wert im Register A (= 1) 4. Thread2 inkrementiert den Wert im Register B (= 1) 5. Thread1 schreibt den Wert im Register A zurück in den Speicher (x = 1) 6. Thread2 schreibt den Wert aus Register B in zurück in den Speicher (x = 1) Am Ende dieser Abfolge hat x den Wert 1, obwohl eigentlich 2 in der Variablen stehen sollte. Um solche Race Conditions zu vermeiden, bietet OpenMP Direktiven zur Synchronisation der Threads, von denen die Wichtigsten nachfolgend vorgestellt werden Kritischer Bereich Kritische Bereiche in parallelen Regionen werden durch die Direktive #pragma omp critical (<name>) <kritischer_bereich> eingebunden und bewirken, dass sich nur ein Thread des Teams in dem kritischen Bereich befinden darf. Die Angabe eines Namens für den kritischen Bereich ist optional. Wenn mehrere kritische Bereiche mit gleichem Namen vorhanden sind, gelten sie als ein kritischer Bereich. Das heißt, dass ein kritischer Bereich auch nicht betreten werden darf, wenn an einer anderen Stelle im Programm gerade ein kritischer Bereich mit dem gleichen Namen bearbeitet wird. Wenn kein Name angegeben wird, werden alle unbenannten kritischen Bereiche behandelt, als hätten sie den gleichen Namen. Wenn nun ein Thread an solch einem kritischen Bereich angelangt ist, kann er nur fortfahren, wenn sich gerade kein anderer Thread in einem gleichnamigen kritischen Bereich befindet. Ansonsten muss er warten bis der andere Thread den kritischen Bereich verlassen hat. Beispiel 5 enthält einen solchen kritischen Bereich: #include <omp.h> main() int x = 0; #pragma omp parallel shared(x) #pragma omp critical x = x + 1; 15

18 Durch die Verwendung der critical-direktive wird die in Kapitel beschriebene Race Condition vermieden, weil nun nicht mehr zwei oder mehrere Threads gleichzeitig die Variable x inkrementieren können Barrieren Mit Hilfe von Barrieren können die Threads des Teams synchronisiert werden. Im Grunde ist es dasselbe Prinzip wie bei der impliziten Synchronisation beim Verlassen eines parallel-, for-, oder sections-abschnitts. An einer solchen Barriere warten alle dort ankommenden Threads auf die übrigen Team-Mitglieder und arbeiten erst weiter, wenn alle Threads die Barriere erreicht haben. Eine Barriere kann mit dem Aufruf #pragma omp barrier eingefügt werden Atomare Operationen Die atomic-direktive mit der Form #pragma omp atomic <zuweisung> ermöglicht, dass der Speicherzugriff für die zu beschreibende Variable als atomare Operation ausgeführt wird. Das heißt, dass während ein Thread eine atomare Operation auf einer gemeinsamen Variablen ausführt, kein anderer Thread diese Variable lesen oder beschreiben darf. Die <zuweisung> muss entweder die Form x binop= E; (Wobei x ein Variablenzugriff, binop ein binärer Operator (+, -, *, /, &, etc.) und E ein Berechnungsausdruck, der x nicht enthalten darf, ist.) oder die Form x++; oder x--; oder ++x; etc. haben. Im Grunde kann die Wirkungsweise der atomic-direktive auch durch eine critical- Direktive erreicht werden, aber die kleinere atomic-direktive kann durch das Laufzeitsystem effizienter ausgenutzt werden Konsistente Sicht auf gemeinsame Datenstrukturen Um den Threads eines Teams eine konsistente Sicht auf gemeinsame Datenstrukturen zu verschaffen, kann die flush-direktive benutzt werden. Mit ihrer Hilfe können die lokalen Kopien der gemeinsamen Variablen abgeglichen werden, so dass alle Threads des Teams wieder eine konsistente Sicht auf die gemeinsamen Variablen haben. Die Syntax der flush-direktive ist: 16

19 #pragma omp flush <liste_der_variablen> Die in der Liste angegebenen Variablen erhalten einen konsistenten Wert. Wenn keine Liste angegeben wird, werden alle zugreifbaren Variablen konsistent gemacht. Eine flush-direktive wird implizit beim Betreten und Verlassen einer parallel- Direktive, beim Betreten und Verlassen einer critical-direktive, beim Verlassen einer for-direktive, beim Verlassen einer sections-direktive und beim Verlassen einer single-direktive ausgeführt. Durch diese implizite Ausführung, muss eigentlich nur an wenigen Stellen eine flush-direktive per Hand eingefügt werden, aber man sollte immer im Kopf behalten, dass z.b. beim Betreten einer for-direktive nicht zwangsweise eine konsistente Datensicht vorliegt Die Master-Direktive Ein Bereich, der nur vom Master des Teams ausgeführt werden soll und den alle anderen Threads des Teams einfach ignorieren, kann durch #pragma omp master <anweisungsblock> eingefügt werden. Nur der Master des Teams wird den in der master-direktive angegebenen Anweisungsblock ausführen. Eine implizite Synchronisation der Threads findet hierbei nicht statt Reduktionsoperationen Speziell für die Akkumulation von Werten gibt es in OpenMP Reduktionsoperationen, die in parallel-, for- und sections-direktiven verwendet werden können. Auf diese Operationen kann mit Hilfe des Parameters reduction (op : <liste_der_variablen>) zugegriffen werden. op bezeichnet die Operation mit der akkumuliert wird und <liste_der_variablen> gibt die Variablen an, die akkumuliert werden sollen. Diese Variablen müssen als gemeinsame Variablen deklariert sein. Bei Verwendung des reduction-parameters wird für jeden Thread eine private Kopie der gemeinsamen Variablen angelegt und mit dem neutralen Element der Operation op initiiert (z.b.: 0 für die Operation +). Am Ende der Direktive, die mit dem reduction- Parameter beginnt, werden die privaten Kopien bezüglich der Operation op akkumuliert und dieser errechnete Wert wird der gemeinsamen Variablen zugewiesen. Beispiel 6 veranschaulicht diese Funktionsweise anhand einer einfachen Inkrementierung der Variablen x: 17

20 include <omp.h> main() int x; #pragma omp parallel shared(x) #pragma omp for schedule(static) reduction (+ : x) for (i = 0;i < 1000;i++) x += 1; Jeder Thread des Teams, das beim Betreten des parallelen Bereichs erzeugt wird, erhält eine private Kopie der gemeinsamen Variablen x, die mit 0 (neutrales Element der Addition) initiiert wird. Durch das statische Scheduling erhält jeder Thread eine gleiche Anzahl an Iterationen der for-schleife. Angenommen der parallele Bereich wird von zwei Threads parallel bearbeitet. Dann übernimmt jeder 500 Iterationen und beide haben am Ende der for-direktive in ihrer privaten Kopie von x den Wert 500. Durch den reduction-parameter werden nun diese Kopien wieder bezüglich der +-Operation zusammengeführt und die gemeinsame Variable hat den Wert Lock-Mechanismen Um den Zugriff auf gemeinsame Variablen zu koordinieren, stellt OpenMP so genannte Lock-Variablen zur Verfügung. Mit Hilfe dieser Variablen kann ein Lock-Mechanismus für gemeinsame Variablen mit Hilfe von Laufzeitfunktionen gesteuert werden. OpenMP unterscheidet zwei Kategorien von Lock-Variablen: einfache (omp_lock_t) und schachtelbare (omp_lock_nested). Die einfachen Lock-Variablen können nur einmal und die schachtelbaren mehrfach belegt werden. Bei den schachtelbaren Lock- Variablen wird dafür ein Zähler benutzt, welcher die Anzahl der Anforderungen speichert. Die Lock-Variablen können mit den Funktionen omp_init_lock(omp_lock_t *lock) bzw. omp_init_nest_lock(omp_nest_lock_t *lock) initialisiert werden. Nach der Initialisierung der Lock-Variablen sind diese nicht belegt. Um Lock- Variablen wieder zu löschen, stehen die Funktionen omp_destroy_lock(omp_lock_t *lock) bzw. omp_destroy_nest_lock(omp_nest_lock_t *lock) zur Verfügung. 18

21 Um Lock-Variablen zu belegen, gibt es die Laufzeitfunktionen omp_set_lock(omp_lock_t *lock) bzw. omp_set_nest_lock(omp_nest_lock_t *lock) und für das Freigeben der Lockvariablen sind die Funktionen omp_unset_lock(omp_lock_t *lock) bzw. omp_unset_nest_lock(omp_nest_lock_t *lock) zuständig. Wenn eine einfache Lock-Variable belegt werden soll, wird geprüft, ob die Variable frei ist. Erst dann kann der Thread die Lock-Variable belegen. Wenn sie bereits belegt ist, wird der aufrufende Thread so lange blockiert, bis die Lock-Variable wieder frei ist. Schachtelbaren Lock-Variablen sind verfügbar, wenn sie von keinem Thread oder dem ausführenden Thread belegt sind. Bei einer Belegung wird der Zähler der Variablen inkrementiert und bei einer Freigabe dekrementiert. Eine belegte schachtelbare Lock- Variable ist wieder frei, wenn der Zähler 0 erreicht. Die Lock-Variablen in OpenMP sind dem Mutex- bzw. dem Semaphor-Konzept sehr ähnlich. Genaue Informationen über Mutexe und Semaphoren finden sich in [TA]. Damit die Threads, die eine schon belegte Lock-Variable anfordern, nicht blockieren, kann zunächst mit den Funktionen omp_test_lock(omp_lock_t *lock) bzw. omp_test_nest_lock(omp_nest_lock_t *lock) getestet werden, ob die Lock- Variable belegt ist. Falls nicht, wird die Lock-Variable angefordert, im anderen Fall kann der Thread etwas anderes tun und blockiert nicht. Im Beispiel 7 wird mit einer Lock-Variablen gearbeitet: include <omp.h> main() omp_lock_t lck; int id; omp_init_lock(&lck); #pragma omp parallel shared(lck) private(id) id = omp_get_thread_num(); omp_set_lock(&lck); printf( My id is %d.\n, id); omp_unset_lock(&lck); omp_destroy_lock(&lck); 19

22 Kapitel 4: Zusammenfassung und Fazit Hierbei kann nur der Thread, der die Lock-Variable belegt, das printf ausführen. Die anderen Threads werden solange die Lock-Variable belegt ist, blockiert und beginnen erst wieder mit ihrer Arbeit, wenn die Variable wieder frei ist. 4 Zusammenfassung und Fazit OpenMP bietet eine mächtige und abstrakte Schnittstelle für die Programmierung von Parallelrechnern mit gemeinsamem Adressraum. Durch die breite Unterstützung der OpenMP Übersetzerdirektiven durch verschiedene Hard- und Software-Hersteller ist OpenMP allerdings auch auf Ein-Prozessor-Systemen einsetzbar. Dort würden dann alle Programme einfach sequentiell ablaufen. Durch die abstraktere Sicht auf die verwendeten Threads, muss sich der Programmierer nicht länger in mühsamer Handarbeit, um das Erzeugen, Verwalten und Synchronisieren der Threads kümmern und kann diese Arbeit den OpenMP Direktiven überlassen, die genau diese Arbeiten oft implizit erledigen. Dennoch nimmt OpenMP einem die Verantwortung für korrekt arbeitende und Race Condition freie Programme nicht ganz aus der Hand. Bei der Programmierung mit mehreren Threads muss immer sorgfältig auf die Probleme, die auftreten können wenn mehrere Threads zusammen arbeiten, geachtet werden. Obwohl die Parallelisierung von Anwendungen nicht nur auf Supercomputern sondern auch auf Workstations und verteilten Systemen immer mehr Wichtigkeit erlangt, wird OpenMP derzeit nur im wissenschaftlichen Umfeld für sehr aufwendige Berechnungen eingesetzt wurde es zum Beispiel in einer Kombination mit MPI eingesetzt, um Wellenbewegungen vor der Küste Floridas zu simulieren und auszuwerten. MPI wurde eingesetzt, um mit Hilfe von Boss-Workern die anfallenden Berechnungen zu verteilen, während OpenMP für die Parallelisierung der Berechnungen benutzt wurde. So konnte die ursprüngliche Berechnungsdauer von 6 Monaten auf nur 72 Stunden reduziert werden. Deshalb können seitdem bei Küstenanalysen Probleme gelöst werden, die vorher als unlösbar eingestuft waren. 20

23 Kapitel 5: Literaturverzeichnis 5 Literaturverzeichnis [RR] Rauber, Rünger: Parallele und verteilte Programmierung, Springer Verlag [TA] Andrew S. Tanenbaum: Moderne Betriebssyteme, Hanser Verlag [WS] (offizielle OpenMP Webseite mit Download Möglichkeit für die Spezifikationen) [SP] Offizielle C/C++ Spezifikation für OpenMP, Version 2.0 [TU] [RC] (Online-Tutorium zu OpenMP) Rohit Chandra et al.: Parallel Programming in OpenMP (das erste Buch, das sich ausschliesslich mit OpenMP beschäftigt leider nicht in Münster verfügbar) 21