i/o操作和获取信号量都属于可能被阻塞（pend）的操作。 这在中断程序中是明确禁止使用到。 对于中断函数中调用可能阻塞的函数，轻则引起系统任务调度打乱，失去实时性，重则系统崩溃或复位。 vxworks属于硬实时操作系统，不能在规定的时间内完成操作即会死机或复位。
在某些操作系统中，是可以在一些特定的低优先级ISR里面进行pend操作的。这要求操作系统的中断，有线程上下文（线程（任务）上下文是任务调度的基础，注意任务上下文不等同于中断上下文）。称为“中断线程化”。 Vxworks的任务调度是依赖于中断的，同时，为了实时性考虑，Vxworks不支持中断线程化，ISR是没有任务（线程）上下文的。如果支持中断线程化，那么将导致中断响应时间不确定，实时性难以得到保证。 如果在vxworks里面，使用了可能blocking的代码，那么有2种情况： 一种是关中断运行。那么，在blocking的地方，将永远等待。因为这时候任务调度依赖的时钟中断都不能响应，也就是说任务调度器都不能运行了，系统就死在中断里了。 另一种是开中断进行。那么，在blocking的地方，任务调度器仍然可能运行。此时，任务调度器会企图把ISR的TCB属性改为pend。但是ISR没有TCB，必然也出错。 在Vxworks里，通常是这样处理的：在ISR里，除了对中断寄存器进行必要的操作之外，尽量简单的就是只释放一个信号量，通知一个高优先级的任务来完成可能引起blocking的工作。这类似于Linux的上下半部的处理方法。 在中断嵌套的情况下，中断上下文没有任务上下文那么复杂。只是保存了PC指针，和一些相应的寄存器的状态就够了。中断有的使用硬件堆栈，有的使用软件堆栈。
中断的优先级很高，如果在那里等信号量的话，别的 Task 可能会被阻塞没有机会释放信号量造成死锁。
