Linux操作系统的嵌入式领域面临新挑战

技术挑战

中断延迟

实时系统（Real-Time System）是指能够在限定的时间（一般是很短的时间范围）内对系统中发生的某类事件（比如从某个外围设备传来的中断请求）进行处理的系统。如果系统对这些事件的响应出现了问题，比如未能在限定时间内对其做出相应处理，就会导致系统出现故障。绝大多数嵌入式系统都有很高的实时性需求，而桌面系统却不一定。在嵌入式系统测试中，衡量系统实时性的最主要参数有两个：一个是中断延迟时间的长短，另一个是线程上下文切换时间的长短。

中断延迟是指从产生中断请求到相应中断服务程序的第一条指令被执行之间的这段时间。由于中断具备有优先级而且可以嵌套产生，因此可以测知优先级最高的中断在执行时的延迟时间。测试表明，产生中断延迟的原因除了处理器响应时间外，更重要的是操作系统往往会大大增加中断被延迟的时间。在操作系统运行过程中，存在着一些关键的操作。这些操作在执行时，操作系统会禁止在其间插入任何中断。因此如果一个中断请求在操作系统禁止中断的这段时间里产生，那么对它的处理就会始终保持在挂起状态，直到操作系统重新允许中断插入。最终，中断延迟在最坏情况下的数值是和操作系统关键操作中的指令序列在中断请求产生后继续执行的时间紧密相关。

实时系统就是要确保系统中的关键事件能够在限定的时间段内被处理。操作系统开发商会提供给用户一个表示中断延迟的数值以体现产品的实时性能。这个数值是在实验室环境下测得的，它可能是平均值，典型值，或者是在最好情况下的系统中断延迟。但在实际应用过程中，最坏情况下的延迟中断才是用户最需要考虑的。那么怎么样才能得到这个数值呢？瑞典的一个研究小组对操作系统中禁止中断产生的代码区域进行分析，试图用这种方法对当前一款商业化的实时操作系统进行研究并得到系统中最坏情况下的中断延迟的大小。

这项研究使用了先进的程序流分析方法来确定操作系统中所有的关键操作（即那些“禁止插入中断”的代码）区域的位置和结构。研究人员还利用了周期精确的模型来测定选定代码区域的被执行次数。但是研究结果并不让人感到振奋。因为用于禁止和允许中断的指令所需的源操作数在执行时才能确定，所以研究人员不能用静态分析的方法得到关键操作的执行情况。还有一些其他的程序流问题，比如关键操作序列的嵌套出现等等，也阻碍了研究的进展。最终据研究人员估测，大概只有一半数目的“禁止插入中断”的关键操作区域能够被确定，而另一半大约有600个区域会对中断响应时间产生未知的影响。

研究人员评估了他们能够确定的那些关键操作区域的执行时间。这些区域的执行情况非常复杂，有很多已经不是以简单的顺序结构执行了，少数几个区域甚至包含了三个嵌套的循环，而且还有一些关键操作区域的循环次数是不定的。在研究人员提供的报告中，可以看到一个具有嵌套循环的关键操作区域的执行周期数的估测为26729。试想在一个主频为100MHz的微处理器上，仅仅是这样一个区域就要消耗大约250微秒的时间。相信没有任何一个实时操作系统的开发商会愿意公开这个量级上的中断延迟。

 如果您对本文有任何疑问或者建议，请到讨论区发表您的意见: >> 论坛入口 <<