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

待续

<Learn From Kernel> Mutex Subsystem

猜你喜欢