Re: Newbie question on mutexes

Perez-Gonzalez, Inaky wrote:
> > We could change the kernel futex code specifically for real-time
> > tasks, so that the highest priority RT task is woken.  However, on SMP
> > or hyperthreaded systems that still wouldn't give the mutex to the
> > highest priority task in many realistic cases, so it's not worth
> > ...
> 
> That's not all that fair; with strict ownership transferal you are
> explicitly enforcing that.

I didn't understand that sentence.  Do both "that"s refer to the same thing?

> Granted it is slower, but you can also switch it on and off
> depending on the application needs (defaulting to the fastest
> method, for example).

Or even better for RT applications: you could do strict ownership
transferral when it is to a strictly higher priority RT scheduling
class, but keep scheduler heuristics in control when the highest
priority wakee is in the same scheduling class as the waker.

That gives the same throughput qualities as we have now, but also
satisfies the expectations of the RT crowd on SMP.

One clean and general way to implement general ownership transferral
may be a combined wake+wait kernel primitive: you tell the kernel to
wait on a futex until the word has a certain matching value (and
futex_wake is called), then the kernel substitutes a different value
and wakes you.  You specify both values.

That's effectively kernel support for a compare-exchange-spin loop.

It has the bonus that the kernel is able to decide whether and how to
do ownership transferal, so it could implement the RT support I
mentioned above.  Also it could stochastically prevent starvation,
without forcing slow convoys, by occasionally deciding to transfer
ownership for non-RT tasks based on a random number.

-- Jamie