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

上一节主要讨论了 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笔记
添加新评论

icon_redface.gificon_idea.gificon_cool.gif2016kuk.gificon_mrgreen.gif2016shuai.gif2016tp.gif2016db.gif2016ch.gificon_razz.gif2016zj.gificon_sad.gificon_cry.gif2016zhh.gificon_question.gif2016jk.gif2016bs.gificon_lol.gif2016qiao.gificon_surprised.gif2016fendou.gif2016ll.gif