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

\
 
 \ /
  Last update: 2005-06-03 00:02    [W:0.050 / U:0.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site