more on light weight mutex

[joel at OARcorp.com (joel at OARcorp.com)]

On Wed, 4 Aug 1999, VALETTE Eric wrote:

> >>>>> "joel" == joel  <joel at OARcorp.com> writes:
> 
> joel> Agreed.  This would unfortunately be a side-effect of using the very
> joel> light-weight mutex proposed.
> 
> ... stuff removed
> 
> joel> I do like the idea of having a low level mutex as proposed.  We just have
> joel> to decide how feature rich the blocking side is.
> 
> Note that the priority inversion handling requires recording owner thread id
> anyway as it will be needed by blocking code to increase the thread priority
> when contention occurs...

You are right, all it takes is a simple addition to the path where the
mutex is acquired.

And blocking the waiting tasks in priority order and bumping the priority
of said owner when a higher priority task blocks.  This part can be
handled by the SuperCore mutex if we use that as the guts of the "not
available path".

Basically you could still start with a simple wrapper for the SuperCore
mutex and then add the cpu dependent exchange to speed up the lock/unlock
when there is no contention.  It would probably require disallowing
priority ceiling as an inheritance protocol to keep the fast path simpler.

--joel