-1

Given a generic message passing pattern between two threads:

Thread-A                  Thread-B
-------------------       ---------------------
LockMutex(M1)
Get memory for Msg
  from shared resource
UnlockMutex(M1)

set Msg attributes (content)
(note: is *NOT* performed
 within a critical section--
 once the Msg's contents
 have been set, no other
 writes to the Msg 
 is performed)

LockMutex(M1)
place pointer of Msg
  within Thread-B's
  message queue.
UnlockMutex(M1)

notify Thread-B
  of new Msg
-------------------       ---------------------
                          LockMutex(M1)
                          extract pointer to Msg from
                            queue.
                          UnlockMutex(M1)

                          read contents of Msg
                          (note: Thread-B only *READS*
                           the contents of Msg)

Q: If 'M1' is a generic mutex, is Thread-B ALWAYS guaranteed to have the correct contents of 'Msg' when C++ or C is used to implement the software? Q: Will this pattern not work correctly for certain combinations of operating systems and/or processor configurations? (Am mostly concerned with OSes such as Linux, Windows, Mac OS X, VxWorks, Green Hills, and Micrium)

My understanding (which could be incorrect) is that the critical section implemented by the locking and/or unlocking of mutex 'M1' will cause a memory barrier/fence instruction to be executed which will ensure processor/core cache coherence; thus Thread-B is guaranteed to read the correct contents of 'Msg'. However, I'm having some difficulty locating authoritative documentation which indicates the above "general pattern" is correct.

Ken Mumme
  • 80
  • 1
  • 3
  • A memory model is an attribute of a programming language (or at a lower level, a feature of a CPU). This question can only be answered in the context of a specific memory model, and so is unanswerable in its current form. – Mankarse Jul 20 '14 at 10:23
  • I think to answer your question, you would have to know the type of CPU, i.e. "weak" vs "strong" memory model, then which runtime your code is using. Though if you're using Java, the JVM has a very specific memory model across all architectures, which leads me to believe that the CPU type doesn't matter for your question. – Chris O Jul 20 '14 at 15:05
  • @Ken Mumme: The definitive documentation that you want is the [C or C++ standard](http://stackoverflow.com/q/81656/485561) (respectively). In `C11`, the relevant sections are `5.1.2.3` and `5.1.2.4` (the memory model), and `7.17` and `7.26` (the standard library components). In `C++11`, the relevant sections are `1.9` and `1.10` (the memory model), and `29` and `30` (the standard library components). Overall, this question is too broad; C and C++ are different languages, and the pseudo-code in your question could be interpreted in a lot of ways. – Mankarse Jul 20 '14 at 15:59

1 Answers1

0

In the general sense, the "message passing pattern" depicted is NOT "thread safe" for all platforms; however, for some platforms (such as single-processor w/ single-core, or certain multi-core processors with strong cache coherency, such as Intel/AMD x86-64) the above pattern will work... but should be avoided due to not conforming to the C++11 memory model.

Ken Mumme
  • 80
  • 1
  • 3
  • `Will work` + `not conforming` doesn't make sense to me. – nwp Jul 26 '14 at 08:29
  • i.e., it is not a _platform_ _independent_ pattern (due to non-conformance with C++11 memory model); however, it will work on some platforms (e.g., most Intel/AMD x86-64 based systems) if the processor(s) use a strong cache coherency protocol. – Ken Mumme Jul 27 '14 at 11:23
  • I didn't express my point very well. The point is that non conforming c++ code will never reliably work. In the above example the compiler can generate code that effectively copies the message data into registers for performance and the update only updates the memory, not the registers, so platform specific guarantees like strong cache coherency do not help. Only compiler extensions can make non conforming c++ code work correctly, not hardware guarantees. – nwp Jul 27 '14 at 13:32