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

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

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.