为什么说在中断服务程序中不能有i/o操作，不能有获取信号量的操作呢？

[armlearnerie]

为什么说在中断服务程序中不能有i/o操作，不能有获取信号量的操作呢？
事实上我做过实验，在中断服务程序中狂打印的话，系统会立即死机或复位。
这个问题一直没怎么想明白，请高手解释一下。谢谢了！

[yangb2014#]

跟堆栈有关，中断中做尽量少的事情。。。

[ahong008]

为了保证实时性以及下一个中断，中断执行的操作越少越好

[topcool99]

i/o操作和获取信号量都属于可能被阻塞（pend）的操作。
这在中断程序中是明确禁止使用到。
对于中断函数中调用可能阻塞的函数，轻则引起系统任务调度打乱，失去实时性，重则系统崩溃或复位。
vxworks属于硬实时操作系统，不能在规定的时间内完成操作即会死机或复位。

[sterrys]

中断的优先级很高，如果在那里等信号量的话，别的 Task 可能会被阻塞没有机会释放信号量造成死锁。

[Hshj]

引用斑竹ningxin的话：
在某些操作系统中，是可以在一些特定的低优先级ISR里面进行pend操作的。这要求操作系统的中断，有线程上下文（线程（任务）上下文是任务调度的基础，注意任务上下文不等同于中断上下文）。称为“中断线程化”。
Vxworks的任务调度是依赖于中断的，同时，为了实时性考虑，Vxworks不支持中断线程化，ISR是没有任务（线程）上下文的。如果支持中断线程化，那么将导致中断响应时间不确定，实时性难以得到保证。
如果在vxworks里面，使用了可能blocking的代码，那么有2种情况：
一种是关中断运行。那么，在blocking的地方，将永远等待。因为这时候任务调度依赖的时钟中断都不能响应，也就是说任务调度器都不能运行了，系统就死在中断里了。
另一种是开中断进行。那么，在blocking的地方，任务调度器仍然可能运行。此时，任务调度器会企图把ISR的TCB属性改为pend。但是ISR没有TCB，必然也出错。

在Vxworks里，通常是这样处理的：在ISR里，除了对中断寄存器进行必要的操作之外，尽量简单的就是只释放一个信号量，通知一个高优先级的任务来完成可能引起blocking的工作。这类似于Linux的上下半部的处理方法。

在中断嵌套的情况下，中断上下文没有任务上下文那么复杂。只是保存了PC指针，和一些相应的寄存器的状态就够了。中断有的使用硬件堆栈，有的使用软件堆栈。

楼主的情况应该属于第2种

[armlearnerie]

谢谢各位的回答，我感觉自己对这个问题的理解越来越清晰了。
在各位的回答中有几点还想麻烦大家帮我明确一下，多谢！
1.Hshi大虾说的“如果支持中断线程化，那么将导致中断响应时间不确定，实时性难以得到保证。”应该怎么理解？为什么线程化会导致中断响应时间不确定？
2.sterrys大虾说的“中断的优先级很高，如果在那里等信号量的话，别的 Task 可能会被阻塞没有机会释放信号量造成死锁。”，中断服务程序正在运行，那么别的task就不会被执行，又怎么会造成死锁呢？
3.topcool99大虾，能不能说一下vxworks中的中断服务程序要在多少时间内完成才不会导致死机或复位呢？

谢谢大家！！

[topcool99]

3.topcool99大虾，能不能说一下vxworks中的中断服务程序要在多少时间内完成才不会导致死机或复位呢？

不调用可能阻塞的函数，时间没有绝对限制，但一般要求越短越好。

[armlearnerie]

谢谢，也请其他几位大侠抽空帮小弟回答一下。多谢！

[洒家一笑]

我觉得：中断的优先级很高，如果在那里等信号量的话，别的 Task 可能会被阻塞没有机会释放信号量造成死锁。
很有说服力。
这个问题真是好啊。
希望大虾们多多发表意见