[Bug libc/17428] lll_trylock barrier semantics when lock was not acquired differ between architectures

["triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #2 from Torvald Riegel <triegel at redhat dot com> ---
See the C++ standard 30.4.1.2/16 (not that I spoke about C++11).

C11 doesn't spell out the spurious failures, but C++11 allows them, IIRC, to be
able to give the guarantee to programmers that a data-race-free program will
behave like under sequential consistency if only locks and
sequentially-consistent atomics are used; that won't work with a trylock
because then you can use a lock like a single-assignment atomic variable,
revealing non-seq_cst semantics.  C11 wants to follow the same memory model, so
I believe it should also allow the spurious failures.  There's several things
that C11 doesn't say although it should...
Anyway, even C11 doesn't give a synchronizes-with guarantee for trylock that
fails to acquire.

POSIX' semantics do matter because that's what pthread_mutex_trylock is meant
to implement.

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