Re: Thread starvation with mutex

Gary S. Robertson wrote on 2/10/2004, 7:04 PM:
> 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'.

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_lock.html

  The pthread_mutex_unlock() function shall release the mutex
  object referenced by mutex. The manner in which a mutex is
  released is dependent upon the mutex's type attribute. If
  there are threads blocked on the mutex object referenced by
  mutex when pthread_mutex_unlock() is called, resulting in
  the mutex becoming available, the scheduling policy shall
  determine which thread shall acquire the mutex.

It all depends on the scheduling policy.  One can define the
SCHED_OTHER policy to optimize performance and let the awakened
waiting thread(s) compete for the mutex with running threads.

The following book section describes the Solaris pthread
library's implementation of pthread_mutex_unlock:

Jim Mauro and Richard McDougall, Solaris Internals: Core
Kernel Architecture, Sec. 3.5.2.3, "Why the Mutex Changes
in Solaris 7," pp. 80-81, Prentice Hall, 2001.

It shows that the Solaris thread implementors seem to have
made the same design decision as Mr. Ulrich.

Even LinuxThreads added a PTHREAD_MUTEX_ADAPTIVE_NP mutex
type with this wakeup behavior in glibc 2.2.  This mutex
type could not be made the default because LinuxThreads
had to be backward compatible.

Wan-Teh