zoukankan      html  css  js  c++  java
  • 内核中断,异常,抢占总结篇

    一、基本概念

    中断分为同步中断和异步中断。同步中断是由CPU控制单元产生的,“同步”是指只有在一条指令执行完毕后,CPU才会发出中断,而不是发生在代码指令执行期间,比如系统调用。而异步中断是由其他硬件设备依照CPU时钟信号产生的,即意味着中断能够在指令之间发生,例如键盘中断

    按照Intel的微处理器手册,同步中断和异步中断也分别称为异常(或者软件中断)和中断。中断大家都比较熟悉,是由硬件设备产生的。异常的产生源有两种:一种是由程序的错误产生的,内核通过发送一个Unix程序员都熟悉的信号来处理异常;第二种时内核必须处理的异常条件产生的,此时内核执行恢复异常需要的所有步骤,例如缺页,或对内核服务的一个请求(系统调用,通过一条int指令)。有一个知识点值得了解:内核态能够触发的唯一异常就是缺页异常,其他的都是用户态触发的。

    二、硬中断、软中断、异常之间的抢占关系

    硬中断可以被另一个优先级比自己高的硬中断“中断”,不能被同级(同一种硬中断)或低级的硬中断“中断”,更不能被软中断“中断”。

    软中断可以被硬中断“中断”,但是不会被另一个软中断“中断”。在一个CPU上,软中断总是串行执行。所以在单处理器上,对软中断的数据结构进行访问不需要加任何同步原语。

    关于这一点,我对《深入理解linux内核》第三版P223页中保护可延迟函数所访问的数据结构有疑问,书上说保护可延迟函数(软中断)所访问的数据结构应采取的措施:对于单处理器的情况,在单处理器上不存在竞争条件,这是因为可延迟函数(软中断)的执行总是在一个CPU上串行执行--也就是说,一个可延迟函数不会被另一个可延迟函数中断。因此,根本不需要同步原语。我认为:一个软中断虽然不会被另一个软中断“中断”,但是可能被硬中断“中断”,而硬中断最后还是要执行到软中断,因此还是会形成对资源的临界区访问。我觉得在保护软中断时,应该关闭本地软中断,比如用local_bh_disable

    还没写完这篇博客,就知道我在这个问题上错了。附上在Linux 内核开发中文邮件列表上某位仁兄提供的解答。

    开始处理软中断的情况主要是
    1、中断退出执行的irq_exit
    2、内核线程ksoftirqd
    3、local_bh_enable


    asmlinkage void do_softirq(void)
    {
           unsigned long flags;
           struct thread_info *curctx;
           union irq_ctx *irqctx;
           u32 *isp;

           if (in_interrupt())
                   return;
    ....
    }
    可以看到,in_interrupt 判断,当前若是从硬件中断退出后执行的irq_exit进入的do_softirq,则立即返回,可以避免你说的情况

    本文最后还将附上一篇软中断源码的分析,很详细地说明了这个问题。

    硬中断和软中断都可以抢占(或者称为中断)异常(最典型的是系统调用),但是异常不能抢占硬中断和软中断。

    硬中断和软中断(只要是中断上下文)执行的时候都不允许内核抢占,换句话说,中断上下文中永远不允许进程切换。(个人理解,由于中断处理程序都需要较快地完成,而且中断处理程序可以嵌套,因此中断处理程序必须不能阻塞,否则性能就非常不能保证了。)


    三、用户抢占和内核抢占

    抢占分两种情况:用户抢占和内核抢占,其中内核抢占在Linux2.5.4版本发布时被并入内核的,通SMP一样作为内核的一项标准可选配置。

    1、用户抢占:内核即将返回用户空间的时候,如果need resched标志被设置,会导致schedule()被调用,此时就会发生用户抢占。在内核返回用户空间的时候,它知道自己是安全的。所以,内核无论是在从中断处理程序还是在系统调用后返回,都会检查need resched标志。如果它被设置了,那么,内核会选择一个其他(更合适的)进程投入运行。在内核抢占还没有出现的时候,内核所有的抢占情况都是用户抢占。

    2、内核抢占:内核抢占是指,一个在内核态运行的进程,可能在执行内核函数期间被另一个进程取代。不是在内核的任何一个地方都可以发生内核抢占的。

    内核不能被抢占的情况如下:

    1)内核正进行中断处理。在Linux内核中进程不能抢占中断(中断只能被其他中断中止、抢占,进程不能中止、抢占中断),在中断例程中不允许进行进程调度。进程调度函数schedule()会对此作出判断,如果是在中断中调用,会打印出错信息。

    2)内核正在进行中断上下文的Bottom Half(中断的底半部)处理。硬件中断返回前会执行软中断,此时仍然处于中断上下文中。

    3)内核的代码段正持有spinlock自旋锁、writelock/readlock读写锁等锁,处干这些锁的保护状态中。内核中的这些锁是为了在SMP系统中短时间内保证不同CPU上运行的进程并发执行的正确性。当持有这些锁时,内核不应该被抢占。

    4)内核正在执行调度程序Scheduler。抢占的原因就是为了进行新的调度,没有理由将调度程序抢占掉再运行调度程序。

    5)内核正在对每个CPU“私有”的数据结构操作(Per-CPU date structures)。在SMP中,对于per-CPU数据结构未用spinlocks保护,因为这些数据结构隐含地被保护了(不同的CPU有不一样的per-CPU数据,其他CPU上运行的进程不会用到另一个CPU的per-CPU数据)。但是如果允许抢占,但一个进程被抢占后重新调度,有可能调度到其他的CPU上去,这时定义的Per-CPU变量就会有问题,这时应禁抢占。

    除了上述情况,在内核的任何地方都可能发生内核抢占,内核抢占发生的时机一般在:

    1)当从中断处理程序正在执行,且返回内核空间之前。

    2)当内核代码再一次具有可抢占性的时候,如解锁(spin_unlock_bh)及使能软中断(local_bh_enable)等。

    3)如果内核中的任务显式的调用schedule()。

    4)如果内核中的任务阻塞(这同样也会导致调用schedule())。

    内核抢占主要是为实时系统来设计的,但也不是在所有情况下都是最优的,因为抢占也需要调度和同步开销,在某些情况下甚至要关闭内核抢占。以下是一篇关于开启和关闭内核抢占性能测试的文章。http://www.ibm.com/developerworks/cn/linux/l-nptl/index.html


    四、怎么对内核临界区进行保护

    在进程内核数据结构的互斥同步访问时,我们最常用的办法是:信号量(睡眠等待),自旋锁(自旋等待),中断禁止和软中断禁止。往往需要几种方法配合使用才能达到我们想要的结果。

    1、保护异常(最典型的是系统调用)所访问的数据结构

    此时最常选用的是信号量,因为信号量原语允许进程睡眠到资源变为可用,对大部分系统调用而言,这是所期望的行为。信号量的工作方式在单处理器系统和多处理器系统上完全相同。只有在访问每CPU变量的情况下,必须显式地禁用内核抢占,其他情况下内核抢占不会出现问题。

    2、保护中断所访问的数据结构

    1)单处理器情况下:假如数据结构只被这一种中断访问,则完全可以不加同步原语,因为中断不能被同一种中断“中断”;假如数据结构被多个中断处理程序访问,则必须通过禁用本地中断来保护临界区。

    2)多处理器情况下:除了必须禁用本地中断,还必须使用自旋锁来避免来自其他CPU的干扰。可以使用如spin_lock_irq()来完成这两件事情。

    3、保护可延迟函数(软中断和tasklet)所访问的数据结构

    1)单处理器情况下:在单处理器系统上不存在竞争条件,因为可延迟函数的执行在一个CPU上是串行的,一个可延迟函数不会被另一个可延迟函数所中断。因此无需同步原语。

    2)多处理器情况下:需要自旋锁来加以保护。由于软中断和tasklet并发程度不同,加锁情况也不同。同一软中断可以在不同CPU上运行,因此无论一个或多个软中断,都必须用如spin_lock加以保护。同一tasklet不能在不同CPU上运行,因此无需加锁;不同tasklet可以在不同CPU上运行,因此也需要如spin_lock的锁加以保护。

    4、保护由异常和中断访问的数据结构

    单处理器情况下:

    1)对中断而言:中断不能被异常“中断”,无需考虑异常的干扰。第1条一样,如果此数据结构只被一种中断访问,则可不加同步原语;否则要禁用本地中断。

    2)对异常而言:异常的优先级低,如需访问共享数据结构,必须先禁用本地中断。

    多处理器情况下:

    1)对中断而言:除了单处理器考虑的情况外,还必须用自旋锁排除其他CPU的干扰。

    2)对异常而言:除了单处理器考虑的情况外,还必须用自旋锁排除其他CPU的干扰。

    5、保护由异常和可延迟函数访问的数据结构

    单处理器情况下:

    1)对可延迟函数而言:可延迟函数不能被异常“中断”,无需考虑异常的干扰。在每个CPU上可延迟函数串行执行,不存在竞争条件,因此不用同步原语。

    2)对异常而言:异常的优先级低,如需访问共享数据结构,必须先禁用本地软中断。

    多处理器情况下:

    1)对中断而言:除了单处理器考虑的情况外,还必须用自旋锁排除其他CPU的干扰。

    2)对异常而言:除了单处理器考虑的情况外,还必须用自旋锁排除其他CPU的干扰。

    6、保护由中断和可延迟函数访问的数据机构

    单处理器情况下:

    1)对中断而言:中断不能被可延迟函数“中断”,无需考虑可延迟函数的干扰。第1条一样,如果此数据结构只被一种中断访问,则可不加同步原语;否则要禁用本地中断。

    2)对可延迟函数而言:可延迟函数的优先级低,如需访问共享数据结构,必须先禁用本地中断。

    多处理器情况下:

    1)对中断而言:除了单处理器上考虑的外,还必须用自旋锁排除其他CPU的干扰。

    2)对可延迟函数而言:除了单处理器上考虑的外,还必须用自旋锁排除其他CPU的干扰。

    7、保护由异常、中断和可延迟函数访问的数据结构

    单处理器情况下:

    1)对中断而言:优先级最高,无需考虑其他两种的影响。第1条一样,如果此数据结构只被一种中断访问,则可不加同步原语;否则要禁用本地中断。

    2)对可延迟函数而言:可延迟函数的优先级低,如需访问共享数据结构,必须先禁用本地中断。

    3)对异常而言:可延迟函数的优先级低,如需访问共享数据结构,必须先禁用本地中断。禁用了本地中断,也就相当于禁用了本地软中断。

    多处理器情况下:

    1)对中断而言:除了单处理器上考虑的外,还必须用自旋锁排除其他CPU的干扰。

    2)对可延迟函数而言:除了单处理器上考虑的外,还必须用自旋锁排除其他CPU的干扰。

    3)对异常而言:除了单处理器上考虑的外,还必须用自旋锁排除其他CPU的干扰。


    五、软中断源码分析

    之所以说软中断的执行时是串行的,是因为在软中断执行时,对于从硬中断进来的即将要执行的新的软中断会采取屏蔽措施,不让他们立即运行,而是保存起来,延迟一会,等自身的软中断执行完毕后,再执行那些保存起来的软中断,从而达到串行的目的。

    本文来源于:http://blog.csdn.net/vividonly/article/details/6609053#

    代码在该地址上

  • 相关阅读:
    windows蓝屏错误小全
    大数据量下高并发同步的讲解(不看,保证你后悔)
    本地或者服务器同时启动2个或多个tomcat
    如何在同一系统里同时启动多个Tomcat
    Java配置----JDK开发环境搭建及环境变量配置
    Tomcat8内置jdk8运行环境发布web项目
    Tomcat 部署项目的三种方法
    Java Web(五) JSP详解(四大作用域九大内置对象等)
    Java 四大作用域总结
    JSP九大隐式对象
  • 原文地址:https://www.cnblogs.com/hehehaha/p/6332891.html
Copyright © 2011-2022 走看看