This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/83638] atomic_is_lock_free should return false on pa-risc


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]