This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: lll_futex_wake_unlock customized on sparc -- why?
- From: Torvald Riegel <triegel at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 07 Jan 2015 16:43:39 +0100
- Subject: Re: lll_futex_wake_unlock customized on sparc -- why?
- Authentication-results: sourceware.org; auth=none
- References: <1418859899 dot 1025 dot 5 dot camel at triegel dot csb> <20141217 dot 233829 dot 323581797258926170 dot davem at davemloft dot net>
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.