让我的问题简短..。我正在为RTOS编写模拟程序。与往常一样,主要的问题是上下文切换模拟。在中断的情况下,很难不偏离“好的”编码准则。
例如,任务A正在运行,用户应用程序正在计算其无害的私有内容,这些内容将运行很长时间。在这个任务A中,一个中断X应该发生。(提示:任务A与触发此中断X无关).现在如何执行从Task到中断X处理程序的上下文切换?
我目前的实现是基于一个上下文线程,该线程等待某个上下文切换被请求;一个中断控制器线程,如果有人请求中断触发时可以产生中断;以及一个正在运行任务A的主线程。现在,我使用中断控制器线程为中断X生成一个新线程,然后请求上下文线程进行上下文切换。上下文线程终止任务一个主线程并恢复中断X处理程序线程。在中断X处理程序线程的末尾,任务A主线程被恢复。
编辑只是为了澄清,我已经知道挂起和终止线程从外部是真的不好。所以我才问这个问题。另外,请不要建议使用事件等来控制任务A。这是用户应用程序代码,我无法控制它。他甚至可以使用而{}如果他想..。
发布于 2015-02-09 08:49:40
我怀疑你不能用那种方式做你想做的事。
你说过从外面挂线程真的很糟糕。原因是当您挂起线程时,您不知道线程在做什么。不可能知道线程当前是否拥有互斥;如果它拥有互斥,那么试图访问同一个互斥的任何其他线程都将陷入死锁。
您的问题是,可能挂起的线程使用的运行时与监控器使用的运行时相同。这意味着监控程序和其他线程之间可能存在许多这样的死锁。
在实际环境中(即不是模拟器),操作系统内核可以挂起线程,因为存在检查以确保这些死锁不会发生。我不知道细节,但是它可能涉及到在某些临界点屏蔽中断,并且可能不会在用户模式代码和内核调度器的关键部分之间共享相同的互斥。(在您的情况下,这意味着您的调度程序不能直接或间接地使用用户线程允许使用的任何相同的OS函数,以防涉及互斥。当然,这几乎是不可能实现的。
我在评论中询问您是否对用户代码编译器有任何控制的原因是,如果您控制了编译器,那么您可以安排用户代码在每次指令的持续时间内有效地屏蔽中断,并且只会在指令之间定义良好的点向另一个线程屈服。在我工作的控制系统中就是这样做的。
另一个方面是平台依赖。在Linux和其他类似unix的操作系统中,有信号,就像用户模式的中断.您可能会使用信号来模拟上下文切换,尽管在互斥中仍然存在相同的问题。在Windows上(据我所知)绝对没有类似的东西,确切地说是因为已经说明的问题。最近的事情是异步过程调用,但是只有当线程将自己置于可报警的等待状态(这意味着线程处于确定性状态,现在中断是安全的)时才会运行。
我认为您将不得不重新考虑整个概念,以便您的监控线程在非模拟环境中具有高于用户线程的特权控制。这可能包括用您自己创造的东西替换编译器或运行时库,或者两者兼而有之。
https://stackoverflow.com/questions/28237748
复制相似问题