保持我的问题简短......我正在为RTOS编写模拟。像往常一样，主要问题来自上下文切换模拟。在中断的情况下，实际上很难不偏离“良好”编码指南。
说任务A正在运行，用户应用程序正在计算其无害的私有内容，这些内容将运行很长时间。在此任务A期间，应该发生中断X. （提示：任务A与触发此中断X无关）...现在如何执行从任务A到中断X处理程序的上下文切换？
我当前的实现基于一个上下文线程，它等待直到请求某个上下文切换;一个中断控制器线程，如果有人请求中断触发，它可以产生中断;和一个正在运行任务A的主线程。现在我使用中断控制器线程为中断X生成一个新线程，然后请求上下文线程进行上下文切换。 Context thread Suspends Task一个主线程并恢复中断X处理程序线程。在中断X处理程序线程结束时，任务A主线程被恢复..
[编辑]只是为了澄清，我已经知道从外部暂停和终止线程非常糟糕。这就是我问这个问题的原因。另外，请不要建议使用事件等来控制任务A.这是用户应用程序代码，我无法控制它。如果他愿意，他甚至可以使用while（1）{}
答案 0 :(得分：0)
我怀疑你不能以这种方式做你想做的事。
你提到从外面暂停一个帖子真的很糟糕。原因是你暂停它时你不知道线程正在做什么。无法知道线程当前是否拥有互斥锁;如果确实如此，那么试图访问同一个互斥锁的任何其他线程都会死锁。
您遇到的问题是，可能被挂起的线程使用的运行时与主管使用的运行时相同。这意味着主管和其他线程之间存在许多潜在的这种死锁。
在真实环境（即不是模拟器）中，操作系统内核可以挂起线程，因为有适当的检查以确保不会发生这些死锁。我不知道细节，但它可能涉及在某些关键点掩盖中断，并且可能不在用户模式代码和内核调度程序的关键部分之间共享相同的互斥锁。 （在您的情况下，这意味着您的调度程序无法直接或间接使用任何相同的OS API函数，因为它们允许用户线程使用，以防它们涉及互斥体。这当然几乎是不可能的实现。）
我在评论中询问您是否对用户代码编译器有任何控制权的原因是，如果您控制了编译器，那么您可以安排用户代码在每条指令的持续时间内有效地屏蔽中断，并且仅产生另一条指令线程在指令之间定义明确的点。这就是我在一个控制系统中完成的工作方式。
另一方面是平台依赖。在Linux和其他类似Unix的操作系统中，您有信号，就像用户模式中断一样。您可能会使用信号来模拟上下文切换，尽管您仍然会遇到与互斥锁相同的问题。由于已经说明的问题，在Windows上（据我所知）绝对没有等价物。最接近的是异步过程调用，但只有当线程将自身置于可警告的等待状态时才会运行（这意味着线程处于确定状态并且现在可以安全地中断）。
我认为您将不得不重新考虑整个概念，以便您的监督线程在操作系统在非仿真环境中的用户线程之上具有某种特权控制权。这可能涉及用您自己制作的东西替换编译器或运行时库，或两者兼而有之。