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

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

[triegel at redhat dot com]

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

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

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

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

[triegel at redhat dot com]

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

            Bug ID: 17428
           Summary: lll_trylock barrier semantics when lock was not
                    acquired differ between architectures
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: triegel at redhat dot com
                CC: drepper.fsp at gmail dot com

This matters because lll_trylock is used by pthread_mutex_trylock; POSIX'
barrier requirements are impractical IMO (the wording would require full
barriers for every synchronization function), but stronger than what all arcs
provide.  C++11 only requires weak barrier semantics (memory_order_relaxed,
essentially, and spurious false negatives (ie, trylock returns that it can't
acquire the lock although it could) are allowed); these semantics make more
sense IMHO.

The default (/sysdeps/nptl/lowlevellock.h) uses
atomic_compare_and_exchange_bool_acq, which is memory_order_relaxed on the
failure path of the CAS (lock not acquired).  ARM uses the default.

Power has memory_order_acquire on the failure path.  x86/x86_64 as well,
effectively.

We should both unify this and, IMO, work towards improving POSIX' semantics.

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

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

[bugdal at aerifal dot cx]

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

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
Could you explain the basis of your claim that C11 mtx_trylock allows spurious
failures? I suspect this is a misstatement of something rather different:
roughly, that there are situations where operations are non-ordered to an
extent that both a view that the mutex is already locked, and a view that it's
not already locked, are both consistent with everything else observable. But in
cases where the mutex is, from the calling thread's perspective, provably in
either the locked or unlocked state, I think mtx_trylock is required to produce
an accurate result. I don't see any language that would exempt it from this
requirement that's specified in its normative Description/Returns text
(7.26.4.5 p2-3).

As for "improving" POSIX's semantics, that's another matter, and it really
depends on the outcome of the alignment process and further action by the
Austin Group and sponsors. I'm still not clear on whether weakening trylock
would be an improvement, and my view largely depends on the degree to which
such a weakening could be inconsistent/counter-intuitive and lead to bugs,
especially in applications which were correct with respect to a previous issue
of the standard. But I think it's outside the scope of this glibc tracker
issue.

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

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

[triegel at redhat dot com]

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.