Re: [RFC] RT-patch update to remove the global pi_lock

[Daniel Walker]

On Mon, 2005-08-22 at 20:26 -0400, Steven Rostedt wrote:

> 
> How would you add to a lock with just holding a lock for a task?  When
> you are grabbing a lock, you must first grab a raw lock associated to
> the lock being grabbed.  Although, I'm starting to look into this idea,
> and I'm going to first see if the current wait_lock could suffice.  I
> may also need to add an additional lock to the task to follow the lock
> -> task -> lock route.  The tasks order should be the same as the locks
> when the are bound (holding) a lock. Since the task won't be able to
> release it without holding the raw lock of the lock it is releasing.
> (boy this gets confusing to talk about, since you need to talk about
> locks and the locking method within the lock!)

You might need to explain that one more time . I'm sure it needs more
though, but the pi_lock just protects another cpu from enter
pi_setprio() . What we really want is to protect only the specific
structures modified inside pi_setprio() . Or that's my understanding .
Are you thinking of something else?

I think you would at least need to lock the wait_lock for each lock that
is looped over inside pi_setprio() . Because you access the wait_list
inside the loop .

There is also a pi_waiters list that is per task. You would need to make
a lock for that, I think . Or protect it somehow .

Daniel




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