Re: Does pthread_mutex_lock/unlock require and imply a memory barrier for all addressable memory?

[Mark Brown <ms_brown at sbcglobal dot net>]

Hey-

On 07/07/2014 11:33 AM, Chip Bagwell wrote:
> In reading the POSIX 2008 standards found here,
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11,
> 
> the following paragraph is written regarding memory synchronization.
> 
> "Applications shall ensure that access to any memory location by more
> than one thread of control (threads or processes) is restricted such
> that no thread of control can read or modify a memory location while
> another thread of control may be modifying it. Such access is
> restricted using functions that synchronize thread execution and also
> synchronize memory with respect to other threads. The following
> functions synchronize memory with respect to other threads:"

The point of the section is to warn applications to synchronize memory
uses, and then points application writers to tools which can help them
do this (the list).

glibc is considered an implementation of the specification, not an
application. Implementations are free to create the APIs in the list in
any fashion they like, as long as they meet the specification for the
API in question. Applications should not expect the API to do anything
more (or less!) than what is described in the specification if they wish
to be POSIX-portable.

>
> I read the "synchronize memory with respect to other threads" to mean
> that a memory barrier is required in both pthread_mutex_lock() and
> pthread_mutex_unlock() along with the other mentioned functions in the
> standard.  Otherwise what would be protecting the data
> structures/variables you are trying to access/modify inside the
> critical section protected by the mutex?

The APIs in the list are meant to be used _in_combination_ to achieve
the application's goals. One locked critical section may not have
critical memory accesses, while another may indeed need barriers.


-- 
Mark Brown
ms_brown@sbcglobal.net