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

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'.





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