关于signal, kill, mutex, spinlock的一些总结

标签：linux   kill   signal   mutex   spinlock   

用户进程，在用户态可以被直接 kill 。
用户进程陷入内核，在内核态进入死循环：
1. 循环体中有 msleep_interruptible ，进程状态为S，即可中断的睡眠状态，kill 命令不能杀死进程。
2. 循环体中有 msleep ，进程状态为D，即不可中断的睡眠状态，kill 命令不能杀死进程。
3. 循环体中无 sleep ，进程状态为R，即可执行状态，kill 命令不能杀死进程。
以上三种情况，不能被kill是因为进程处于内核态，信号不会被处理，在进程退出内核态时，信号将会被处理。

内核线程默认不处理信号，也就是说不能被杀死。
如果需要内核线程处理信号，需要显示指定，加入如下代码：
allow_signal(SIGXXXX);
并且在线程中处理该信号。
如果内核现在指定接收 SIGKILL 信号，并且受到该信号后即退出，则该内核线程可被杀死。

spinlock:
lock时首先禁止了cpu抢占，即当前进程拿到spinlock后，是不允许别的进程把它所占用的cpu抢走的，所以spinlock可以用在中断处理函数中。
当然，拿到spinlock后，当前进程也不允许schedule出去的，例如不允许调用sleep函数。如果有将自己schedule出去的操作，将会报以下bug:
BUG: scheduling while atomic:
spinlock被占用之后，除非释放，否则一直处于被占用状态。就算占用spinlock的进程被kill掉了，spinlock仍然为被占用状态。

mutex:
持有mutex的过程中，可能会被schedule出去，所以中断处理函数中不允许使用mutex。
既然可能会被schedule出去，当然也允许自己schedule出去，因此在持有mutex过程中允许sleep发生。
mutex被占用之后，除非释放，否则一直处于被占用状态。就算占用mutex的进程被kill掉了，mutex仍然为被占用状态，这一点与spinlock相同。

用户进程陷入内核，在内核态取得 mutex ，在未释放的情况下退出，其他进程再尝试获取同一 mutex 时会卡住，状态为D，即不可中断的睡眠状态。
用户进程陷入内核，在内核态取得 spinlock ，在未释放的情况下就回到用户态，执行时 kernel 将会崩溃，并打印如下信息：
BUG: scheduling while atomic:
用户进程陷入内核，在内核态取得 spinlock ，返回用户态之前释放 spinlock 是允许的。
用户进程陷入内核，在内核态取得 spinlock ，在未释放的情况下返回用户态不被允许，并且处于内核态时，进程不会被杀死，所以不存在用户进程持有 spinlock 并且被杀死的情况。

内核线程获取 mutex ，在未释放的情况下退出，其他进程再尝试获取同一 mutex 时会卡住，状态为D，即不可中断的睡眠状态。
内核线程获取 spinlock ，在未释放的情况下退出，其他进程再尝试获取同一 spinlock 时会卡住，状态为R。
获取 mutex 时，如果获取不到会进入睡眠；获取 spinlock 时，如果获取不到不会睡眠，而是忙等待。

关于signal, kill, mutex, spinlock的一些总结

标签：linux   kill   signal   mutex   spinlock   

原文地址：http://blog.csdn.net/njuitjf/article/details/41011229