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

Re: Poor condvar performance



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamie Lokier wrote:

> The man pages that I've read for cond_wait suggest that all waiters
> use the same mutex.  But it doesn't seem to be a requirement.

It is a requirement.  Using more than one mutex is unspecified.  What is
possible is that if the condvar is cmopletely unused, a new caller can
start using a different mutex.  But all waiters must at any time use the
same one.


> If one mutex is a hard requirement, then failing FUTEX_WAIT2 is fine.

Yep.  But the question is: when is the address value stored by WAKE2
reset?  It must be possible to start using a new mutex.


> Another possibility is that whichever mutex address is given to the
> _last_ call to FUTEX_WAIT2 is used.  That provides a mechanism for
> multiple requeueings of a waiter, if that should ever prove to
> be useful.

There is a semantics problem if this would be done.  What happens if the
later call has a timeout and returns prior to being woken?  Then you
have only the first thread waiting and the second waiters address is
remembered.

It's cleaner to force the use of only one value.


> FIFO is used by Rusty's "fair mutex" in the futex-2.2 example code,
> which cannot starve any threads unlike the simplest mutex type in his
> code.

I haven't looked at that code for some time but I think it is flawed.


> Indeed, futex seems quite useful for RT synchronisation.  If only we
> had a good idea what we wanted from the kernel to permit userspace to
> implement all the different priority inversion workarounds that
> various programs would want.

Well, some of the Intel guys here have some ideas.


> Isn't it safe for the woken thread to be told if any were requeued,
> and if so do the atomic word op _as if_ another thread had done "lock
> and block"?  Or do signals complicate this picture?

The problem are the threads in flight, either on the way into the kernel
or out (because they are woken or signalled or timed out).  I don't want
to discourage you want I would sure like you to look at some other
things first.


> If I understand right that all cond_wait-ers _must_ use the same
> mutex, then I agree.

As said above, the one-mutex rule can be enforced.


> Do you still need REQUEUE?

Yes.  I'm looking at another change where REQUEUE is needed.


> It seems we could drop it and just have WAIT2/REQUEUE2.  We could also
> drop WAKE (just use REQUEUE2 with 0 for nr_requeue) but the API hit is
> too severe for that ;)

Don't drop REQUEUE and dropping WAKE was already rejected at the time we
introduced REQUEUE.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/xq4i2ijCOnn/RHQRAjV3AJ9D57TQ+GK7aTQIl6UYIxzc7dSx/wCdHMBZ
qFOmX/eDuPLa8sckMw9syZk=
=3BSa
-----END PGP SIGNATURE-----




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