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

RE: Newbie question on mutexes



> From: Jamie Lokier [mailto:jamie shareable org]
> 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?

Gee...my apologies--first "that" refers to the "still wouldn't give..."
part of your comment; the second refers to the enforcing giving the
mutex to the highest guy.

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

You mean priorities or scheduling classes? I can see doing that if
the first wakee is RT (strict) or if it is _OTHER (non-strict), but if
the first wakee is RT, lower prio, I still want to do strict to
avoid the time window where you are open to priority inversion in 
an SMP system (when a _OTHER or lower prio RT could sneak in).

OTOH, you can only do that from inside the kernel, as it is the only
place where you can, atomically speaking, get the first wakee and
what kind of guy he is.

As another OTOH, not being strict also breaks a little bit the guarantee
of robustness that RTNPTL+fusyn offers, having a little window of time
where you can be left in the water.

> 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 more or less the basis of fulocks :)

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

But that breaks the determinism you want for RT applications. In RT
you want to force a guy to starve. If it is starving and I don't know 
why, then I have a bigger problem.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)




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