用count=1的信号量实现的互斥方法还不是Linux下经典的用法，Linux内核针对count=1的信号量重新定义了一个新的数据结构，一般都称其为互斥锁或者互斥体。同时内核根据使用场景的不同，把用于信号量的DOWN和UP操作在struct mutex上作了优化与扩展，专门用于这种新的数据类型。
互斥锁的定义与初始化
互斥锁mutex的概念本来就来自semaphore，如果去除掉那些跟调试相关的成员，struct mutex和struct semaphore并没有本质的不同：
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_MUTEX_SPIN_ON_OWNER) struct task_struct *owner; #endif #ifdef CONFIG_MUTEX_SPIN_ON_OWNER struct optimistic_spin_queue osq; /* Spinner MCS lock */ #endif #ifdef CONFIG_DEBUG_MUTEXES void *magic; #endif #ifdef CONFIG_DEBUG_LOCK_ALLOC struct lockdep_map dep_map; #endif };
如同struct semaphore一样，对struct mutex的初始化不能直接通过操作其成员变量的方式进行，而应该利用内核提供的宏或者函数定义一个静态的struct mutex变量同时初始化的方法是利用内核的DEFINE_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变量，则可以使用mutex_init宏。去除掉那些与调试相关的操作之后，mutex_init宏可以展开成如下的函数定义形式：
# 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); #endif debug_mutex_init(lock, name, key); }
互斥锁的DOWN操作
互斥锁mutex上的DOWN操作在Linux内核中为mutex_lock函数，定义如下：
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); }
函数的设计思想体现在__mutex_fastpath_lock和__mutex_lock_slowpath两条主线上，__mutex_fastpath_lock用来快速判断当前可否获得互斥锁，如果成功获得锁，则函数直接返回，否则进入到__mutex_lock_slowpath函数中·这种设计是基于这样一个事实：想要获得某一互斥锁的代码绝大部分时候都可以成功获得。由此延伸开来在代码层面就是，mutex_lock函数进入__mutex_lock_slowpath的概率很低。
__mutex_fastpath_lock是一平台相关函数，下面以ARM处理器为例，分析其代码实现：
static inline void __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) { int __done, __res; __asm__ __volatile__ ( L1 "movli.l @%2, %0 \n" "add #-1, %0 \n" "movco.l %0, @%2 \n" "movt %1 \n" : "=&z" (__res), "=&r" (__done) : "r" (&(count)->counter) : "t"); if (unlikely(!__done || __res != 0)) fail_fn(count); }
函数在百处通过ldrex完成“__res=count->counter，L2处完成__res=__res-1，L3处试图用__res的当前值来更新count->counter.这里说“试图”是因为这个更新的操作未必会成功，主要是考虑到可能有别的进程也在操作count->counter，为不使这种可能的竞争引起对
作count->counter值更新的混乱，这里用了ARM指令中用于实现互斥访问的指令ldrex和strex（前面在spinlock的代码分析时己经提过)。ldrex和strex保证了对count->counter读取一更新一写回”操作序列的原子性。如果L3处的更新操作成功，那么_ex_flag将为0。
接下来在__res|=__ex_flag执行完之后，通过if语句判断__res是否为0，有两种情况会导致__res不为0：一是在调用这个函数前count->counter=0，表明互斥锁己经被别的进程获得，
这样L2处的__res=-1：二是在L3处的更新操作不成功，表明当前有另外一个进程也在对count->counter进行同样的操作·这两种情况都将导致__mutex_fastpath_lock不能直接返回，而是进入fail_fn也就是调用__mutex_lock_slowpath。
此处if语句中的unlikely是利用GCC编译优化扩展的一个宏，这里的意思是条件语句__res！=0为真的可能性很小，编译器借此可以调整一些编译后代码的顺序达到某种程度的优化。与之对应的是likely。
如果__mutex_fastpath_lock函数不能在第一时间获得互斥锁返回，那么将进入__mutex_lock_slowpath，正如其名字所预示的那样，代码将进入一段艰难坎坷的旅途。
在Linux源码中，__mutex_lock_slowpath函数与信号量DOWN操作中的函数非常相似，不过__mutex_lock_slowpath在把当前进程放入mutex的wait_list之前会试图多次询问mutex中的count是否为1，也就是说当前进程在进入wait_list之前会多次考察别的进程是否己经释放了这个互斥锁。这主要基于这样一个事实：拥有互斥锁的进程总是会在尽可能短的时间里释放·如果别的进程己经释放了该互斥锁·那么当前进程将可以获得该互斥锁而没有必要再去睡眠。
互斥锁的UP操作
互斥锁的操作为mutex_unlock，函数定义如下：
void __sched mutex_unlock(struct mutex *lock) { /* * The unlocking fastpath is the 0->1 transition from 'locked' * into 'unlocked' state: */ #ifndef CONFIG_DEBUG_MUTEXES /* * When debugging is enabled we must not clear the owner before time, * the slow path will always be taken, and that clears the owner field * after verifying that it was indeed current. */ mutex_clear_owner(lock); #endif __mutex_fastpath_unlock(&lock->count, __mutex_unlock_slowpath); }
和mutex_lock函数一样，mutex_unlock函数也有两条主线：__mutex_fastpath_unlock和__mutex_unlock_slowpath，分别用于对互斥锁的快速和慢速解锁操作。
static inline void __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *)) { int __done, __res; __asm__ __volatile__ ( "movli.l @%2, %0 \n\t" "add #1, %0 \n\t" "movco.l %0, @%2 \n\t" "movt %1 \n\t" : "=&z" (__res), "=&r" (__done) : "r" (&(count)->counter) : "t"); if (unlikely(!__done || __res <= 0)) fail_fn(count);
这里除了是将count->counter的值加1以外，代码和__mutex_fastpath_lock中的几乎完全一样。在最后的if语句中，导致代码count->counter不为0也有两种情况：一是在调用这个函数前count->counter不为0，表明在当前进程占有互斥锁期间有别的进程竞争该互斥锁：二是对count->counter的更新操作不成功，表明当前有另外一个进程也在对count->counter进行操作，这种情况主要是针对别的进程此时调用mutex1k函数导致的竞争，因为互斥的原因别的进程此时不可能调用mutex_lock。这种情况的处理是非常重要的，不只是关系到count->counter正确更新的问题，还涉及能否防止一个唤醒操作的丢失。
在没有别的进程竞争该互斥锁的情况下，__mutex_fastpath_unlock函数要完成的工作最简单，把count->counter的值加1然后返回·如果有别的进程在竞争该互斥锁，那么函数进入__mutex_unlock_slowpath这个函数主要用来唤醒在当前mutex的wait_list中休眠的进程，如同up函数一样。
