我要努力工作，加油！
文章目录

Linux学习第30节，内核中互斥锁的设计，及其C语言代码实现

		发表于: 2019-03-22 16:53:41 | 已被阅读: 94 | 分类于: Linux笔记

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

更多阅读