OpenMP: Probleme mit Ausgabe

[Schlitzauge]

[flashpixx]

cout bzw die STL Typen sind nicht thread-safe, d.h. um eine korrekte Ausgabe zu erzielen, musst Du via Mutex passend die Schreibzugriffe auf die Resouce koordinieren.

[Schlitzauge]

So, hab die Ausgabe nun soweit hinbekommen.

Durch meine Recherchen stieß ich in der englischen Wikipedia auf folgenden Codeschnipsel:

#include <omp.h>

#include <iostream>

int main (int argc, char *argv[]) {

  int th_id, nthreads;

  #pragma omp parallel private(th_id)

  {

    th_id = omp_get_thread_num();

    std::cout << "Hello World from thread " << th_id << std::endl;

    #pragma omp barrier

    #pragma omp master

    {

      nthreads = omp_get_num_threads();

      std::cout << "There are " << nthreads << " threads" << std::endl;

    }

  }

  return 0;

}

Auch dieses Prog funktioniert nicht. Ebenso "fehlerhafte" Ausgabe und da wird bereits eine Barriere angewandt. Warum das nicht funktionieren kann, liegt nach wie vor auf der Hand (Threadsicherheit != iostreams). ;-) Da Frage ich mich nur, ob dieser Code bei Demjenigen funktioniert hat, als er den bei Wiki postete??? Also hab ich mich etwas weiter belesen und das ganze mit einer kritischen Zone gelöst: Mein Prog (korrigiert) "helloworld6.cpp":

#ifdef _OPENMP

#include <omp.h>

#endif


#include <stdlib.h>

#include <stdio.h>

#include <iostream>


using namespace std;


int main(int argc, char *argv[])

{

  #pragma omp parallel

  {

    #pragma omp critical

    {

      cout << "Hello World, says thread " << omp_get_thread_num()+1 << " of " << omp_get_num_threads() 

<< ".\n";

    }

    #pragma omp barrier

  }


  getchar();

  return 0;

}

Ich hab da noch anderweitig einen Tipp mit LOCKS bekommen. Das wär auch ne Lösung, muss ich mich aber noch weiter belesen. Inwieweit unterscheiden sich denn der Einsatz einer kritischen Zone (#pragma omp critical) und der Einsatz von Locks? Kommt da nicht das selbe heraus? -------------------------------------------- Dann hättsch mal noch ne Frage. Die Barriere (#pragma omp barrier) aus meiner nun funktionierenden Version, rührt nur daher, weil ich mich zunächst daran gesetzt habe, die EN-Wikipedia-Version zu korrigieren. Ich habs dann auch glei bei EN-Wiki korrigiert:

#include <omp.h>

#include <iostream>


using namespace std;


int main(int argc, char *argv[])

{

  int th_id, nthreads;

  #pragma omp parallel private(th_id) shared(nthreads)

  {

    th_id = omp_get_thread_num();

    #pragma omp critical

    {

      cout << "Hello World from thread " << th_id << '\n';

    }

    #pragma omp barrier

    #pragma omp master

    {

      nthreads = omp_get_num_threads();

      cout << "There are " << nthreads << " threads" << '\n';

    }

  }


  getchar();

  return 0;

}

Meine Frage ist nun, ob die Barriere in meinem Programm noch einen logischen Sinn macht oder ob ich die wieder entfernen soll? Ob mit oder ohne Barriere, das Prog funktioniert in jedem Fall. :upps

Ich weiß jetzt nicht, wie der Schrittbetrieb beim Einsatz einer kritischen Zone ausschaut. Grob betrachtet, müsste intern am Ende einer kritischen Zone bereits eine Barriere gesetzt sein, da ja nur jeweils ein Thread simultan diese kritische Zone ausführen soll und die anderen warten müssen.

Mein ursprünglicher Gedanke war ja, dass ich die Barriere-Extra am Ende belasse, falls dem nicht so ist und ich so die kritische Zone erstmal von allen Threads nacheinander ausführen lasse. Es wäre natürlich unnötiger Code mehr, wenn ich mit meiner Vermutung falsch liege.

THX nochmal.

Grüße

Schlitzauge :):)

[flashpixx]

Der Barrier ist letztendlich das Kommando, dass an diesem Punkt alle Thread synchronisiert werden, d.h. jeder Thread muss dieses Barrier erreichen, bevor die Verarbeitung weiter geht.

Ein Lock ist letztendlich eine Sperre, d.h. in dem Fall für das Critical wird hier synchronisiert auf das IOStream Objekt zugegriffen. Ich denke mal das critical wird letztendlich intern einen Mutex setzen sein, d.h. wenn der Mutex nicht belegt ist, dann kann der Thread den Teil innerhalb des Criticals ausführen, kommt während dessen ein weiterer Thread an das Critical wird der auf "wait" gesetzt, bis der erste fertig ist, erst dann geht es für den bei Wait wartenden Thread weiter

OpenMP macht nichts anderes als einen Threadpool aufbauen und eben entsprechenden der Direktiven das verteilen. Im Grunde kann man das auch selbst nachbauen.