Taking a mutex. Low-level point of view

Taking a mutex must be a atomic operation. Moreover, taking mutex must be supported by OS- it controls if mutex is free ( or not). And, I've taken a look into assembly output: And locking mutex in C++11 looks like:

<__GI___pthread_mutex_lock+103>  lock cmpxchg %edi,(%r8)                                                                                                                         
<__GI___pthread_mutex_lock+108>  je     0x7ffff7323d04 <__GI___pthread_mutex_lock+132>                                                                                           
<__GI___pthread_mutex_lock+110>  lea    (%r8),%rdi                                                                                                                               
<__GI___pthread_mutex_lock+113>  sub    $0x80,%rsp                                                                                                                               
<__GI___pthread_mutex_lock+120>  callq  0x7ffff7329b40 <__lll_lock_wait>   

And lock ensures about atomicity of taking a mutex. But what about memory ordering? We know, that x86 can reorder StoreLoad. And, we don't want the CPU can execute instruction without a taken mutex. I mean the following situation:

std::mutex mut;
mut.lock() 
( here is called pthread_mutex_lock ) 
.......
Any LOAD operation. // THE CPU executed it because of the memory reordering- I don't see any fences in assembly output.

I've written a piece of pseudocode- I hope it is clear what I mean.