3

I have read that both pthread_mutex_lock() and pthread_mutex_unlock() contain memory barriers.

And I also read that when you call a function, the function call itself act as a memory barrier.

So what is the point of including memory barriers in the functions pthread_mutex_lock() and pthread_mutex_unlock()?

I mean say that we have the following code:

a = 5;
b = 7;
pthread_mutex_lock(&lock);
i++;
pthread_mutex_unlock(&lock);
c = 10;

Whether pthread_mutex_lock() and pthread_mutex_unlock() contain memory barriers or not, the above code would still be executed the same.

James
  • 703
  • 8
  • 17
  • Function calls in C also involve [sequence points](https://en.wikipedia.org/wiki/Sequence_point), which may be what you're thinking of. There's no explicit guarantee changes made to memory by one thread are visible to other threads even when functions are called, which is why memory barriers exist - to make sure changes to memory are not only visible beyond the current thread of execution, but are also coherent. – Andrew Henle May 19 '18 at 12:56
  • 1
    A function call is at most a compiler barrier, and only if the compiler cannot see what's happening inside that function (eg. a library call). Mutex lock & unlock calls need stronger guarantees which may or may not result in the compiler generating CPU barrier instructions (depending on your architecture). On `X86` a compiler barrier suffices for `lock` and `unlock`; ie. it's unlikely you will find any CPU barrier instructions in the compiler generated assembly – LWimsey May 20 '18 at 01:03
  • @LWimsey But if a function call did not also act as a CPU barrier, the code inside `pthread_mutex_lock()` and `pthread_mutex_unlock()` could get out! – James May 20 '18 at 05:35
  • @James not on `X86` where the normal mode of operation guarantees that acquire and release barriers are implicit. Check [this page](http://preshing.com/20120913/acquire-and-release-semantics/) for more details and look for the `X86` part – LWimsey May 20 '18 at 05:47

1 Answers1

1

A memory barrier just tells you that it makes sure that you can control if you can access some part of your code (to clarify: code manipulates memory).

If you mean the function pthread_barrier_wait() : There is a small difference. If you just call mutex_lock you will have to wait till this mutex unlocks, before you can continue.

With barrier you will have to wait till the requiered number of threads have called a 'wait' on the 'barrier'.

phtread1-------é[..........blocked]-------

phtread2----é[.............blocked]-------

pthread3--------------------------é-------

to clarify what i did above: the é are calls for a barrier, the '-' is when the program is executing and the '.' is when you are waiting.

J. Joly
  • 113
  • 3
  • 14
  • I believe you are confusing [a memory barrier](https://en.wikipedia.org/wiki/Memory_barrier) with function calls such as [`pthread_barrier_wait()`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_barrier_wait.html). – Andrew Henle May 19 '18 at 12:50
  • you are totally right, I adjusted it. But I thought that was the thing his question referenced to. – J. Joly May 21 '18 at 08:41