This is the mail archive of the mailing list for the glibc 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]

Re: lll_futex_wake_unlock customized on sparc -- why?

On Wed, 2014-12-17 at 23:38 -0500, David Miller wrote:
> From: Torvald Riegel <>
> Date: Thu, 18 Dec 2014 00:44:59 +0100
> > Dave, do you know why sparc lowlevellock.h avoids FUTEX_WAKE_OP (see
> > code snippet below)?  The only client of this function seems to be in
> > nptl/pthread_cond_signal.c, which falls back to normal FUTEX_WAKE due to
> > this change.
> > 
> > Is this customization essential, or just bit-rot?  Except this change,
> > sparc lowlevellock.h seems to have standard futex operations; it would
> > be nice if we could use the generic lowlevellock-futex.h on sparc too.
> Until the tree builds for sparc again I won't be able to test any
> changes in this area anyways, so it will take me some to get to a
> point where I can look into this.


The only use of lll_futex_wake_unlock that I see is in
nptl/pthread_cond_signal.c.  What do you think about moving the
SPARC-specific customization there (if it's still really needed)?
That's not as nice because we move an arch-specific hack to a generic
file, but the condvar replacement I'm working on that fixes the condvar
ordering bugs isn't using an internal lock in pthread_cond_signal, so
this would go away anyway as soon as the new condvar makes it into

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