This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/16432] pthread_spin_unlock should imply a memory barrier
- From: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 23 Sep 2014 18:02:56 +0000
- Subject: [Bug nptl/16432] pthread_spin_unlock should imply a memory barrier
- Auto-submitted: auto-generated
- References: <bug-16432-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16432
Torvald Riegel <triegel at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx,
| |triegel at redhat dot com
--- Comment #1 from Torvald Riegel <triegel at redhat dot com> ---
IMO, POSIX is wrong in requiring all synchronization functions to "synchronize
memory". POSIX essentially requires all of these functions to contain a full
memory barrier, including lock acquisition and lock release functions. This
would slow them down significantly in the uncontended case, just for the
benefit of use cases that aren't about locking but "abusing" locks for barriers
(e.g., to do Dekker(-like) synchronization).
I've raised this topic on the C11/POSIX aligment list. It hasn't been
discussed yet, but I strongly believe that lock acquire/release should not have
full barrier (ie, memory_order_seq_cst semantics).
--
You are receiving this mail because:
You are on the CC list for the bug.