[Bug libc/17428] New: 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

            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.