¿Por qué los RTOS se consideran deterministas?

No es cierto que las tareas en un RTOS sean automáticamente deterministas, pero es posible poner restricciones mucho más estrictas sobre cuándo y con qué frecuencia se ejecutan las tareas. Un RTOS generalmente proporcionará prioridades difíciles para las tareas; en cualquier momento se ejecuta la tarea lista con la prioridad más alta. El autor del código también tiene control total sobre el conjunto de tareas que se ejecutan; razonablemente puede esperar que no haya tareas en segundo plano de alta prioridad que puedan interrumpir su código para, por ejemplo, intercambiar datos en el disco, a menos que los haya escrito.

Además de esto, algunos RTOS proporcionan la multitarea cooperativa. A diferencia de la multitarea preventiva, con la multitarea cooperativa, una tarea continuará ejecutándose hasta que ceda voluntariamente el control de la CPU.

  

En lo que respecta a los RTOS (en un sistema integrado), cuando escribimos un   Aplicación de multiproceso, creo que lo mismo ocurre dependiendo   en cuántos subprocesos se ejecutan simultáneamente.

NOPE!

Si eso sucede, entonces no es un SO EN TIEMPO REAL (RTOS).

La respuesta corta es que la definición de un RTOS no tiene nada que ver con la multitarea o la prioridad. Es simplemente que todas las tareas tienen garantías de temporización .

El resto de lo que considera que son características de un RTOS (priorización, finalización de tareas, etc.) son simplemente consecuencias (o características) de la construcción de un sistema donde las tareas deben terminar dentro del intervalo de tiempo especificado .

La multitarea en un RTOS es conceptualmente más simple que en un SO de tiempo suave, ya que muchos de los casos complicados no están permitidos.

Un RTOS generalmente no garantiza el rendimiento , sino que le permite garantizar latencia .

Esto generalmente se logra mediante un sistema de prioridad, como aquí en FreeRTOS:

  

El programador de FreeRTOS garantiza que a las tareas en estado Preparado o En ejecución siempre se le dará tiempo de procesador (CPU) en lugar de las tareas de menor prioridad que también están en estado preparado. En otras palabras, la tarea colocada en el estado En ejecución siempre es la tarea de mayor prioridad que se puede ejecutar.

Supongamos que tiene una tarea de prioridad 1 que toma 10ms para manejar un evento, una tarea de prioridad 2 que toma 100ms para manejar un evento diferente, y una tarea de prioridad 3 de fondo. Si espera obtener un evento de prioridad 1 no más de cada segundo, puede decir que el caso más desfavorable para manejar un evento de prioridad 2 es de 10 ms + 100 ms. La tarea de la prioridad 3 puede ser ralentizada arbitrariamente por los eventos, pero no le importa, porque es de baja prioridad.

Prefiero que esto sea un comentario pero toma demasiados caracteres. De todos modos, a juzgar por las preguntas en las respuestas de tus comentarios, parece que te estás perdiendo el punto de que simplemente no puedes decir que mi hilo tarda tanto en ejecutarse y espera que funcione mágicamente junto con otros hilos, todo gracias al sistema operativo. Tienes que diseñar tus hilos y analizarlos para el peor desempeño. Si el peor de los casos no cumple con sus requisitos, necesita rediseñar sus hilos.

Entonces, en lugar de simplemente decir que el hilo 1 tarda 10 ms en completarse y el hilo 2 tarda 20 ms, también debe decir que el hilo 1 debe ejecutarse cada 15 ms. El hilo 2 debe ejecutarse cada 40 ms. El subproceso 3 debe ejecutarse cada 500 ms, el subproceso N debe ejecutarse cada 1500 ms. Luego, asigna tiempo para la duración de cada subproceso en el peor de los casos. Pones todo eso junto, identificas los peores escenarios posibles y luego tienes que asegurarte de que cada hilo cumpla con sus requisitos de tiempo. Este análisis también es donde usted identifica si algunos subprocesos deben tener una prioridad más alta que otros para cumplir con sus requisitos de tiempo.

Por ejemplo, el subproceso 5 que se está ejecutando se interrumpe por el subproceso 4 que se interrumpe por el subproceso 3 que se interrumpe por el subprocesoN podría ser el peor de los casos. Coloca todo esto en una línea de tiempo y verifica que incluso en este peor de los casos, cada hilo cumple con sus requisitos de tiempo. Puede asegurarse de que los subprocesos completen este peor escenario de manera determinista utilizando el planificador y las prioridades en un sistema operativo en tiempo real. Ese determinismo es lo que hace que un sistema operativo en tiempo real.

Si hace que los subprocesos tengan la misma prioridad, habrá perdido parte de ese determinismo (si no todo) porque el programador puede elegir libremente el subproceso que quiera ejecutar a continuación.

En un sistema operativo como Windows, no solo no puede especificar cuándo se ejecutará cada subproceso, sino que tampoco puede garantizar que su aplicación se ejecutará en cualquier momento. El sistema operativo podría detener su aplicación y ejecutar algún servicio en segundo plano cuando lo desee. En otras palabras, no hay determinismo. Por lo tanto, Windows no es un sistema operativo en tiempo real. Aunque, si sus requisitos de tiempo son grandes, como (el hilo 1 se ejecuta cada 10 segundos, el hilo 2 se ejecuta cada 15 segundos), entonces esencialmente puede tratar a Windows como un sistema operativo en tiempo real siempre que tenga en cuenta la pendiente y aproximadamente cada 10 o 15 segundos. (dar o tomar unos cientos de milisegundos y una ventana perdida ocasional) es suficiente.

Aunque otras respuestas han declarado que en el "mundo real" su escenario no es posible, para poder responder a su pregunta, tenemos que construir un sistema hipotético .

Nuestro sistema consiste en un arma que dispara bolas a una velocidad constante, dos cajas que "atrapan" las bolas y avanzan un paso con cada bola atrapada. La pistola se puede cambiar para disparar en una de las cajas, pero pierde una bola cada vez que se cambia. La primera caja necesitará 1000 pasos (bolas) para llegar a su final y la caja 2 necesitará 2000.

Escenario 1 (tareas una tras otra):
- la pistola dispara 1000 bolas en el cuadro 1, cambia (cuesta 1 bola) y dispara 2000 bolas en el cuadro 2, para un total de 3001 bolas .

Escenario 2 (tareas "simultáneas"):
- la pistola dispara 5 bolas en una casilla, cambia y dispara 5 bolas en la otra casilla para dar la apariencia de simultaneidad . El costo de cambio es (1000/5 x 2 =) 400 bolas. Entonces, después de lanzar 2400 bolas, la caja 1 llegará a su fin y la caja 2 necesitará 1000 bolas adicionales para llegar a su final, para un total de 3400 bolas .

Aplicando estos resultados a su escenario, la Tarea 1 y la primera mitad de la Tarea 2 se completarían después de 24 ms, y la segunda mitad de la Tarea 2 se completaría en 10 ms adicionales para un total de 34 ms. Esto muestra claramente que el tiempo requerido para completar las tareas aumenta debido a el tiempo perdido en cambiar entre tareas . Estos resultados también son equivalentes a la Tarea 1 que toma 12ms y la Tarea 2 que toma 22ms, para completar.