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