¿Qué garantías ofrecen los sistemas operativos en tiempo real "blandos"?

Creo que sé lo que es un sistema operativo en tiempo real "duro". Es un sistema operativo con un planificador que proporciona un contrato con el programador de la aplicación. Una aplicación proporciona una fecha límite con cada solicitud de asignación de recursos. Si las solicitudes de la fecha límite son factibles , el planificador garantiza que cada recurso se asignará a la aplicación solicitante antes de la fecha límite. La garantía es suficiente para permitir que un programador de aplicaciones razone sobre las latencias máximas y los rendimientos mínimos de solicitudes específicas.

Todas las definiciones que encuentro de sistemas de tiempo real "blandos" me parecen vacías. Wikipedia dice

la utilidad de un resultado se degrada después de su fecha límite, lo que degrada la calidad del servicio del sistema.

Uhhhh Bueno. Según ese criterio, Windows 95 era un sistema blando en tiempo real y también lo era 3BSD y también Linux. Wikipedia no es una gran fuente, pero los próximos dos éxitos de Google no son mucho mejores. Por ejemplo, http://users.ece.cmu.edu/~koopman/des_s99/real_time/ dice

En un sistema blando en tiempo real, se puede tolerar una operación degradada en una carga máxima que ocurre raramente.

Eso no es un contrato, es una forma elegante de no decir nada.

¿Cuáles son ejemplos de garantías / contratos reales en tiempo real que ofrecen los sistemas operativos reales?

Estoy buscando respuestas de la forma:

En (nombre del sistema operativo) si el programador hace (what-programmer-needs-to-do), entonces el sistema operativo garantiza (what-the-system-garantiza).

Lo has entendido bien, y Wikipedia es tan informativa como puede ser: el tiempo real suave no es una caracterización formal, es un juicio de valor. Otra forma de decir "tiempo real suave" es "Desearía que fuera en tiempo real", o quizás con mayor precisión "debería ser en tiempo real, pero eso es demasiado difícil".

Si realmente desea expresar en forma de garantía, es una garantía del mejor esfuerzo en lugar de una garantía de rendimiento específico.

O, para citar las preguntas frecuentes de Erlang (Erlang es un lenguaje de programación diseñado originalmente para su uso en telefonía):

¿Qué significa tiempo real suave?

Los cínicos dirán "básicamente nada".

(...) Muchos sistemas de telecomunicaciones tienen requisitos menos estrictos [que el tiempo real duro], por ejemplo, podrían requerir una garantía estadística en la línea de "una búsqueda en la base de datos toma menos de 20 ms en el 97% de los casos". Los sistemas de software en tiempo real, como Erlang, le permiten hacer ese tipo de garantía.

Y esto proporciona una definición útil. El tiempo real suave indica un diseño que está optimizado para cada tarea individual que no requiere más de una cierta cantidad de tiempo , en lugar de optimizar el tiempo total dedicado a realizar todas las tareas. Por ejemplo, un sistema de tiempo real flexible tendría como objetivo completar el 99.9% de las solicitudes en 10 ms y procesar 100 solicitudes por segundo, donde un tiempo no real podría tener como objetivo procesar 200 solicitudes por segundo, pero permitir que la solicitud ocasional se bloquee 50 ms o más. Un tiempo real difícil garantizaría una solicitud cada 15 ms sin importar qué.

El tiempo real blando se usa para aplicaciones en las que un plazo vencido significa una degradación del servicio, pero no es crítico para el rendimiento. Multimedia y telefonía son algunos casos de uso típicos. Cada fotograma de audio o video debe procesarse a tiempo, o de lo contrario debe omitirse; pero saltar un marco no es el fin del mundo. Los diseñadores de Erlang tenían objetivos similares en cuanto a confiabilidad en otros asuntos: observaron que era mejor que una central telefónica interrumpiera ocasionalmente una llamada, pero para estar absolutamente seguros de que la central en su conjunto seguiría funcionando en cualquier caso, en lugar de alguna vez arriesgarse a una falla catastrófica al tratar de mantener las conexiones a toda costa.

Por el contrario, algo como controlar un motor requiere que el software nunca pierda una fecha límite. Esto tiene costos: el rendimiento general suele ser más lento y solo se pueden lograr comportamientos relativamente simples. En el otro lado del espectro, una aplicación de cálculo numérico generalmente solo se preocupa por el rendimiento general: lo importante es qué tan rápido se multiplican las matrices 1000x1000, no qué tan rápido se calcula cada columna.

Linux con el conjunto de parches -rt (en tiempo real) proporciona un programador que ofrece una garantía interesante que parece no vacía. (Aunque no tengo claro cómo se puede utilizar la garantía).

La SCHED_FIFOpolítica de programación de Linux-rt funciona de la siguiente manera: el usuario asigna una prioridad a cada proceso. (Los números de prioridad para los procesos "en tiempo real" son 0-99, y los nicevalores tradicionales de Unix -20 a 19 se asignan a las prioridades 100 a 139. (Entonces "0" es la prioridad "más alta" y "139" es la "más baja "prioridad.)

La garantía es que en cualquier momento el planificador programará los Ntrabajos ejecutables de mayor prioridad en una Nmáquina procesadora. Se han hecho grandes esfuerzos para evitar problemas de inversión prioritaria dentro del núcleo. Cuando el proceso se Avuelve ejecutable y tiene una prioridad más alta que algún otro proceso en ejecución B, Ainmediatamente se adelantará B.

Sin embargo, tenga en cuenta que no hay garantías estrictas de tiempo. El tiempo dedicado a realizar la prevención podría, en teoría, ser arbitrariamente largo. Además, parece haber algunas formas en que un trabajo de baja prioridad podría iniciar un montón de E / S de latencia larga. Cuando la E / S completa los controladores de interrupción para el trabajo de baja prioridad, podría interrumpir un trabajo de mayor prioridad, lo cual es, posiblemente, una forma de inversión de prioridad.

Por lo tanto, la garantía limitada proporcionada es: si hay un solo proceso con la máxima prioridad, siempre que sea ejecutable obtendrá todos los recursos de procesador que el sistema operativo puede darle de manera realista. Si tiene un buen límite superior en la cantidad de recursos de procesador consumidos por el proceso de mayor prioridad, puede calcular una estimación razonablemente precisa de los recursos que estarán disponibles para el proceso de segunda mayor prioridad, y así sucesivamente.

Un artículo detallado que describe el planificador en tiempo real de Linux es http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .

Para definir "tiempo real suave", es más fácil compararlo con "tiempo real duro".

Hablando casualmente, la mayoría de las personas tiene implícitamente un modelo mental informal que considera la información o un evento como "en tiempo real"

• si, o en la medida en que, se les manifiesta con un retraso (latencia) que puede estar relacionado con su moneda percibida

• es decir, en un período de tiempo en el que la información o el evento tiene un valor aceptablemente satisfactorio para ellos.

Existen numerosas definiciones diferentes de "tiempo real difícil", pero en ese modelo mental, el término "si" representa el tiempo real difícil. Específicamente, suponiendo que las acciones en tiempo real (como las tareas) tengan plazos de finalización, el valor aceptablemente satisfactorio del evento de que todas las tareas se completen se limita al caso especial de que todas las tareas cumplan con sus plazos.

Los sistemas duros en tiempo real hacen suposiciones muy fuertes de que todo lo relacionado con la aplicación, el sistema y el entorno es estático y se conoce a priori, por ejemplo, qué tareas, que son periódicas, sus tiempos de llegada, sus períodos, sus plazos, que ganaron No tiene conflictos de recursos y, en general, la evolución temporal del sistema. En un sistema de control de vuelo de una aeronave o en un sistema de frenos automotrices y en muchos otros casos, esas suposiciones generalmente pueden cumplirse para que se cumplan todos los plazos.

Este modelo mental es deliberadamente y muy útil, lo suficientemente general como para abarcar tanto el tiempo real duro como el blando: el blando se adapta a la frase "en la medida en que". Por ejemplo, suponga que el evento de finalización de tareas tiene un valor subóptimo pero aceptable si

• no más del 10% de las tareas pierden sus plazos
• o ninguna tarea tiene más del 20% de retraso
• o la tardanza promedio de todas las tareas no es más del 15%
• o la tardanza máxima entre todas las tareas es inferior al 10%

Todos estos son ejemplos comunes de casos blandos en tiempo real en muchas aplicaciones.

Considere la aplicación de una sola tarea de recoger a su hijo después de la escuela. Eso probablemente no tiene una fecha límite real, en cambio, hay algo de valor para usted y su hijo en función de cuándo se produce ese evento. Demasiado temprano desperdicia recursos (como su tiempo) y demasiado tarde tiene un valor negativo porque su hijo podría quedarse solo y potencialmente en peligro (o al menos incomodado).

A diferencia del caso especial de tiempo real estático, el tiempo real suave solo hace las suposiciones mínimas necesarias específicas de la aplicación sobre las tareas y el sistema, y ​​se esperan incertidumbres. Para recoger a su hijo, debe conducir a la escuela, y el tiempo para hacerlo es dinámico, dependiendo del clima, las condiciones del tráfico, etc. Es posible que tenga la tentación de sobreaprovisionar su sistema (es decir, permita que lo que espera sea el en el peor de los casos, el tiempo de conducción), pero nuevamente esto está desperdiciando recursos (su tiempo y ocupando el vehículo familiar, posiblemente negando el uso por otros miembros de la familia).

Ese ejemplo puede no parecer costoso en términos de recursos desperdiciados, pero considere otros ejemplos. Todos los sistemas de combate militar son suaves en tiempo real. Por ejemplo, considere realizar un ataque de aeronave en un vehículo terrestre hostil usando un misil guiado con actualizaciones a medida que el objetivo maniobra. La máxima satisfacción para completar las tareas de actualización del curso se logra mediante un ataque destructivo directo en el objetivo. Pero un intento de sobreaprovisionar recursos para asegurarse de este resultado suele ser demasiado costoso e incluso puede ser imposible. En este caso, puede estar menos satisfecho pero suficiente si el misil golpea lo suficientemente cerca del objetivo como para desactivarlo.

Obviamente, los escenarios de combate tienen una gran cantidad de posibles incertidumbres dinámicas que la gestión de recursos debe tener en cuenta. Los sistemas blandos en tiempo real también son muy comunes en muchos sistemas civiles, como la automatización industrial, aunque obviamente los militares son los más peligrosos y urgentes para lograr un valor aceptablemente satisfactorio.

La piedra angular de los sistemas en tiempo real es la "previsibilidad". El caso difícil en tiempo real está interesado en un solo caso especial de previsibilidad, es decir, que todas las tareas cumplan con sus plazos y que ese evento logre el máximo valor posible. Ese caso especial se llama "determinista".

Hay un espectro de previsibilidad; La mayoría de los sistemas en tiempo real (es decir, los blandos) tienen una predictibilidad no determinista, por ejemplo, de los tiempos de finalización de las tareas y, por lo tanto, de los valores obtenidos de esos eventos. En general, la previsibilidad y, por lo tanto, el valor, se pueden hacer tan cerca del punto final determinista como sea necesario, pero a un precio que puede ser físicamente imposible o excesivamente costoso (como en el combate o tal vez incluso al recoger a su hijo de la escuela).

El tiempo real suave requiere una elección específica de la aplicación de un modelo de probabilidad (no el modelo frecuente de frecuentista) y, por lo tanto, un modelo de previsibilidad para razonar sobre las latencias de eventos y los valores resultantes.

Volviendo a la lista anterior de eventos que proporcionan un valor aceptable, ahora podemos agregar casos no deterministas, como

• la probabilidad de que ninguna tarea pierda su fecha límite en más del 5% es mayor que 0.87.

En una aplicación de defensa antimisiles, dado que en combate la ofensiva siempre tiene la ventaja sobre la defensa, ¿cuál de estos dos escenarios de computación en tiempo real preferiría:

• Debido a que la destrucción perfecta de todos los misiles hostiles es muy improbable o imposible, asigne sus recursos defensivos para maximizar la probabilidad de que tantos de los misiles hostiles más amenazantes (por ejemplo, basados ​​en sus objetivos) sean interceptados con éxito (la intercepción cercana cuenta porque puede mover el misil hostil fuera de curso);

• se quejan de que este no es un problema informático en tiempo real porque es dinámico en lugar de estático, y los conceptos y técnicas tradicionales en tiempo real no se aplican, por lo que no está interesado en realizar actividades de I + D en tiempo real flexible.

A pesar de los diversos malentendidos sobre el tiempo real flexible en la comunidad informática en tiempo real (pero no en otros campos no informáticos), el tiempo real flexible es muy general y poderoso, y potencialmente muy complejo en comparación con el tiempo real difícil.

Para responder directamente a la pregunta de OP:

• un sistema duro en tiempo real puede proporcionar garantías deterministas: lo más común es que todas las tareas cumplan con sus plazos, la interrupción o el tiempo de respuesta de la llamada del sistema siempre será menor que x, etc. todo lo que importa es estático y se conoce a priori (en general, tales garantías para sistemas de tiempo real difíciles son un problema de investigación abierto, excepto en casos bastante simples)

• un sistema blando en tiempo real no ofrece garantías deterministas, está destinado a proporcionar la mejor oportunidad probabilística analíticamente especificada posible y la previsibilidad de la oportunidad que sea factible en las circunstancias dinámicas actuales, de acuerdo con criterios específicos de la aplicación. Obviamente, el tiempo real difícil es un caso especial simple de tiempo real suave. Obviamente, las garantías analíticas no deterministas analíticas en tiempo real pueden ser muy complejas, pero son obligatorias en los casos en tiempo real más comunes (incluidos los más peligrosos para la seguridad, como el combate), ya que la mayoría de los casos son dinámicos y no estáticos.

Tengo una discusión detallada mucho más precisa de tiempo real, tiempo real duro, tiempo real blando, previsibilidad, determinismo y temas relacionados en mi sitio web real-time.org .