linux 内核信号量

Linux内核的信号量在概念和原理上和用户态的System V的IPC机制信号量是相同的，不过他绝不可能在内核之外使用，因此他和System V的IPC机制信号量毫不相干。
信号量在创建时需要设置一个初始值，表示同时能有几个任务能访问该信号量保护的共享资源，初始值为1就变成互斥锁（Mutex），即同时只能有一个任务能访问信号量保护的共享资源。
一个任务要想访问共享资源，首先必须得到信号量，获取信号量的操作将把信号量的值减1，若当前信号量的值为负数，表明无法获得信号量，该任务必须挂起在 该信号量的等待队列等待该信号量可用；若当前信号量的值为非负数，表示能获得信号量，因而能即时访问被该信号量保护的共享资源。
当任务访问完被信号量保护的共享资源后，必须释放信号量，释放信号量通过把信号量的值加1实现，如果信号量的值为非正数，表明有任务等待当前信号量，因此他也唤醒所有等待该信号量的任务。

信号量的API有：

DECLARE_MUTEX(name)
该宏声明一个信号量name并初始化他的值为1，即声明一个互斥锁。

DECLARE_MUTEX_LOCKED(name)
该宏声明一个互斥锁name，但把他的初始值设置为0，即锁在创建时就处在已锁状态。因此对于这种锁，一般是先释放后获得。

void sema_init (struct semaphore *sem, int val);
该函用于数初始化设置信号量的初值，他设置信号量sem的值为val。

void init_MUTEX (struct semaphore *sem);
该函数用于初始化一个互斥锁，即他把信号量sem的值设置为1。

void init_MUTEX_LOCKED (struct semaphore *sem);
该函数也用于初始化一个互斥锁，但他把信号量sem的值设置为0，即一开始就处在已锁状态。

void down(struct semaphore * sem);
该函数用于获得信号量sem，他会导致睡眠，因此不能在中断上下文（包括IRQ上下文和softirq上下文）使用该函数。该函数将把sem的值减1，如果信号量sem的值非负，就直接返回，否则调用者将被挂起，直到别的任务释放该信号量才能继续运行。

int down_interruptible(struct semaphore * sem);
该函数功能和down类似，不同之处为，down不会被信号（signal）打断，但down_interruptible能被信号打断，因此该函数有返回值来区分是正常返回还是被信号中断，如果返回0，表示获得信号量正常返回，如果被信号打断，返回-EINTR。

int down_trylock(struct semaphore * sem);
该函数试着获得信号量sem，如果能够即时获得，他就获得该信号量并返回0，否则，表示不能获得信号量sem，返回值为非0值。因此，他不会导致调用者睡眠，能在中断 上下文使用。

int down_killable(struct semaphore *sem);

int down_timeout(struct semaphore *sem, long jiffies);

int down_timeout_interruptible(struct semaphore *sem, long jiffies);

void up(struct semaphore * sem);
该函数释放信号量sem，即把sem的值加1，如果sem的值为非正数，表明有任务等待该信号量，因此唤醒这些等待者。

信号量在绝大部分情况下作为互斥锁使用，下面以console驱动系统为例说明信号量的使用。
在内核源码树的kernel/printk.c中，使用宏DECLARE_MUTEX声明了一个互斥锁console_sem，他用于保护console驱动列表console_drivers及同步对整个console驱动系统的访问。
其中定义了函数acquire_console_sem来获得互斥锁console_sem，定义了release_console_sem来释放互斥 锁console_sem，定义了函数try_acquire_console_sem来尽力得到互斥锁console_sem。这三个函数实际上是分别 对函数down，up和down_trylock的简单包装。
需要访问console_drivers驱动列表时就需要使用acquire_console_sem来保护console_drivers列表，当访问完该列表后，就调用release_console_sem释放信号量console_sem。
函数 console_unblank，console_device，console_stop，console_start，register_console 和unregister_console都需要访问console_drivers，因此他们都使用函数对acquire_console_sem和 release_console_sem来对console_drivers进行保护。

入浅出down_interruptible函数
int down_interruptible(struct semaphore *sem)
这个函数的功能就是获得信号量，如果得不到信号量就睡眠，此时没有信号打断，那么进入睡眠。但是在睡眠过程中可能被信号打断，打断之后返回-EINTR，主要用来进程间的互斥同步。

下面是该函数的注释：
/**
* down_interruptible - acquire the semaphore unless interrupted
* @sem: the semaphore to be acquired
*
* Attempts to acquire the semaphore. If no more tasks are allowed to
* acquire the semaphore, calling this function will put the task to sleep.
* If the sleep is interrupted by a signal, this function will return -EINTR.
* If the semaphore is successfully acquired, this function returns 0.
*/

一个进程在调用down_interruptible()之后，如果sem<0，那么就进入到可中断的睡眠状态并调度其它进程运行， 但是一旦该进程收到信号，那么就会从down_interruptible函数中返回。并标记错误号为:-EINTR。一个形象的比喻：传入的信号量为1好比天亮，如果当前信号量为0，进程睡眠，直到（信号量为1）天亮才醒，但是可能中途有个闹铃（信号）把你闹醒。又如：小强下午放学回家，回家了就要开始吃饭嘛，这时就会有两种情况：情况一：饭做好了，可以开始吃；情况二：当他到厨房去的时候发现妈妈还在做，妈妈就对他说：“你先去睡会，待会做好了叫你。”小强就答应去睡会，不过又说了一句：“睡的这段时间要是小红来找我玩，你可以叫醒我。”小强就是down_interruptible，想吃饭就是获取信号量，睡觉对应这里的休眠，而小红来找我玩就是中断休眠。

使用可被中断的信号量版本的意思是，万一出现了semaphore的死锁，还有机会用ctrl+c发出软中断，让等待这个内核驱动返回的用户态进程退出。而不是把整个系统都锁住了。在休眠时，能被中断信号终止，这个进程是可以接受中断信号的！比如你在命令行中输入# sleep 10000，按下ctrl + c，就给上面的进程发送了进程终止信号。信号发送给用户空间，然后通过系统调用，会把这个信号传给递给驱动。信号只能发送给用户空间，无权直接发送给内核的，那1G的内核空间，我们是无法直接去操作的。