This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17428] lll_trylock barrier semantics when lock was not acquired differ between architectures
- From: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 06 Apr 2017 12:11:29 +0000
- Subject: [Bug libc/17428] lll_trylock barrier semantics when lock was not acquired differ between architectures
- Auto-submitted: auto-generated
- References: <bug-17428-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17428
--- Comment #3 from Torvald Riegel <triegel at redhat dot com> ---
I do not remember who brought this up, but one can argue that the POSIX
requirements on synchronization only apply to function calls that do not fail.
This seems sensible to me. It means that trylocks that fail by returning EBUSY
do not imply any synchronization effects, so implementing lock acquisition
attempts in trylock with an atomic_compare_exchange_weak_acquire would be okay
(whose failure path has relaxed MO semantics and can fail spuriously).
--
You are receiving this mail because:
You are on the CC list for the bug.