上一节主要讨论了 Linux 内核中的信号量，知道了持有信号量的线程可以睡眠，因此如果有一段临界区需要较长时间的保护，与自旋锁相比，选择信号量无疑是更合适的。多数用户使用信号量只使用计数 1，这时的信号量其实就是一个互斥的排它锁——好比允许睡眠的自旋锁。

事实上，相对于自旋锁，信号量在C语言程序开发中更加通用，并没有多少使用限制。因此信号量特别适合处理那些较复杂的互斥访问，比如 Linux 内核空间与用户空间的交互行为等。

Linux 内核中的互斥锁（mutex）

不过，简单的互斥访问再使用信号量就不方便了，因此 Linux 内核开发大神们又引入了互斥锁（mutex）。严格来说，互斥锁是一类锁，任何可以睡眠的强制互斥访问机制都可以称为mutex。但是通常情况下，互斥锁是指 Linux 内核中特定实现的一种互斥睡眠锁。

互斥锁在 Linux 内核中使用的数据结构为 struct mutex，相关的C语言代码如下，请看：

- 48 struct mutex { 
| 49 /* 1: unlocked, 0: locked, negative: locked, possible waiters */
| 50 atomic_t count;
| 51 spinlock_t wait_lock;
| 52 struct list_head wait_list; 
| 53 #ifdef CONFIG_DEBUG_MUTEXES
| 54 struct thread_info *owner; 
| 55 const char *name;
| 56 void *magic;
| 57 #endif 
| 58 #ifdef CONFIG_DEBUG_LOCK_ALLOC
| 59 struct lockdep_map dep_map; 
| 60 #endif
| 61 };

显然，结构体 mutex 的核心成员与信号量数据结构的核心成员是非常相似的，事实上，互斥锁的行为也和计数为 1 的信号量类似，只不过互斥锁的接口更简单，实现也更高效。

信号量数据结构上一节已经介绍的比较清楚，这里就不赘述了。

互斥锁的设计和C语言代码实现

静态定义互斥锁可使用 DEFINE_MUTEX 宏，它的 C语言代码如下，请看：

#define __MUTEX_INITIALIZER(lockname) \
- 97 { .count = ATOMIC_INIT(1) \
| 98 , .wait_lock = __SPIN_LOCK_UNLOCKED(lockname.wait_lock) \
| 99 , .wait_list = LIST_HEAD_INIT(lockname.wait_list) \
| 100 __DEBUG_MUTEX_INITIALIZER(lockname) \
| 101 __DEP_MAP_MUTEX_INITIALIZER(lockname) }
 102 
 103 #define DEFINE_MUTEX(mutexname) \
 104 struct mutex mutexname = __MUTEX_INITIALIZER(mutexname)

如果希望动态初始化互斥锁，可以调用 mutex_init() 方法，它的C语言代码如下，请看：

do { \
 static struct lock_class_key __key; \
 \
 __mutex_init((mutex), #mutex, &__key); \
} while (0)

显然，核心功能由 __mutex_init() 函数实现，继续跟踪，得到相关C语言代码如下，请看：

 void __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key)
{
 atomic_set(&lock->count, 1);
 spin_lock_init(&lock->wait_lock);
 INIT_LIST_HEAD(&lock->wait_list);
 debug_mutex_init(lock, name, key);
}

__mutex_init() 函数的C语言比较简单，无非就是初始化了原子变量 count，以及自旋锁和等待队列。

其实从这里可以看出，互斥锁和信号量一样，也是要使用自旋锁保护临界区的。

创建好一个互斥锁后，可以如下使用，请看C语言代码：

mutex_lock(&mutex);
/** 临界区 */
mutex_unlock(&mutex);

互斥锁其实很像简化版的信号量，从上面的C语言代码也可以看出，互斥锁的接口相当简洁，某一线程调用 mutex_lock() 对临界区加锁后，在其调用 mutex_unlock() 释放互斥锁之前，其他线程是无法进入临界区的。mutex_lock() 的C语言代码如下，请看：

void inline __sched mutex_lock(struct mutex *lock)
{
 might_sleep();
 __mutex_fastpath_lock(&lock->count, __mutex_lock_slowpath);
 }

从代码也可以看出持有互斥锁的线程是允许睡眠的，mutex_lock() 函数的核心功能由 __mutex_fastpath_lock() 实现， __mutex_fastpath_lock() 是一个宏，它在 x86 平台下由C语言和内嵌汇编实现，请看：

__mutex_fastpath_lock() 宏负责将 count 由 1 减小为 0，也即将锁从“unlock”状态改为“lock”状态，并调用 fail_fn 指向的函数，也即__mutex_lock_slowpath()函数，相关的C语言代码如下，请看：

 static noinline void __sched
 __mutex_lock_slowpath(atomic_t *lock_count)
 {
 struct mutex *lock = container_of(lock_count, struct mutex, count);
 __mutex_lock_common(lock, TASK_UNINTERRUPTIBLE, 0, _RET_IP_);
}

container_of 宏我们在之前的文章中介绍过，这里就不再赘述了。继续跟踪__mutex_lock_common()函数，发现它是一个庞大的函数，主要功能的相关C语言代码如下，请看：

 static inline int __sched
 __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 unsigned long ip)
{
...
 list_add_tail(&waiter.list, &lock->wait_list);
 waiter.task = task;
...
 for (;;) {
 old_val = atomic_xchg(&lock->count, -1);
 if (old_val == 1)
 break;
 ...
 spin_unlock_mutex(&lock->wait_lock, flags);
 schedule();
 spin_lock_mutex(&lock->wait_lock, flags);
 }
 ...
}	

从上面的C语言代码可以看出，__mutex_lock_common()函数首先会把任务加入等待队列，然后进入死循环，在循环中请求锁，如果请求到锁，就跳出死循环，否则就把任务状态设置为 state，并进入睡眠，等待下一次循环。

mutex_unlock() 函数的C语言代码分析与 mutex_lock() 函数的C语言代码分析是类似的，就不赘述了。

小结

互斥锁 mutex 的简洁性和高效性来自于比使用信号量更多的受限性，它也无需维护引用计数，显然互斥锁是一个比信号量更轻量级的锁，使用它时应注意：

• 任一时刻只能有一个任务持有 mutex，原因上面已经讨论了；
• 不能在上下文 A 中锁定 mutex，而在上下文 B 中解锁 mutex，即“解锁还需加锁人”；
• 不允许递归使用 mutex，否则可能会造成死锁；
• 因为持有 mutex 的线程允许睡眠，所以中断处理程序以及下半部中是不能使用 mutex 的。

迎在评论区一起讨论，质疑。文章都是手打原创（本文部分参考linux内核原理和设计），每天最浅显的介绍C语言、linux等嵌入式开发，喜欢我的文章就关注一波吧，可以看到最新更新和之前的文章哦。