GPOS 最有可能失败的 RTOS 示例
RTOS example where GPOS will most likely fail
我想知道几个需要使用RTOS来保证系统正常工作的应用实例。
我做了一些 google 搜索，无论我找到什么例子，我觉得都可以使用 windows 或 linux 系统来实现。
RTOS 和 GPOS 之间的主要区别在于 RTOS 保证确定性响应。也就是说，事件的最坏情况响应时间是精确限定的（而且通常很快）。 GPOS 通常在 "balanced load" 的基础上安排进程 - 它假定所有进程和事件都同等重要，并将分配 "fair" 的处理器资源份额。因此，当进程具有 CPU 时，除非它产生 "cooperatively"，否则它将在其时隙期间单独使用 CPU（假设单核 - 多核处理器允许真正的并发，但 GPOS 仍然分配平衡负载基础的内核）。一个时隙可能是几十毫秒，服务特定进程所花费的时间将在很大程度上取决于同时需要 CPU 时间的进程数。除了实现内核级驱动程序之外，在 GPOS 中实现几十微秒（或更短）的时序约束是不可能的（或不可取的）。
如果您的应用程序是 Microsoft 的市场营销过去称为 "soft" 实时 （即根本不是实时）的应用程序，那么 GPOS 可能适合。 Linux 可以构建 "real-time" 调度支持，但它并不能真正使 Linux 适合大量 "hard" 实时任务，它仍然是 "soft" 在大多数情况下它会按时完成，但在某些异常情况下它可能会失败。如果那是您的医疗生命支持系统，您可能不想相信它！
作为在 GPOS 上尝试 运行 本质上实时任务失败的一个例子，几年前当 MMX 指令被添加到奔腾处理器时（运行当时通常在 60MHz） ，有人提出 "Host Signal Processing" 的好主意，一种通过在 PC 上执行信号处理而不是在调制解调器硬件中使用专用处理器或 DSP 来降低 PSTN 调制解调器（拨号）成本的方法 - 这些"modems" 根本不是真正的调制解调器；它们是调制解调器软件的电话接口和数字转换器。当时我在一家生产 PSTN 调制解调器测试设备的公司工作，我们尝试了其中一种早期的 HSP 调制解调器，它一直有效，直到你启动 Microsoft Word（或几乎任何大型应用程序），然后它会立即断开连接.随着 PC 变得更快，情况有所改善，但关键是它不能保证工作 - 它只是 mostly 做到了。
我工作过的另一个例子是食品包装中的装箱机。将产品放入纸箱，涂上胶条，然后折叠封口。纸箱在这个过程中不断移动，胶枪的时间很关键——要使纸箱上的胶条精确到一毫米以内，以每秒一米的速度移动，需要时间在一毫秒内。
另一个例子是 TDMA 通信，例如用于数字电话。这种通信为每个站传输分配一个时隙，不能在准确正确的时隙中传输，或者侵占另一个站的时隙是不可接受的。这样的系统在全球范围内同步到原子钟精度（通常来自 GPS 接收器）。例如一个 GSM 时隙是 577 微秒，在这段时间内，发射机必须提高发射机功率，传输数据并降低
简而言之，任何需要 100% 确定性时序的示例都需要 RTOS。如果您的时序约束大于 100 毫秒，并且满足时序的小概率失败是可以容忍的，那么 GPOS 可能会在所有时间或大部分时间工作。如果时序限制是亚毫秒或失败的成本或后果不可接受，那么 RTOS 是合适的。
我想知道几个需要使用RTOS来保证系统正常工作的应用实例。
我做了一些 google 搜索，无论我找到什么例子，我觉得都可以使用 windows 或 linux 系统来实现。
RTOS 和 GPOS 之间的主要区别在于 RTOS 保证确定性响应。也就是说，事件的最坏情况响应时间是精确限定的（而且通常很快）。 GPOS 通常在 "balanced load" 的基础上安排进程 - 它假定所有进程和事件都同等重要，并将分配 "fair" 的处理器资源份额。因此，当进程具有 CPU 时，除非它产生 "cooperatively"，否则它将在其时隙期间单独使用 CPU（假设单核 - 多核处理器允许真正的并发，但 GPOS 仍然分配平衡负载基础的内核）。一个时隙可能是几十毫秒，服务特定进程所花费的时间将在很大程度上取决于同时需要 CPU 时间的进程数。除了实现内核级驱动程序之外，在 GPOS 中实现几十微秒（或更短）的时序约束是不可能的（或不可取的）。
如果您的应用程序是 Microsoft 的市场营销过去称为 "soft" 实时 （即根本不是实时）的应用程序，那么 GPOS 可能适合。 Linux 可以构建 "real-time" 调度支持，但它并不能真正使 Linux 适合大量 "hard" 实时任务，它仍然是 "soft" 在大多数情况下它会按时完成，但在某些异常情况下它可能会失败。如果那是您的医疗生命支持系统，您可能不想相信它！
作为在 GPOS 上尝试 运行 本质上实时任务失败的一个例子，几年前当 MMX 指令被添加到奔腾处理器时（运行当时通常在 60MHz） ，有人提出 "Host Signal Processing" 的好主意，一种通过在 PC 上执行信号处理而不是在调制解调器硬件中使用专用处理器或 DSP 来降低 PSTN 调制解调器（拨号）成本的方法 - 这些"modems" 根本不是真正的调制解调器；它们是调制解调器软件的电话接口和数字转换器。当时我在一家生产 PSTN 调制解调器测试设备的公司工作，我们尝试了其中一种早期的 HSP 调制解调器，它一直有效，直到你启动 Microsoft Word（或几乎任何大型应用程序），然后它会立即断开连接.随着 PC 变得更快，情况有所改善，但关键是它不能保证工作 - 它只是 mostly 做到了。
我工作过的另一个例子是食品包装中的装箱机。将产品放入纸箱，涂上胶条，然后折叠封口。纸箱在这个过程中不断移动，胶枪的时间很关键——要使纸箱上的胶条精确到一毫米以内，以每秒一米的速度移动，需要时间在一毫秒内。
另一个例子是 TDMA 通信，例如用于数字电话。这种通信为每个站传输分配一个时隙，不能在准确正确的时隙中传输，或者侵占另一个站的时隙是不可接受的。这样的系统在全球范围内同步到原子钟精度（通常来自 GPS 接收器）。例如一个 GSM 时隙是 577 微秒，在这段时间内，发射机必须提高发射机功率，传输数据并降低
简而言之，任何需要 100% 确定性时序的示例都需要 RTOS。如果您的时序约束大于 100 毫秒，并且满足时序的小概率失败是可以容忍的，那么 GPOS 可能会在所有时间或大部分时间工作。如果时序限制是亚毫秒或失败的成本或后果不可接受，那么 RTOS 是合适的。