需要明确上下文切换在 RTOS 中的工作原理

发布于 2025-01-15 08:34:04 字数 1323 浏览 3 评论 0原文

我想知道我是否正确理解了 RTOS 的概念,更具体地说是调度过程。

所以,我想我了解定时器中断的过程(为了更好的可读性,我省略了中断启用/禁用命令)

1. program runs...
2. A timer tick occurs that triggers a Timer Interrupt
3. The Timer ISR is called
    The timer ISR looks like this:
    3.1. Kernel saves context (registers etc.)
    3.2. Kernel checks if there is a higher priority task
    3.3. If so, the Kernel performs the context switch
    3.4. Return from Interrupt
4. Program runs with another task executing   

但是,当 I/O 引脚发生中断时,该过程是什么样的?

1. program runs
2. an interrupt is triggered because data is available
3. a general ISR is called?
    3.1. Kernel saves context
    3.2. Kernel have to call the User defined ISR, because the Kernel doesn't know what to do now
        3.1.1 User ISR runs and does whatever it should do (maybe change priority of a task, that should run now, because the data is now available)
        3.1.2 return from User ISR
    3.3. Kernel checks if there is a higher priority task available
    3.4. If so the Kernel performs a context switch
    3.5. Return from Interrupt
4. program runs with the different task

在这种情况下,内核必须实现一个通用的ISR,以便所有中断都映射到这个ISR。例如(据我所知)ATmega168p 微控制器有 26 个中断向量。因此应该有一个特定于处理器的文件,它将所有中断映射到通用 ISR。内核 ISR 确定导致中断的原因并调用特定的用户 ISR(处理实际中断)。

我是不是误会了什么? 感谢您的帮助

im wondering whether I understand the concept of a RTOS, and more specifically the scheduling process, correctly.

So, I think I understand the process of a timer interrupt (i omitted the interrupt enable/disable commands for better readability here)

1. program runs...
2. A timer tick occurs that triggers a Timer Interrupt
3. The Timer ISR is called
    The timer ISR looks like this:
    3.1. Kernel saves context (registers etc.)
    3.2. Kernel checks if there is a higher priority task
    3.3. If so, the Kernel performs the context switch
    3.4. Return from Interrupt
4. Program runs with another task executing   

But how does the process looks like, when an Interrupt occurs from lets say a I/O Pin?

1. program runs
2. an interrupt is triggered because data is available
3. a general ISR is called?
    3.1. Kernel saves context
    3.2. Kernel have to call the User defined ISR, because the Kernel doesn't know what to do now
        3.1.1 User ISR runs and does whatever it should do (maybe change priority of a task, that should run now, because the data is now available)
        3.1.2 return from User ISR
    3.3. Kernel checks if there is a higher priority task available
    3.4. If so the Kernel performs a context switch
    3.5. Return from Interrupt
4. program runs with the different task

In this case the kernel must implement a general ISR, so that all interrupts are mapped to this ISR. For example (as far as i know) the ATmega168p microcontroller has 26 interrupt vectors. So there should be a processor specific file, that maps all the Interrupts to a general ISR. The Kernel-ISR determines what caused the interrupt and calls the specific User-ISR (that handles the actual interrupt).

Did I misunderstood something?
Thank you for your help

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

只有影子陪我不离不弃 2025-01-22 08:34:04

操作系统滴答中断和操作系统调度程序之间有明显的区别—​​—但是您将两者混为一谈。当操作系统节拍 ISR 发生时,节拍计数会增加,如果该增量导致计时器或延迟到期,则这是一个调度事件,并且调度事件会导致调度程序在退出中断上下文时运行。

不同的 RTOS 可能有细微的差异,但一般来说,在任何 ISR 中,如果发生调度事件,调度程序会在退出中断上下文之前立即运行,为调度策略要运行的任何线程(通常是最高优先级的就绪线程)设置线程上下文。

调度事件包括:

  • 操作系统计时器到期、
  • 任务延迟到期、
  • 时间片到期(用于循环调度)。
  • 信号量给
  • 消息队列发布
  • 任务事件标志设置

最后三个可以出现在任何ISR中(只要它们是“尝试语义”非阻塞/零超时),前三个作为tick ISR的结果。因此,当任何中断导致至少一个调度事件(可能存在嵌套或多个同时中断)时,调度程序将在退出中断上下文时运行。

调度事件可能发生在任务上下文中,还包括任何潜在的阻塞操作,例如:

  • 信号量给予
  • 信号量获取 消息
  • 队列接收
  • 消息队列发布
  • 任务事件标志设置
  • 任务事件标志等待
  • 任务延迟启动
  • 计时器等待
  • 显式“yield”

调度程序也会在以下情况运行线程触发调度事件,因此上下文切换不仅仅作为中断的结果发生。

总结并具体针对您的问题;滴答声或任何其他中断不会直接导致调度程序运行。中断,任何中断都可以执行使调度程序运行的操作。与线程上下文不同,在线程上下文中,此类操作会导致调度程序立即运行,而在中断上下文中,调度程序会被推迟,直到所有挂起的中断都已得到服务,并在从中断上下文退出时运行。

有关上下文切换的特定 RTOS 实现的详细信息,请参阅 MicroC/OS-II:实时内核(内核和这本书是专门为了教授这些原理而开发的,因此它是一个有用的资源,并且这些原理适用于其他 RTOS 内核)。特别是清单 3.18 至 3.20图 3.10 以及相关解释。

There is a clear distinction between the OS tick interrupt and the OS scheduler - you have however conflated the two. When the OS tick ISR occurs, the tick count is incremented, if that increment causes a timer or delay expiry, that is a scheduling event, and scheduling events causes the scheduler to run on exit from the interrupt context.

Different RTOS may have subtle differences, but in general in any ISR, if a scheduling event occurred, the scheduler runs immediately before exiting the interrupt context, setting up the threading context for whatever thread is due to run by the scheduling policy (normally highest priority ready thread).

Scheduling events include:

  • OS timer expiry
  • Task delay expiry
  • Timeslice expiry (for round-robin scheduling).
  • Semaphore give
  • Message queue post
  • Task event flag set

These last three can occur in any ISR (so long as they are "try semantics" non-blocking/zero timeout), the first three as a result of the tick ISR. So the scheduler will run on exit from the interrupt context when any interrupt has caused at least one scheduling event (there may have been nested or multiple simultaneous interrupts).

Scheduling events may occur in the task context also including on any potentially blocking action such as:

  • Semaphore give
  • Semaphore take
  • Message queue receive
  • Message queue post
  • Task event flag set
  • Task event flag wait
  • Task delay start
  • Timer wait
  • Explicit "yield"

The scheduler runs also when a thread triggers a scheduling event, so context switches do not only occur as the result of an interrupt.

To summarise and with respect to your question specifically; the tick or any other interrupt does not directly cause the scheduler to run. An interrupt, any interrupt can perform an action that makes the scheduler due to run. Unlike the thread context where such an action causes the scheduler to run immediately, in the interrupt context, the scheduler is deferred until all pending interrupts have been serviced and runs on exit from the interrupt context.

For details of a specific RTOS implementation of context switching see §§3.05, 3.06 and 3.10 of MicroC/OS-II: The Real Time Kernel (the kernel and the book were specifically developed to teach such principles, so it is a useful resource and the principles apply to other RTOS kernels). In particular Listings 3.18 to 3.20 and Figure 3.10 and the associated explanation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文