This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/16432] New: pthread_spin_unlock should imply a memory barrier
- From: "mikulas at artax dot karlin.mff.cuni.cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 11 Jan 2014 02:38:39 +0000
- Subject: [Bug nptl/16432] New: pthread_spin_unlock should imply a memory barrier
- Auto-submitted: auto-generated
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.