Messages in this thread | | | Date | Fri, 3 Jun 2005 11:08:57 +0200 (METDST) | From | Esben Nielsen <> | Subject | Re: [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.
Esben
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |