如果硬实时任务超过了截止日期会怎样？
What happens if a hard realtime task exceeds its deadline?
我想通过使用 RTOS 更具体地了解硬实时系统的基本概念。根据 RTOS 的定义，它保证实时任务永远不会超过它们的截止日期。
void RT_task1(void *params)
{
do_inits();
while (true)
{
... // Do the job whatever it is in realtime.
Delay(20); // Wait for 20 ms.
}
}
这是RTOS中基于任务的实时系统的简单结构。在这一点上，我想知道这些问题；
1) 这个代码块中RTOS的定义提到的"DEADLINE"是什么。是 "Delay" 时间 20 毫秒还是由 "Do Job" 部分确定的其他内容？
2) 如果超过截止日期会怎样？我知道它由 RTOS 保证，但在 "what if case" 中：我们是否定义了灾难性错误过程？
3) RTOS如何保证交期？我的意思是，我可以 运行 很多 RT 任务，所以 CPU 资源可能不够，或者编程不当的任务比其他 RT 任务消耗太多时间？ "guarateed" 部分在哪里？
我知道 RTOS 和传统 OS 之间的主要区别在于调度程序。 RTOS使用确定性的方式给用户调度保证。然而，这些信息并不能完全满足我对整个系统的理解。
谢谢。
硬实时系统的定义是，错过最后期限被视为失败。因此，如果硬实时系统错过了最后期限，就会发生 "failure"。失败的后果因一个应用程序而异，因此，一般来说，您只能说发生了失败。
使用 RTOS 并不能自动保证实时任务永远不会错过最后期限。就像挥动锤子并不能保证你永远不会错过钉子和击中你的拇指。 RTOS 只是一个工具。如果使用得当，它可以帮助开发人员满足系统的实时性要求。但能否正确设计和实现系统，还是要靠开发者。
1) 截止日期由系统要求定义。它们不是由 RTOS 的使用方式定义的。
2) 如果超过截止日期会发生什么完全取决于应用程序。考虑截止日期要求的原因，这将为您提供有关如果错过截止日期会发生什么情况的线索。
3) RTOS 不保证会在最后期限前完成。系统的设计和实施应保证满足最后期限。
错过最后期限可能是失败。例如，假设您有两个任务，A 和 B。A 运行s 在 30 毫秒内，B 运行s 在 15 毫秒内。如果您有 20 毫秒的时间块，A 将每次都错过截止日期并且B 每次都会通过。
A是否失败这个问题要看需求。如果 A 在一个时间片 中必须 运行，那么错过最后期限就是失败。另一方面，如果 A 可以在其下一个时间片和 运行 完成期间被中断和恢复，如果没问题，那么 A 的 运行 时间不一定构成失败。
这完全取决于要求。 RTOS 无法保证任务的完成。示例：将 A 视为使用埃拉托色尼筛法算法计算大质数的任务，而 B 只是切换外部时钟引脚。这两项任务的复杂性和持续时间相差很多个数量级。 RTOS 无法神奇地让每个 A 或 B 按时完成，但它可以确保任务 B 不会因为错过 运行 的机会而饿死，因为 A 需要很长时间才能完成。
By the definition of an RTOS it guaranties the realtime tasks will
never exceed their deadlines.
RTOS 不就截止日期向您保证任何事情。它只保证您的任务顺序将根据您定义的优先级。
确保在最后期限前完成是你的工作。
截止日期通常由系统本身及其与其他元素的交互定义。
例如：
如果您踩下汽车的制动踏板，汽车实际制动需要多长时间？
您需要多久刷新一次屏幕？
此外，您不会在第一个示例中错过截止日期是灾难性的，而在第二个示例中还不错。
@System Coder 写道：
By the definition of an RTOS it guaranties the realtime tasks will never exceed their deadlines.
事实并非如此。根据定义，RTOS 保证任务的确定性调度。一项任务是否能在最后期限前完成完全取决于您的应用程序的设计和实现，尤其是您如何划分任务、如何触发任务以及如何分配优先级。
What happens if a hard realtime task exceeds its deadline?
一个更合适的问题是，如果任务未能在最后期限前完成，您的应用程序会如何表现？这个问题完全取决于应用程序。 RTOS 本质上不会检测失败的截止日期，因为它不知道您的应用程序。 RTOS 的目的是以永远不会超过截止日期的方式设计调度和优先级分配。如果超过了最后期限 ，则说明您的设计存在缺陷，而不是 RTOS.
的失败
您的代码片段过于简单；实时应用程序通常必须响应外部事件（除了时间），如果循环的目的是每 20 OS 刻度（根据评论为毫秒）执行一次任务，那么它将失败如果延迟之前的代码花费的时间超过 1 个刻度，则该目标。此外，初始执行将与 RTOS 节拍异步，并且第一次和第二次循环执行之间的时间在任何情况下都不太确定（介于 19 到 20 节拍之间）。
循环中的延迟对于没有硬截止日期的任务来说很好；例如说 PID 回路是一个糟糕的设计。相反，在您的示例中，您应该使用 RTOS 计时器（而不是延迟）；这样循环体只需要在 20 毫秒而不是 1 毫秒内完成。如果有更高优先级的任务和中断抢占了这个任务，即使代码本身在 1ms 内运行良好，如果被其他代码抢占和延迟，它也可能会错过该截止时间；所以有 20ms 来完成它的任务显然是有益的。
1) What is the "DEADLINE" which is mentioned by the definition of RTOS in this code block. Is it the "Delay" time 20 ms or something else determined by "Do Job" part?
截止日期是您的申请成功满足其要求所必需的；它不是RTOS定义的，它是由您的要求定义的。如上所述，您的示例可能不是实时任务的良好设计，除非它和所有可能的抢占任务都可以在不到 1 毫秒的时间内完成。在任何情况下，它的可扩展性都不是很好，最初满足最后期限的设计在维护、新代码或优先级重新分配后可能不再这样做。
2) What happens if the deadline is exceeded? I know it is guaranteed by RTOS, but in a "what if case": do we define a catastrophic error procedure?
如我所说； RTOS 不保证它，失败的后果取决于您的应用程序。如果没有什么不好的事情发生，也许最后期限是错误的并且不必要地紧迫。如果失败，您需要重新考虑系统的可调度性。
3) How can RTOS guarantee the deadlines? I mean, I can run a lot of RT task so CPU resource may not be enough or a badly programmed task consumes too much time over other RT tasks? Where is the "guarateed" part?
不能；可以保证确定性调度；最高优先级 "ready" 任务将 运行 立即（在上下文切换时间的限制内）——就这么简单，仅此而已。即使在 RTOS 中，由于中断处理程序设计不佳，您仍然可以呈现不确定的调度。它们也需要是确定性的——每一个都在有限的、理想的恒定时间内执行。任务执行的最大延迟是所有更高优先级任务和中断执行时间的总和；作为一般经验法则，通过将最高优先级分配给执行时间最短的任务，可以最大限度地减少延迟。执行时间不确定或变化很大的任务应给予较低的优先级。其他特定于应用程序的因素也会发挥作用，例如任务如何与其他任务交互、通信或同步。
3) How can RTOS guarantee the deadlines? I mean, I can run a lot of RT
task so CPU resource may not be enough or a badly programmed task
consumes too much time over other RT tasks? Where is the "guarateed"
part?
RTOS 使用硬件计时器，当任务为 started/reentered 时，该计时器开始 运行。当任务挂起 (delay/sleeps/exit) 时，计时器停止。如果定时器确实 运行s 停止，硬件中断 returns 控制 RTOS 采取一些行动。这些类型的机制在一个 RTOS 和下一个 RTOS 之间是不同的，并不是所有的 RTOS 都有截止时间计时器机制。
我想通过使用 RTOS 更具体地了解硬实时系统的基本概念。根据 RTOS 的定义，它保证实时任务永远不会超过它们的截止日期。
void RT_task1(void *params)
{
do_inits();
while (true)
{
... // Do the job whatever it is in realtime.
Delay(20); // Wait for 20 ms.
}
}
这是RTOS中基于任务的实时系统的简单结构。在这一点上，我想知道这些问题；
1) 这个代码块中RTOS的定义提到的"DEADLINE"是什么。是 "Delay" 时间 20 毫秒还是由 "Do Job" 部分确定的其他内容？
2) 如果超过截止日期会怎样？我知道它由 RTOS 保证，但在 "what if case" 中：我们是否定义了灾难性错误过程？
3) RTOS如何保证交期？我的意思是，我可以 运行 很多 RT 任务，所以 CPU 资源可能不够，或者编程不当的任务比其他 RT 任务消耗太多时间？ "guarateed" 部分在哪里？
我知道 RTOS 和传统 OS 之间的主要区别在于调度程序。 RTOS使用确定性的方式给用户调度保证。然而，这些信息并不能完全满足我对整个系统的理解。
谢谢。
硬实时系统的定义是，错过最后期限被视为失败。因此，如果硬实时系统错过了最后期限，就会发生 "failure"。失败的后果因一个应用程序而异，因此，一般来说，您只能说发生了失败。
使用 RTOS 并不能自动保证实时任务永远不会错过最后期限。就像挥动锤子并不能保证你永远不会错过钉子和击中你的拇指。 RTOS 只是一个工具。如果使用得当，它可以帮助开发人员满足系统的实时性要求。但能否正确设计和实现系统，还是要靠开发者。
1) 截止日期由系统要求定义。它们不是由 RTOS 的使用方式定义的。
2) 如果超过截止日期会发生什么完全取决于应用程序。考虑截止日期要求的原因，这将为您提供有关如果错过截止日期会发生什么情况的线索。
3) RTOS 不保证会在最后期限前完成。系统的设计和实施应保证满足最后期限。
错过最后期限可能是失败。例如，假设您有两个任务，A 和 B。A 运行s 在 30 毫秒内，B 运行s 在 15 毫秒内。如果您有 20 毫秒的时间块，A 将每次都错过截止日期并且B 每次都会通过。
A是否失败这个问题要看需求。如果 A 在一个时间片 中必须 运行，那么错过最后期限就是失败。另一方面，如果 A 可以在其下一个时间片和 运行 完成期间被中断和恢复，如果没问题，那么 A 的 运行 时间不一定构成失败。
这完全取决于要求。 RTOS 无法保证任务的完成。示例：将 A 视为使用埃拉托色尼筛法算法计算大质数的任务，而 B 只是切换外部时钟引脚。这两项任务的复杂性和持续时间相差很多个数量级。 RTOS 无法神奇地让每个 A 或 B 按时完成，但它可以确保任务 B 不会因为错过 运行 的机会而饿死，因为 A 需要很长时间才能完成。
By the definition of an RTOS it guaranties the realtime tasks will never exceed their deadlines.
RTOS 不就截止日期向您保证任何事情。它只保证您的任务顺序将根据您定义的优先级。
确保在最后期限前完成是你的工作。 截止日期通常由系统本身及其与其他元素的交互定义。
例如： 如果您踩下汽车的制动踏板，汽车实际制动需要多长时间？ 您需要多久刷新一次屏幕？
此外，您不会在第一个示例中错过截止日期是灾难性的，而在第二个示例中还不错。
@System Coder 写道：
By the definition of an RTOS it guaranties the realtime tasks will never exceed their deadlines.
事实并非如此。根据定义，RTOS 保证任务的确定性调度。一项任务是否能在最后期限前完成完全取决于您的应用程序的设计和实现，尤其是您如何划分任务、如何触发任务以及如何分配优先级。
What happens if a hard realtime task exceeds its deadline?
一个更合适的问题是，如果任务未能在最后期限前完成，您的应用程序会如何表现？这个问题完全取决于应用程序。 RTOS 本质上不会检测失败的截止日期，因为它不知道您的应用程序。 RTOS 的目的是以永远不会超过截止日期的方式设计调度和优先级分配。如果超过了最后期限 ，则说明您的设计存在缺陷，而不是 RTOS.
的失败您的代码片段过于简单；实时应用程序通常必须响应外部事件（除了时间），如果循环的目的是每 20 OS 刻度（根据评论为毫秒）执行一次任务，那么它将失败如果延迟之前的代码花费的时间超过 1 个刻度，则该目标。此外，初始执行将与 RTOS 节拍异步，并且第一次和第二次循环执行之间的时间在任何情况下都不太确定（介于 19 到 20 节拍之间）。
循环中的延迟对于没有硬截止日期的任务来说很好；例如说 PID 回路是一个糟糕的设计。相反，在您的示例中，您应该使用 RTOS 计时器（而不是延迟）；这样循环体只需要在 20 毫秒而不是 1 毫秒内完成。如果有更高优先级的任务和中断抢占了这个任务，即使代码本身在 1ms 内运行良好，如果被其他代码抢占和延迟，它也可能会错过该截止时间；所以有 20ms 来完成它的任务显然是有益的。
1) What is the "DEADLINE" which is mentioned by the definition of RTOS in this code block. Is it the "Delay" time 20 ms or something else determined by "Do Job" part?
截止日期是您的申请成功满足其要求所必需的；它不是RTOS定义的，它是由您的要求定义的。如上所述，您的示例可能不是实时任务的良好设计，除非它和所有可能的抢占任务都可以在不到 1 毫秒的时间内完成。在任何情况下，它的可扩展性都不是很好，最初满足最后期限的设计在维护、新代码或优先级重新分配后可能不再这样做。
2) What happens if the deadline is exceeded? I know it is guaranteed by RTOS, but in a "what if case": do we define a catastrophic error procedure?
如我所说； RTOS 不保证它，失败的后果取决于您的应用程序。如果没有什么不好的事情发生，也许最后期限是错误的并且不必要地紧迫。如果失败，您需要重新考虑系统的可调度性。
3) How can RTOS guarantee the deadlines? I mean, I can run a lot of RT task so CPU resource may not be enough or a badly programmed task consumes too much time over other RT tasks? Where is the "guarateed" part?
不能；可以保证确定性调度；最高优先级 "ready" 任务将 运行 立即（在上下文切换时间的限制内）——就这么简单，仅此而已。即使在 RTOS 中，由于中断处理程序设计不佳，您仍然可以呈现不确定的调度。它们也需要是确定性的——每一个都在有限的、理想的恒定时间内执行。任务执行的最大延迟是所有更高优先级任务和中断执行时间的总和；作为一般经验法则，通过将最高优先级分配给执行时间最短的任务，可以最大限度地减少延迟。执行时间不确定或变化很大的任务应给予较低的优先级。其他特定于应用程序的因素也会发挥作用，例如任务如何与其他任务交互、通信或同步。
3) How can RTOS guarantee the deadlines? I mean, I can run a lot of RT task so CPU resource may not be enough or a badly programmed task consumes too much time over other RT tasks? Where is the "guarateed" part?
RTOS 使用硬件计时器，当任务为 started/reentered 时，该计时器开始 运行。当任务挂起 (delay/sleeps/exit) 时，计时器停止。如果定时器确实 运行s 停止，硬件中断 returns 控制 RTOS 采取一些行动。这些类型的机制在一个 RTOS 和下一个 RTOS 之间是不同的，并不是所有的 RTOS 都有截止时间计时器机制。