6

I'm currently using openMP to write code running on multi-core nodes. openMP has a specific memory model which guarantees that memory is synchronised between threads running on different cores when a lock is acquired.

I consider using C++11 constructs (std::thread with std::mutex and std::lock) instead of openMP (because of their larger flexibility) and wonder if/how memory synchronisation between processors is guaranteed here? And if not, how can I enforce it?

Walter
  • 44,150
  • 20
  • 113
  • 196
  • 1
    Your question is a bit unclear. It almost looks like your asking how to do multithreaded programming. – John Dibling Jun 08 '12 at 13:44
  • Some synchronization is guaranteed, some isn't. This question is really vague. – jpalecek Jun 08 '12 at 13:47
  • 1
    Do you mean memory synchronisations of the `mutex` itself or of the data accesses in the code protected by the mutex? – KillianDS Jun 08 '12 at 13:57
  • 1
    C++ doesn't care about cores or processors (other than the `hardware_concurrency` function, perhaps). If it synchronizes between threads, it synchronizes between threads. – R. Martinho Fernandes Jun 08 '12 at 14:24
  • 2
    Seems like a clear question to me - I assume he's asking if c++ mutexes imply a full memory barrier? – jcoder Jun 08 '12 at 14:41
  • @JohnB: The the answer is also simple: **No.** However, *memory is synchronized between cores* isn't really a description of a full memory barrier. – jpalecek Jun 08 '12 at 15:47
  • No, I just assumed that was what he meant. – jcoder Jun 08 '12 at 16:07
  • @KillianDS the second of your points is exactly what I meant (of course). As far as I understand, the compiler doesn't know which data are protected by the mutex, does it? – Walter Jun 10 '12 at 08:44

1 Answers1

10

The standard makes the following guarantees about synchronization of std::mutex, in §30.4.1.2[thread.mutex.requirements.mutex]/6-25

The expression m.lock() shall be well-formed and have the following semantics

Synchronization: Prior unlock() operations on the same object shall synchronize with this operation.

And, likewise,

The expression m.unlock() shall be well-formed and have the following semantics

Synchronization: This operation synchronizes with subsequent lock operations that obtain ownership on the same object.

(Where "synchronizes with" is a specific term explained in $1.10, although it's much easier to understand by reading C++ Concurrency In Action)

Community
  • 1
  • 1
Cubbi
  • 46,567
  • 13
  • 103
  • 169
  • 1
    Which suggests that the presence (or absence) of multiple processors does not matter... It is up to the implementation to enforce these guarantees. – André Jun 08 '12 at 13:53
  • can you refer me to a web resource that explains what "synchronizes with". Does this imply cache coherence on a multi-core node? – Walter Jun 10 '12 at 08:42
  • 3
    @Walter in brief, it means every store made by the thread that released the mutex becomes visible to the thread that acquired the mutex, but not to other thread. It implies a release barrier and an acquire barrier, or their equivalents. – Cubbi Jun 10 '12 at 13:52