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