Re: [PATCH] Abstracted Priority Inheritance for RT

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

 



On Thu, 2 Jun 2005, Daniel Walker wrote:

> On Thu, 2005-06-02 at 22:27 +0200, Esben Nielsen wrote:
> 
> > But right now the following ideas spring to my mind:
> > If it is to solve the problem of having a callback wrap every use
> > in macroes and use the TYPE_EQUAL() to expclicit call the right function.
> > Only if the explicit type is unknown in the macro use the callback. That
> > should optimize stuff a little bit.. Just a wild idea.
> 
> It's a little hard to do that. It's basically the situation you have
> below, there is no way to know what "waiter" is at compile time, so you
> can't really do the TYPE_EQUAL() trick on "get_next_waiter" .
> 
> I have "waiter->waiter_changed_prio()" which results in the same
> problem. There is no way to know what "type" waiter is at compile
> time .. 
> 
> 
> > If it is explicitly for PI you can do a thing like
> >  waiter->get_next_waiter();
> > to resolve the chain of waiters. Then you can have the PI algotithm work
> > iteratively without knowing the explicit kind of lock involved.
> 
> This is essentially what I have now, but it's also what I'm unhappy
> with. The only reason that I don't like this method is that it's a
> little slow .. I don't mind keeping it as long as no better way presents
> itself. 
> 
> Daniel
> 
C++ templates would have helped a lot...  But we only have the low
tech version: macroes.

Esben

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux