<![CDATA[C++ und out-of-order execution]]>Hallo zusammen,

gegenben sei folgendes Code-Snippet:

// 
MyClass::setValue(int newValue)
{
  // yourMutexType mutex;
  // boost::mutex, QMutex als Beispiel
  mutex.lock();
  mValue = newValue;
  mutex.unlock();
}

Ist dann das Setzen von mValue dann wirklich in allen Fällen auf einen x86er threadsafe ?
Prinzipiell darf der Compiler doch die Write-Back Reihenfolge umsortieren (siehe Topic).

Bitte keine sinnlosen Diskussionen über volatile starten.
Ich gehe übrigens davon aus, dass mutex keinen impliziten Memory Barrier hat und CPU Architektur ist x86 (cache-cohärent).

]]>https://www.c-plusplus.net/forum/topic/290217/c-und-out-of-order-executionRSS for NodeTue, 18 Aug 2026 16:56:05 GMTThu, 21 Jul 2011 14:48:50 GMT60<![CDATA[Reply to C++ und out-of-order execution on Thu, 21 Jul 2011 14:48:50 GMT]]>Hallo zusammen,

gegenben sei folgendes Code-Snippet:

// 
MyClass::setValue(int newValue)
{
  // yourMutexType mutex;
  // boost::mutex, QMutex als Beispiel
  mutex.lock();
  mValue = newValue;
  mutex.unlock();
}

Ist dann das Setzen von mValue dann wirklich in allen Fällen auf einen x86er threadsafe ?
Prinzipiell darf der Compiler doch die Write-Back Reihenfolge umsortieren (siehe Topic).

Bitte keine sinnlosen Diskussionen über volatile starten.
Ich gehe übrigens davon aus, dass mutex keinen impliziten Memory Barrier hat und CPU Architektur ist x86 (cache-cohärent).

]]>https://www.c-plusplus.net/forum/post/2096130https://www.c-plusplus.net/forum/post/2096130Thu, 21 Jul 2011 14:48:50 GMT<![CDATA[Reply to C++ und out-of-order execution on Thu, 21 Jul 2011 14:58:57 GMT]]>Angenommen, es waere nicht threadsafe, welchen Sinn macht dann mutex bzw. deine verwendete Bibliothek?

]]>https://www.c-plusplus.net/forum/post/2096136https://www.c-plusplus.net/forum/post/2096136Thu, 21 Jul 2011 14:58:57 GMT<![CDATA[Reply to C++ und out-of-order execution on Thu, 21 Jul 2011 15:14:01 GMT]]>In der abstrakten Maschine erfolgt die Zuweisung nach dem Lock und vor dem Unlock (schon allein deshalb, weil das Semikolon jeweils einen Sequenzpunkt darstellt).
Der Compiler darf Reihenfolgen verändern, sofern das die Semantik des Programmes nicht verändert (aus Sicht eines einzelnen Threads). Das wäre also nur dann möglich, wenn weder Lock noch Unlock eine Abhängigkeit bzgl. mValue haben. Dieses Fehlen der Abhängkeit kann der Compiler im Prinzip nur dann beweisen, wenn er den Code dieser Funktionen kennt. Jede brauchbare Threading-Bibliothek ist allerdings so geschrieben, dass genau das nicht der Fall ist, die Funktionen also opaque sind. Ist auf diese Weise eine Umordnung durch den Compiler ausgeschlossen, genügt die Bedingung von sequentieller Cache-Kohärenz auch ohne explizite Barriers, sofern jeder Zugriff auf mValue von entsprechenden Locks umgeben ist.

]]>https://www.c-plusplus.net/forum/post/2096144https://www.c-plusplus.net/forum/post/2096144Thu, 21 Jul 2011 15:14:01 GMT<![CDATA[Reply to C++ und out-of-order execution on Thu, 21 Jul 2011 15:22:19 GMT]]>Okay, die Antwort geht in die Richtung die ich wissen wollte.

Allerdings sollte in meiner threading-bibliothek doch explizit das Opaque-Verhalten in der Doku erwähnt sein, oder nicht ?
Bei QT finde ich in der Doku von QMutex beispielsweise nichts darüber, aber beim QAtomicInt kann ich mir die Art der Memory Order auswählen.

]]>https://www.c-plusplus.net/forum/post/2096151https://www.c-plusplus.net/forum/post/2096151Thu, 21 Jul 2011 15:22:19 GMT<![CDATA[Reply to C++ und out-of-order execution on Thu, 21 Jul 2011 20:56:10 GMT]]>Also ich glaube, so etwas Gravierendes wäre bereits aufgefallen...

]]>https://www.c-plusplus.net/forum/post/2096254https://www.c-plusplus.net/forum/post/2096254Thu, 21 Jul 2011 20:56:10 GMT