[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: pingpong, etc. programs

> From: Ulrich Drepper [mailto:drepper redhat com]

> The correct solution is to have the kernel handle the wakeup correctly.
>  Our current thinking is to wake up only one thread.  All the other
> threads are moved from the wait-queue of the condvar to the wait-queue
> of the mutex.  Since there is exactly one mutex involved with every
> condvar at any one time the pthread_cond_broadcast function knows where
> the mutex wait list is.
> I just have to wait for Ingo to have some time to implement this.

I tried to take a spin at this: basically moving all waiters from
the condvar's futex to the mutex's futex, right?

I twidled the futex code to do this, creating
FUTEX_WAKE_REQUEUE. I am sure I must have missed a bunch of
things, but as a proof-of-concept it should be ok. I tried to
modify NPTL to play with it, but I got nowhere. The problem is
in __pthread_cond_broadcast (the asm version), when the first
waiter gets out of the futex_wait and gets the mutex without
knowing that there are waiters in the kernel; I tried to play
dirty a wee bit, but I didn't invest too much effort, as I
need to move on to other stuff. So I thought maybe you guys would
like to play with it.

Attached are the patch for the requeue kernel support (2.5.68) and
the hacks I did to nptl 0.30 trying to get it to work ...

Ulrich, is this something like what you are looking for? Could you
pipe it to Ingo?

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

Attachment: requeue-1.patch
Description: Binary data

Attachment: requeue-nptl-0.30.patch
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]