因为信号量会导致线程睡眠。
中断发生以后，CPU 跳到内核设置好的中断处理代码中去，由这部分内核代码来处理中断。这个处理过程中的上下文就是中断上下文。
- 为什么可能导致睡眠的函数都不能在中断上下文中使用呢？
首先睡眠的含义是将进程置于睡眠 状态，在这个状态的进程不能被调度执行。然后，在一定的时机，这个进程可能会被重新置为 运行 状态，从而可能被调度执行。 可见，睡眠 与 运行 是针对进程而言的，代表进程的 task_struct 结构记录着进程的状态。内核中的“调度器”通过 task_struct 对进程进行调度。
但是，中断上下文却不是一个进程，它并不存在 task_struct，所以它是不可调度的。所以，在中断上下文就不能睡眠。
- 那么，中断上下文为什么不存在对应的 task_struct 结构呢？
中断的产生是很频繁的（至少每毫秒（看配置，可能 10 毫秒或其他值）会产生一个时钟中断），并且中断处理过程会很快。如果为中断上下文维护一个对应的 task_struct 结构，那么这个结构频繁地分配、回收、并且影响调度器的管理，这样会对整个系统的吞吐量有所影响。
但是在某些追求实时性的嵌入式 linux 中，中断也可能被赋予 task_struct 结构。这是为了避免大量中断不断的嵌套，导致一段时间内 CPU 总是运行在中断上下文，使得某些优先级非常高的进程得不到运行。这种做法能够提高系统的实时性，但是代价是吞吐量的降低。
以上结论在 RTOS 系统中也是一样的，在中断上下文中不存在线程结构，他是不能被调度的，也就是不能被挂起的，如果尝试在中断中挂起，理论分析的话会代表背景线程（被中断的线程）挂起，就会在系统运行时出现莫名其妙的错误。