您的位置:首页 > 运维架构 > Linux

linux kernel同步机制的思考

2015-07-08 09:52 351 查看
  在学习内核同步机制的时候,书中介绍了同步方法:原子操作(atomic)、自旋锁(spinlock)、信号量(semaphore)、互斥锁(mutex)、完成变量(completion)、大内核(BLK)、顺序锁(seqlock)、禁止抢占(preempt)、顺序与屏障(mb).面对如此多的同步机制,希望自己可以弄清这些机制的使用场合。

  首先明白一些概念:

 ①进程可以被中断处理程序中断,但中断处理程序不可以被进程中断。
  因为在中断context中,唯一能打断当前中断handler的只有更高优先级的中断,它不会被进程打断。中断包括:中断处理程序(上半部)、下半部机制(softirq,tasklet)。
 ②中断中不能发生休眠,进程上下文可以休眠。
  因为如果在中断context中休眠,则没有办法唤醒它,因为所有的wake_up_xxx都是针对某个进程而言的,而在中断context中,没有进程的概念,没有一个task_struct(这点对于softirq和tasklet一样),因此真的休眠了,比如调用了会导致block的例程,内核几乎肯定会死.
  schedule()在切换进程时,保存当前的进程上下文(CPU寄存器的值、进程的状态以及堆栈中的内容),以便以后恢复此进程运行。中断发生后,内核会先保存当前被中断的进程上下文(在调用中断处理程序后恢复);但在中断处理程序里,CPU寄存器的值肯定已经变化了吧(最重要的程序计数器PC、堆栈SP等),如果此时因为睡眠或阻塞操作调用了schedule(),则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。
  中断运行在中断上下文,没有一个所谓的中断描述符来描述它,它不是操作系统调度的单位。一旦在中断上下文中睡眠,首先无法切换上下文(因为没有中断描述符,当前上下文的状态得不到保存),其次,没有人来唤醒它,因为它不是操作系统的调度单位。此外,中断的发生是非常非常频繁的,在一个中断睡眠期间,其它中断发生并睡眠了,那很容易就造成中断栈溢出导致系统崩溃。
  休眠是一种进程的特殊状态(即task->state=TASK_UNINTERRUPTIBLE|TASK_INTERRUPTIBLE)],休眠是针对进程,也就是拥有task_struct的独立个体,休眠就是为了更好地利用CPU。休眠发生和结束时都会发生处理器的调度,因此也是一种进程间的同步机制。

同步机制的结论:
①自旋锁适用于中断处理程序,而引发休眠的信号量(semaphore)、互斥锁(mutex)则不适合使用在中断处理程序中,他们往往使用在进程中。
②原子操作(atomic)是最简单的同步方法,即保证程序的顺序执行。
③互斥锁就是信号量为1的简化版,但在内核中常常使用互斥的特性,所以更常用。
④完成变量(completion)、大内核(BLK)、顺序锁(seqlock)、禁止抢占(preempt)、顺序与屏障(mb).适用场合较少,暂不描述。

这篇文章,我会在工作和学习中慢慢增添自己的理解,也希望博友批评指正!。





                                            
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: