Re: nptl 0.30

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> dada1 wrote:
>
> > File sysdeps/pthread/pthread_cond_wait.c, line 61
> >
> > lll_futex_wake (futex, INT_MAX);
> > /* We are done.  */
> > lll_mutex_unlock (cbuffer->cond->__data.__lock);
>
> That is in a cancellation handler.  And I used that order deliberately
> to enable the canceled thread to resolve as quickly as possible.  If it
> makes people happy I can revert it.  It's of no real consequence since
> in all probability, if any thread gets awaken, it's most of the time put
> the sleep again.
>
> Provide some benchmarking.
>

Ulrich, I was speaking of your habit to such constructs. I chose to talk
about cancellation because this is what I saw at first code inspection.
I wont provide benchmark as I dont use cancellation myself.

About performance, I am 100% sure your order CANT be faster... awaken
threads put to sleep again just blow the CPU caches for nothing (each thread
has its own stack)

I have a big threaded application that benefit a huge gain just by inverting
the unlock/wake. This is because the linux kernel *always* preempt the
current thread in favor of the awaken thread(s). The number of context
switchs came from 11000 to 3000 per second.

You already did the change I suggested in
sysdeps/unix/sysv/linux/i386/i486/pthread_cond_broadcast.S

Why dont you do the same in sysdeps/pthread/pthread_cond_broadcast.c ?
If this file is not used at all, then suppress it, we wont loose time to
inspect the source code and bother you.

Eric