深层次探讨mutex与semaphore之间的区别(中)

关于Linux内核中的mutex机制，一篇很重要的文档来自内核源码中的Documentation/mutex- design.txt，由Ingo molnar同学起头，标题是"Generic Mutex Subsystem"，这篇文档开宗名义，直接将1楼中最后一个问题给端了出来(因此我估计这个问题此前已经有很多人骚扰过Ingo等同学了)：

"Why on earth do we need a new mutex subsystem, and what's wrong with semaphores?" 前面已经讲过，当struct semaphore中的成员变量为1，就可以用来实现mutex这种东西，而且内核也明确定义了DEFINE_SEMAPHORE宏将count初始化为 1，信号量上的DOWN与UP操作就更不用说了，在内核中也都有很好的实现，难道这种binary semaphore机制还不能满足我们的要求吗，干嘛还非得弄一个新的mutex机制出来呢？

下面是Ingo同学对此的解释，他说“firstly, there's nothing wrong with semaphores. But if the simpler mutex semantics are sufficient for your code, then there are a couple of advantages of mutexes”，就是说，信号量在Linux中的实现是没任何问题的(上来先安抚一下大家躁动的心情)，但是mutex的语义相对来说要较信号量要来得 简单，所以如果你的代码若只是想对某一共享资源进行互斥访问的话，那么使用这种简化了的mutex机制可以带来如下的一坨好处。这句话字面上的理解 是，mutex将binary semaphore的实现简化了(the simper mutex)，因此如果单纯从互斥的角度，用mutex会有很多好处。 其实后面我们会看到，在内核源码中，相对于semaphore的DOWN和UP实现，因为后期引入的特别针对binary semaphore的性能优化，也就是现在看到的mutex机制，其实现代码要更为复杂。

接下来Ingo列出的一大堆使用mutex的好处，在这个帖子中我们将一条一条地来看，再结合内核源码，看看事实是否的确象他说的那样：

- 'struct mutex' is smaller on most architectures: E.g. on x86, 'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes. A smaller structure size means less RAM footprint, and better CPU-cache utilization.

这条最好验证，尤其还是x86平台，找个简单的内核模块，打印一下sizeof就可以了。在我的x86-64 32位Linux系统(内核版本2.6.37)上， struct semaphore的大小是16字节，而struct mutex的大小则是20字节，另两台x86-64 64位Linux系统(内核版本3.x)上的结果则是，struct semaphore的大小是24字节，而struct mutex的大小则是32字节。这里不妨看一下struct mutex在内核中的定义：

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
};

可以看到stuct mutex的定义其实比semaphore要来得复杂，里面有一些条件编译选项在里面。因为我们实际使用当中很少会使用它的调试功能，但是SMP现在则很普遍，我上面测试用的Linux环境都是多处理器系统。所以，mutex的定义实际上可简化为：

struct mutex {
        /* 1: unlocked, 0: locked, negative: locked, possible waiters */
        atomic_t                count;
        spinlock_t                wait_lock;
        struct list_head        wait_list;
        struct task_struct        *owner;
};

对比一下前面struct semaphore的定义你会发现，struct mutex比semaphore多了一个owner指针，因此上面的结果也就不难理解了，指针在32位系统上是4字节，而64位系统则是8字节。我相信 Ingo同学肯定不会胡说八道，那么明显地，相对于Ingo当时写mutex-design.txt时的情形，Linux内核源码发生了变化，这个在 Linux的开发过程中实在是太正常不过的一件事了：文档总是远远落后于代码的更新--大家都忙着写code，而很少有人想着去更新文档。
所以接下来Ingo提到的tighter code的优势，估计对mutex而言也不复存在了... (他本人对mutex相对于semaphore在RAM footprint方面的优势不复存在的最新回复是："Mutex got larger due to the adaptive spin-mutex performance optimization"，因此我很自然地将这句话理解成，由于要实现所谓的“adaptive spin-mutex performance optimization"，那么就不惜牺牲了"less RAM footprint, and better CPU-cache utilization"，所以我们有理由期待接下来的spin-mutex performance optimization会给mutex带来性能上比较大的提升...)

下面我们来讨论一下mutex所做的性能优化，在将mutex的引入Linux内核这件事上，Ingo同学是带头大哥，喜欢围观Linux内核开发的同学对这厮肯定不会陌生，在我看来，这厮简直是牛逼得一塌糊涂，将kgdb引入内核也是这厮的杰作...
在mutex的性能提升方面，mutex-design.txt文档中有个具体的测试，采用了一个test-mutex的工具，因为google没找到这 个东西，所以我个人猜测是Ingo自己搞出来的东西，本来想趁这两天放假将最新版下的binary semaphore和mutex的性能测试一把的，结果这两天啥都没干成。我本来是想索要那个test-mutex程序的，但是Ingo只是建议采用 perf来做。我自己找了个sysbench,但是还没时间用,貌似这个是针对数据库的。之所以做这个测试，是我想知道采用mutex到底能比 binary semaphore能带来多大的性能提升。

按照Ingo的测试数据，"the mutex based kernel was 2.4 times faster than the semaphore based kernel, _and_ it also had 2.8 times less CPU utilization"，因为事先看过mutex的实现源码，所以我对这个数据有点怀疑，这也是为什么我自己要做性能分析的原因。

semaphore和mutex的代码实现中都有fast path和slow path两条路径，所谓的fast path，就是当前的代码直接获得信号量，而所谓的slow path，则是当前代码没能第一时间获得信号量。semaphore和mutex在fast path上性能上的变化应该微乎其微，这个在metex-design.txt文档中也有说明。两者之间最大的差别来自对slow path的处理，先看semaphore，semaphore的slow path的调用链是down_interruptible-->__down_interruptible --> __down_common,  __down_common的代码实现为：

static inline int __sched __down_common(struct semaphore *sem, long state,
                                                                long timeout)
{
        struct task_struct *task = current;
        struct semaphore_waiter waiter;

        list_add_tail(&waiter.list, &sem->wait_list);
        waiter.task = task;
        waiter.up = 0;

        for (;;) {
                if (signal_pending_state(state, task))
                        goto interrupted;
                if (timeout <= 0)
                        goto timed_out;
                __set_task_state(task, state);
                raw_spin_unlock_irq(&sem->lock);
                timeout = schedule_timeout(timeout);
                raw_spin_lock_irq(&sem->lock);
                if (waiter.up)
                        return 0;
        }

 timed_out:
        list_del(&waiter.list);
        return -ETIME;

 interrupted:
        list_del(&waiter.list);
        return -EINTR;
}

相对mutex对slow path的处理，semaphore要简单多了，它的主要流程是设置当前进程状态为TASK_INTERRUPTIBLE，然后睡眠到一个等待队列中。所 以semaphore如果第一时间没有获得信号量，那么它接下来就会sleep。但是mutex的slow path呢，所有关于性能优化的代码都集中在该条路径中，所有它看起来比semaphore复杂许多...