Messages in this thread | | | Subject | Re: [PATCH] Abstracted Priority Inheritance for RT | From | Daniel Walker <> | Date | Thu, 02 Jun 2005 14:50:28 -0700 |
| |
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
- 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/
| |