Messages in this thread | | | Subject | Re: [RFC] RT-patch update to remove the global pi_lock | From | Daniel Walker <> | Date | Mon, 22 Aug 2005 17:51:31 -0700 |
| |
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/
| |