Re: Thread starvation with mutex

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

Jamie Lokier wrote:

> No, the problem is _starvation_.  It would be good for the second
> thread to run _eventually_,

Why?  This means sacrifizing the superior position the long running
thread is in.

Fairness in the presence of a single mutex/semaphore is detrimenal to
performance.  This is not what the implementation is supposed to do.  If
fairness is _needed_ the programmer must take this into account and
design the program to not have this one big lock.

If the kernel gets a scheduler policy where, if a kernel process waits
for a very long time it'll acrue tons of karma so that it immediately
displaces all running threads, then this is fine.  I sincerely hope this
will never be default scheduling policy but, hey, if it makes you feel
better implement it.  This all has nothing to do with the userlevel code
since it was a design decision to let the kernel handle all scheduling
decisions.

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

iD8DBQFAKSl/2ijCOnn/RHQRAlwZAKCF2QAyr8TI6Ajbna7BlgB/TvNzhgCggwRO
uPCnAoCdAagUsREuXFO3Nk4=
=wptT
-----END PGP SIGNATURE-----