中断和锁的问题

adidiaos丶丶

中断的问题：
      大家都知道中断上下文里面是不能睡觉的，我在网上看到这样一个描述：        schedule()在切换进程时，保存当前的进程上下文(CPU寄存器的值、进程的状态以及堆栈中的内容),以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文(在调用中断处理程序后恢复)；但在中断处理程序里，CPU寄存器的值肯定已经变化了吧(最重要的程序计数器PC、堆栈SP等)，如果此时因为睡眠或阻塞操作调用了schedule()，则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。
    这句话里面有三处提到进程上下文。蓝色、红色所说的进程上下文应该是同一个吧，粉色字体的进程上下文是指中断handler的上下文？是这样吗？当系统运行时候，某个时间段内，可能会有好多进程会被中断吧，内核是怎么管理这些被中断的进程的上下文呢？我应该看哪部分代码和数据结构呢？


锁的问题：            
       在一定的环境下锁的效率大概是 rcu > atomic > Spinlock >mutex这个排序是我认为的，可能有不对的。
  内核里面给人的感觉是这些锁的使用为什么好像没有固定的章法，用起来都是很随意。
  按我的理解应该大部分情况下使用rcu和atomic啊，但是rcu使用的是不多的。   

jerryhua_cu

我理解的，可以把进程上下文看做集合A，而中断上下文看做集合B，B是A的子集。schedule设计的时候就是作为进程切换使用的，而如果在中断上下文中调用schedule（），schedule保存进程上下文即集合A，然而A-B的部分是进程的上下文，而集合B的部分已经被中断的上下文替换了，自然会产生问题。中断退出后不需要保存上下文，因为不会被调度，再触发的时候就是新的中断了，而即使有未完成的工作也放在下半部进行。

锁的使用有各自的适用场景，比如rcu适用于指针，且在写操作较多的时候，由于写之间的同步可能会有较大的性能损失；而spinlock，持有自旋锁的时间最好小于两次上下文切换时间；

vallrock

我的理解是，楼主是否把中断上下文当成普通进程上下文感觉需要进行管理呢？中断是不需要被调度的，因此可以理解为中断实际上并不需要被管理（进程上下文那样的管理）

对于锁的问题我也很好奇，希望有大牛来解答。

我爱你我的菜

设计上中断已经不能被调度了，看中断保存现场恢复现场那部分实现就是了啊，就是中断流程都要看。。

adidiaos丶丶

回复 4# 我爱你我的菜 对。在大伙的指导正在看这块。

nswcfd

锁的使用一点都不随意啊，而且一旦代码有scalablity需求的话，基本就是考虑无锁实现了。

回顾一下某个子系统的发展过程，可以看到比较明显的粗粒度锁->细粒度锁->无锁的演化过程，比如说网络中的路由表。

当然这么说比较笼统，建议参考一些多核编程的书籍或者文章。

mournjust

回复 1# adidiaos丶丶

(1)中断虽然保存和恢复了寄存器，但是它复用了当前进程的栈空间。从scheduler的角度来讲，中断不是一个完整的entity。睡眠就涉及到了进程的切换，如果一个在中断睡眠了。你如何再次将其**并切换。
虽然可以实现，但是我个人认为从实现复杂度和稳定性的角度来讲，得不偿失。

现在的kernel中已经引入了threaded irq.将irq的实体作为一个RT thread。中断处理函数中只管去wake up就可以了。

(2) 锁的使用其实极其讲究。比如RCU，一般用于read较多，但是update较少的情况。如果你随意用的话，反而效率极其低下。
由于中断中不能休眠，所以只能使用spinlock。所以需要严格的区分这些锁的特点，以及为什么要引入这些锁。