(kurze Nebenbemerkung vorab: ich bin mir nicht ganz sicher, in welchem Forum dieser Post am besten aufgehoben ist, ggf. also bitte verschieben.)

Jetzt zum eigentlichen Problem. Ich habe ein bisschen mit der Parallelisierung einer Berechnung (mit OpenMP) experimentiert und würde gerne noch einmal sicherstellen, in welchen Fällen Zugriffsprobleme auftreten können. Hier ein paar Beispiele, um die es mir geht:

1.) Initialisierung (oder auch Zuweisung) einer gemeinsam genutzten Variablen

MyObj global;
{ // start paralleler Block
    MyObj aObj(global);
    // bzw.
    MyObj* pObj = new MyObj(global);
} // ende paralleler Block

2.) Aufruf einer Methode einer gemeinsam genutzten Variablen

class MyObj
{
    //...
    // Fall a)
    void DoSomething() const;
    // Fall b)
    void DoSomething();
}

MyObj global;
{ // start paralleler Block
    global.DoSomething();
} // ende paralleler Block

3.) Aufruf einer Funktion, die eine gemeinsam genutzte Variable übergeben bekommt

void DoSomethingWith(const MyObj&)
{
    // do something with MyObj
}
MyObj global;
{ // start paralleler Block
    DoSomethingWith(global); 
} // ende paralleler Block

Mir geht es also darum, in welchen Fällen ich "global" schützen muss, d.h. in welchen Fällen die beschriebenen Operationen beispielsweise in einer "Critical Section" erfolgen müssen.
Persönlich denke ich, dass nur 1.) in Ordnung ist und dass bei 2.) und 3.) Probleme entstehen können, ich wäre aber dankbar, wenn mir das hier nochmal jemand bestätigen bzw. mich korrigieren könnte.

Vielen Dank schonmal vorab!

vor gut zwei Monaten habe ich hier die obige Frage gestellt. Um auf Nummer sicher zu gehen habe ich damals vorsichtshalber lieber eine Variable zu viel als zu wenig geschützt. Wenn es sich um Objekte handelt, die ein wenig mehr Speicher benötigen, ist das aber unter Umständen keine so gute Lösung.

Ich hole deshalb den Thread einfach nochmal hoch und hoffe, dass mir vielleicht diesmal jemand ein paar Hinweise geben kann.

Besten Dank im Voraus!

Sollten gewisse Voraussetzungen erfüllt sein, dann reicht es, wenn du beim Lesen einen shared-lock holst. Locken musst du aber auf jeden Fall auch beim Lesen!

Also nochmal ganz klar: du musst bei 1, 2 UND 3 den Zugriff synchronisieren!
Ja, auch bei 1!

Die Fragen kann man sich doch alle selber beantworten, wenn man einfach mal ein Beispiel Schritt für Schritt durchgeht.

So ein Schwachsinn!

Dass viele Leute so wie du denken, gleichzeitig aber leider zu wenig Ahnung von Threading haben (die ich dir auch abspreche, sonst wüsstest du dass das Thema lange nicht so einfach ist), ist der Grund, warum so irre viele Leute andauernd Threading-bezogene Fehler machen.

Bla-Blubb.

Viel Spass beim schlechte Programme schreiben noch weiterhin.

Mal ganz davon abgesehen, dass es selbst bei "nur ein Prozessor und auch nur ein Core (und auch kein Hyper-Threading etc.)" Probleme geben kann.

mal ehrlich schrieb:

Die Fragen kann man sich doch alle selber beantworten, wenn man einfach mal ein Beispiel Schritt für Schritt durchgeht.

So ein Schwachsinn!

Dass viele Leute so wie du denken, gleichzeitig aber leider zu wenig Ahnung von Threading haben (die ich dir auch abspreche, sonst wüsstest du dass das Thema lange nicht so einfach ist), ist der Grund, warum so irre viele Leute andauernd Threading-bezogene Fehler machen.

Bla-Blubb.

Viel Spass beim schlechte Programme schreiben noch weiterhin.

Dann unterstell ich dir jetzt mal, dass du dumm bist, wenn das hier schon kompliziert für dich ist. Jetzt sag mir doch mal bitte bei welchem dieser 3 einfachen Beispiele man nicht selber drauf kommen kann, was schief gehen kann, wenn er es genauer beschrieben hätte, so dass man es Schritt für Schritt durchgehen kann? Das was du hier machst sie doch nur dummes raten, weil die Beschreibung viel zu ungenau ist.

@xBlackKnightx:
Wie kommst du auf die Idee dass nur ein Thread gleichzeitig laufen würde??? Ich hab nen Quad-Core (auch "nur 1 Prozessor"), da laufen hübsch 4 Threads gleichzeitig.

Mal ganz davon abgesehen, dass es selbst bei "nur ein Prozessor und auch nur ein Core (und auch kein Hyper-Threading etc.)" Probleme geben kann.

Hmm also die Prozesse werden im Prozessor verteilt? Würde ein Programm auch schneller laufen wenn man Skripte, Funktionen in Threads verteilt? Also bei 1-Prozessor PC

1.) Initialisierung (oder auch Zuweisung) einer gemeinsam genutzten Variablen

MyObj global;
{ // start paralleler Block
    MyObj aObj(global);
    // bzw.
    MyObj* pObj = new MyObj(global);
} // ende paralleler Block

Du erstellst doch fuer jeden Thread eine eigene Kopie von global. Sollte der MyObj-Ctor keine Schreibzugriffe irgendeiner Art (siehe Fall 2) enthalten, muesste das okay sein.
Aber wenn du im parallelen Block auf global zugreifst, muss dieser Zugriff geschuetzt werden!

2.) Aufruf einer Methode einer gemeinsam genutzten Variablen

class MyObj
{
    //...
    // Fall a)
    void DoSomething() const;
    // Fall b)
    void DoSomething();
}

MyObj global;
{ // start paralleler Block
    global.DoSomething();
} // ende paralleler Block

die const-Methode musst du nicht schuetzen, wenn diese wirklcih keine Zustaende schreibt. Aber wenn MyObj mutable-Variablen hat, DoSomething eine globale Funktion aufruft/auf globale Variablen zugreift, Dateizugriffe hat etc. etc. musst du auch hier synchronisieren.
Ebenfalls synchronisieren musst du, wenn es einen anderen Thread gibt, der gleichzeitig ausgefuehrt wird und dieser irgendwie global veraendert.
Die nicht-const-Methode - welche vermutlich irgend eine Schreib-Operation enthaelt - muss sowieso synchronisiert werden.

3.) Aufruf einer Funktion, die eine gemeinsam genutzte Variable übergeben bekommt

void DoSomethingWith(const MyObj&)
{
    // do something with MyObj
}
MyObj global;
{ // start paralleler Block
    DoSomethingWith(global); 
} // ende paralleler Block

Wenn DoSomethingWith irgend einen Status schreibt (s.o.) musst du synchronisieren.

Ich gebe zu, dass meine Beispiele für konkrete Antworten eigentlich zu allgemein sind. Die Antworten haben trotzdem geholfen, dass mir die Sache ein wenig klarer geworden ist.

hustbaer schrieb:

mal ehrlich schrieb:

Die Fragen kann man sich doch alle selber beantworten, wenn man einfach mal ein Beispiel Schritt für Schritt durchgeht.

So ein Schwachsinn!

Dass viele Leute so wie du denken, gleichzeitig aber leider zu wenig Ahnung von Threading haben (die ich dir auch abspreche, sonst wüsstest du dass das Thema lange nicht so einfach ist), ist der Grund, warum so irre viele Leute andauernd Threading-bezogene Fehler machen.

Bla-Blubb.

Viel Spass beim schlechte Programme schreiben noch weiterhin.

Dann unterstell ich dir jetzt mal, dass du dumm bist, wenn das hier schon kompliziert für dich ist. Jetzt sag mir doch mal bitte bei welchem dieser 3 einfachen Beispiele man nicht selber drauf kommen kann, was schief gehen kann, wenn er es genauer beschrieben hätte, so dass man es Schritt für Schritt durchgehen kann? Das was du hier machst sie doch nur dummes raten, weil die Beschreibung viel zu ungenau ist.

Aha.

hustbaer schrieb:

@xBlackKnightx:
Wie kommst du auf die Idee dass nur ein Thread gleichzeitig laufen würde??? Ich hab nen Quad-Core (auch "nur 1 Prozessor"), da laufen hübsch 4 Threads gleichzeitig.

Mal ganz davon abgesehen, dass es selbst bei "nur ein Prozessor und auch nur ein Core (und auch kein Hyper-Threading etc.)" Probleme geben kann.

Hmm also die Prozesse werden im Prozessor verteilt? Würde ein Programm auch schneller laufen wenn man Skripte, Funktionen in Threads verteilt? Also bei 1-Prozessor PC

Was hat denn schneller laufen mit Korrektheit und Thread-Safety zu tun?

Und was meinst du jetzt mit "1-Prozessor PC"? Single-Core, oder Single-CPU? Auf Single-CPU, Multi-Core Systemen bringt das was, ja.

Auf Single-CPU, Single-Core Systemen bringt es u.U. auch was, z.B. wenn die Skripte oder Funktionen IO machen, und dadurch auf etwas warten müssen, während die CPU Däumchen dreht.

Bezüglich deiner "bloss eine Variable" Frage, lies mal das, da werden einige der Probleme angesprochen:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1680.pdf