Zum Inhalt springen

OpenMP: Probleme mit Ausgabe


Schlitzauge

Empfohlene Beiträge

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 :):):):)

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...