Introducción al tiempo real en sistemas empotrados

1. Master en Ingeniería de Sistemas Empotrados Introducción al tiempo real en sistemas empotrados Departamento de Arquitectura y Tecnología de Computadores Universidad del País Vasco / Euskal Herriko Unibertsitatea Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

2. Contenido • Introducción • Soporte de interrupciones • Conceptos de sistemas operativos • Planificación en sistemas de tiempo real • Mecanismos de sincronización y comunicación • Planificación de tiempo real con recursos compartidos Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

3. Mecanismos de sincronización y comunicación CONTENIDO • Recursos compartidos. Secciones críticas • Mecanismos de sincronización • Comunicación por paso de mensajes • Inanición e interbloqueo BIBIOGRAFIA • A. Lafuente: Sistemas Operativos II. Apuntes de la asignatura. Edición 2008-09, http://www.sc.ehu.es/acwlaroa/SO2.htm. Capítulo 2. • S. Sánchez Prieto: Sistemas Operativos. Universidad de Alcalá de Henares, Servicio Editorial, 2005. • A. Silberschatz, P. Galvin, G. Gagne: Conceptos de Sistemas Operativos(7a edición). Willey, 2006. • A.S. Tanenbaum: Modern Operating Systems (3rd edition). Prentice-Hall, 2008. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

4. Recursos compartidos • En un sistema operativo (o de tiempo real) los procesos (tareas) compiten por el uso a recursos compartidos. • El acceso al recurso se realiza mediante la ejecución de un trozo de código. • Ejemplo: • Recurso compartido: buffer fifo • Código de acceso al buffer: … R <- cuenta; buffer[R] <- elemento; R <- R+1; cuenta <- R; … Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

5. Recursos compartidosAcceso concurrente R <- cuenta; buffer[R] <- elemento; R <- R+1; cuenta <- R; • Ejemplo de ejecución: • Dos procesos, P1 y P2, ejecutan concurrentemente el código de acceso al buffer compartido • Inicialmente, cuenta=7 P1 P2 R=7 R=7 Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

6. Recursos compartidosCondiciones de carrera R <- cuenta; buffer[R] <- elemento; R <- R+1; cuenta <- R; • Condición de carrera • Ambos procesos almacenan su elemento en la misma posición del buffer P1 P2 R=7 R=7 Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

7. Secciones críticas • En el acceso concurrente a recursos compartidos, las condiciones de carrera conducen a comportamientos incorrectos. • ¿Cómo evitar condiciones de carrera? • El trozo de código que controla el acceso a recursos compartidos es una sección crítica de código. • Hay que proporcionar acceso exclusivo a las secciones críticas. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

8. Acceso exclusivo a secciones críticas de código Entrar_SC(SC_buf); R <- cuenta; buffer[R] <- elemento; R <- R+1; cuenta <- R; Dejar_SC(SC_buf); P1 P2 Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

9. Secciones críticasModelo de sección crítica • Protocolo genérico de acceso a una sección crítica: Entrar_SC(la_SC) /* Solicitud de ejecutar la_SC */ /* código de la_SC */ Dejar_SC(la_SC) /* Otro proceso puede ejecutar la_SC */ • Un proceso que va a ejecutar la SC: • Ejecuta Entrar_SC(). Si la SC está ocupada, el proceso espera. • Ejecuta la SC. • Ejecuta Dejar_SC(), permitiendo que entre uno de los procesos en espera. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

10. Secciones críticasPropiedades • El acceso a una sección crítica debe poseer las siguientes propiedades: • Exclusión mutua. No puede haber más de un proceso simultáneamente en la SC. • No interbloqueo. Ningún proceso fuera de la SC puede impedir que otro entre a la SC. • No inanición. Un proceso no puede esperar por tiempo indefinido para entrar a la SC. • Independencia del hardware. No se pueden hacer suposiciones acerca del número de procesadores o de la velocidad relativa de los procesos. • Suposición: las instrucciones del Lenguaje Máquina son atómicas y se ejecutan secuencialmente Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

11. Secciones críticasMecanismos de sincronización • ¿Cómo espera un proceso para acceder a una SC ocupada (paso 1 del protocolo)? • Mecanismos de sincronización: • El proceso ejecuta una espera activa (espera por ocupado). • En sistemas monoprocesador suele utilizarse inhibición de interrupciones. • El proceso se bloquea (espera por bloqueado). Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

12. Mecanismos de sincronizaciónEspera por ocupado • En monoprocesadores: inhibición de interrupciones s= inhibir() /* Entrar_SC() */ /* Sección crítica */ desinhibir(s) /* Dejar_SC() */ Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

13. Mecanismos de sincronizaciónEspera por ocupado • En multiprocesadores: cerrojos de espera activa lock(cerrojo_A) /* Entrar_SC() */ /* Sección crítica */ unlock(cerrojo_A) /* Dejar_SC() */ • Implementación de lock() • Por Sw: muy restrictivo (algoritmo de Decker) o ineficiente (Lamport). • Instrucciones del Lenguaje Máquina que proporcionan consulta y modificación atómica sobre el cerrojo (tipo test_and_set). Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

14. Mecanismos de sincronizaciónEspera por ocupado • Los mecanismos de espera por ocupado dependen del soporte (no cumplen la condición 4): • La inhibición de interrupciones sólo es válida para monoprocesadores. • La espera activa en monoprocesadores depende de la política de planificación: • Con prioridades estáticas y expulsión, si una SC está ocupada por un proceso de prioridad baja, un proceso de prioridad alta que llegue a la SC ejecutaría espera activa indefinidamente e impediría al de prioridad baja liberarla (fenómeno de inversión de prioridad). Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

15. Mecanismos de sincronizaciónEspera por bloqueado • El proceso que accede a una SC ocupada se bloquea. • Implica un cambio de contexto, luego sólo es rentable si la SC es de largo plazo. • El proceso bloqueado no consume CPU. • El proceso que abandona la SC provoca que algún proceso en espera se desbloquee. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

16. Mecanismos de sincronizaciónEspera por bloqueado: semáforos • Un semáforo es una abstracción que implementa espera por bloqueado proporcionando orden FIFO. • Un semáforo lleva asociadas • Una cuenta • Una cola • Primitivas sobre semáforos: • bajar(sem) • Si la cuenta de sem es positiva, se decrementa y el proceso continúa. • Si la cuenta vale 0, el proceso se bloquea en la cola de sem. • subir(sem) • Si la cola de sem no está vacía, se desbloquea al primer proceso de la cola • Si la cola está vacía, se incrementa la cuenta de sem. • Primitiva para la inicialización de la cuenta. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

17. Mecanismos de sincronizaciónEspera por bloqueado: semáforos • La inicialización del semáforo determina su utilización. • Para controlar el acceso a una sección crítica se usa un semáforo inicializado a 1: bajar(sem); /* Sección crítica */ subir(sem); • Si el semáforo se inicializa a n, permite gestionar el uso simultáneo de n recursos. • Si se inicializa a 0, puede utilizarse como evento sobre el que esperar una notificación. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

18. Mecanismos de sincronizaciónEjemplo struct semaf huecos, items; tipo_cerrojo mutex; ini_semaforo(huecos, N); ini_semaforo(items, 0); consumidor() { int elemento; while (1) { bajar(items); lock(mutex); retirar_elemento(&elemento); unlock(mutex); subir(huecos); consumir_elemento(elemento); } } Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

19. Mecanismos de sincronizaciónEjemplo (cont) productor() { int elemento; while (1) { producir_elemento(&elemento); bajar(huecos); lock(mutex); dejar_elemento(elemento); unlock(mutex); subir(items); } } Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

20. Comunicación por paso de mensajes • En la comunicación por paso de mensajes, las propias primitivas incluyen la información a comunicar: enviar (p, mensaje) recibir (p, mensaje) • La sincronización va implícita. • El origen/destino de la comunicación especifica un puerto. • Directa o indirectamente el puerto de comunicación identifica un elemento de de naturaleza FIFO (canal, buzón o mailbox). • Los procesos (productores/consumidores de mensajes) se sincronizan con las condiciones de canal vacío y canal lleno. • La longitud del canal es relevante para la forma de sincronización. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

21. Ejemplo:paso de mensajes en Linux #define MI_FIFO “mi_fifo” int main (int argc, constchar * argv[]) { int pid; char i, a= 'a'; FILE * fp; if (mkfifo(MI_FIFO, 0666)) exit(-1); pid= fork(); if (pid == 0) { if ((fp= fopen(MI_FIFO, "r")) == (FILE *)0) exit(-1); for(i=0; i<5; i++) printf("%d: Recibido (%c)\n", getpid(), getc(fp)); } else { if ((fp= fopen(MI_FIFO, "w")) == (FILE *)0) exit(-1); printf("%d: Soy el padre de %d\n", getpid(), pid); for(i=0; i<5; i++) putc(a+i, fp); } fclose(fp); unlink(MI_FIFO); exit(0); } Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

22. Comunicación por paso de mensajesImplementación struct { tipo_cerrojo mutex; struct semaf huecos; struct semaf items; tipo_buffer buffer[N]; } buzon[N_BUZONES]; /* Inicialmente: */ for (i=0; i<N_BUZONES; i++) { ini_semaforo(buzon[i].huecos, N); ini_semaforo(buzon[i].items, 0); } Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

23. Comunicación por paso de mensajesImplementación void enviar (int i, tipo_mensaje m) { bajar(buzon[i].huecos); lock(buzon[i].mutex); dejar_elemento(buzon[i].buffer, m); unlock(buzon[i].mutex); subir(buzon[i].items); } Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

24. Comunicación por paso de mensajesImplementación void recibir (int i, tipo_mensaje m) { bajar(buzon[i].items); lock(buzon[i].mutex); tomar_elemento(buzon[i].buffer, m); unlock(buzon[i].mutex); subir(buzon[i].huecos); } Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

25. Inanición e interbloqueo • Aún con primitivas de exclusión mutua adecuadas, el acceso a recursos compartidos no está libre de problemas: • Inanición: un proceso espera indefinidamente para entrar a la sección crítica. • Posible escenario: Las primitivas de sincronización utilizan criterios de prioridad para seleccionar el siguiente proceso a entrar en la sección crítica. • Interbloqueo: es una situación de reciprocidad en el acceso a recursos múltiples. • Un conjunto de procesos está interbloqueado cuando cada proceso está esperando por un recurso que está siendo usado por otro proceso del conjunto. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

26. Inanición e interbloqueoEscenario para un interbloqueo • El siguiente código puede conducir a un interbloqueo entre P1 y P2 Proceso P1Proceso P2 ... ... bajar(R1); bajar(R2); ... ... bajar(R2); bajar(R1); ... ... subir(R2); subir(R1); subir(R1); subir(R2); ... ... SC R1 SC R2 SC R2 SC R1 Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

27. p3 solicita r1: el ciclo en el grafo denota un interbloqueo. Inanición e interbloqueoModelo del interbloqueo • Grafo de asignación de recursos a procesos Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

28. Inanición e interbloqueoCondiciones para el interbloqueo • Un interbloqueo sólo puede producirse si en el sistema se cumplen todas y cada una de las condiciones siguientes: • Exclusión mutua. En todo momento, cada recurso, o está asignado a un proceso, o está libre. • Retención y espera. Un proceso que está utilizando un recurso ri puede solicitar otro recurso rj antes de liberar ri. • No expulsión. Un proceso no puede ser forzado a liberar un recurso. • Espera circular. Existe un conjunto de procesos PD entre los que se define un círculo de espera por recursos que están siendo usados Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

29. Inanición e interbloqueoSoluciones al interbloqueo • Dos enfoques: • Políticas paliativas: • El Algoritmo del Avestruz • Detección y eliminación • Políticas preventivas: • Prevención de interbloqueos • Predicción de interbloqueos Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

30. Inanición e interbloqueoSoluciones al interbloqueo • Algoritmo del Avestruz • No hacer nada • Detección y eliminación • Detectar cuando ocurra un interbloqueo • Manteniendo un grafo de asignación o mediante otros indicios. • Una vez detectado, tratar de eliminarlo • Eliminando alguno de los procesos involucrados. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

31. Inanición e interbloqueoSoluciones al interbloqueo • Prevención • Si el sistema impide alguna de las condiciones para el interbloqueo, estos no se producirán. • En general, resulta muy restrictivo. • Se puede proponer como metodología. • Por ejemplo, asignar recursos por conjuntos (para eliminar la condición 2) o en un orden determinado (condición 4). • Predicción • Se definen estados seguros e inseguros. • Los estados inseguros son los que pueden conducir a interbloqueos y se evitan denegando el acceso a recursos libres. • Algoritmo del banquero. • Computacionalmente complejo y muy restrictivo. Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores

32. Inanición e interbloqueoPredicción de interbloqueos Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores