Compiler reordering around mutex boundaries?

前端 未结 6 822
心在旅途
心在旅途 2020-12-17 23:14

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 o

相关标签:
6条回答
  • 2020-12-17 23:23

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

    0 讨论(0)
  • 2020-12-17 23:30

    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.

    0 讨论(0)
  • 2020-12-17 23:32

    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 );
    
    0 讨论(0)
  • 2020-12-17 23:37

    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).

    0 讨论(0)
  • 2020-12-17 23:38

    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.

    0 讨论(0)
  • 2020-12-17 23:41

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

    0 讨论(0)
提交回复
热议问题