"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.
按照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的实现源码,所以我对这个数据有点怀疑,这也是为什么我自己要做性能分析的原因。