Messages in this thread | | | Subject | Re: rt_mutex_timed_lock() vs hrtimer_wakeup() race ? | From | Thomas Gleixner <> | Date | Tue, 01 Aug 2006 14:52:01 +0200 |
| |
On Tue, 2006-08-01 at 08:07 -0400, Steven Rostedt wrote: > > We hold lock->wait_lock. The owner of this lock can be blocked itself, > > which makes it necessary to do the chain walk. The indicator is > > owner->pi_blocked_on. This field is only protected by owner->pi_lock. > > > > If we look at this field outside of owner->pi_lock, then we might miss a > > chain walk. > > > > Actually Thomas, not counting the debug case, his patch wont miss a > chain walk. That is because the boost is read _after_ the owner's prio > is adjusted. So the only thing the lock is doing for us is to prevent > us from walking the chain twice for the same lock grab. (btw. I'm > looking at 2.6.18-rc2, and not the -rt patch, just to make things > clear).
So what do we win, when we drop the lock before we check for boosting ? In the worst case we do a redundant chain walk.
tglx
- 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/
| |