This is the mail archive of the libc-alpha@sourceware.org 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?


From: Torvald Riegel <triegel@redhat.com>
Date: Wed, 07 Jan 2015 16:43:39 +0100

> On Wed, 2014-12-17 at 23:38 -0500, David Miller wrote:
>> From: Torvald Riegel <triegel@redhat.com>
>> 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.
> 
> Ping.
> 
> 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
> glibc.

I'm travelling and won't be able to look at this until next Monday.


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