Linux内核：进程管理——互斥锁

一、互斥锁(mutex)

1.1 什么是互斥锁

互斥锁实现了“互相排斥”(mutual exclusion)同步的简单形式，所以名为互斥锁。互斥锁禁止多个进程同时进入受保护的代码“临界区”（critical section）。因此，在任意时刻，只有一个进程被允许进入这样的代码保护区。

mutex的语义相对于信号量要简单轻便一些，在锁争用激烈的测试场景下，mutex比信号量执行速度更快，可扩展性更好，另外mutex数据结构的定义比信号量小。

1.2 互斥锁的特性

互斥锁是Linux内核中用于互斥操做的一种同步原语；
互斥锁是一种休眠锁，锁争用时可能存在进程的睡眠与唤醒，context的切换带来的代价较高，适用于加锁时间较长的场景；
互斥锁每次只容许一个进程进入临界区，有点相似于二值信号量；
互斥锁在锁争用时，在锁被持有时，选择自旋等待，而不当即进行休眠，能够极大的提升性能,这种机制（optimistic spinning）也应用到了读写信号量上；
互斥锁的缺点是互斥锁对象的结构较大，会占用更多的CPU缓存和内存空间；
与信号量相比，互斥锁的性能与扩展性都更好，所以，在内核中老是会优先考虑互斥锁；
互斥锁按为了提升性能，提供了三条路径处理：快速路径，中速路径，慢速路径；

1.3 互斥锁的使用

定义互斥锁：

struct mutex my_mutex;

初始化互斥锁：

mutex_init(&my_mutex);

或者使用宏定义，并初始化互斥锁：

DEFINE_MUTEX(my_mutex)

获取互斥锁：

void mutex_lock(struct mutex *lock);

该函数用于获得mutex，它会导致睡眠，因此不能在中断上下文中使用。

int mutex_lock_interruptible(struct mutex *lock);

该函数功能与mutex_lock类似，不同之处为mutex_lock进入睡眠状态的进程不能被信号打断，而mutex_lock_interruptible进入睡眠状态的进程能被信号打断，而使用此函数进入休眠后，进程状态被设置为TASK_INTERRUPTIBLE，该类型的睡眠是可以被信号打断的。

如果返回0，表示获得互斥锁；如果被信号打断，返回EINTR。

int mutex_trylock(struct mutex *lock);

mutex_trylock用于尝试获得mutex，获取不到mutex时不会引起进程睡眠。

释放互斥锁：

void mutex_unlock(struct mutex *lock);

1.4 mutex和信号量

mutex和信号量相比要高效的多：

mutex最先实现自旋等待机制；
mutex在睡眠之前尝试获取锁；
mutex实现MCS所来避免多个CPU争用锁而导致CPU高速缓存颠簸现象；

二、MCS锁机制

2.1 MCS锁

上文中提到过mutex在实现过程当中，采用了optimistic spinning自旋等待机制，这个机制的核心就是基于MCS锁机制来实现的；
MCS锁机制是由John Mellor Crummey和Michael Scott在论文中《algorithms for scalable synchronization on shared-memory multiprocessors》提出的，并以他俩的名字来命名；
MCS锁机制要解决的问题是：在多CPU系统中，每当一个spinlock的值出现变化时，所有试图获取这个spinlock的CPU都需要读取内存，刷新自己对应的cache line，而最终只有一个CPU可以获得锁，也只有它的刷新才是有意义的。锁的争抢越激烈（试图获取锁的CPU数目越多），无谓的开销也就越大；
MCS锁机制的核心思想：每一个CPU都分配一个自旋锁结构体，自旋锁的申请者（per-CPU）在local-CPU变量上自旋，这些结构体组建成一个链表，申请者自旋等待前驱节点释放该锁；
osq(optimistci spinning queue)是基于MCS算法的一个具体实现，并通过了迭代优化；

2.2 oqs流程分析

optimistic spinning，乐观自旋，到底有多乐观呢？当发现锁被持有时，optimistic spinning相信持有者很快就能把锁释放，因此它选择自旋等待，而不是睡眠等待，这样也就能减少进程切换带来的开销了。

看一下数据结构吧：

osq_lock如下：

osq加锁有几种情况：

加锁过程中使用了原子操作，来确保正确性；无人持有锁，那是最理想的状态，直接返回；
有人持有锁，将当前的Node加入到OSQ队列中，在没有高优先级任务抢占时，自旋等待前驱节点释放锁；
自旋等待过程中，如果遇到高优先级任务抢占，那么需要做的事情就是将之前加入到OSQ队列中的当前节点，从OSQ队列中移除，移除的过程又分为三个步骤，分别是处理prev前驱节点的next指针指向、当前节点Node的next指针指向、以及将prev节点与next后继节点连接；

加锁过程中使用了原子操作，来确保正确性；

osq_unlock如下：

解锁时也分为几种情况：

无人争用该锁，那直接可以释放锁；
获取当前节点指向的下一个节点，如果下一个节点不为NULL，则将下一个节点解锁；
当前节点的下一个节点为NULL，则调用osq_wait_next，来等待获取下一个节点，并在获取成功后对下一个节点进行解锁；

从解锁的情况可以看出，这个过程相当于锁的传递，从上一个节点传递给下一个节点；

在加锁和解锁的过程中，由于可能存在操作来更改osq队列，因此都调用了osq_wait_next来获取下一个确定的节点：

内核资料直通车：Linux内核源码技术学习路线+视频教程代码资料

学习直通车：Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈

三、互斥锁源码实现

3.1 mutex

mutext结构体在include/linux/mutex.h文件中定义：

/*
 * 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)
 */
struct mutex {
        atomic_long_t           owner;
        spinlock_t              wait_lock;
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
        struct optimistic_spin_queue osq; /* Spinner MCS lock */
#endif
        struct list_head        wait_list;
#ifdef CONFIG_DEBUG_MUTEXES
        void                    *magic;
#endif
#ifdef CONFIG_DEBUG_LOCK_ALLOC
        struct lockdep_map      dep_map;
#endif
};

可以看到上面的英文注释：

一次只能有一个进程能持有互斥锁；
只有锁的持有者能进行解锁操作；
禁止多次解锁操作；
禁止递归加锁操作；
mutext结构必须通过API进行初始化；
mutex结构禁止通过memset或者拷贝来进行初始化；
持有互斥锁的进程可能无法退出；
不能释放持有锁所在的内存区域；
已经被持有的muetxt锁禁止被再初始化；
mutext锁不能在硬件或软件中断上下文中使用，比如tasklet、定时器等；

然后我们再来介绍这个结构体中几个重要的成员：

owner：原子计数。用于指向锁持有者进程的task struct，0表示没有被进程持有锁；
wait_lock：自旋锁，用于wait_list链表的保护操作；
wait_list：是一个双向链表，使用该等待列表保存因获取不到互斥锁而进行睡眠的进程：；

从上面成员可以看到，mutext的源码实现应该使用到了原子操作、以及自旋锁。

当存在多个进程竞争互斥锁时，由于互斥锁是共享变量，因此对互斥锁的成员变量的修改都要是互斥操作。

3.2 mutext初始化

mutex锁的初始化有两种方式，一种是静态使用DEFINE_MUTEX宏：

#define __MUTEX_INITIALIZER(lockname) \
                { .owner = ATOMIC_LONG_INIT(0) \
                , .wait_lock = __SPIN_LOCK_UNLOCKED(lockname.wait_lock) \
                , .wait_list = LIST_HEAD_INIT(lockname.wait_list) \
                __DEBUG_MUTEX_INITIALIZER(lockname) \
                __DEP_MAP_MUTEX_INITIALIZER(lockname) }

#define DEFINE_MUTEX(mutexname) \
        struct mutex mutexname = __MUTEX_INITIALIZER(mutexname)

这里初始化了原子计数owner、自旋锁结构体wait_lock 、以及等待列表wait_list。

另一种是在内核代码中动态使用mutex_init函数,定义在kernel/locking/mutex.c文件中：：

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

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);
    mutex_clear_owner(lock);
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
    osq_lock_init(&lock->osq);      //初始化MCS锁
#endif

    debug_mutex_init(lock, name, key);
}

3.2 mutex_lock

mutext_lock加锁流程如下图：

mutex_lock定义在kernel/locking/mutex.c文件中：

/**
 * mutex_lock - acquire the mutex
 * @lock: the mutex to be acquired
 *
 * Lock the mutex exclusively for this task. If the mutex is not
 * available right now, it will sleep until it can get it.
 *
 * The mutex must later on be released by the same task that
 * acquired it. Recursive locking is not allowed. The task
 * may not exit without first unlocking the mutex. Also, kernel
 * memory where the mutex resides must not be freed with
 * the mutex still locked. The mutex must first be initialized
 * (or statically defined) before it can be locked. memset()-ing
 * the mutex to 0 is not allowed.
 *
 * (The CONFIG_DEBUG_MUTEXES .config option turns on debugging
 * checks that will enforce the restrictions and will also do
 * deadlock debugging)
 *
 * This function is similar to (but not equivalent to) down().
 */
void __sched mutex_lock(struct mutex *lock)
{
        might_sleep();

        if (!__mutex_trylock_fast(lock))
                __mutex_lock_slowpath(lock);
}

mutex_lock为了提高性能，分为三种路径处理，优先使用快速和中速路径来处理，如果条件不满足则会跳转到慢速路径来处理，慢速路径中会进行睡眠和调度，因此开销也是最大的。

3.3 fast-path

快速路径是在__mutex_trylock_fast中实现：

/*
 * Lockdep annotations are contained to the slow paths for simplicity.
 * There is nothing that would stop spreading the lockdep annotations outwards
 * except more code.
 */

/*
 * Optimistic trylock that only works in the uncontended case. Make sure to
 * follow with a __mutex_trylock() before failing.
 */
static __always_inline bool __mutex_trylock_fast(struct mutex *lock)
{
        unsigned long curr = (unsigned long)current;
        unsigned long zero = 0UL;

        if (atomic_long_try_cmpxchg_acquire(&lock->owner, &zero, curr))
                return true;

        return false;
}

直接调用原子操作函数atomic_long_try_cmpxchg_acquire来进行判断：

如果lock->owner等于0，则将curr赋值给lock->owner，标识curr进程持有锁，并直接返回：
如果lock->owner不等于0，表明锁被持有，需要进入下一个路径来处理了；

3.4 mid-path

中速路径和慢速路径都在__mutex_lock_common中实现：

static noinline void __sched
__mutex_lock_slowpath(struct mutex *lock)
{
        __mutex_lock(lock, TASK_UNINTERRUPTIBLE, 0, NULL, _RET_IP_);
}
static int __sched
__mutex_lock(struct mutex *lock, long state, unsigned int subclass,
             struct lockdep_map *nest_lock, unsigned long ip)
{
        return __mutex_lock_common(lock, state, subclass, nest_lock, ip, NULL, false);
}

可以看到__mutex_lock_slowpath的最终实现在__mutex_lock_common函数中：

View Code

这个代码实在太多了，我懒得看了，直接看其它博主分析的流程图吧：

当发现mutex锁的持有者正在运行（另一个CPU）时，可以不进行睡眠调度，而可以选择自选等待，当锁持有者正在运行时，它很有可能很快会释放锁，这个就是乐观自旋的原因；

自旋等待的条件是持有锁者正在临界区运行，自旋等待才有价值；

__mutex_trylock_or_owner函数用于尝试获取锁，如果获取失败则返回锁的持有者。互斥锁的结构体中owner字段，分为两个部分：

1）锁持有者进程的task_struct（由于L1_CACHE_BYTES对齐，低位比特没有使用）；

2）MUTEX_FLAGS部分，也就是对应低三位，如下：

MUTEX_FLAG_WAITERS：比特0，标识存在非空等待者链表，在解锁的时候需要执行唤醒操作；
MUTEX_FLAG_HANDOFF：比特1，表明解锁的时候需要将锁传递给顶部的等待者；
MUTEX_FLAG_PICKUP：比特2，表明锁的交接准备已经做完了，可以等待被取走了；

mutex_optimistic_spin用于执行乐观自旋，理想的情况下锁持有者执行完释放，当前进程就能很快的获取到锁。实际需要考虑，如果锁的持有者如果在临界区被调度出去了，task_struct->on_cpu == 0，那么需要结束自旋等待了，否则岂不是傻傻等待了。

mutex_can_spin_on_owner：进入自旋前检查一下，如果当前进程需要调度，或者锁的持有者已经被调度出去了，那么直接就返回了，不需要做接下来的osq_lock/oqs_unlock工作了，节省一些额外的overhead；
osq_lock用于确保只有一个等待者参与进来自旋，防止大量的等待者蜂拥而至来获取互斥锁；
for(;;)自旋过程中调用__mutex_trylock_or_owner来尝试获取锁，获取到后皆大欢喜，直接返回即可；
mutex_spin_on_owner，判断不满足自旋等待的条件，那么返回，让我们进入慢速路径吧，毕竟不能强求；

3.5 slow-path

慢速路径的主要代码流程如下：

从for(;;)部分的流程可以看到，当没有获取到锁时，会调用schedule_preempt_disabled将本身的任务进行切换出去，睡眠等待，这也是它慢的原因了；

3.6 mutex_unlock

mutex_unlock释放锁流程如下图：

mutex_unlock定义在kernel/locking/mutex.c文件中：

/**
 * mutex_unlock - release the mutex
 * @lock: the mutex to be released
 *
 * Unlock a mutex that has been locked by this task previously.
 *
 * This function must not be used in interrupt context. Unlocking
 * of a not locked mutex is not allowed.
 *
 * This function is similar to (but not equivalent to) up().
 */
void __sched mutex_unlock(struct mutex *lock)
{
#ifndef CONFIG_DEBUG_LOCK_ALLOC
        if (__mutex_unlock_fast(lock))
                return;
#endif
        __mutex_unlock_slowpath(lock, _RET_IP_);
}

释放锁的流程相对来说比较简单，也分为快速路径与慢速路径；

快速路径是在__mutex_unlock_fast中实现：

static __always_inline bool __mutex_unlock_fast(struct mutex *lock)
{
        unsigned long curr = (unsigned long)current;

        if (atomic_long_cmpxchg_release(&lock->owner, curr, 0UL) == curr)
                return true;

        return false;
}

直接调用原子操作函数atomic_long_cmpxchg_release来进行判断：

如果lock->owner等于curr，也是锁的持有者为当前进程，则将lock->owner设置为0，并返回true；
如果lock->owner不等于curr，表明锁的持有者不是当前进程，返回false；

慢速路径释放锁，针对三种不同的MUTEX_FLAG来进行判断处理，并最终唤醒等待在该锁上的任务；

void __sched __mutex_unlock_slowpath(struct mutex *lock, ...)
{
    // 释放mutex，同时获取记录状态的低3个bits
    unsigned long old = atomic_long_cmpxchg_release(&lock->owner, 
                        owner, __owner_flags(owner));
    ...
    spin_lock(&lock->wait_lock);
    if (!list_empty(&lock->wait_list)) {
        // 获取等待队列中的第一个线程
        struct mutex_waiter *waiter = list_first_entry
                                      (&lock->wait_list, struct mutex_waiter, list);
                   
        // 将该线程加入wake_q     
        struct task_struct *next = waiter->task;
        wake_q_add(&wake_q, next);
    }

    spin_unlock(&lock->wait_lock);

    // 唤醒该线程
    wake_up_q(&wake_q);
}

原文作者：精通Linux内核

原文地址：Linux内核：进程管理——互斥锁 - 知乎（版权归原文作者所有，侵权留言联系删除）