[lkml]   [2005]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Abstracted Priority Inheritance for RT
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-03 11:13    [W:0.023 / U:7.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site