<Learn From Kernel> Mutex Subsystem

 

在我想办法弄懂supermirco 服务用的Super IO w83795的驱动的时候 ,我不幸又陷入了mutex_lock :

 

具体的设计文档见 document/mutex-design. 我这里只是摘录演义~

 

故事开始:

 

"为什么在这个地球上 ,我们需要一个新的mutex 子系统 ,

  原来的semaphore怎了么他不行了吗 "

 

   让我来帮大家怀恋一下他吧

struct semaphore {
	spinlock_t		lock;
	unsigned int		count;
	struct list_head	wait_list;
};

void down(struct semaphore *sem);//ldd上说 你是惹恼的用户的好方法
int down_interruptible(struct semaphore *sem);
int down_trylock(struct semaphore *sem);

void up(struct semaphore *sem); 

 其实,错不在semaphore . 而是我的心变了.

 

现在有一个简单的 mutex语义出现了,他完全满足我的代码需要, 而且semaphore 有下面的诱惑.

 

第一:

'struct mutex'  在大多数的平台上他更小 只有16字节 而你 'struct semaphore' 有20个字节

要知道更小的结构意味着 更少的 RAM空间 ,能更好的被CPU cache利用

 

第二:

紧凑的代码, 在x86上, .text的大小比较:

 

写道

text data bss dec hex filename
3280380 868188 396860 4545428 455b94 vmlinux-semaphore
3255329 865296 396732 4517357 44eded vmlinux-mutex

 

 

 

你看 25051字节的代码被节省了  小代码意味着更优越的指令高速缓冲存储器占用 ,这是linux 内核当前优化的主要目标

 

第三:

mutex 子系统 对于竞争带来的负载 表现的更轻盈更可扩展(想想长矛).  在一个8-way的 x86系统上,允许一个

基于mutex的内核测试 creat+unlink+close  在/tmp文件系统下 16个并行的任务:

 

写道

Semaphores: Mutexes:

$ ./test-mutex V 16 10 $ ./test-mutex V 16 10
8 CPUs, running 16 tasks. 8 CPUs, running 16 tasks.
checking VFS performance. checking VFS performance.
avg loops/sec: 34713 avg loops/sec: 84153
CPU utilization: 63% CPU utilization: 22%

 

 

结果显而易见 ~

 

第四：

 

没有快路径的开销(看下面) 只要2条汇编指令这和 semaphora是一样的

 

    c0377ccb <mutex_lock>:
    c0377ccb:       f0 ff 08                lock decl (%eax)
    c0377cce:       78 0e                   js     c0377cde <.text.lock.mutex>
    c0377cd0:       c3                      ret
 

 

 

 

不容忽视的好处：

 

　struct mutex 被很好的赋义　

 

*　一次只有一个任务可以拥有mutex

*   只有拥有者可以解锁

*  多次解锁是不允许的

*  递归加锁也是不可以的

*  一个mutex对象必须通过api初始化不能memset啥的

*  拥有mutex的任务不能exit

* 被锁控制的内存区域不能free

* mutex不能在软件中断或者硬件中断中

* 可以在tasklets软中断或者timers的context中

 

(ps 以上除了第３条当 mutexattr_init 为"PTHREAD_MUTEX_RECURSIVE_NP" 前几条大家其实和 pthread_mutex是一样一样的~)

 

　当编译内核的　CONFIG_DEBUG_MUTEXES 　打开后会变得更强大

   * - 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)

--------------------------------------------------------------------------------

当然他也有一些缺点

 

你不能用在中断上下文　也不能在不同的context中解锁　但是semaphore可以

 

 

 

下面来简单看一些函数

 

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

 

这里有一个　　might_sleep();
如果编译内核打开了　CONFIG_PREEMPT_VOLUNTARY　宏，那么在这里就如果需要就会面临　schedule();

 

__mutex_fastpath_lock(&lock->count, __mutex_lock_slowpath);

 

其实是把原子计数　conut 从1变成０　，如果初始值不是1 ,那么这里就去调用 __mutex_lock_slowpath 函数

 

这样就进入了慢加锁的　路径(原来是不是很快呢，有的体系结构上是用汇编写的)

 

static __used noinline void __sched//__used gcc版本适应 __sched 
__mutex_lock_slowpath(atomic_t *lock_count)
{
	struct mutex *lock = container_of(lock_count, struct mutex, count);

	__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE, 0, _RET_IP_);
}

 

 

首先container_of  获得对应原子数的　mutex，然后去调用不可中断的　__mutex_lock_common()

 

待续