[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 #5 from Rich Felker <bugdal at aerifal dot cx> ---
Perhaps I'm being redundant saying this again, but I believe that whether the
function synchronizes memory on failure (I agree that it doesn't have to) is a
separate issue from whether it's permitted to return an error when the
conditions for that error code are not met. The answer to the latter is no, but
there are subtleties to the condition itself that make the topic nontrivial
still.

I don't believe there is any viable argument for returning EBUSY simply due to
a weak cas, when the mutex was never locked or the semaphore value was never
zero, and regardless of any ordering (perhaps this is even a single-threaded
process!) the operation should succeed. Likewise if you have a strong cas, but
the cas failure is due to something that wouldn't preclude the operation from
succeeding (like waiting on a semaphore whose value is >1 from another thread),
this should not be able to cause EBUSY. The only case in which there is an
argument to be made that a "spurious" EBUSY is valid is when, despite a lack of
other operations that synchronize memory, some other side channel (like a pipe)
establishes an ordering whereby the operation "should have" succeeded.

If no such order-imposing operation is present at all, then I think it's clear
that you can "spuriously" fail whenever there's any possible ordering that
would have produced failure.

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