Something about Mutex

最近打开内核Mutex debug选项，出现一些Mutex Warning，重新审查和学习了一点东西，记录一下。

目前在学习SMP相关的东西，已经开始，坚持！

一.Mutex Slowpath & Fastpath

1. Can someone help me to understand what is the difference between

> >> > fastpath

> >> > lock and slowpath lock?

> >>

> >> The fastpath is taken when nobody else is holding the lock (so the

> >> caller acquires the mutex without blocking).

> >>

> >> The slowpath is taken when somebody else is holding the lock and the

> >> caller needs to block (i.e. sleep) until the mutex is released.

> >>

> > Thanks David.

> > Could you give a bit more idea on the "How this reduce the register

> pressure

> > on fast path"

> 

> The code for the slowpath is considerably more complex than the code

> for the fastpath. So the fastpath will need much fewer registers.

> Since the compiler needs to generate save/restore operations for many

> touched registers, by having the slow path in a separate function, the

> extra save/restores are only done if they're needed.

> 

> The fastpath does the minimal amount required, so fewer registers will

> be required and less saving/restoring needs to be done.

> 

二.Mutex Info:

1.Debug-mutex.c

check if the lock is created and unlocked by the owner.Only the owner can unlock the mutex.

Multiple unlocks are not permitted.That is to say that if kernel has the warning about the lock magic,the lock had been unlocked twice or more.

So you must check the use of unlock.

Mutexes may not be used in hardware or software interrupt contexts such as tasklets and timers.

 

2. mutex info:

 * Simple, straightforward mutexes with strict semantics:

 *

 * - only one task can hold the mutex at a time

 * - only the owner can unlock the mutex

 * - multiple unlocks are not permitted

 * - recursive locking is not permitted

 * - a mutex object must be initialized via the API

 * - a mutex object must not be initialized via memset or copying

 * - task may not exit with mutex held

 * - memory areas where held locks reside must not be freed

 * - held mutexes must not be reinitialized

 * - mutexes may not be used in hardware or software interrupt

 *   contexts such as tasklets and timers

 *

 * These semantics are fully enforced when DEBUG_MUTEXES is

 * enabled. Furthermore, besides enforcing the above rules, the mutex

 * debugging code also implements a number of additional features

 * that make lock debugging easier and faster:

 *

 * - uses symbolic names of mutexes, whenever they are printed in debug output

 * - point-of-acquire tracking, symbolic lookup of function names

 * - list of all locks held in the system, printout of them

 * - owner tracking

 * - detects self-recursing locks and prints out all relevant info

 * - detects multi-task circular deadlocks and prints out all affected

 *   locks and tasks (and only those tasks)

 */