上一节主要讨论了 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 的。