[RT] remove_waiter does not need to do chain walk?(2.6.25.4-rt)

From: hyl
Date: Tue Jun 24 2008 - 04:08:55 EST


Hi, everyone

lets us just focus on remove_waiter in rt_spin_lock_slowlock
(2.6.25.4-rt). refer to bellowing brief code .

i notice the comments above calling the remove_waiter , but i can't
figure out the sequence which meet
the comment.

I do figure out a event sequence to proof we must call
remove_waiter , but chain walk seems is not needed.

0). current process block on this lock (note:block on lock not the process)
1). adaptive_wait continue the loop without sleeping due to event
2): owner change( held no lock while adaptive wait)
2.) owner free the lock, another process be selected as pending
owner, then release lock
2.x) then current be boosted , and become pending owner's top
waiter, so pending owner be boosted too
3. in the new round loop: do_try_to_take_rt_mutex->try_to_steal_lock
lucky own the lock,
and at this time, waiter.task is not NULL

Question is: seems pending owner's block_on is null, remove_waiter
seems need no chain walk?

My scenario may not be the one of author, please don't hesitate to
offer a example to clarity this question,
i think discuss about this make it clear and easy to maintain.


rt_spin_lock_slowlock(struct rt_mutex *lock)
{
.........
for (;;) {
if (do_try_to_take_rt_mutex(lock, STEAL_LATERAL)) {
...
if (!waiter.task) {
. ..
}
....
if (adaptive_wait(&waiter, orig_owner)) {
......
}

.....
}
....
/*
* Extremely rare case, if we got woken up by a non-mutex wakeup,
* and we managed to steal the lock despite us not being the
* highest-prio waiter (due to SCHED_OTHER changing prio), then we
* can end up with a non-NULL waiter.task:
*/
if (unlikely(waiter.task))
remove_waiter(lock, &waiter, flags);
.....
}

Regards
hyl
--
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/