lkml.org 
[lkml]   [2006]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: RT Mutex patch and tester [PREEMPT_RT]
    From
    On Wed, Jan 11, 2006 at 06:25:36PM +0100, Esben Nielsen wrote:
    > So how many locks do we have to worry about? Two.
    > One for locking the lock. One for locking various PI related data on the
    > task structure, as the pi_waiters list, blocked_on, pending_owner - and
    > also prio.
    > Therefore only lock->wait_lock and sometask->pi_lock will be locked at the
    > same time. And in that order. There is therefore no spinlock deadlocks.
    > And the code is simpler.

    Ok, got a question. How do deal with the false reporting and handling of
    a lock circularity window involving the handoff of task A's BKL to another
    task B ? Task A is blocked trying to get a mutex owned by task B, task A
    is block B since it owns BKL which task B is contending on. It's not a
    deadlock since it's a hand off situation.

    I didn't see any handling of this case in the code and I was wondering
    if the traversal logic you wrote avoids this case as an inherent property
    and I missed that stuff ?

    bill

    -
    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: 2006-01-15 05:30    [W:0.019 / U:60.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site