lkml.org 
[lkml]   [2015]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Question on mutex code
On 03/10/15 16:59, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 10 Mar 2015 14:03:59 +0100, Yann Droneaud said:
>
>>> Consider the following sequence of events:
>>>
>>> 0. Suppose a mutex is locked by task A and has no waiters.
>>>
>>> 1. Task B calls mutex_trylock().
>>>
>>> 2. mutex_trylock() calls the architecture-specific
>>> __mutex_fastpath_trylock(), with __mutex_trylock_slowpath() as
>>> fail_fn.
>>>
>>> 3. According to the description of __mutex_fastpath_trylock() (for
>>> example in include/asm-generic/mutex-dec.h), "if the architecture
>>> has no effective trylock variant, it should call the fail_fn
>>> spinlock-based trylock variant unconditionally". So
>>> __mutex_fastpath_trylock() may now call __mutex_trylock_slowpath().
>>>
>>> 4. Task A releases the mutex.
>>>
>>> 5. Task B, in __mutex_trylock_slowpath, executes:
>>>
>>> /* No need to trylock if the mutex is locked. */
>>> if (mutex_is_locked(lock))
>>> return 0;
>>>
>>> Since the mutex is no longer locked, the function continues.
>>>
>>> 6. Task C, which runs on a different cpu than task B, locks the mutex
>>> again.
>>>
>>> 7. Task B, in __mutex_trylock_slowpath(), continues:
>>>
>>> spin_lock_mutex(&lock->wait_lock, flags);
>
> B will spin here until C releases the lock.
>
> When that spin exits, C no longer holds the lock. Re-do the analysis
> from this point.
>

Thank you for the review.

I don't think B waits for C here - C holds the mutex (lock), not the
internal spinlock (lock->wait_lock). I might be wrong though.


\
 
 \ /
  Last update: 2015-03-15 00:21    [W:0.767 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site