Udostępnij przez

1. Wprowadzenie

Ten dokument określa kolekcję dyrektyw kompilatora, funkcji biblioteki i zmiennych środowiskowych, których można użyć do określenia równoległości pamięci współdzielonej w programach C i C++. Funkcjonalność opisana w tym dokumencie jest zbiorczo znana jako interfejs API (API) openMP C/C++. Celem tej specyfikacji jest zapewnienie modelu programowania równoległego, który umożliwia przenoszenie programu między architekturami pamięci współdzielonej od różnych dostawców. Kompilatory od wielu dostawców obsługują interfejs API OpenMP C/C++. Więcej informacji na temat protokołu OpenMP, w tym interfejsu programu OpenMP Fortran Application Program, można znaleźć w następującej witrynie internetowej:

https://www.openmp.org

Dyrektywy, funkcje biblioteki i zmienne środowiskowe zdefiniowane w tym dokumencie umożliwiają tworzenie programów równoległych i zarządzanie nimi przy jednoczesnym umożliwieniu przenoszenia. Dyrektywy rozszerzają model programowania sekwencyjnego C i C++ przy użyciu konstrukcji wielu danych (SPMD, single program multiple data), konstrukcji udostępniania pracy i konstrukcji synchronizacji. Wspierają one również udostępnianie i prywatyzację danych. Kompilatory obsługujące interfejs API OpenMP C i C++ zawierają opcję wiersza polecenia kompilatora, który aktywuje i umożliwia interpretację wszystkich dyrektyw kompilatora OpenMP.

1.1 Zakres

Ta specyfikacja obejmuje tylko równoległe przetwarzanie kierowane przez użytkownika, gdzie jawnie zdefiniuj akcje wykonywane przez kompilator i system czasu wykonywania w celu równoległego wykonywania programu. Implementacje openMP C i C++ nie są wymagane do sprawdzania zależności, konfliktów, zakleszczeń, warunków wyścigu lub innych problemów, które powodują nieprawidłowe wykonanie programu. Odpowiadasz za upewnienie się, że aplikacja korzystająca z konstrukcji interfejsu API OpenMP C i C++ jest wykonywana poprawnie. W tym dokumencie nie opisano automatycznego przetwarzania równoległego i dyrektyw generowanych przez kompilator w celu ułatwienia takiego przetwarzania równoległego.

1.2 Definicja terminów

W tym dokumencie są używane następujące terminy:

  • ograniczenie

    Punkt synchronizacji, do którego muszą dotrzeć wszystkie wątki w zespole. Każdy wątek czeka, aż wszystkie wątki w zespole pojawią się w tym momencie. Istnieją wyraźne bariery zidentyfikowane przez dyrektywy i niejawne bariery utworzone przez implementację.

  • konstrukcja

    Konstrukcja jest instrukcją. Składa się z dyrektywy, po której następuje blok ustrukturyzowany. Niektóre dyrektywy nie są częścią konstrukcji. (Patrz dyrektywa openmp w dodatku C).

  • dyrektywa

    Po identyfikatorze#pragma, innym tekście i nowym wierszu następuje kod C lub C++omp. Dyrektywa określa zachowanie programu.

  • zakres dynamiczny

    Wszystkie instrukcje w zakresie leksykalnym oraz wszelkie instrukcje wewnątrz funkcji wykonywanej w wyniku wykonywania instrukcji w zakresie leksykalnym. Zakres dynamiczny jest również określany jako region.

  • zakres leksykalny

    Instrukcje leksykalnie przechowywane w bloku ustrukturyzowanym.

  • wątek główny

    Wątek tworzący zespół po wprowadzeniu regionu równoległego.

  • region równoległy

    Instrukcje powiązane z konstrukcją równoległą OpenMP i mogą być wykonywane przez wiele wątków.

  • prywatny

    Zmienna prywatna nazywa blok magazynu unikatowy dla wątku tworzącego odwołanie. Istnieje kilka sposobów określania, że zmienna jest prywatna: definicja w regionie równoległym, dyrektywa, threadprivateklauzula , private, firstprivatelastprivate lub użycie zmiennej jako reduction zmiennej sterującej pętli w for pętli bezpośrednio po for dyrektywie lubfor.parallel for

  • region

    Zakres dynamiczny.

  • region szeregowy

    Instrukcje wykonywane tylko przez wątek główny poza zakresem dynamicznym dowolnego regionu równoległego.

  • serializować

    Aby wykonać konstrukcję równoległą z:

    • zespół wątków składających się tylko z jednego wątku (który jest wątkiem głównym dla tej konstrukcji równoległej),

    • kolejność szeregowa wykonywania instrukcji w bloku ustrukturyzowanym (taka sama kolejność jak w przypadku, gdy blok nie był częścią konstrukcji równoległej) i

    • brak wpływu na wartość zwracaną przez omp_in_parallel() (oprócz efektów wszelkich zagnieżdżonych konstrukcji równoległych).

  • udostępnione

    Współdzielona zmienna nazywa pojedynczy blok magazynu. Wszystkie wątki w zespole, które uzyskują dostęp do tej zmiennej, również uzyskują dostęp do tego pojedynczego bloku magazynu.

  • blok ustrukturyzowany

    Blok ustrukturyzowany jest instrukcją (pojedynczą lub złożoną), która ma pojedynczy wpis i pojedyncze wyjście. Jeśli istnieje skok do instrukcji lub z niej, instrukcja ta jest blokiem ustrukturyzowanym. (Ta reguła zawiera wywołanie metody longjmp(3C) lub użycie throwmetody , chociaż dozwolone jest wywołanie exit . Jeśli jego wykonanie zawsze rozpoczyna się od otwarcia { i zawsze kończy się na zamknięciu }, instrukcja złożone jest blokiem ustrukturyzowanym. Instrukcja wyrażenia, instrukcja wyboru, instrukcja iteracji lub try blok jest blokiem ustrukturyzowanym, jeśli odpowiednia instrukcja złożone uzyskana przez dołączenie jej do { elementu i } będzie blokiem ustrukturyzowanym. Instrukcja skoku, instrukcja oznaczona etykietą lub instrukcja deklaracji nie jest blokiem ustrukturyzowanym.

  • zespół

    Co najmniej jeden wątek współpracujący w wykonaniu konstrukcji.

  • konwersacja

    Jednostka wykonywania mająca szeregowy przepływ sterowania, zestaw zmiennych prywatnych i dostęp do zmiennych udostępnionych.

  • zmienna

    Identyfikator, opcjonalnie kwalifikowany przez nazwy przestrzeni nazw, który nazywa obiekt.

1.3 Model wykonywania

Protokół OpenMP używa modelu sprzężenia rozwidlenia równoległego. Mimo że ten model łączenia rozwidlenia może być przydatny do rozwiązywania różnych problemów, jest dostosowany do dużych aplikacji opartych na tablicy. Program OpenMP jest przeznaczony do obsługi programów, które są wykonywane poprawnie zarówno jako programy równoległe (wiele wątków wykonywania i pełna biblioteka obsługi OpenMP). Dotyczy to również programów, które są wykonywane poprawnie jako programy sekwencyjne (dyrektywy ignorowane i prosta biblioteka wycinków OpenMP). Jest jednak możliwe i dozwolone tworzenie programu, który nie działa prawidłowo podczas wykonywania sekwencyjnie. Ponadto różne stopnie równoległości mogą powodować różne wyniki liczbowe ze względu na zmiany w skojarzeniu operacji liczbowych. Na przykład redukcja dodawania szeregowego może mieć inny wzorzec skojarzeń dodawania niż redukcja równoległa. Te różne skojarzenia mogą zmieniać wyniki dodawania zmiennoprzecinkowego.

Program napisany za pomocą interfejsu API OpenMP C/C++ rozpoczyna wykonywanie jako pojedynczy wątek wykonywania nazywany wątkiem głównym. Wątek główny jest wykonywany w regionie szeregowym do momentu napotkania pierwszej konstrukcji równoległej. W interfejsie API parallel openMP C/C++ dyrektywa stanowi konstrukcję równoległą. Po napotkaniu konstrukcji równoległej wątek główny tworzy zespół wątków, a wzorzec staje się mistrzem zespołu. Każdy wątek w zespole wykonuje instrukcje w dynamicznym zakresie regionu równoległego, z wyjątkiem konstrukcji udostępniania pracy. Wszystkie wątki w zespole muszą napotkać konstrukcje udostępniania pracy w tej samej kolejności, a co najmniej jeden wątek wykonuje instrukcje w skojarzonym bloku ustrukturyzowanym. Bariera implikowana na końcu konstrukcji udostępniania pracy bez nowait klauzuli jest wykonywana przez wszystkie wątki w zespole.

Jeśli wątek modyfikuje obiekt udostępniony, ma wpływ nie tylko na własne środowisko wykonywania, ale także na inne wątki w programie. Modyfikacja jest gwarantowana do ukończenia, z punktu widzenia innego wątku, w następnym punkcie sekwencji (zgodnie z definicją w języku podstawowym) tylko wtedy, gdy obiekt jest zadeklarowany jako nietrwały. W przeciwnym razie modyfikacja jest gwarantowana do ukończenia po pierwszym modyfikowaniu wątku. Inne wątki następnie (lub współbieżnie) widzą dyrektywę określającą flush obiekt (niejawnie lub jawnie). flush Gdy dyrektywy, które są dorozumiane przez inne dyrektywy OpenMP, nie gwarantują prawidłowej kolejności skutków ubocznych, jest to odpowiedzialność programisty za dostarczanie dodatkowych, wyraźnych flush dyrektyw.

Po zakończeniu konstrukcji równoległej wątki w zespole synchronizują się z niejawną barierą, a tylko główny wątek kontynuuje wykonywanie. W jednym programie można określić dowolną liczbę konstrukcji równoległych. W rezultacie program może wielokrotnie rozwidlić i łączyć się podczas wykonywania.

Interfejs API OpenMP C/C++ umożliwia programistom używanie dyrektyw w funkcjach wywoływanych z konstrukcji równoległych. Dyrektywy, które nie pojawiają się w zakresie leksykalnym konstrukcji równoległej, ale mogą znajdować się w zakresie dynamicznym, są nazywane dyrektywami oddzielonych . Dzięki oddzielonym dyrektywom programiści mogą równolegle wykonywać główne części programu, przy minimalnych zmianach w programie sekwencyjnym. Dzięki tej funkcji można kodować konstrukcje równoległe na najwyższych poziomach drzewa wywołań programu i używać dyrektyw do kontrolowania wykonywania w dowolnej z wywoływanych funkcji.

Niezsynchronizowane wywołania funkcji wyjściowych C i C++, które zapisują w tym samym pliku, mogą spowodować, że dane zapisane przez różne wątki są wyświetlane w nieokreślonej kolejności. Podobnie niezsynchronizowane wywołania funkcji wejściowych odczytywanych z tego samego pliku mogą odczytywać dane w nieokreślonej kolejności. Niezsynchronizowane użycie operacji we/wy, tak aby każdy wątek uzyskiwał dostęp do innego pliku, daje takie same wyniki jak wykonywanie szeregowe funkcji We/Wy.

1.4 Zgodność

Implementacja interfejsu API OpenMP C/C++ jest zgodna z protokołem OpenMP, jeśli rozpoznaje i zachowuje semantyka wszystkich elementów tej specyfikacji, zgodnie z opisem w rozdziałach 1, 2, 3, 4 i dodatku C. Dołączanie A, B, D, E i F są przeznaczone wyłącznie do celów informacyjnych i nie są częścią specyfikacji. Implementacje, które zawierają tylko podzbiór interfejsu API, nie są zgodne z protokołem OpenMP.

Interfejs API OpenMP C i C++ to rozszerzenie języka podstawowego obsługiwanego przez implementację. Jeśli język podstawowy nie obsługuje konstrukcji języka ani rozszerzenia wyświetlanego w tym dokumencie, implementacja openMP nie jest wymagana do jej obsługi.

Wszystkie standardowe funkcje biblioteki C i C++ oraz wbudowane funkcje (czyli funkcje, których kompilator ma konkretną wiedzę), muszą być bezpieczne wątkowo. Niezsynchronizowane używanie funkcji bezpiecznych wątkowo przez różne wątki w regionie równoległym nie generuje niezdefiniowanego zachowania. Jednak zachowanie może nie być takie samo jak w regionie szeregowym. (Przykładem jest funkcja generowania liczb losowych).

Interfejs API OpenMP C/C++ określa, że określone zachowanie jest zdefiniowane przez implementację. W tych przypadkach wymagana jest zgodna implementacja protokołu OpenMP do zdefiniowania i udokumentowania jego zachowania. Aby uzyskać listę zachowań zdefiniowanych przez implementację, zobacz dodatek E.

1.5 Odwołania normatywne

  • ISO/IEC 9899:1999, Technologia informacyjna - Języki programowania - C. Ta specyfikacja interfejsu API OpenMP odnosi się do iso/IEC 9899:1999 jako C99.

  • ISO/IEC 9899:1990, Information Technology - Programming Languages - C. Ta specyfikacja interfejsu API OpenMP odnosi się do ISO/IEC 9899:1990 jako C90.

  • ISO/IEC 14882:1998, Information Technology - Programming Languages - C++. Ta specyfikacja interfejsu API OpenMP odnosi się do iso/IEC 14882:1998 jako C++.

W przypadku, gdy ta specyfikacja interfejsu API OpenMP odnosi się do języka C, odwołanie jest wykonywane do podstawowego języka obsługiwanego przez implementację.

1.6 Organizacja

  • Last updated on