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

19

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í?

Chad Harrison
fuente
44
QNX es en tiempo real, por ejemplo.
nuevo123456

Respuestas:

21

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.

Shinrai
fuente
66
Los sistemas operativos en tiempo real normalmente se usan en roles muy dedicados, como sistemas de control extremadamente precisos en los que una decisión / cálculo / etc. debe completarse en un marco de tiempo muy exigente.
Lamar B
¿Hay algún ejemplo de RTOS? Actualización de la pregunta a este respecto.
Chad Harrison
Lo que @ ta.speot.is dice: hay algunos en el artículo que ya están vinculados. Sin embargo, editaré algunos.
Shinrai
No llegué al final de la página Wiki ... Perdón por eso: /
Chad Harrison
19

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).

Scott C Wilson
fuente
10

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.

LawrenceC
fuente
¿Podría explicar qué quiere decir con "x86 tiene solo 1 línea IRQ"? La última vez que cableé una computadora 80186 (es cierto que hace décadas), parece recordar que el 8259 PIC tiene 8 canales, y la PC nominal en ese momento tenía una segunda en cascada, para un total de 15 canales, sin incluir el NMI?
Glenn Slayden
Necesita el PIC precisamente porque el x86 solo tiene una línea IRQ. Pero si las interrupciones x86 están desactivadas, el PIC solo puede esperar hasta que la CPU los vuelva a habilitar, y el IIRC lo hace. IIRC otras CPU como la 68000 tenían 3 pines de interrupción y esperaban un nivel de prioridad codificado 0-7 directamente en la CPU. Aunque ahora que realmente lo considero, tal vez el 68000 desactive todas las interrupciones al recibir cualquier IRQ también. Nunca programé el 68000.
LawrenceC
Ah sí, ahora lo recuerdo. Y IIRC, se suponía que el aspecto de "prioridad" del diseño del chip 8259, al permitir el manejo anidado de IRQ, alentaba al sistema operativo a deshabilitar las interrupciones lo menos posible o nada, pero las líneas de interrupción de la PC se asignaron al azar, derrotando eso ¿Acercarse? De cualquier manera, seguramente llamar a cualquier cantidad sustancial de código bajo CLI ... STI nunca fue la intención.
Glenn Slayden