This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/83638] atomic_is_lock_free should return false on pa-risc
- From: "dave.anglin at bell dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 26 Mar 2018 20:51:31 +0000
- Subject: [Bug target/83638] atomic_is_lock_free should return false on pa-risc
- Auto-submitted: auto-generated
- References: <bug-83638-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638
--- Comment #3 from dave.anglin at bell dot net ---
On 2018-03-26 2:23 PM, mikulas at artax dot karlin.mff.cuni.cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638
>
> --- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
> >From performance point of view it doesn't matter if the lock is taken inside
> the kernel or inside the gcc library.
Actually, I believe it does. It's not possible for a userspace
implementation to be non
interruptable. The atomic implementation is also tied to the futex
implementation in the kernel.
Interrupts are disabled around the lock to ensure the code can't
schedule. The lock itself is
never held for more than a few instructions. However, the code may spin
in kernel and
userspace.
The original choice whether the support was "lock free" was based on the
following in md.texi:
For the purposes of C++11 @code{std::atomic::is_lock_free}, it is
assumed that these library calls do @emph{not} use any kind of
interruptable locking.
The original linuxthread implementation used userspace locks and it was
pretty much a disaster
for a variety of reasons.
>
> If the userspace wants to optimize different code paths for lockless atomics
> and for locked atomics, atomic_is_lock_free should return false, to indicate
> that the atomic operation is as costly as taking a lock.
I'm not against atomic_is_lock_free always returning 0 on hppa but I've
yet to see a
real world situation where it makes a difference.
Dave