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: Tue, 03 Feb 2015 10:46: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> <1420645419 dot 29798 dot 35 dot camel at triegel dot csb> <20150107 dot 214633 dot 1588826977456196901 dot davem at davemloft dot net>
Ping. (For 2.22 ...)
On Wed, 2015-01-07 at 21:46 -0800, David Miller wrote:
> 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.