Operating system ISR期间不应删除UCO任务的原因

我正在修改UCOSII的一些功能（主要是调度）

我发现OSTaskDel函数在被ISR调用时不起任何作用

虽然我学到了操作系统的一些基本功能，但我真的不明白为什么要禁止这些功能

它所做的只是从readylist中调用Rawl并释放获得的资源，如TCB或信号量

---

在处理中断时有什么理由禁止它们吗？

通常，您不能在ISR中执行以下几项操作：

在信号灯等上阻塞

如果是单CPU系统，则在获取旋转锁时阻塞

导致页面错误，必须由虚拟内存子系统解决（即使用虚拟磁盘内存）

如果在ISR中执行上述任一操作，将出现死锁

---

OSTaskDel（）

可能正在做其中的一些事情。

文档中不清楚为什么在这种情况下禁止它，但是

OSTaskDel（）

显式调用

OS_Sched（）

，在ISR中，只有当最外层的嵌套中断处理程序存在时（由

ositexit（）处理）

才会发生这种情况

我不认为以下是可取的，因为可能有其他原因禁止这样做，但您可以删除：

if (OSIntNesting > 0) {
    return (OS_TASK_DEL_ISR);
}

然后将调用条件设置为

OS_Sched（）

如下：

if (OSIntNesting == 0) {
    OS_Sched();
}

如果这死得很惨，记得我说过这是不明智的

在任何情况下，此操作都会延长中断处理时间，因此如果仅出于此原因，这可能是一个坏主意

无论任务状态或资源使用情况如何，异步删除另一个任务通常是一个坏主意（不仅仅是从ISR开始）。uC/OS-II提供了

OSTaskDelReq（）

功能来管理任务删除，从而允许任务根据请求删除自身，从而能够正确释放其所有资源。即使没有这一点，通过任务的正常IPC机制发送请求通常会更好（而且更便于携带）

---

如果任务不是为按需自删除而设计的，那么您可以简单地使用OSSuspend（）。

谢谢您的回答。：）它所做的只是释放共享对象（比如信号量）。我可以猜到为什么应该禁止阻塞（或挂起），但不释放。是否有任何明确的理由发布也应该被禁止？我不知道所有的实施细节。再看深一点。也可能是函数最初不是设计（意指）在ISR上下文中调用的，即使实际上没有任何东西阻止它运行。就我个人而言，我不会从ISR调用这样的函数。ISR是简单的东西。是的，我想你是对的。我想我应该找到别的方法来做我想做的事。感谢您的建议：-）在获得旋转锁时，线程如何阻止？它永远不会阻塞，它会继续旋转。您可以在ISR中尝试获取自旋锁。@Harman这不是关于线程阻塞，但您是对的，自旋可能是一个更好的词。您可以尝试获取，对吗？对不起，检查晚了！我正在我的国家度国庆节。我想你的回答已经很有帮助了我要检查OSTskDelReq（）！谢谢你友好的回答：）