Re: Thread starvation with mutex

Ulrich Drepper wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Gary S. Robertson wrote:
>
>>System/library function calls should be engineered to reliably perform
>>the operations their names and documentation suggest will occur when
>>they are invoked - otherwise they should return with an error.  In this
>>case, if the programmer calls pthread_mutex_unlock, then most likely the
>>intent is to yield the mutex to the next waiting pthread, if any.
>>
>
>What a piece of crap.
>
>The function signals that whatever is protected is available now and
>that the program should make use of the resources in the most efficient
>way.  If this means that same thread uses the resource again that's what
>should happen.  And it is often the case that the running thread is the
>one which can be handled the fastest since the cache are still hot.
>This is what the scheduler takes into account.
>
>If you want explicit hand-off program an appropriate device yourself.
>
>- -- 
>➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAKA0N2ijCOnn/RHQRAt33AKCdzotUJuqXg2OLCam7frfloo1v8gCghPcl
>4OoqPJ18tm3a/ibUmlngEuc=
>=y4tJ
>-----END PGP SIGNATURE-----
>
We obviously have a number of philosophical differences at play here. 
 You say it is 'crap' to suggest that a library function call should 
always do what it's man page says it will, and apparently feel it's okay 
to deviate from the functionality suggested  by that primary 
documentation resource in the name of glorious speed.  Your responses on 
this mailing lists consistently reflect an attitude of contempt for 
anyone and everyone who attempts to write software without intimate 
knowledge of the latest kernel and library developments.  I think this 
attitude is inappropriate for someone who is developing a utility 
library for general programming use.  If your library can't be properly 
used without intimate knowledge of kernel internals then your library is 
crap.

Now, as to the behavior of the pthread_mutex_unlock call... it is my 
perception that the purpose of the mutex is to facilitate the orderly 
SHARING of resources among asynchronous threads of execution. 
 Therefore, if the current holder of the mutex invokes a function call 
whose expressed purpose is to make a shared resource available to other 
waiting threads,  proper handling of that function should include 
checking to see if there are other threads waiting and then passing 
ownership to the next waiting thread.  Only if there are no waiters at 
or above the priority level of the thread releasing the mutex should the 
ownership be immediately reclaimable by a subsequent lock call by that 
same thread.  The scheduler should determine who runs next - not who 
receives mutex ownership.  The transfer of mutex ownership should be 
consistent regardless of scheduler activity.  You show me a man page, a 
POSIX spec, or any other piece of credible standards documentation that 
says pthread_mutex_unlock only yields ownership to the next waiter if it 
won't reduce scheduling efficiency and I will happily concede that my 
position is 'crap'.  Until then I will continue to maintain that POSIX 
mutex behavior is intended for portability's sake to behave 
independently of the 'scheduler du jour' and it is NPTL's preoccupation 
with scheduling efficiency over programmer usability that's 'crap'.