Re: Thread starvation with mutex

Ulrich Drepper wrote:
> 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.
> 
> 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.

That is a very good description, thank you.

> If you want explicit hand-off program an appropriate device yourself.

The problem here isn't a desire for explicit hand off.  We do not want
the second thread to run every time the mutex is released, therefore
hand off would be _wrong_.

No, the problem is _starvation_.  It would be good for the second
thread to run _eventually_, and it is not running at all.  This is not
something can be practically solved at the userspace level: as you
say, userspace has the option of starvation or explicit hand-off,
_both_ of which are wrong.

Practically, we depend on the unix scheduler to ensure that all
processes/threads make progress eventually, if it is logically
possible.  Not necessarily quickly, just eventually.  The general
priniciple of forward progress is assumed implicitly by a great deal
of code, for good reason.

-- Jamie