¿Qué significa "Windows no es un sistema operativo en tiempo real"?

Encontré una aplicación llamada LatencyMon , que aparentemente hace monitoreo de latencia.

Siempre he entendido que cuanto más carga le pones al procesador, menos sensible o más latente se vuelve el sistema. Sin embargo, en la segunda sección de la página LatencyMon, la primera oración dice: "Windows no es un sistema operativo en tiempo real" (RTOS). Eso me hizo pensar. Quiero decir, ¿es esto diferente de cualquier otro sistema operativo como Linux, Unix o Mac OS X?

¿Hay algún sistema operativo "en tiempo real"? ¿O es simplemente un esquema de marketing para que compre su producto?

EDITAR:

Además, ¿hay algún ejemplo de RTOS por ahí?

Wikipedia en realidad tiene una sorprendente riqueza de información aquí.

Un sistema operativo en tiempo real (RTOS) es un sistema operativo (SO) destinado a atender solicitudes de aplicaciones en tiempo real.

Una característica clave de un RTOS es el nivel de consistencia con respecto a la cantidad de tiempo que lleva aceptar y completar la tarea de una aplicación; La variabilidad es jitter. Un sistema operativo duro en tiempo real tiene menos fluctuaciones que un sistema operativo suave en tiempo real. El objetivo principal del diseño no es un alto rendimiento, sino más bien una garantía de una categoría de rendimiento suave o difícil. Un RTOS que puede cumplir generalmente o generalmente una fecha límite es un SO suave en tiempo real, pero si puede cumplir con una fecha límite de manera determinista, es un SO difícil en tiempo real.

Un RTOS tiene un algoritmo avanzado para la programación. La flexibilidad del programador permite una orquestación más amplia del sistema informático de las prioridades del proceso, pero un sistema operativo en tiempo real se dedica con mayor frecuencia a un conjunto limitado de aplicaciones. Los factores clave en un sistema operativo en tiempo real son latencia mínima de interrupción y latencia mínima de conmutación de subprocesos; Un sistema operativo en tiempo real se valora más por la rapidez o la forma en que puede responder que por la cantidad de trabajo que puede realizar en un período de tiempo determinado.

Esto es algo que muy pocos sistemas operativos realmente hacen, porque para muchas cargas de trabajo es simplemente menos eficiente. Ninguno de los principales sistemas operativos de consumo es ahora (o que yo sepa que haya sido) en tiempo real. Desafortunadamente, significa que a veces las cosas en un entorno que no es en tiempo real tienen que quedarse esperando otras cosas. Esto solo se convierte en un problema cuando algo no cede en un período de tiempo razonable, en general.

Actualmente, los sistemas operativos en tiempo real más conocidos y más ampliamente implementados son:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

Consulte la lista de sistemas operativos en tiempo real para obtener una lista completa.

Los sistemas operativos en tiempo real a menudo se utilizan para sistemas integrados, donde podrían ser responsables de algo como orientación o monitoreo del sistema. La clave para recordar acerca de un sistema de tiempo real (y lo que lo diferencia de un sistema de tiempo no real) es que en un sistema de tiempo real, si una respuesta llega tarde, está mal. Puede ver fácilmente cómo funciona esto al pensar en sumar una serie de cifras en Excel (donde si la operación se retrasa, no hay un impacto real) versus aplicar un freno en un automóvil (donde un retraso podría ser catastrófico).

Básicamente, un RTOS puede garantizar que puede atender una IRQ (solicitud de interrupción) en un período de tiempo específico (generalmente bajo). Los sistemas operativos estándar no tienen esa garantía.

En la mayoría de los sistemas modernos, la mayoría de los dispositivos pueden generar una IRQ. Esto hace que la CPU se detenga (es decir, se interrumpa) de lo que está haciendo y ejecute un programa de servicio de interrupción. La idea es que este programa de servicio haga lo que el dispositivo necesite, es decir, saque los datos del dispositivo y los ingrese en la RAM, le diga al dispositivo qué hacer a continuación, etc.

En x86, dado que solo tiene 1 línea IRQ en la CPU, cuando recibe una interrupción, las interrupciones adicionales se deshabilitan automáticamente (excepto NMI, RESET y SMI) hasta que la CPU reconoce la fuente de interrupción y las vuelve a habilitar. Por lo tanto, los buenos controladores de dispositivos bajo el estándar i386 / amd64 Windows realizarán un procesamiento mínimo en este estado, lo suficiente para que esté bien volver a habilitar las interrupciones, y luego diferir el procesamiento completo de la interrupción hasta más tarde (porque el sistema técnicamente solo puede atender 1 interrupción por CPU núcleo a la vez). No estoy seguro, pero creo que Linux hace lo mismo. No obstante, no existe una garantía sólida del tiempo durante el cual se prestará servicio a la interrupción.

Para la mayoría de los dispositivos de PC, como discos, teclados, NIC, si hay un ligero retraso en el mantenimiento de su IRQ, no ocurrirá nada malo aparte de una pérdida de rendimiento. Esto puede ser un problema mayor para dispositivos como la entrada de audio y video, donde el dispositivo no almacena nada y la PC realmente necesita mantenerse al día con el flujo de datos entrantes.