Kleine OpenMP Programm manchmal friert (gcc, c, Linux)

Question

Schreiben Sie einfach einen kleinen omp-Test, und es funktioniert nicht richtig, all Zeiten:

#include <omp.h>
int main() {
  int i,j=0;
#pragma omp parallel
  for(i=0;i<1000;i++)
  {
#pragma omp barrier
    j+= j^i;
  }
  return j;
}

Die Nutzung von j für von allen Threads schreiben, ist falsch in diesem Beispiel, aber

• Es darf nur nicht deterministischer Wert von j sein

• Ich habe eine Kühltruhe.

Zusammengestellt mit gcc-4.3.1 -fopenmp a.c -o gcc -static

Ausführen auf 4-Kern x86_Core2 Linux-Server: $ ./gcc und bekam freeze (manchmal, wie ein Einfrieren für 4-5 schnelle Läufe)

.

Strace:

[pid 13118] futex(0x80d3014, FUTEX_WAKE, 1) = 1
[pid 13119] <... futex resumed> )       = 0
[pid 13118] futex(0x80d3020, FUTEX_WAIT, 251, NULL <unfinished ...>
[pid 13119] futex(0x80d3014, FUTEX_WAKE, 1) = 0
[pid 13119] futex(0x80d3020, FUTEX_WAIT, 251, NULL                       
                        <freeze>

Warum habe ich ein Einfrieren (Deadlock)?

Answer 1

Versuchen i privat macht so jede Schleife seine eigene Kopie hat.

Nun, da ich mehr Zeit habe, werde ich versuchen und erklären. Standardmäßig Variablen in OpenMP werden gemeinsam genutzt. Es gibt ein paar Fälle, in denen Standardwerte sind die Variablen privat zu machen. Parallel Regionen ist nicht einer von ihnen (so High Performance Mark Antwort ist falsch). In Ihrem ursprünglichen Programm, haben Sie zwei Rennbedingungen - einen auf i und eine auf j. Das Problem ist, mit dem man auf i. Jeder Faden wird die Schleife eine Anzahl von Malen ausgeführt werden, aber da i durch jeden Thread geändert wird, die Anzahl von Malen jeder Thread führt die Schleife unbestimmt ist. Da alle Fäden der barrrier auszuführen haben für die Barriere zufrieden zu sein, kommen Sie mit dem Fall, in dem Sie einen Hang an der Schranke erhalten wird, die niemals enden wird, da nicht alle Fäden es die gleiche Anzahl von Malen ausgeführt wird.

Da die OpenMP-Spezifikation eindeutig fest (OMP-Spezifikation V3.0, Abschnitt 2.8.3 Barriere Construct), dass „die Folge der Arbeitsteilung Regionen und Barrierebereiche angetroffen muss die seine gleiche gilt für jeden Thread in einem Team“Ihr Programm ist nicht konform und kann als solche unbestimmten Verhalten haben.

Answer 2

Sie versuchen, auf die gleiche Stelle von mehreren Threads hinzuzufügen. Sie können nicht tun, was Sie versuchen, parallel zu tun. Wenn Sie eine Summe parallel tun wollen, müssen Sie es in kleinere Stücke teilen und sammeln sie danach.

Update von A5B: richtige Idee, aber falschen Teil wurde der Code entdeckt. Die i Variable wird von beiden Threads geändert.

Answer 3

@ejd, wenn ich mich als privat kennzeichne, wird mein Programm kompatibel sein?

Sorry - ich sehe nur diese Frage. Technisch gesehen wird, wenn Sie Variable markieren „i“ als private Ihr Programm OpenMP-kompatibel sein. Allerdings gibt es noch eine Race-Bedingung auf „j“ und während Ihr Programm kompatibel ist (weil es gültige Fälle sind Rennbedingungen haben), wird der Wert von „j“ ist nicht spezifiziert (gemäß der OpenMP-Spezifikation).

In einem Ihre früheren Antworten sagen Sie, dass Sie die Geschwindigkeit der Barriere Umsetzung zu messen versuchen. Es gibt mehrere „Benchmarks“, dass Sie an, die für eine Vielzahl von OpenMP-Konstrukte veröffentlichten Ergebnisse haben sehen möchten. Einer wurde von Mark Bull (EPCC, University of Edinburgh) geschrieben, einem anderen (Sphinx) kommt von Lawrence Livermore National Labs (LLNL) und die dritten (Parkbank) stammt aus einer japanischen Computing-Partnerschaft. Sie können Ihnen einige Hinweise bieten.