lkml.org 
[lkml]   [2005]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] RT-patch update to remove the global pi_lock
From
Date
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@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-08-23 02:55    [W:0.112 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site