This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]