Documentos de Académico
Documentos de Profesional
Documentos de Cultura
(Real-Time Systems)
Definiciones
Un sistema de tiempo real (STR o real-time system o RTS) es aquel cuyo correcto funcionamiento depende de que las salidas lleguen a tiempo
O sea que debe estar acotado el tiempo entre cada evento y la respuesta que provoca
No necesariamente tiene que ser breve, pero s acotado
Deadline (relativo), o sea, tiempo mximo aceptable para la respuesta Tiempo de procesamiento
Llega un estmulo
Se empieza a atender
Se termina de atender
Deadline t (absoluto)
2 de 32
Requerimientos de un STR
Un STR est definido por una lista de:
Los eventos externos que puede atender La respuesta lgica (o sea, salida) que debe producir cada evento Los requerimientos de temporizacin de esas respuestas
O sea, sus deadlines relativos
Para simplificar, los STR suaves frecuentemente se disean como si fueran STR duros
O sea, como si sus deadlines fueran estrictos
Ejemplo
5 de 32
Requerimientos de temporizacin
A veces se recurre a mtodos formales para verificar el cumplimiento de los requerimientos de temporizacin, pero es ms frecuente testearlos mediante simulaciones y pruebas en prototipos
Problemas:
Ante cambios menores, hay que volver a testear todo Se aliviana automatizando esas pruebas, si se puede El testeo nunca da garantas al 100%
Es muy valioso usar tcnicas de programacin que nos den cierta seguridad sobre el cumplimiento que los requisitos de temporizacin, para no depender mucho de la verificacin.
Para cumplir esos requerimientos, a veces hay que evitar usar tcnicas que implican tiempos largos y/o poco predecibles
Ejemplos:
Programacin orientada a objetos Garbage collecting (como el de Java) malloc() y free() comunes de C
6 de 32
Diseo de un STR
Como ven, un STR es un sistema reactivo con requisitos (estrictos o no) en cuanto a sus tiempos de respuesta Esos requisitos se consideran desde la etapa de elaboracin de requerimientos y durante todo el proceso de diseo
a diferencia del diseo de un software transaccional comn, en los cuales lo tpico, como mucho, es chequear la velocidad una vez programadas sus unidades, para decidir si optimizarlas o no
Recordar que reactivo significa que responde a eventos externos, que no necesariamente tienen orden o periodicidad
7 de 32
Diseo de un STR
Un STR puede disearse directamente en Assembly sin libreras ni nada
Ejemplo:
Un ciclo infinito donde se encuestan, una tras otra, las entradas correspondientes a los eventos externos, y se las atiende rpidamente El evento externo que no pueda esperar, que vaya colgado de una interrupcin, etc.
Sin embargo, en sistemas medianamente complejos, suele ser difcil asegurar los requisitos de temporizacin si se emplea ese enfoque
Recordar que valoramos las tcnicas de programacin que dan cierta seguridad sobre el cumplimiento que esos requisitos
Por eso, a veces es conveniente utilizar un sistema operativo de tiempo real (real-time operating system o RTOS)
8 de 32
RTOS
Un sistema operativo de tiempo real (RTOS) es un software de base que simplifica el diseo de software con requerimientos de tiempo real
El RTOS gestiona la ejecucin de esas tareas y provee servicios que la aplicacin utiliza para acceder, con tiempos razonables y predecibles, al hardware
Ej., para manejar memoria y entrada/salida
9 de 32
O sea, un ncleo del sistema operativo, que est siempre en memoria gestionando la ejecucin de las tareas y sirviendo de puente con el hardware Sin embargo, algunos RTOS son solo libreras, o sea, kernel-less
Diferencias:
En los RTOS, la gestin del multitasking est especialmente diseada para atender requisitos de tiempo real No suelen incluir interfaces al usuario grficas, solo a veces incluyen gestin de archivos en disco, etc. Son programas mucho ms livianos Los hay especiales para sistemas que requieren una confiabilidad excepcional
O sea, sistemas de misin crtica o seguridad crtica
10 de 32
QNX
De QNX, subsidiaria de Research in Motion (los del Blackberry) desde mayo de 2010 Smil Unix, ofrece funcionalidad parecida al VxWorks En 2007 fue abierto el cdigo de su ncleo Basado en Linux
RTLinux
FreeRTOS
11 de 32
12 de 32
Componentes de un RTOS
Programador (scheduler)
Establece el orden de ejecucin de los procesos
Ejecutor (dispatcher)
Gestiona el inicio y la finalizacin de cada tramo de procesamiento, cambiando el contexto (stack, memoria, registros, etc.) para pasar de una tarea a otra
Administrador de memoria
En arquitecturas con kernel, ste suele contener al scheduler, al dispatcher y al administrador de memoria
Servicios
Drivers para acceder al hardware Administrador de interrupciones de hardware o software Etc.
Multitasking
Como dijimos antes, el procesador (usualmente) se reparte entre distintas tareas, creando la ilusin del procesamiento concurrente
Tarea C
Tarea B
Tarea A
Tarea B
Tarea A
1. En el ejemplo, el procesador primero est ejecutando la tarea A. 2. Esta le hace un pedido a la B, as que se transfiere el control del procesador a sta ltima, hasta que requiere la respuesta de un perifrico. 3. (Contina)
15 de 32
Como dijimos antes, el procesador (usualmente) se reparte entre distintas tareas, creando la ilusin del procesamiento concurrente
Tarea C
Multitasking
Tarea B
Tarea A
Tarea B
Tarea A
3. Mientras espera, se le da el control a la tarea C, hasta que sta termina lo que haca y llama a una funcin especial del scheduler, mediante la cual queda en espera mientras no tenga nada que hacer 4. El procesador vuelve con B, dado que la respuesta que esperaba ya lleg. 5. B termina de realizar el pedido de A, as que se le devuelve el control a sta. 16 de 32
Multitasking
Como dijimos antes, el procesador (usualmente) se reparte entre distintas tareas, creando la ilusin del procesamiento concurrente
Tarea C
Tarea B
Tarea A
Tarea B
Tarea A
Programacin (Scheduling)
Quin decidi que A est seguido de B, si poda haber arrancado C ah? O que se haya ejecutado C en el intervalo, en lugar de alguna otra tarea (D, E, etc.) que estuviera lista?
Lo decidi el scheduler del RTOS, en base al algoritmo de programacin (o scheduling algorithm) definido al disear el sistema
Esas decisiones (o sea, la programacin de tareas, o scheduling) tienen un rol crucial en el cumplimiento de los requisitos de temporizacin
Ej., deben tener prioridad las tareas con deadline inminente En aquellos momentos donde se pas a procesar otra tarea, se ocup de
1. Tomar una de una lista (ordenada) de tareas listas que fue preparada por el scheduler 2. Cambiar el contexto (o sea, hacer el context switch) 3. Transferir el control del procesador a la instruccin que corresponde, de la nueva tarea
18 de 32
Preemptive Scheduling
En el ejemplo anterior, el cambio de una tarea a otra se da slo cuando el proceso en ejecucin solicita un servicio del sistema
Puede ser porque realmente requiere el servicio (ej., un acceso a un perifrico) o porque est programado que ah debe liberar al procesador (como lo haba hecho C)
Pero la mayora de los sistemas operativos pueden tambin interrumpir la tarea que se est ejecutando, cuando pasa demasiado tiempo sin devolver el procesador
A esto se le dice programacin preventiva (o preemptive scheduling o preemptive multitasking)
Para realizarlo, se necesita algn timer o reloj de tiempo real (RTC) Es preventiva porque no se depende de que las tareas devuelvan el control a tiempo
A la programacin de tareas que no hace estas interrupciones, se les dice programacin cooperativa (o cooperative scheduling)
19 de 32
Cuando lo hace, vuelve a elaborar la lista de tareas listas (esa que lee el dispatcher), dndoles un orden que, idealmente, depende del tiempo remanente hasta el deadline de cada una Existen varios tipos de algoritmos para la elaboracin de este orden
Esos son los algoritmos de scheduling que mencionamos antes
20 de 32
Algoritmos de scheduling
Se ejecuta siempre el proceso de mayor prioridad, entre los que estn listos
Si aparece uno de mayor prioridad, se interrumpe la ejecucin y se le da el control
Se depende de que las tareas de alta prioridad devuelvan el control (simil scheduling cooperativo) Problema: por ms que lo hagan, puede pasar mucho tiempo hasta que se ejecutan los de baja prioridad
si es que siempre hay una de mayor prioridad que est lista A esa situacin se le llama starvation
21 de 32
Algoritmos de scheduling
22 de 32
Mejores algoritmos
Rate-monotonic scheduling
Algoritmos de scheduling
Es un equema basado en prioridades (fijas), en donde la prioridad de una tarea es inversamente proporcional a su deadline relativo
23 de 32
Que la primera sealice que le acaba de mandar un dato a la otra, para que sta pase del estado bloqueada al estado lista, y pueda leerlo
A esto se le llama sincronizacin de procesos
24 de 32
Memoria compartida
Se pueden definir partes de memoria accesibles por los dos procesos que necesitan comunicarse Los datos pueden ser comunicados escribindolos all
Pero cuidado, que un proceso no interprete un dato a medio escribir, como si estuviera escrito del todo Es decir que se necesita algo como un handshaking. Por ejemplo, una seal de sincronizacin
Son colecciones ordenadas de (estructuras de) datos Se puede ingresar un elemento al final, o sacar uno del principio Es una estructura de nivel ms alto que la memoria compartida, que incluye sincronizacin 25 de 32
O sea que es una estructura first-in, first-out (FIFO)
Sin embargo, el semforo implica que hay un tipo de sincronizacin entre las dos tareas
Si una est ejecutando su regin crtica y la otra quiere entrar a la suya, va a tener que esperar a que la primera termine
26 de 32
Sirve, por ejemplo, para evitar que el proceso B est leyendo, de una memoria compartida, algo que A est a medio escribir Tambin sirve para compartir recursos
O sea, podran ser N las tareas compitiendo por el token Y podran haber M tokens, para que puedan estar, en sus regiones crticas, no ms de M de ellas
27 de 32
signal()
Para devolver el token Son las transiciones de abajo Tambin se la llama V()
Tarea(semforo sem) { pasos previos wait(sem) regin crtica signal(sem) pasos posteriores }
Pseudo-cdigo
28 de 32
Con colas:
Productor(cola queue) { while(1) { produce el dato send(queue, dato) } } Consumidor(cola queue) { while(1) { receive(queue, dato) consume el dato } }
29 de 32
Starvation
Inversin de la prioridad
30 de 32
31 de 32
Conclusiones
32 de 32