¿Cómo es que los RTOS se consideran deterministas?

En una PC (un sistema operativo, por supuesto) cualquier programa C se vuelve indeterminista en términos de tiempo. Por ejemplo, un ciclo toma entre 1.2 y 1.3 segundos dependiendo de "qué tan rápido estoy moviendo otra ventana". Esto se debe a que el sistema operativo hace que los procesos (o subprocesos) compartan la potencia de procesamiento.

En lo que respecta a los RTOS (en un sistema integrado), cuando escribimos una aplicación de subprocesos múltiples, creo que sucede lo mismo dependiendo de cuántos subprocesos se ejecutan simultáneamente.

No tengo instrumentos para probar esto con precisión en un sistema integrado. Por lo tanto, quería preguntar. ¿Es razonable mi preocupación o me estoy perdiendo algo muy fundamental?

EDITAR : daré un ejemplo. tenemos task1 (toma 10 ms) y task2 (toma 20 ms). Comenzaron al mismo tiempo en dos hilos separados. Mi reclamo (también preocupación, no estoy seguro) es que la tarea1 tarda más de 10 ms, porque comparten el poder de procesamiento con la tarea2.

No es cierto que las tareas en un RTOS sean automáticamente deterministas, pero es posible establecer 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 preparada con la máxima prioridad. El autor del código también tiene control total sobre qué conjunto de tareas se están ejecutando; puede esperar razonablemente 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, algunas RTOS proporcionan una multitarea cooperativa. En contraste con la multitarea preventiva, con la multitarea cooperativa una tarea continuará ejecutándose hasta que voluntariamente abandone el control de la CPU.

En lo que respecta a los RTOS (en un sistema integrado), cuando escribimos una aplicación de subprocesos múltiples, creo que sucede lo mismo dependiendo de cuántos subprocesos se ejecutan simultáneamente.

NO!

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

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

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

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

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

El planificador FreeRTOS garantiza que las tareas en estado Listo o En ejecución siempre tendrán tiempo de procesador (CPU) en lugar de tareas de menor prioridad que también estén en estado listo. En otras palabras, la tarea colocada en el estado Ejecutando es siempre la tarea de mayor prioridad que se puede ejecutar.

Suponga que tiene una tarea de prioridad 1 que requiere 10 ms para manejar un evento, una tarea de prioridad 2 que requiere 100 ms para manejar un evento diferente y una tarea de prioridad 3 en segundo plano. Si espera obtener un evento de prioridad 1 no más de cada segundo, puede decir que el peor de los casos para manejar un evento de prioridad 2 es 10 ms + 100 ms. La tarea de prioridad 3 puede ralentizarse arbitrariamente por eventos, pero no le importa, porque es de baja prioridad.

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

Entonces, en lugar de simplemente decir que el subproceso 1 tarda 10 ms en completarse y el subproceso 2 toma 20 ms, también debe decir que el subproceso 1 debe ejecutarse cada 15 ms. el hilo 2 debe ejecutarse cada 40 ms. el hilo 3 debe ejecutarse cada 500 ms, el hilo N debe ejecutarse cada 1500 ms. Luego, asigna el tiempo que tarda cada subproceso en completarse 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 identifica si algunos subprocesos deben tener mayor prioridad que otros para cumplir con sus requisitos de tiempo.

Por ejemplo, el subproceso 5 en ejecución se interrumpe por el subproceso 4 que se interrumpe por el subproceso 3 que se interrumpe por el subproceso N podría ser el peor de los casos. Pones todo esto en una línea de tiempo y verificas que incluso en el 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 lo convierte en un sistema operativo en tiempo real.

Si hace que los hilos tengan la misma prioridad, ha perdido parte (si no todo) de ese determinismo porque el planificador puede elegir libremente el hilo que quiera ejecutar a continuación.

En un sistema operativo como Windows, no solo no puede especificar cuándo se ejecutará cada subproceso, ni siquiera 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 (thread1 se ejecuta cada 10 segundos, thread2 se ejecuta cada 15 segundos), esencialmente puede tratar a Windows como un sistema operativo en tiempo real, siempre que tenga en cuenta la falla y aproximadamente cada 10 o 15 segundos (más o menos unos cientos de milisegundos y una ventana perdida ocasional) es lo suficientemente bueno.

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 una pistola que dispara bolas a una velocidad constante, dos cajas que "atrapan" las bolas y avanzan un paso con cada bola atrapada. El arma puede cambiarse para disparar a 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 la casilla 1, cambia (cuesta 1 bola) y dispara 2000 bolas en la casilla 2, para un total de 3001 bolas .

Escenario 2 (tareas "simultáneas"):
- la pistola dispara 5 bolas en una caja, cambia y dispara 5 bolas en la otra caja para dar la apariencia de simultaneidad . El costo de cambio es (1000/5 x 2 =) 400 bolas. Entonces, después de disparar 2400 bolas, la caja 1 llegará a su final 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 al tiempo perdido en el cambio entre tareas . Estos resultados también son equivalentes a la Tarea 1 que toma 12 ms y la Tarea 2 que toma 22 ms, para completar.