Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1562440
  • 博文数量: 77
  • 博客积分: 1205
  • 博客等级: 少尉
  • 技术积分: 4476
  • 用 户 组: 普通用户
  • 注册时间: 2010-04-22 21:48
文章分类
文章存档

2018年(1)

2017年(1)

2015年(1)

2014年(18)

2013年(12)

2012年(44)

分类: LINUX

2012-04-09 21:41:50

看过Linux内核的同学都知道,Linux内核中除了有semaphore之外,还有一个mutex lock。前者我们的操作系统教科书称之为信号量,后者不知道教科书有没有具体的名称,但是在Linux内核中,它的称谓是"互斥锁"或者“互斥体”(总 之,称谓不是问题)。为了提升一下本帖的理论密度,特从Wiki中摘录一段关于semaphore的描述:

In computer science, a semaphore is a variable or abstract data type that provides a simple but useful abstraction for controlling access by multiple processes to a common resource in a parallel programming environment.

A useful way to think of a semaphore is as a record of how many units of a particular resource are available, coupled with operations to safely (i.e., without race conditions) adjust that record as units are required or become free, and if necessary wait until a unit of the resource becomes available. Semaphores are a useful tool in the prevention of race conditions and deadlocks; however, their use is by no means a guarantee that a program is free from these problems. Semaphores which allow an arbitrary resource count are called counting semaphores, while semaphores which are restricted to the values 0 and 1 (or locked/unlocked, unavailable/available) are called binary semaphores (same functionality that mutexes have).
”。

其中关键信息主要是“a semaphore is a data type for controlling access by multiple processes to a common resource in a parallel programming environment... Semaphores which allow an arbitrary resource count are called counting semaphores, while semaphores which are restricted to the values 0 and 1 (or locked/unlocked, unavailable/available) are called binary semaphores (same functionality that mutexes have)”,也即信号量在并行处理环境下对多个processes访问某个公共资源进行保护,后面提到的binary semaphore,本质上应该就是mutex了,从same functionality that mutexes have这句话来看,mutex和binary semaphore功能应该相同。从以上的文字中显然可以看到,相对mutex而言信号量的适用范围更广(mutex只是信号量的用途之一),这个我们接 下来在后续的Linux源码中也可以看到这其中某些细微之处的区分。

*注:昨天写这个帖子时手头没有操作系统方面的书籍拿来参考,今天我翻了一下《现代操作系统》(陈向群等译,机械工业出版社  1999年11月第1 版), 关于这个话题,书里明确提到的只有"2.2.5 信号量",至于mutex,书中并没有作为一个独立的概念提出来,只是在讲信号量时提到了上面所说的binary semaphore,并且说“信号量mutex(应该是指binary semaphore)用于互斥...互斥是避免混乱所必需的操作...信号量的另一种用途是用于实现同步(synchronization)。信号量 full和empty用来保证一定的事件顺序发生或不发生。在本例中,它们保证缓冲区满的时候生产者停止运行,或者当缓冲区空的时候消费者停止运行。这种 用法与互斥是不同的” --- P30-31 *

OK,理论上的概念有了,那么就来看看实际当中Linux下的semaphone到底长的啥样。以下是semaphore在Linux源码中的定义,源码来自3.2.9:


  1. /* Please don't access any members of this structure directly */
  2. struct semaphore {
  3.         raw_spinlock_t lock;
  4.         unsigned int count;
  5.         struct list_head wait_list;
  6. };
如果count=1的话,那么semaphore就可以用来进行互斥操作了,早先内核源码中曾有一个专门的宏用来定义一个count=1的信号量DECLARE_MUTEX:

  1. #define DECLARE_MUTEX(name) \
  2.             struct semaphore name = __SEMAPHORE_INITIALIZER(name, 1)
因为我们知道在Linux内核源码中还有一个DEFINE_MUTEX宏,所以Marcin Slusarz同学认为DECLARE_MUTEX宏容易让人困惑,毕竟它其实只是定义了一个count=1的信号量,因此该同学早在08年就向内核社区 提交了一个PATCH,要求Rename DECLARE_MUTEX to DEFINE_SEMAPHORE(), 这个PATCH最终被社区所接受(应该是在2.6.35和2.6.39版本之间,2.6.39已经没有了DECLARE_MUTEX,取而代之的是 DEFINE_SEMAPHORE,但2.6.35还有,我当时在写《深入Linux设备驱动程序内核机制》时,最早引用的是2.6.35的版本,虽然在 写作的中晚期将内核版本切换到2.6.39并在定稿阶段曾试图将之前写的文档全部修正到39版,但是DECLARE_MUTEX的残留显然是条漏网之 鱼...)。因为只是rename,所以DEFINE_SEMAPHORE的定义和原来的DECLARE_MUTEX完全相同。


那么既然count=1的信号量可以用来完成mutex lock的功能,那么内核何必再多此一举弄出个mutex lock出来呢?


阅读(12207) | 评论(3) | 转发(9) |
给主人留下些什么吧!~~

2012-04-12 13:52:44

M兄写的东西有理有据,造福于我们这些后生啊,顶一个

MagicBoy20102012-04-11 17:54:18

asuka2001: 在《Linux内核的设计与实现》第3版中提到了:

The simplicity and efficiency of the mutex comes from the additional constraints it imposes on its users.....
其实mutex的优化通过最近我近距离的围观,其对性能的确有所提升,虽然我手边直到现在尚没有第一手数据,不过通过对内核一些改动,来得到系统中在mutex_lock和mutex_unlock之间代码执行的平均时间来看,它的优化是现实可行的。

asuka20012012-04-10 23:22:28

在《Linux内核的设计与实现》第3版中提到了:

The simplicity and efficiency of the mutex comes from the additional constraints it imposes on its users over and above what the semaphore requires. Unlike a semaphore, which implements the most basic of behavior in accordance with Dijkstra’s original de-sign, the mutex has a stricter, narrower use case:

1. Only one task can hold the mutex at a time.That is, the usage count on a mutex is always one.

2. Whoever locked a mutex m