From mboxrd@z Thu Jan 1 00:00:00 1970 From: hyl Subject: [RT] remove_waiter does not need to do chain walk?(2.6.25.4-rt) Date: Tue, 24 Jun 2008 16:07:58 +0800 Message-ID: <505766fa0806240107hacebf36q6c5b4d97278272b4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mingo@elte.hu To: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org Return-path: Received: from wf-out-1314.google.com ([209.85.200.168]:28046 "EHLO wf-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752861AbYFXIIL (ORCPT ); Tue, 24 Jun 2008 04:08:11 -0400 Received: by wf-out-1314.google.com with SMTP id 27so2372108wfd.4 for ; Tue, 24 Jun 2008 01:08:10 -0700 (PDT) Content-Disposition: inline Sender: linux-rt-users-owner@vger.kernel.org List-ID: 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