OS调度和RTOS调度的区别

发布于 2024-11-14 13:12:15 字数 411 浏览 6 评论 0原文

考虑函数/过程,

void task_fun(void) { 同时(1) } 如果这个进程在普通的 PC 操作系统上运行,它会很高兴地永远运行。但在手机上,随着硬件看门狗到期并重置系统,它肯定会在几分钟内使整个手机崩溃。 在 PC 上,该进程在其规定的时间片到期后将被安排出去,并安排一个新的可运行进程来运行。

我的疑问是为什么我们不能在 RTOS 上应用相同的策略?如果在 RTOS 上实现这样的调度策略,会带来什么性能限制?

还有一个疑问是我检查了我的 PC 操作系统 (Ubuntu) 和也运行 Linux 内核的手机的 schedule() 函数。我发现他们两个几乎是一样的。我的手机上的看门狗移交在哪里完成?我的假设是调度程序是在让进程运行之前启动看门狗的人。有人能指出我在代码中完成的位置吗?

Consider the function/process,

void task_fun(void)
{
while(1)
}

If this process were to run on a normal PC OS, it would happily run forever. But on a mobile phone, it would surely crash the entire phone in a matter of minutes as the HW watchdog expires and resets the system.
On a PC, this process, after it expires its stipulated time slice would be scheduled out and a new runnable process would be scheduled to run.

My doubt is why cant we apply the same strategy on an RTOS? What is the performance limitation involved if such a scheduling policy is implemeted on an RTOS?

One more doubt is that I checked the schedule() function of both my PC OS ( Ubuntu ) and my phone which also runs Linux Kernel. I found both of them to be almost the same. Where is the watchdog handing done on my phone? My assumption is that scheduler is the one who starts the watchdog before letting a process run. Can someone point me where in code its being done?

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

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

发布评论

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

评论(4

無處可尋 2024-11-21 13:12:15

手机“崩溃”是手机设计或特定操作系统的问题,而不是一般嵌入式操作系统或 RTOS 的问题。它会“饿死”较低优先级的任务(可能包括看门狗服务),这可能就是这里发生的情况。

在大多数嵌入式 RTOS 中,所有进程都由系统设计者在部署时定义,并且设计是为了根据需要调度所有进程。将用户定义或第三方代码放置在此类系统上可能会损害其调度方案,如您的示例所示。我建议所有此类进程应以与所有其他进程相同的低优先级运行,以便循环调度程序平等地为用户应用程序提供服务,而不会影响系统服务。

电话操作系统通常是 RTOS,但用户进程不应以高于系统进程的优先级运行。此类进程可能故意运行在比看门狗服务更高的位置,以保护系统免受您模拟的“行为不当”应用程序的影响。

大多数 RTOS 使用基于抢占优先级的调度程序(最高优先级就绪任务一直运行,直到它终止、让出或被更高优先级的任务或中断抢占)。有些还为相同优先级的任务安排循环(任务运行直到它终止、产生或消耗其时间片并且相同优先级的其他任务准备好运行)。

The phone "crashing" is an issue with the phone design or the specific OS, not embedded OSes or RTOSes in general. It would 'starve' lower priority tasks (possibly including the watchdog service), which is probably what is happening here.

In most embedded RTOSes it is intended that all processes are defined at deployment by the system designer and the design is for all processes to be scheduled as required. Placing user defined or third party code on such a system can compromise its scheduling scheme as in your example. I would suggest that all such processes should run at the same low priority as all others so that the round-robin scheduler will service user application equally without compromising system services.

Phone operating systems are usually RTOS, but user processes should not run at higher priority that system processes. It may be intentional that such processes run higher than the watchdog service exactly to protect the system from "misbehaving" applications which yours simulates.

Most RTOSes use a pre-emptive priority based scheduler (highest priority ready task runs until it terminates, yields, or is pre-empted by a higher priority task or interrupt). Some also schedule round-robin for tasks at the same priority level (task runs until it terminates, yields or consumes its time-slice and other tasks of the same priority are ready to run).

萌吟 2024-11-21 13:12:15

有多种方法可以实现看门狗,其中没有一种是由 Linux 强加的:

  • 进程或线程定期运行以测试是否正在执行重要操作。如果不是,则会采取纠正措施,例如重新启动机器或重置有问题的组件。
  • 进程或线程连续运行以吸收额外的 CPU 时间并重置计时器。如果任务无法运行,计时器就会到期并采取纠正措施。
  • 如果硬件组件不定期进行调整,则会重置系统;也就是说,硬件定时器到期。

在 RTOS 或任何其他多任务操作系统上,没有什么是不能完成的。

There are several ways a watchdog can be implemented, none of which is imposed by Linux:

  • A process or thread runs periodically to test that vital operations are being performed. If they are not, correction action is taken, like reboot the machine, or reset a troublesome component.
  • A process or thread runs continuously to soak up extra CPU time and reset a timer. If the task is not able to run, a timer expires and takes corrective action.
  • A hardware component resets the system if it is not periodically massaged; that is, a hardware timer expires.

There is nothing here that can't be done on either an RTOS or any other multitasking operating system.

情泪▽动烟 2024-11-21 13:12:15

无论是在台式电脑还是手机上,Linux 都不是 RTOS。其调度策​​略是时间驱动的。

在 RTOS 上,调度由事件触发,事件可以通过 ISR 从环境触发,也可以通过系统调用从软件本身触发(发送消息、等待互斥体……)

Linux, on a desktop computer or on a mobile phone, is not a RTOS. Its scheduling policy is time-driven.

On a RTOS, scheduling is triggered by events, either from environment through ISR or from software itself through system calls (send message, wait for mutex, ...)

若言繁花未落 2024-11-21 13:12:15

在普通操作系统中,我们有两种类型的进程。用户进程&内核进程。内核进程有时间限制。而用户进程则没有时间限制。

在RTOS中,所有进程都是内核进程和内核进程。因此,应严格遵守时间限制。所有进程/任务(可以互换使用)都基于优先级,时间限制对于系统的正确运行非常重要。

因此,如果您的代码 void task_fun(void) { while(1) } 永远运行,其他更高优先级的任务将会挨饿。因此,看门狗将使系统崩溃,以向开发人员表明其他任务的时间限制未得到满足。

例如,GSM Scheduler需要每4.6ms运行一次,如果您的任务运行时间更长,则无法满足GSM Scheduler任务的时间限制。因此系统必须重新启动,因为它的目的已经落空。

希望这有帮助:)

In a normal OS, we have two types of processes. User process & kernel Process. Kernel processes have time constraints.However, user processes do not have time constraints.

In a RTOS,all process are Kernel process & hence time constraints should be strictly followed. All process/task (can be used interchangeably) are based on priority and time constraints are important for the system to run correctly.

So, if your code void task_fun(void) { while(1) } runs forever, other higher priority tasks will be starving. Hence, watch dog will crash the system to specify the developer that time constraints of other tasks are not met.

For example, GSM Scheduler needs to run every 4.6ms, if your task runs for more time, time constraints of GSM Scheduler task cannot be satisfied. So the system has to reboot as its purpose is defeated.

Hope this helps :)

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