深入理解linux互斥锁(mutex)

锁机制，可以说是linux整个系统的精髓所在，linux内核都是围绕着同步在运转。在多进程和多线程编程中，锁起着极其重要的作用。我这里说的是互斥锁，其实是泛指linux中所有的锁机制。我在这里不讲如果创建锁，关于锁的创建，网上代码很多，我在这里就不多说了。我要谈一谈一个让所有刚刚接触锁机制的程序员都很困惑的问题：如何使用以及锁机制在程序中是如何运作的。

一、定义：

/linux/include/linux/mutex.h

struct mutex {
/* 1: unlocked, 0: locked, negative: locked, possible waiters */
atomic_t		count;
spinlock_t		wait_lock;
struct list_head	wait_list;
#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_SMP)
struct task_struct	*owner;
#endif
#ifdef CONFIG_DEBUG_MUTEXES
const char 		*name;
void			*magic;
#endif
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map	dep_map;
#endif
};

二、作用及访问规则：

互斥锁主要用于实现内核中的互斥访问功能。内核互斥锁是在原子 API 之上实现的，但这对于内核用户是不可见的。对它的访问必须遵循一些规则：同一时间只能有一个任务持有互斥锁，而且只有这个任务可以对互斥锁进行解锁。互斥锁不能进行递归锁定或解锁。一个互斥锁对象必须通过其API初始化，而不能使用memset或复制初始化。一个任务在持有互斥锁的时候是不能结束的。互斥锁所使用的内存区域是不能被释放的。使用中的互斥锁是不能被重新初始化的。并且互斥锁不能用于中断上下文。但是互斥锁比当前的内核信号量选项更快，并且更加紧凑，因此如果它们满足您的需求，那么它们将是您明智的选择。

三、各字段详解：

1、atomic_t count;指示互斥锁的状态：

1 没有上锁，可以获得

0 被锁定，不能获得

负数 被锁定，且可能在该锁上有等待进程

初始化为没有上锁。

2、spinlock_t wait_lock;

等待获取互斥锁中使用的自旋锁。在获取互斥锁的过程中，操作会在自旋锁的保护中进行。初始化为为锁定。

3、struct list_head wait_list;

等待互斥锁的进程队列。

四、操作：

1、定义并初始化：

DEFINE_MUTEX(ac_mutex);

#define __MUTEX_INITIALIZER(lockname) \
{ .count = ATOMIC_INIT(1) \
, .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)

直接定于互斥锁mutex并初始化为未锁定，己count为1，wait_lock为未上锁，等待队列wait_list为空。

2、获取互斥锁：

(1)具体参见linux/kernel/mutex.c

void __sched mutex_lock(struct mutex *lock)
{
might_sleep();
/*
* The locking fastpath is the 1->0 transition from
* 'unlocked' into 'locked' state.
*/
__mutex_fastpath_lock(&lock->count, __mutex_lock_slowpath);
mutex_set_owner(lock);
}

获取互斥锁。实际上是先给count做自减操作，然后使用本身的自旋锁进入临界区操作。首先取得count的值，在将count置为－1，判断如果原来count的置为1，也即互斥锁可以获得，则直接获取，跳出。否则进入循环反复测试互斥锁的状态。在循环中，也是先取得互斥锁原来的状态，在将其之为－1，判断如果可以获取(等于1)，则退出循环，否则设置当前进程的状态为不可中断状态，解锁自身的自旋锁，进入睡眠状态，待被在调度唤醒时，再获得自身的自旋锁，进入新一次的查询其自身状态(该互斥锁的状态)的循环。

(2)具体参见linux/kernel/mutex.c

int __sched mutex_lock_interruptible(struct mutex *lock)

和mutex_lock()一样，也是获取互斥锁。在获得了互斥锁或进入睡眠直到获得互斥锁之后会返回0。如果在等待获取锁的时候进入睡眠状态收到一个信号(被信号打断睡眠)，则返回_EINIR。

(3)具体参见linux/kernel/mutex.c

int __sched mutex_trylock(struct mutex *lock)

试图获取互斥锁，如果成功获取则返回1，否则返回0，不等待。

3、释放互斥锁：

具体参见linux/kernel/mutex.c

void __sched mutex_unlock(struct mutex *lock);

释放被当前进程获取的互斥锁。该函数不能用在中断上下文中，而且不允许去释放一个没有上锁的互斥锁。

五、使用形式：

DEFINE_MUTEX(ac_mutex);/*定义*/

mutex_lock(&mutex); /*获取互斥锁*/

... /*临界资源*/

mutex_unlock(&mutex); /*释放互斥锁*/

为什么要使用锁

这个就比较简单，linux里面，锁的种类很多，包括互斥锁，文件锁，读写锁······其实信号量说白了也是一种锁。使用锁的目的是达到同步的作用，使共享资源在同一时间内，只有能有一个进程或者线程对他进行操作。

linux是如何通过锁来实现对数据的保护和维护的

这个问题是我要将的重点。很多刚刚接触锁机制的程序员，都会犯这种错误。比如，此时有2个线程，分别是线程A，线程B。A和B共享了资源M。为了同步A和B，使得同一时刻，同意时刻，只有一个线程对M操作。于是，很自然的会在A中对M资源先lock，等到A对M操作完毕之后，然后做一个操作unlock。B中则因为A加了锁，B就直接操作M。这个时候，你会发现，B同样可以操作到M。这个是为什么呢？

我们利索当然的把检测锁的任务交给了操作系统，交给了内核。可以翻看APUE上对于所的讲解，其中一部分是这么写的：

This mutual-exclusion mechanism works only if we design our threads to follow the same data-access rules. The operating system doesn't serialize access to data for us. If we allow one thread to access a shared resource without first acquiring a lock, then inconsistencies
can occur even though the rest of our threads do acquire the lock before attempting to access the shared resource.

这里This mutual-exclusion mechanism指的就是锁机制。说的很清楚，只有程序员设计线程的时候，都遵循同一种数据访问规则，锁机制才会起作用。操作系统不会为我们序列化数据访问，也就是说，操作系统不会为我们拟定任何数据访问顺序，到底是A在先还是B在先，操作系统不会为我们规定。如果我们允许一个线程在没有多的锁(lock)之前，就对共享数据进行访问操作，那么，即使我们其他的线程都在访问之前试图去先锁住资源(获取锁)，同样会导致数据访问不一致，即多个线程同时在操作共享资源。

从上面文字可以看出，操作系统不会为我们去检查，此时是不是有线程已经把资源锁住了。为了使锁能够正常工作，为了保护共享资源，我们只有在设计线程的时候，所有线程都用同一种方法去访问共享数据，也就是访问数据之前，务必先获取锁，然后再操作，操作完之后要解锁(unlock)。操作系统提供锁机制，就是提供了一种所有程序员都必须遵循的规范。而不是说我们锁住资源，其他线程访问共享资源的时候，让操作系统去为我们检查数据是否有其他的线程在操作。