Question on mutex code

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Tue Mar 10 10:59:17 EDT 2015


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150310/a9317184/attachment.bin 


More information about the Kernelnewbies mailing list