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

Question

En un pc (un SO por supuesto) cualquier programa en C se vuelve indeterminista en términos de tiempo. Por ejemplo, un bucle tarda entre 1,2 y 1,3 segundos dependiendo de "lo rápido que esté moviendo otra ventana". Es porque el SO hace que los procesos (o hilos) compartan la capacidad de procesamiento.

En cuanto a los RTOS (en un sistema embebido), cuando escribimos una aplicación multihilo, creo que ocurre lo mismo dependiendo de cuántos hilos se ejecuten de forma concurrente.

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 falta algo muy fundamental?

EDITAR : Voy a poner un ejemplo. Tenemos la tarea1(tarda 10 ms) y la tarea2(tarda 20 ms). Han empezado al mismo tiempo en dos hilos separados. Mi afirmación (también preocupación, no estoy seguro) es que la tarea1 tarda más de 10ms, porque comparte la potencia de procesamiento con la tarea2.

Answer 1

En cuanto a los RTOS (en un sistema embebido), cuando escribimos una aplicación multithreading, creo que ocurre lo mismo dependiendo de del número de hilos que se ejecuten simultáneamente.

¡NO!

Si eso ocurre, entonces no es un sistema operativo 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. Se trata simplemente de que todas las tareas tengan garantías de tiempo .

El resto de lo que consideras características de un RTOS (priorización, finalización de tareas, etc.) no son más que consecuencias (o características) de construir un sistema donde las tareas debe terminar dentro del intervalo de tiempo especificado.

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

Answer 2

Un RTOS no suele garantizar rendimiento En cambio, le permite garantizar latencia .

Esto se suele conseguir mediante un sistema de prioridades, como por ejemplo aquí en FreeRTOS:

El planificador de FreeRTOS asegura que las tareas en estado Listo o en Ejecución siempre recibirán tiempo de procesador (CPU) con preferencia a las tareas de menor prioridad que también están en estado Listo. En otras palabras, la tarea colocada en el estado Running es siempre la tarea de mayor prioridad que puede ejecutarse.

Suponga que tiene una tarea de prioridad 1 que tarda 10ms en gestionar un evento, una tarea de prioridad 2 que tarda 100ms en gestionar otro evento y una tarea de prioridad 3 en segundo plano. Si esperas recibir un evento de prioridad 1 como máximo cada segundo, puedes decir que el El peor de los casos para gestionar un evento de prioridad 2 es de 10ms+100ms. La tarea de prioridad 3 puede ser arbitrariamente ralentizada por los eventos, pero no le importa - porque es de baja prioridad.

Answer 3

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 suele establecer prioridades estrictas para las tareas; en cualquier momento se ejecuta la tarea lista con la mayor prioridad. El autor del código también tiene un control total sobre el conjunto de tareas que se ejecutan; puedes esperar razonablemente que no haya tareas de fondo de alta prioridad que puedan interrumpir tu código para, por ejemplo, intercambiar datos al disco, a menos que las hayas escrito tú.

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

Answer 4

Preferiría que esto fuera un comentario, pero se necesitan demasiados caracteres. De todos modos, ozgur, a juzgar por las preguntas en las respuestas a tus comentarios parece que no entiendes que no puedes simplemente decir que mi hilo tarda tanto en ejecutarse y esperar que mágicamente funcione en conjunto con otros hilos todo gracias al SO. Tienes que diseñar tus hilos y analizarlos para el peor caso de rendimiento. Si el peor caso no cumple con tus requisitos, entonces tienes que rediseñar tus hilos.

Así que en lugar de decir simplemente que el hilo 1 tarda 10 ms en completarse y el hilo 2 tarda 20 ms, tienes que decir también que el hilo 1 debe ejecutarse cada 15 ms. el hilo 2 debe ejecutarse cada 40 ms. el hilo 3 debe ejecutarse cada 500 ms, el hiloN debe ejecutarse cada 1500 ms. Luego asignas el tiempo que puede tardar cada hilo 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 cumple con sus requisitos de tiempo. En este análisis también se identifica si algunos subprocesos deben ser más prioritarios que otros para cumplir con sus requisitos de tiempo.

Por ejemplo, si el hilo 5 se está ejecutando y es interrumpido por el hilo 4, que a su vez es interrumpido por el hilo 3, que a su vez es interrumpido por el hilo N, podría ser el peor de los casos. Se pone todo esto en una línea de tiempo y se verifica que incluso en este peor escenario cada hilo cumple con sus requisitos de tiempo. Puedes asegurarte de que los hilos completen este peor escenario de forma determinista utilizando el planificador y las prioridades de un sistema operativo en tiempo real. Ese determinismo es lo que hace que un sistema operativo en tiempo real.

Si haces que los hilos tengan la misma prioridad, habrás perdido parte (si no todo) de ese determinismo porque el planificador puede ser libre de elegir el hilo que quiera ejecutar a continuación.

En un sistema operativo como Windows, no sólo no se puede especificar cuándo se ejecutará cada hilo, sino que ni siquiera se puede garantizar que la aplicación vaya a ejecutarse en cualquier momento. El sistema operativo podría detener tu 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 hilo1 se ejecuta cada 10 segundos, el hilo2 se ejecuta cada 15 segundos), entonces usted puede tratar esencialmente a Windows como un sistema operativo en tiempo real, siempre y cuando tenga en cuenta la pendiente y aproximadamente cada 10 o 15 segundos (más o menos unos cientos de milisegundos y una ventana ocasional perdida) es suficiente.

Answer 5

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

Nuestro sistema consiste en una pistola que dispara bolas a un ritmo constante, dos cajas que "atrapan" las bolas y avanzan un paso con cada bola atrapada. La pistola 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):
- dispara 1000 bolas a la casilla 1, cambia (cuesta 1 bola) y dispara 2000 bolas a la casilla 2, para un total de 3001 bolas .

Escenario 2 (tareas "simultáneas"):
- pistola dispara 5 bolas a una caja, cambia y dispara 5 bolas a la otra caja para dar el apariencia de simultaneidad . El coste de cambio es (1000/5 x 2 =) 400 bolas. Por lo tanto, después de disparar 2.400 bolas, la caja 1 llegará a su final y la caja 2 necesitará 1.000 bolas más 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 10ms adicionales para un total de 34ms. Esto demuestra claramente que el tiempo requerido para completar las tareas aumenta debido a el tiempo perdido en cambio de tareas . Estos resultados también son equivalente a la Tarea 1 que tarda 12ms y a la Tarea 2 que tarda 22ms, en completarse.