Compiler reordering around mutex boundaries?

Question

Suppose I have my own non-inline functions LockMutex and UnlockMutex, which are using some proper mutex - such as boost - inside. How will the compiler know not to reorder other operations with regard to calls to the LockMutex and UnlockMutex? It can not possibly know how will I implement these functions in some other compilation unit.

void SomeClass::store(int i)
{
  LockMutex(_m);
  _field = i;  // could the compiler move this around?
  UnlockMutex(_m);
}

ps: One is supposed to use instances of classes for holding locks to guarantee unlocking. I have left this out to simplify the example.

Answer 1

If compiler was doing so that'd be a bad compiler. ;-)

Answer 2

In general, a compiler will not move code around unless it knows with certainty that doing so will not affect run-time behavior.

Answer 3

If the compiler can't guarantee that the function calls won't have side effects that will modify the variables between the calls, it can't move the code. If the variable is a local variable and you've never taken a reference or created a pointer to it, the compiler might assume it's safe to move; I don't know.

Answer 4

As it is written, if the functions are not inline, the compiler won't move the variable assignation, as the call may be unrelated to the _field variable, but it has to preserve the strict order of calls. If, however, the compiler decides to inline the calls, I think it will treat them as blocks of independent code, that is, it will only reorder instructions within the same code unit (the inlined function itself) but not with the following or preceding code (the assignation to the _field variable).

Answer 5

You're right, that code is correct and safe. I did think of a "code joke," though.

pthread_mutex_lock( &mx ) + foo() + pthread_mutex_unlock( &mx );

Answer 6

It can not possibly know how will I implement these functions in some other compilation unit.

This is the key - since the compiler cannot know (in general) about the implementation of the function calls, it can't move the store to _field outside those function calls.

Generally, since _field is accessible outside of SomeClass::store() (it's not a local), the compiler can't know whether or not it's modified by the external function, therefore it must perform the store to _field between the function call sequence points.

The underlying hardware platform might need some attention in the form of memory barriers or cache flushes to deal with caching or out of order operations that occur in the hardware. The platform's implementation of the mutex APIs will deal with those issues if necessary.