[Bug nptl/16432] New: pthread_spin_unlock should imply a memory barrier

["mikulas at artax dot karlin.mff.cuni.cz" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16432

            Bug ID: 16432
           Summary: pthread_spin_unlock should imply a memory barrier
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: mikulas at artax dot karlin.mff.cuni.cz
                CC: drepper.fsp at gmail dot com

This specification lists functions that should synchronize memory:
http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11

One of the functions is pthrad_spin_unlock. In glibc on i386, x86-64 and x32,
pthread_spin_unlock is an alias for pthread_spin_init. pthread_spin_init
doesn't synchronize memory, so it violates the specification.



Note: in the Linux kernel (or other custom environments), there are acquire and
release semantics for locking functions defined in the following way:

mutex or spinlock locking has "acquire" consistency semantics - that means that
access_memory();spin_lock() can be reordered to spin_lock();access_memory()

mutex or spinlock unlocking has "release" consistency semantics - that means
that spin_unlock();access_memory() can be reordered to
access_memory();spin_unlock()


The current implementation of pthread_spin_unlock in glibc conforms to the
"release" consistency semantics (that is, the processor can move memory
accesses before the call to pthread_spin_unlock, but it will not move any
memory access past the call to pthread_spin_unlock).

However, the posix document doesn't mention "acquire" or "release" semantics,
it just states that all specified functions should synchronize memory, so you
should implement them to perform a full memory barrier.

-- 
You are receiving this mail because:
You are on the CC list for the bug.