• Author / Uploaded
• Julio Liñan Alvarez

• Categories
• Lenguaje de programación
• Lenguaje de modelado unificado
• Sistema operativo
• Java (lenguaje de programación)
• Programación de computadoras

Citation preview

dit UPM

Sistemas de tiempo real 1er semestre, curso 2004-2005

Juan Antonio de la Puente Alejandro Alonso DIT/UPM

Profesores

‹

Juan Antonio de la Puente – Correo electrónico: [email protected] – Página personal: http://www.dit.upm.es/jpuente – Tutorías: B-318, martes de 12 a 13 horas

‹

Alejandro Alonso – Correo electrónico: [email protected] – Página personal: http://www.dit.upm.es/aalonso – Tutorías: B-319, miércoles de 12 a 13 horas

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

1

1

Objetivos de la asignatura

‹

Comprender los problemas específicos de los sistemas de tiempo real y los conceptos básicos asociados a ellos.

‹

Conocer los métodos más importantes que se utilizan para desarrollar sistemas de tiempo real con un grado de fiabilidad elevado, y comprender sus principios y formas de aplicación.

‹

Conocer algunas herramientas (lenguajes de programación y sistemas operativos) adecuadas para la realización de sistemas de tiempo real.

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

2

Asignaturas relacionadas ‹ ‹ ‹

‹ ‹

‹ ‹

Programación Fundamentos de ordenadores Sistemas digitales Arquitectura de ordenadores Laboratorio de programación de sistemas Ingeniería del software Software de comunicaciones

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

3

2

Enfoque ‹ ‹

Conceptos teóricos sobre tiempo y planificación de tareas Mecanismos de realización – Lenguajes de programación » C » Ada 95 » RT-Java

– Sistemas operativos » Multiprogramación con prioridades fijas » POSIX con extensiones de tiempo real ‹

Métodos de diseño – Diseño mediante objetos » HRT-HOOD » UML

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

4

Programa 1 2 3 4 5 6 7 8 9 10

STRL - 21/09/2004

Introducción a los sistemas de tiempo real (2 h) Programación de sistemas de tiempo real (6 h) Sistemas cíclicos (2 h) Sistemas multiprogramados (6 h) Gestión del tiempo (2 h) Planificación de tareas (8 h) Sistemas distribuidos (4 h) Programación de bajo nivel (4 h) Análisis temporal y diseño de sistemas (2 h) Aplicaciones industriales (4 h)

©2004 Juan Antonio de la Puente

5

3

Prácticas

1. 2. 3. 4.

Sistema de control con un ejecutivo cíclico. (4 h) Sistema de control con tareas concurrentes. (4 h) Análisis temporal de sistemas (4 h) Diseño y realización de una aplicación completa (6 h) – Control de un brazo robótico

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

6

Evaluación

‹ Examen

– Preguntas cortas y problemas (con libros) – 75% de la nota final ‹ Prácticas

– Documentación de las prácticas – 25% de la nota final

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

7

4

Bibliografía Texto básico Alan Burns & Andy Wellings Real-Time Systems and Programming Languages, 3rd ed. Addison-Wesley, 2001

´

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

8

Bibliografía adicional ‹ ‹

‹ ‹ ‹

John Barnes. Programming in Ada 95. Addison-Wesley, 1995. Brian Kernigan & Dennis Richtie. The C Programming Language. 2nd. ed (ANSI-C). Prentice-Hall, 1991. Bill Gallmeister. Posix.4. O’Reilly, 1995. Bradford Nichols, Dick Butlar & Jacqueline Farrell. Pthreads programming. O’Reilly, 1996. Hermann Kopetz. Real-Time Systems. Kluwer, 1997.

STRL - 21/09/2004

©2004 Juan Antonio de la Puente

9

5

Otros recursos ‹ ‹

Transparencias Software – Compilador GNAT – Núcleos de tiempo real Marte y ORK – Analizador de tiempo de respuesta RTA

‹

Lista de correo – Para consultas, dudas, aviso, etc. – Darse de alta en https://lists.dit.upm.es/mailman/listinfo/strl

‹

Página de la asignatura:

http://www.dit.upm.es/jpuente/strl.html STRL - 21/09/2004

©2004 Juan Antonio de la Puente

10

6

dit UPM

Introducción a los sistemas de tiempo real Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 1 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languuages, 3ª edición (2001)

Objetivos ‹

Veremos los conceptos más importantes relacionados con los sistemas de tiempo real

‹

Analizaremos sus requisitos y características más importantes

‹

Examinaremos los tipos de sistemas de tiempo real más comunes

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

1

1

Sistemas empotrados ‹

Muchos sistemas de uso común en la industria, el transporte, las comunicaciones y el hogar tienen computadores empotrados: – – – – – –

aviones trenes coches teléfonos móviles televisores etc.

Los computadores empotrados realizan funciones de control de sistemas físicos

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

2

Características ‹

Los recursos están limitados – procesador, memoria, pantalla, etc.

‹

Los dispositivos de entrada y salida son especiales para cada sistema – no hay teclado ni pantalla normales

‹

El computador debe reaccionar a tiempo ante los cambios en el sistema físico – una acción retrasada puede ser inútil o peligrosa – ejemplo: imágenes de TV, sistema de frenado ABS

El desarrollo de software para sistemas empotrados tiene requisitos especiales STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

3

2

Sistemas de tiempo real Un sistema de tiempo real es un sistema informático que – Interacciona repetidamente con su entorno físico – Responde a los estímulos que recibe del mismo dentro de un plazo de tiempo determinado Para que el funcionamiento del sistema sea correcto no basta con que las acciones sean correctas, sino que tienen que ejecutarse dentro del intervalo de tiempo especificado

El tiempo en que se ejecutan las acciones del sistema es significativo ©2001 Juan Antonio de la Puente

STRL – introducción-17/09/2001

4

Requisitos temporales activación

límite plazo de ejecución

intervalo de ejecución arranque

terminación

ejecución de la tarea

tiempo de respuesta

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

5

3

Tipos de requisitos temporales ‹

Tiempo real estricto (hard real-time) – todas las acciones deben ocurrir dentro del plazo especificado » ejemplo: control de vuelo

‹

Tiempo real flexible (soft real-time) – se pueden perder plazos de vez en cuando – el valor de la respuesta decrece con el tiempo » ejemplo: adquisición de datos

‹

Tiempo real firme (firm real-time) – se pueden perder plazos ocasionalmente – una respuesta tardía no tiene valor » ejemplo: sistemas multimedia

En un mismo sistema puede haber componentes con distintos tipos de requisitos temporales ©2001 Juan Antonio de la Puente

STRL – introducción-17/09/2001

6

Ejemplo: freno con computador

actuador

Computador

pedal de freno

sensor de velocidad

sensor de guiñada

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

7

4

Ejemplo: control de posición

motor

sensor

amplificador

carga

medida computador

STRL – introducción-17/09/2001

referencia

©2001 Juan Antonio de la Puente

8

Ejemplo: control de fabricación

máquinas

robots

transporte

computador

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

9

5

Ejemplo: control de procesos

consigna

sensor de temperatura computador

calefactor

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

10

Estructura de un STR típico Reloj de tiempo real

Control digital

Registro de datos

Sistema controlado

Interfaz

Sistema remoto de supervisión

Base de datos Visualización de datos

Consola de operador

STRL – introducción-17/09/2001

Interfaz de operador ©2001 Juan Antonio de la Puente

Pantallas

Computador de tiempo real 11

6

Características de los STR (1) ‹

Gran tamaño y complejidad – algunos STR tienen millones de líneas de código – la variedad de funciones aumenta la complejidad incluso en sistemas relativamente pequeños

‹

Simultaneidad de acciones (concurrencia) – los dispositivos físicos controlados funcionan al mismo tiempo – los componentes de software que los controlan actúan concurrentemente

‹

Dispositivos de entrada y salida especiales – los manejadores de dispositivos forman parte del software de aplicación

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

12

Características de los STR (2) ‹

Seguridad y fiabilidad – sistemas críticos: fallos con consecuencias graves » pérdida de vidas humanas » pérdidas económicas » daños medioambientales

‹

Determinismo temporal – acciones en intervalos de tiempo determinados – es fundamental que el comportamiento temporal de los STR sea determinista » no hay que confundirlo con la necesidad de que sea eficiente » el sistema debe responder correctamente en todas las situaciones » hay que prever el comportamiento en el peor caso posible

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

13

7

Resumen ‹

‹

Los sistemas de tiempo real interaccionan con su entorno y ejecutan sus acciones dentro de intervalos de tiempo determinados Tienen requisitos muy exigentes – – – – –

‹

tamaño y complejidad concurrencia interfaces de hardware específicas fiabilidad y seguridad determinismo temporal

Hay dos clases principales de requisitos de tiempo real – tiempo real estricto (hard real-time) – tiempo real flexible (soft real-time)

STRL – introducción-17/09/2001

©2001 Juan Antonio de la Puente

14

8

dit UPM

Diseño de sistemas de tiempo real Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 2 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languuages, 3ª edición (2001)

Objetivos

‹

Repasaremos algunos conceptos de ingeniería de software y su aplicación a sistemas de tiempo real

‹

Introduciremos brevemente el método HRT-HOOD

‹

Analizaremos los lenguajes de programación y sistemas operativos más adecuados para realizar sistemas de tiempo real

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

1

1

Motivación ‹

Los métodos y herramientas que se usan para construir otros tipos de sistemas no sirven para el software de tiempo real – no son suficientemente fiables – sólo contemplan el tiempo de respuesta medio, no el peor – no se garantizan los requisitos temporales

‹

Las plataformas de desarrollo y ejecución suelen ser diferentes – es difícil hacer pruebas en la plataforma de ejecución – es difícil medir los tiempos con precisión

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

2

Niveles de abstracción ‹

‹

Los métodos de diseño de software comprenden una serie de transformaciones desde los requisitos iniciales hasta el código ejecutable Normalmente se consideran distintos niveles de abstracción en la descripción de un sistema: – – – – –

‹

Especificación de requisitos Diseño arquitectónico Diseño detallado Codificación Pruebas

Cuanto más precisa sea la notación empleada en cada nivel mejor será la calidad del sistema final

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

3

2

abstracción

Ciclo de desarrollo secuencial

pruebas de sistema

análisis

diseño arquitectónico

pruebas de integración diseño detallado

pruebas de unidades realización tiempo

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

4

Características ‹

Se descompone en una secuencia de etapas – Hay que completar cada etapa antes de empezar la siguiente

‹

Las pruebas se llevan a cabo después de la realización – Muchos errores se encuentran sólo al final – Volver atrás es muy costoso – A veces se hace sin documentar y de forma poco rigurosa

‹

Es mejor utilizar un proceso iterativo – Veremos uno centrado en la etapa de diseño – Se trata de validar todos los aspectos que se pueda en la etapa de diseño del sistema – Prestaremos especial atención a la validación del comportamiento temporal

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

5

3

HRT-HOOD ‹

HRT-HOOD – Hard Real-Time Hierarchical Object-Oriented Design – desarrollado por Burns & Wellings en1994

‹

Es un método de diseño estructurado, basado en objetos, para sistemas de tiempo real estricto – derivado de HOOD (Hierarchical Object-Oriented Design) – estándar en la Agencia Europea del Espacio (ESA)

‹

Principios – – – –

abstracción descomposición jerárquica ocultamiento de información análisis temporal

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

6

Proceso de desarrollo iterativo Definición de requisitos

Diseño de la arquitectura lógica Diseño de la arquitectura física y análisis temporal

Restricciones

Diseño detallado Codificación y cálculo de tiempos de ejecución

Restricciones

Pruebas y medida de tiempos

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

7

4

Características ‹

Elementos en cada nivel de abstracción – Compromisos: propiedades que ya no se cambiarán – Obligaciones que se dejan para niveles inferiores

‹

En el diseño se van transformando las obligaciones en compromisos – Este proceso está sujeto a restricciones impuestas por el entorno de ejecución

‹

Dos niveles de diseño arquitectónico – Modelo lógico - compromisos independientes del entorno – Modelo físico - compromisos dependientes del entorno

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

8

Elementos de HRT-HOOD ‹

Un sistema se diseña como una jerarquía de objetos abstractos – un objeto se caracteriza por sus operaciones y su comportamiento (abstracción y ocultamiento de información) – cada objeto se puede descomponer en otros de más bajo nivel – modelo de objetos simple, sin herencia » apropiado para sistemas de tiempo real

‹

Se puede analizar el comportamiento temporal si el entorno de ejecución es conocido y predecible – los objetos tienen atributos temporales – las relaciones entre objetos están restringidas para asegurar que el diseño se puede analizar

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

9

5

Objetos y relaciones El objeto parent contiene los objetos child_1 y child_2

parent

T T

op1

child_1

datos

uncle

op

op2

excepción T

op

STRL - Diseño de sistemas -30/09/2002

child_2

parent usa uncle child_1 usa child_2 y uncle child_1.op implementa parent.op1 child_2.op implementa parent.op2

©2001 Juan Antonio de la Puente

10

Tipos de objetos ‹

Pasivos » no controlan cuándo se ejecutan sus operaciones » no invocan operaciones de otros objetos espontáneamente

‹

Protegidos » pueden controlar cuándo se ejecutan sus operaciones » no invocan operaciones de otros objetos espontáneamente

‹

Activos » pueden controlar cuándo se ejecutan sus operaciones » pueden invocar operaciones de otros objetos espontáneamente

– Cíclicos » sus operaciones se ejecutan a intervalos regulares

– Esporádicos » sus operaciones se ejecutan cuando ocurre un suceso externo o interno STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

11

6

UML ‹

UML – Unified Modeling Language – desarrollado por Booch, Rumbaugh y Jacobson

‹

Notación basada en objetos con diversos aspectos – – – – – –

‹ ‹

clases y objetos casos de uso comportamiento paquetes estructura del software estructura física

UML es un lenguaje, no un método Se están desarrollando variantes para STR

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

12

Diseño de sistemas y lenguajes de programación ‹

El diseño debe tener en cuenta lo que se puede hacer en los niveles de abstracción inferiores

‹

Los lenguajes de programación proporcionan la notación básica para la realización de los diseños

‹

La elección de un lenguaje es importante desde el punto de vista de la eficiencia y la fiabilidad del sistema – también tiene que ver con la productividad de la programación – un programa se escribe una vez, pero se lee y se modifica muchas durante las etapas de mantenimiento – la vida útil de los sistemas empotrados puede ser muy larga

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

13

7

Lenguajes de programación ‹

Un lenguaje de programación de sistemas de tiempo real debe facilitar la realización de sistemas – concurrentes, – fiables, – con un comportamiento temporal analizable

‹

Hay varias clases de lenguajes de interés para STR: – Lenguajes ensambladores » flexibles y eficientes, pero costosos y poco fiables

– Lenguajes secuenciales (Fortran, Pascal, C, C++) » necesitan un SO para concurrencia y tiempo real

– Lenguajes concurrentes (Modula, Ada, Java, ...) » concurrencia y tiempo real incluidos en el lenguaje

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

14

C ‹ ‹

Es un lenguaje muy utilizado para programación de sistemas Es un lenguaje – estructurado, con bloques – sin tipado fuerte – muy flexible (pero a veces poco seguro)

‹

No tiene integrada la concurrencia ni el tiempo real – se consigue invocando servicios del sistema operativo de forma explícita

‹

No facilita la descomposición en módulos ni la programación con objetos – se puede hacer con C++ » extensión de C para programar con objetos » no se suele usar en STR por problemas de fiabilidad

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

15

8

Ada ‹

Es un lenguaje diseñado específicamente para sistemas de tiempo real empotrados – concurrencia – tiempo real – acceso al hardware e interrupciones

‹

Es un lenguaje descendiente de Pascal – estructura en bloques – fuertemente tipado

‹

Está pensado para construir sistemas grandes y cambiantes – – – –

paquetes (módulos) y esquemas genéricos extensión de tipos con herencia biblioteca jerárquica interfaces normalizadas con otros lenguajes (C, Fortran)

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

16

Ada 95 ‹ ‹

Es la versión actual normalizada de Ada La norma define – un núcleo común para todas las implementaciones (core language) – unos anexos especializados para » » » » » »

programación de sistemas sistemas de tiempo real sistemas distribuidos sistemas de información cálculo numérico fiabilidad y seguridad

– Los anexos definen » paquetes de biblioteca » mecanismos de implementación

No añaden sintaxis ni vocabulario al lenguaje

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

17

9

Perfiles para sistemas críticos ‹

El documento Guide for the use of the Ada programming language in high-integrity systems define subconjuntos seguros de Ada para aplicaciones críticas

‹

SPARK es un subconjunto / extensión de Ada que permite el uso de técnicas de análisis estático

‹

El perfil de Ravenscar define un subconjunto seguro de la parte concurrente de Ada, y los correspondientes servicios de sistema operativo

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

18

Java ‹

Es un lenguaje pensado para construir sistemas distribuidos – – – –

basado en objetos dinámicos con concurrencia integrada en el lenguaje bibliotecas de clases (APIs) muy útiles pensado para que el código objeto sea portátil » interpretado por una máquina virtual (JVM) » “write once, run everywhere”

‹

La definición original no es adecuada para tiempo real – – – – –

la planificación de actividades concurrentes no está bien definida los mecanismos de sincronización son inadecuados la gestión dinámica de memoria introduce indeterminismo la medida del tiempo no es suficientemente precisa otros problemas con excepciones y concurrencia

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

19

10

Java para tiempo real ‹

Hay varias propuestas de modificaciones para usar Java en sistemas de tiempo real – NIST Requirements for Real-Time Extensions to Java (1999) » no modificar la sintaxis, coexistencia con aplicaciones convencionales

– Java Real-time Experts Group (Sun & otros) » Real-Time Specification for Java (2000-2001) » basada en un máquina virtual extendida para STR » hay una implementación de referencia

– Real-Time Java Working Group (J-Consortium) » Real-Time Core Specification (2000) » basada en una máquina virtual separada para STR ‹

Los compiladores y las máquinas virtuales para Java de tiempo real están en sus comienzos

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

20

Sistemas operativos ‹

Los sistemas operativos convencionales no son adecuados para realizar sistemas de tiempo real – no tienen un comportamiento determinista – no permiten garantizar los tiempos de respuesta – algunos de ellos son poco fiables

‹

Un sistema operativo de tiempo real (SOTR) debe soportar – concurrencia: procesos ligeros (threads) con memoria común – temporización: medida de tiempos y ejecución periódica – planificación determinista » ej.: prioridades fijas con desalojo

– dispositivos de E/S: acceso a recursos de hardware e interrupciones STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

21

11

Arquitectura de software y SO (1)

Sistema operativo

Programa de aplicación con componentes de sistema operativo

Hardware

Hardware

Aplicación convencional

Sistema empotrado

Programas de usuario

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

22

Arquitectura de software (2)

programa de aplicación núcleo de ejecución (run-time system) sistema operativo de tiempo real hardware

Arquitectura con sistema operativo de tiempo real

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

23

12

Arquitectura de software (3)

programa de aplicación núcleo de ejecución (run-time system)

aplicaciones convencionales

programa de tiempo real

SO convencional

RTS

núcleo de tiempo real

hardware hardware

Arquitectura con máquina desnuda

STRL - Diseño de sistemas -30/09/2002

Arquitectura con máquina virtual

©2001 Juan Antonio de la Puente

24

POSIX ‹ ‹ ‹ ‹

‹

Es un conjunto de normas IEEE/ISO que definen interfaces de sistemas operativos Permiten desarrollar software portátil y reutilizable (Portable Operating System Interface) Las normas definen servicios que se pueden incluir o no en un sistema operativo particular Además se definen perfiles de aplicación con conjuntos de servicios estándar Hay interfaces para C, Ada, y otros lenguajes

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

25

13

Normas POSIX POSIX 1, 1a POSIX 1b,1d,1j POSIX 1c POSIX 1e POSIX 1f POSIX 1g POSIX 1h POSIX 5,5a,5b POSIX 13 POSIX 21

STRL - Diseño de sistemas -30/09/2002

Interfaz básica similar a UNIX™ Extensiones de tiempo real Procesos ligeros (threads) Seguridad NFS Servicios de red (sockets, XTI) Tolerancia de fallos Interfaces para Ada Perfiles para sistemas de tiempo real Comunicaciones de tiempo real

©2001 Juan Antonio de la Puente

26

Perfiles de aplicación ‹

Definen subconjuntos de servicios para distintos tipos de aplicaciones

‹

POSIX 13 : Perfiles para sistemas de tiempo real – PSE50 : sistema de tiempo real mínimo » sin gestión de memoria, ficheros ni terminal » sólo threads (no procesos pesados)

– PSE51 : controlador de tiempo real » tiene sistema de ficheros y terminal

– PSE52 : sistema de tiempo real dedicado » tiene gestión de memoria y procesos pesados

– PSE53 : sistema de tiempo real generalizado » sistema completo con todo tipo de servicios

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

27

14

Ejemplos de SOTR ‹ ‹ ‹ ‹ ‹ ‹ ‹ ‹

LynxOS pSOS QNX VRTX VxWorks RTEMS RT-Linux Marte — Universidad de Cantabria – perfil POSIX PSE50 – para sistemas empotrados en PCx86

‹

Open Ravenscar Kernel (ORK) — DIT/UPM – núcleo de SOTR para Ada / Ravenscar

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

28

Resumen ‹

Los métodos y herramientas convencionales no son adecuados para desarrollar sistemas de tiempo real

‹

HRT-HOOD es un método de diseño bien adaptado a este tipo de sistemas

‹

En el curso usaremos algunos lenguajes de programación para ilustrar los conceptos más importantes de los STR – C / POSIX – Ada 95 – RT Java

STRL - Diseño de sistemas -30/09/2002

©2001 Juan Antonio de la Puente

29

15

dit UPM

Introducción a Ada Juan Antonio de la Puente DIT/UPM

Objetivos ‹ ‹ ‹

Haremos un repaso de las características básicas de un lenguaje de programación: Ada 95 Veremos un subconjunto mínimo que permite realizar programas en pequeña escala Suponemos que se conoce algún lenguaje estructurado (como Pascal o Modula)

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

1

1

Índice ‹ ‹ ‹ ‹ ‹ ‹ ‹

Introducción Léxico Tipos de datos Instrucciones Subprogramas Estructura de programas Aspectos avanzados

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

2

Lenguajes de programación ‹

Un lenguaje de programación de sistemas de tiempo real debe facilitar la realización de sistemas – concurrentes, – fiables, – puntuales.

‹

Las características más importantes para la realización de programas en pequeña escala son – – – – –

léxico tipos de datos y objetos instrucciones subprogramas estructura de programas

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

3

2

Ada

‹

Es un lenguaje imperativo, descendiente de Pascal – estructura en bloques – fuertemente tipado

‹ ‹

Es un lenguaje pensado para realizar sistemas empotrados de gran dimensión Dos versiones normalizadas – Ada 83 (ISO 8652:1987) – Ada 95 (ISO 8652:1995)

‹

Desarrollado por iniciativa y bajo la supervisión del DoD (Department of Defense) de los EE.UU.

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

4

Núcleo y anexos La norma (ISO) de Ada 95 define – un núcleo común para todas las implementaciones – unos anexos especializados para » » » » » »

programación de sistemas sistemas de tiempo real sistemas distribuidos sistemas de información cálculo numérico fiabilidad y seguridad

– Los anexos definen » paquetes de biblioteca » mecanismos de implementación

(no añaden sintaxis ni vocabulario al lenguaje)

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

5

3

Índice ‹ ‹ ‹ ‹ ‹ ‹ ‹

Introducción Léxico Tipos de datos Instrucciones Subprogramas Estructura de programas Aspectos avanzados

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

6

Léxico ‹

Los identificadores pueden contener letras, dígitos o el carácter '_' Ejemplos: Sensor

Tiempo_de_Activación

‹

No hay distinción entre mayúsculas y minúsculas

‹

Hay palabras reservadas que no se pueden usar como identificadores

‹

Los números pueden contener el carácter '_' Ejemplos: 123 150_000 3.141_592_654 1.7E-5

‹

Los comentarios empiezan con "--" y van hasta el final de la línea

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

7

4

Índice ‹ ‹ ‹ ‹ ‹ ‹ ‹

Introducción Léxico Tipos de datos Instrucciones Subprogramas Estructura de programas Aspectos avanzados

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

8

Tipos de datos ‹

Un tipo de datos es un conjunto de valores con un conjunto de operaciones primitivas asociadas

‹

Tipado fuerte – No se pueden usar valores de un tipo en operaciones de otro tipo sin efectuar una conversión de tipo explícita – Las operaciones dan siempre resultados del tipo correcto

‹

Una clase es la unión de varios tipos con características comunes

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

9

5

Clasificación de los tipos de datos

tipos elementales

compuestos

acceso

escalares discretos

formaciones registros etiquetados privados tareas protegidos tiras numéricos

enumerables caracteres

booleanos

STRL - 30/09/2002

enteros

reales c. flotante

otros modulares con signo

©2001 Juan Antonio de la Puente

c. fija

ordinarios

decimales

10

Tipos discretos ‹

Enumerables Boolean -- predefinido Character -- predefinido type Mode is (Manual, Automatic);

‹

Enteros – Con signo Integer -- predefinido type Index is range 1 .. 10;

– Modulares type Octet is mod 256;

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

11

6

Tipos reales ‹

Coma flotante Float -- predefinido type Length is digits 5 range 0.0 .. 100.0;

‹

Coma fija – Ordinarios Duration -- predefinido type Voltage is delta 0.125 range 0.0 .. 5.25;

– Decimales type Money is delta 0.01 digits 15;

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

12

Ejemplos type Index is range 1 .. 100; -- entero type Length is digits 5 range 0.0 .. 100.0; -- coma flotante First, Last : Index; Front, Side : Length; Last Side Side Side Side

:= := := := :=

First + 15; 2.5*Front; 2*Front; Front + 2*First; Front + 2.0*Length(First);

STRL - 30/09/2002

------

correcto correcto incorrecto incorrecto correcto

©2001 Juan Antonio de la Puente

13

7

Tipos compuestos (1) ‹ Formaciones String type Voltages is array (Index) of Voltage; type Matrix is array (1 .. 10, 1 .. 10) of Float;

Elementos: V : Voltages; V(5) := 1.0; V := (1.0, 0.0, 0.0, 0.0, 2.5, 0.0, 0.0, 0.0, 0.0, 0.0); V := (1 => 1.0, 5 => 2.5, others => 0.0);

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

14

Tipos compuestos (2) ‹ Registros type State is record Operating_Mode : Mode; Reference : Voltage; end record;

Elementos: X : State X.Reference := 0.0; X := (Automatic, 0.0); X := (Operating_Mode => Automatic, Reference => 0.0);

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

15

8

Tipos acceso ‹

Los objetos de tipos acceso designan valores de otros tipos type State_Reference is access State;

‹

Los objetos a los que se accede a través de un tipo acceso de crean dinámicamente S : State_Reference := new State; Las variables de acceso se inician a null si no se dice nada

‹

Acceso al objeto dinámico: S.Operating_Mode := Manual; S.all := (Operating_Mode => Manual, Reference => 0.0); S := new State := (Manual, 0.0); – No se puede operar con los valores de los tipos acceso – No pueden quedar punteros “colgando”

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

16

Declaraciones ‹

Asocian nombres con definiciones de – tipos type Real is digits 8;

– objetos X : Real := 0.0; J : constant Complex := (0.0, -1.0);

– números Pi : constant := 3.141_592_654;

– subprogramas – otras entidades ‹

¡Ojo! Todas terminan en ';'

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

17

9

Elaboración ‹ ‹

Las declaraciones se colocan en zonas declarativas Al entrar en la zona declarativa se elaboran – Puede ser al arrancar el programa o durante la ejecución

‹

La elaboración consiste en la creación de la entidad declarada, seguida por la realización de las operaciones iniciales asociadas a la misma – Ejemplos: » iniciación del valor de una variable » Asignación de memoria para crear un objeto dinámico

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

18

Índice ‹ ‹ ‹ ‹ ‹ ‹ ‹

Introducción Léxico Tipos de datos Instrucciones Subprogramas Estructura de programas Aspectos avanzados

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

19

10

Instrucciones ‹

Simples – Asignación – Llamada a procedimiento – Nula

‹

Compuestas – – – –

‹

Secuencia Bloque Selección Iteración

¡Ojo! Todas las instrucciones terminan con ';'

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

20

Instrucciones simples ‹

Asignación U := 2.0*V(5) + U0;

– El tipo de la expresión debe ser el mismo que el de la variable – No hay conversión implícita de tipos ‹

Llamada a procedimiento Get(V);

‹

Instrucción nula null;

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

21

11

Secuencia Get(V); U := 2.0*V(65) + U0;

Sintaxis: secuencia ::= instrucción {instrucción}

¡Ojo! No se puede omitir ';' en la última instrucción

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

22

Bloque

declare V : Voltages begin Get(V); U := 2.0*V(65) + U0; end;

-- variable local al bloque

-- V deja de existir aquí

Sintaxis: bloque ::= [identificador :] [declare {declaración}] -- parte declarativa begin secuencia end [identificador];

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

23

12

Selección if T = 180.0 then P := 0.0; else P := Control(R,t); end if;

Sintaxis selección-if ::= if expresión-booleana then secuencia {elsif expresión-booleana then secuencia} [else secuencia] end if;

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

24

Selección por casos case Day is when Monday => when Tuesday .. Thursday => when Friday .. Saturday => when others => end case;

Start_Week; Continue_Work; End_Week; Relax;

Sintaxis selección-case ::= case expresión-discreta is alternativa {alternativa} end case; alternativa ::= when lista => secuencia lista ::= opción {|opción} opción ::= expresión |intervalo|others

¡Ojo! Hay que cubrir todos los valores del tipo discreto STRL - 30/09/2002

©2001 Juan Antonio de la Puente

25

13

Iteración (1) Hay tres clases de bucles for I in 1..10 loop Get(V(I)); end loop;

¡Ojo! El índice del bucle for solo está definido en el cuerpo del bucle while T 80.0; V(I) := U; I := I+1; end loop;

Sintaxis exit[identificador] [when expresión-booleana];

– La ejecución continúa inmediatamente después del bucle – Si hay bucles anidados, se sale del interior, o del que tiene el identificador que se indica

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

28

Transferencia de control Sintaxis goto etiqueta; etiqueta ::= instrucción-etiquetada ::= etiqueta instrucción

‹

Hay limitaciones para aumentar la seguridad – La instrucción etiquetada tiene que estar en la misma secuencia y con el mismo grado de anidamiento que la de transferencia – No se puede salir de un subprograma ni de otras entidades de programa

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

29

15

Índice ‹ ‹ ‹ ‹ ‹ ‹ ‹

Introducción Léxico Tipos de datos Instrucciones Subprogramas Estructura de programas Aspectos avanzados

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

30

Subprogramas ‹

Hay dos tipos de subprogramas – procedimiento: abstraccción de acción – función: abstracción de valor

‹

Ambos pueden tener parámetros Un subprograma tiene dos partes – especificación: define la interfaz (nombre y parámetros) – cuerpo: define la acción o el algoritmo que se ejecuta cuando se invoca el subprograma

A veces se puede omitir la especificación En este caso la interfaz se define al declarar el cuerpo

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

31

16

Declaración de subprograma (1) La especificación se declara en una zona declarativa procedure Reset;

-- sin parámetros

procedure Increment(Value : in out Integer; Step : in Integer := 1); function Minimum (X,Y : Integer) return Integer;

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

32

Declaración de subprograma (2) Sintaxis declaración-de-subprograma ::= especificación-de-subprograma; especificación-de-subprograma ::= procedure nombre [parámetros-formales] |function nombre [parámetros-formales] return tipo parámetros formales ::= (definición{, definición}) definición ::= lista : modo tipo [::= valor-pordefecto] lista ::= identificador{, identificador} modo ::= [in] | out | in out valor-por-defecto ::= expresión STRL - 30/09/2002

©2001 Juan Antonio de la Puente

33

17

Declaración de subprograma (3)

‹

Hay tres modos de parámetros formales – in

No se modifica al ejecutar el subprograma Pueden tener un valor por defecto – out El subprograma debe asignar un valor al parámetro – in out El subprograma modifica el valor del parámetro Los parámetros de las funciones solo pueden ser de modo in Los modos no están ligados al mecanismo de paso de parámetros ‹

Puede haber subprogramas homónimos – Se distinguen por sus parámetros formales (y en el caso de las funciones por el tipo del resultado) – El compilador genera la llamada al subprograma adecuado

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

34

Cuerpo de subprograma (1)

‹

Se coloca en una zona declarativa procedure Increment (Value : in out Integer; Step : in Integer := 1) is begin Value := Value + Step; end Increment; function Minimum(X,Y : Integer) return Integer is begin if X X, Step => 2); -- asociación nombrada Increment(X); -- Step => 1 (defecto) W := 2*Minimum(U,V);

Puede formar parte de cualquier secuencia

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

37

19

Llamada a subprograma (2)

Sintaxis llamada-a-subprograma ::= nombre; | nombre parámteros-reales; parámetros-reales ::= (asociación{, asociación}) asociación ::= [nombre-formal =>] parámetro-real parámetro-real ::= expresión | nombre-de-variable

– Los parámetros formales de modo in se asocian a expresiones – Los de modo out o in out se asocian a variables – Con asociación nombrada los parámetros pueden ir en cualquier orden

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

38

Índice ‹ ‹ ‹ ‹ ‹ ‹ ‹

Introducción Léxico Tipos de datos Instrucciones Subprogramas Estructura de programas Aspectos avanzados

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

39

20

Estructura de programas (1)

‹

Los subprogramas son unidades de programa – hay otras: paquetes, tareas, y objetos protegidos – un paquete es un módulo que contiene declaraciones de tipos, objetos, subprogramas, y otras unidades de programa

‹

También son unidades de compilación – los paquetes también lo son – un fichero fuente contiene una (o a veces más) unidad de compilación

‹ ‹

Los subprogramas y paquetes compilados forman una biblioteca de compilación Un programa ejecutable se monta a partir de una biblioteca que incluya un procedimiento principal

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

40

Estructura de programas (2) ‹

Un programa Ada se compone de – un procedimiento principal (normalmente sin parámetros) – otros subprogramas o paquetes escritos por el programador – subprogramas y paquetes predefinidos (y precompilados)

‹

Cuando se usan elementos de un paquete hay que importar el paquete con una cláusula with with nombre-de-paquete{, nombre-de-paquete};

‹

La cláusula use permite hacer referencia directa a los nombres declarados en los paquetes importados use nombre-de-paquete{, nombre-de-paquete};

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

41

21

Paquetes predefinidos ‹

Operaciones numéricas – Ada.Numerics, Ada.Numerics.Generic_Elementary_Functions

‹

Operaciones con caracteres y tiras – Ada.Characters, Ada.Strings, etc.

‹

Entrada y salida – Ada.Text_IO, Ada.Integer_Text_IO, Ada.Float_Text_IO, etc.

‹ ‹

Interfaces con otros lenguajes Otros

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

42

Entrada y salida ‹

Ada.Text_IO procedure procedure procedure procedure

‹

Get (Item : out String); Put (Item : in String); Put_Line (Item : in String); New_Line;

Ada.Integer_Text_IO procedure Get (Item : out Integer); procedure Put (Item : in Integer);

‹

Ada.Float_Text_IO procedure Get (Item : out Float); procedure Put (Item : in Float);

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

43

22

Ejemplo

with Ada.Text_IO; procedure Hello is begin Put_Line("Hello!"); end Hello;

use Ada.Text_IO;

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

44

Compilación con GNAT ‹

Se parte de un fichero hello.adb. Para compilar se hace: $ gcc -c hello.adb – resultado: ficheros hello.o y hello.ali

‹

Montaje y enlace : $ gnatbind hello.ali $ gnatlink hello.ali – resultado: fichero hello (linux) o hello.exe (Windows)

‹

Se puede hacer todo de una vez: $ gnatmake hello.adb – compila todo lo que haga falta, no sólo hello.adb

‹

Para ejecutarlo se hace (en linux) $ ./hello

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

45

23

Compilación y montaje RTS ALI files gnat.adc

application sources

application ALI files

GNAT binder

application object files

elaboration code

GNAT linker

ELF-32 executable

GNAT compiler

RTS specs RTS & library object files

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

46

Índice ‹ ‹ ‹ ‹ ‹ ‹ ‹

Introducción Léxico Tipos de datos Instrucciones Subprogramas Estructura de programas Aspectos avanzados

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

47

24

Subtipos

‹

Un subtipo es un subconjunto de valores de un tipo, definido por una restricción – La forma más simple de restricción es un intervalo de valores subtype Small_Index is Index range 1 .. 5; subtype Big_Index is Index range 6 .. 10; subtype Low_Voltage is Voltage range 0.0 .. 2.0;

– Hay dos subtipos predefinidos subtype Natural is Integer range 0 .. Integer'Last; subtype Positive is Integer range 1 .. Integer'Last; ‹ ‹

Las operaciones con valores de distintos subtipos de un mismo tipo están permitidas Las restricciones se comprueban al compilar o al ejecutar

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

48

Ejemplos A : Small_Index := 1; B : Big_Index; C : Index; A A A A A

:= := := := :=

3; 6; B; C; A + 1;

STRL - 30/09/2002

------

correcto error error error si C > 5 error si A > 4

©2001 Juan Antonio de la Puente

49

25

Tipos derivados

Un tipo derivado es una copia de otro tipo, cuyos valores y operaciones hereda type Surface is new Float;

– Se puede imponer una restricción en el conjunto de valores type Length is new Float range 0.0 .. 100.0; type Width is new Float range 0.0 .. 20.0; S : Surface; L : Length; W : Width; -- tipos distintos

– Los valores no son compatibles, pero se pueden convertir S := L*W; S := Surface(Float(L)*Float(W));

---

incorrecto correcto

– Las restricciones se comprueban al compilar o al ejecutar

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

50

Formaciones irrestringidas

‹

Se pueden declarar tipos formación con un intervalo de índices indefinido (formaciones irrestringidas) type Measurements is array (Positive range ) of Voltage;

– El tipo String está predefinido: type String is array (Positive range ) of Character; ‹

Al declarar objetos hay que restringir los índices M M M S S

: : : : :

STRL - 30/09/2002

Measurements; Measurements (1 .. 10); Measurements := (1..10 => 0.0); String (1 .. 25); String := "ejemplo";

©2001 Juan Antonio de la Puente

------

incorrecto correcto correcto correcto correcto

51

26

Formaciones dinámicas

‹

También se puede declarar formaciones con intervalos dinámicos (que se evalúan al elaborar la declaración) type Measurements is array (1 .. No_Of_Inputs) of Voltage;

‹

Las expresiones que aparecen en los límites tiene que estar definidas en el momento de la elaboración (pero no necesariamente al compilar)

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

52

Registros con discriminantes

‹

Un discriminante es un componente de un registro que permite parametrizar los objetos del tipo type Variable is (Temperature, Pressure); type Measurement (Kind: Variable) is record Value : Voltage; end record; T : Measurement(Temperature); P : Measurement := (Kind => Pressure, Value => 2.5);

‹ ‹

El discriminante tiene que ser de un tipo discreto No se puede cambiar una vez asignado

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

53

27

Registros con variantes

‹

Se puede usar un discriminante para declarar tipos registro con partes variantes type Measurement (Kind: Variable) is record Value : Voltage; case Kind is when Temperature => Too_High : Boolean := False; when Pressure => Sensor_Id : Sensor_Range; end case; end record; T : Measurement(Temperature); P : Measurement := (Pressure, 2.5, 4); T.Too_High := True; Id := P.Sensor_Id;

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

54

Conversión de tipos

‹

Se pueden convertir valores de un tipo a otro – entre tipos numéricos – entre formaciones con la misma estructura y tipo de elementos – entre registros con los mismos discriminantes y tipo de componentes – entre un tipo y sus derivados (pero no éstos entre sí)

‹

El nombre del tipo al que se convierte se usa como si fuera una función I : Integer; S : Surface; I := Integer(S); S := Surface(Float(L)*Float(W));

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

55

28

Excepciones

‹

Una excepción es una manifestación de un cierto tipo de error – cuando se produce un error, se eleva la excepción correspondiente – se abandona la ejecución normal y se pasa a ejecutar un manejador asociado a la excepción – se busca un manejador en el mismo cuerpo o bloque – si no lo hay, la excepción se propaga al nivel superior » bloque exterior o punto de invocación de un subprograma

– si no se encuentra ningún manejador, se termina el programa

©2001 Juan Antonio de la Puente

STRL - 30/09/2002

56

Nombres de excepciones ‹

Se pueden declarar excepciones en cualquier zona declarativa (no son objetos) Sensor_Failure

: exception;

– Se elevan con una instrucción raise : raise Sensor_Failure; ‹

Algunas excepciones están predefinidas: Constraint_Error Program_Error Storage_Error Tasking_Error

: : : :

exception; exception; exception; exception;

– Se elevan automáticamente por el entorno de ejecución, o explícitamente con raise

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

57

29

Manejadores de excepciones ‹

Los manejadores se declaran al final de un bloque o cuerpo begin ... exception when Constraint_Error => ...; when Sensor_Failure => ...; when Storage_Error | Program_Error => ...; when others => ...; end;

‹

Un manejador es una secuencia de instrucciones – cuando termina, se devuelve el control al punto de invocación del bloque o cuerpo que falló

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

58

Bibliografía ‹ ‹ ‹ ‹

Ada 95 Language Reference Manual Ada 95 Rationale John Barnes – Programming in Ada 95 GNAT User's Guide

STRL - 30/09/2002

©2001 Juan Antonio de la Puente

59

30

dit UPM

Programación de sistemas grandes Juan Antonio de la Puente DIT/UPM

Objetivos u

u

u

Repasaremos los elementos de los lenguajes de programación que facilitan la realización de sistemas grandes Veremos cómo usar módulos o paquetes para descomponer un sistema y abstraer los detalles de realización Veremos también cómo realizar componentes de software que se puedan reutilizar en varios sistemas

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

1

Contenido u u u u u u u

Introducción Ocultamiento de información Tipos abstractos de datos Compilación separada Objetos Reutilización Programación en C

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

2

Descomposición y abstracción u

Descomposición División de un sistema complejo en componentes más sencillos, hasta conseguir que cada componente pueda ser comprendido y realizado por una o varias personas – diseño descendente

u

Abstracción Especificación de los aspectos esenciales de un componente, dejando para más adelante su diseño detallado – diseño ascendente

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

3

Módulos u

u

u

Un módulo es una colección de declaraciones de tipos, objetos y operaciones relacionados entre sí Los módulos permiten encapsular partes del sistema mediante interfaces bien definidas Los módulos permiten utilizar algunas técnicas que facilitan el desarrollo de sistemas grandes: – ocultamiento de información – tipos abstractos de datos – compilación separada

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

4

Contenido u u u u u u u

Introducción Ocultamiento de información Tipos abstractos de datos Compilación separada Objetos Reutilización Programación en C

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

5

Ocultamiento de información u u

Los módulos permiten controlar la visibilidad de las declaraciones Para ello se distingue entre – interfaz visible (especificación) – cuerpo invisible (implementación) » contiene los detalles que no son visibles desde fuera

u u

Es deseable poder compilar la especificación sin necesidad de escribir el cuerpo Ejemplos – Ada: paquetes – C: ficheros .h y .c

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

6

Paquetes en Ada u

Un paquete (package) tiene dos partes: – especificación: contiene únicamente declaraciones visibles desde otras partes del programa (la interfaz del paquete) – cuerpo: contiene los detalles invisibles desde fuera

u

u

Todos los identificadores definidos en la especificación son visibles a la vez Hay una relación formal entre la especificación y el cuerpo

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

7

Ejemplo (1) u

Especificación de paquete (greetings.ads)

package Greetings is -- procedimientos para saludar procedure Hello; procedure Goodbye; end Greetings;

u u

Contiene la especificación de dos procedimientos Los cuerpos van en el cuerpo del paquete

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

8

Ejemplo (2) u

Cuerpo del paquete (greetings.adb) with Ada.text_IO; use Ada.Text_IO; package body Greetings is procedure Hello is begin Put_Line ("Hello); end Hello; procedure Goodbye is begin Put_Line ("Goodbye"); end Goodbye; end Greetings;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

9

Uso de los paquetes u

Los identificadores declarados en la especificación van cualificados con el nombre del paquete Greetings.Hello;

u

Se puede evitar la cualificación con una cláusula use: with Greetings; use Greetings; procedure Greet is begin Hello; Goodbye; end Greet;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

10

Contenido u u u u u u u u

Introducción Ocultamiento de información Tipos abstractos de datos Compilación separada Módulos genéricos Objetos Reutilización Programación en C

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

11

Tipos abstractos de datos u

u

Un TAD es un tipo de datos declarado conjuntamente con un conjunto de operaciones primitivas Los detalles de representación del tipo se ocultan – se dice que el tipo es privado

u

Los detalles sobre la representación del tipo van en una parte privada de la especificación del paquete – la parte privada define la interfaz física del paquete y es invisible desde fuera del mismo – la utiliza el compilador para crear objetos del tipo abstracto

u u

Los tipos limitados no tienen operaciones predefinidas Los demás tipos privados tienen predefinida la asignación (“:=“) y la igualdad (“=“)

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

12

Ejemplo: TAD cola (1)

package Queues is -- tipo abstracto type Queue is limited private; -- operaciones primtivas procedure Create (Q : in out Queue); function Empty (Q : Queue) return Boolean; procedure Insert (Q : in out Queue; E : Element); procedure Remove (Q : in out Queue; E : out Element);

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

13

Ejemplo: TAD cola (2) private -- estas declaraciones no son visibles desde fuera type Queue_Node; type Queue_Node_Pointer is access Queue_Node; type Queue_Node is record Contents : Element; Next : Queue_Node_Pointer; end record; type Queue is limited record Front : Queue_Node_Pointer; Back : Queue_Node_Pointer; end record; end Queues;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

14

Ejemplo: TAD cola (3) package body Queues is ... end Queues;

declare use Queues; Q1, Q2 : Queue; E : Element; begin if not Empty (Q1) then Remove (Q1,E); Insert (Q2, E); end if; end;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

15

Contenido u u u u u u u u

Introducción Ocultamiento de información Tipos abstractos de datos Compilación separada Módulos genéricos Objetos Reutilización Programación en C

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

16

Compilación separada u

u

Es interesante compilar por separado los módulos de un programa grande Conviene distinguir – Compilación independiente » los módulos se compilan por separado, pero el compilador no comprueba la interdependencias » la resolución de las dependencias se hace al montar el programa » los errores aparecen al ejecutar el programa

– Compilación separada » el compilador comprueba el uso de las definiciones de unos módulos en otros » se pueden detectar errores al compilar Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

17

Compilación separada en Ada u

u

Un programa grande se puede dividir en unidades de compilación En Ada las unidades de compilación pueden ser: – especificaciones de paquetes – especificaciones de subprogramas – los cuerpos de paquetes y subprogramas son unidades secundarias

u

La dependencia entre unidades se indica con una cláusula with with Greetings; use Greetings; procedure Greet is begin Hello; Goodbye; end Greet;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

18

Compilación separada con GNAT u

Ahora hay tres ficheros: (especificación de Greetings) (cuerpo de Greetings) (cuerpo del procedimiento Greet)

greetings.ads greetings.adb greet.adb u

Para compilar se hace: $ $ » »

u

gcc -c greet.adb gcc -c greetings.adb ¡ no hace falta compilar greetings.ads ! no importa el orden de compilación

Montaje y enlace : $ gnatbind greet.ali $ gnatlink greet.ali

u

Se puede hacer todo de una vez: $ gnatmake greet

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

19

Biblioteca de compilación u

u

u

Las unidades que forman un programa se almacenan en una biblioteca de compilación La cláusula with establece una relación de dependencia entre unidades Se pueden escribir (y compilar) las especificaciones antes que los cuerpos – – – –

el compilador comprueba que las interfaces son consistentes esto es adecuado para implementar hacia arriba (bottom-up) es compatible con el diseño descendente (top-down) los cuerpos dependen de las especificaciones

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

20

Diagramas de módulos u

Permiten representar gráficamente las dependencias entre unidades de compilación cuerpo

especificación Dispatcher Queues

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

21

Paquetes sin cuerpo u

u u

Los paquetes cuya especificación está completa no tienen cuerpo Por ejemplo, si sólo se declaran tipos, constantes y variables Ejemplo: package Elevation_Definitions is type Elevation_Angle is digits 5 range -30.0 .. 90.0; Maximum_Elevation : constant Elevation_Angle := 60.0; Current_Elevation : Elevation_Angle; end Elevation_Definitions;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

22

Unidades separadas u

La cláusula separate facilita la implementación hacia abajo – se puede sustituir un cuerpo por un resguardo (stub) que se compila más tarde procedure Main is type Reading is ... type Control_Value is ... procedure Convert (R : Reading; V : out Control_Value) is separate; begin -- Main loop Get (R); Convert (R,V); Put (V); end loop; end Main; separate (Main) procedure Convert (R : Reading; V : out Control_Value) is -- cuerpo del procedimiento end Convert;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

23

Biblioteca jerárquica u

u

Cuando un programa se hace muy grande, puede haber conflictos de nombres entre unidades de programa Para evitar esto, Ada tiene una biblioteca jerárquica – Un paquete P puede tener uno o más «hijos» P.Q – La especificación de P.Q es una extensión de la especificación de P » En la parte pública sólo se ve la parte pública de P » En la parte privada de P.Q se ve también la parte privada de P

– El cuerpo de P.Q implementa la extensión » Aquí también se ve la parte privada de P

– Cuando se hace with P.Q se importa también P » Pero use P.Q no implica use P

– La jerarquía se puede hacer tan profunda como sea necesario – La especificación de los hijos depende de la del padre Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

24

Ejemplo (1) package Queues.Extended is function First (Q : in out Queue) return Element; end Queues.Extended;

package body Queues.Extended is function First (Q : in out Queue) return Element is begin return Q.Front.Contents; end First; end Queues.Extended;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

25

Ejemplo (2)

with Queues.Extended; -- se importa también Queues use Queues, Queues.Extended; procedure Advance (Q : Queue) is -- remove first element if equal to some value E : Element; begin if First (Q) = Some_Value then Remove (Q,E); end if; end Advance;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

26

Diagramas de módulos advance

Queues

Programación de sistemas grandes - 28/09/00

Queues. Extended

©1997-2000, Juan Antonio de la Puente

27

Hijos privados u

u

Sirven para extender la implementación de un paquete sin necesidad de recompilar los clientes del padre La especificación de un hijo privado es una extensión de la parte privada del padre – En su especificación se ve la parte privada del padre – Sólo se puede ver en la parte privada de la jerarquía del padre » cuerpo del padre » cuerpo de los descendientes públicos del padre » especificación y cuerpo de los descendientes privados del padre

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

28

Ejemplo (1) private package Queues.Internals is procedure Copy (E : in Element; Q : in out Queue_Node); end Queues.Internals; package body Queues.Extended is procedure Copy (E : in Element; Q : in out Queue_Node) is begin ... end Copy; end Queues.Extended;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

29

Diagramas de módulos Queues. Extended

client

hijo privado

Queues. Extended. Debug

hijo público

Queues

hijo privado

Queues. Internals

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

30

Contenido u u u u u u u

Introducción Ocultamiento de información Tipos abstractos de datos Compilación separada Objetos Reutilización Programación en C++

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

31

Programación mediante objetos u

u

Un objeto es un elemento (constante o variable) de un tipo abstracto de datos Para realizar programas a partir de objetos es interesante disponer de – – – –

tipos extensibles con herencia constructores de objetos con iniciación automática destructores con terminación automática selección de operaciones durante la ejecución (dynamic dispatching)

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

32

Tipos extensibles u

u

u

u

En Ada, un tipo derivado hereda las operaciones primitivas del progenitor Se pueden añadir o modificar las operaciones del tipo Si el tipo es un registro extensible (tagged record) se pueden añadir también componentes Una clase es la unión de todos los tipos que derivan de un antepasado común (la raíz de la clase)

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

33

Ejemplo type Point is tagged record X, Y : Float; end record; procedure Plot (P : Point);

type 3D_Point is new Point with record Z : Float; end record; procedure Plot (P : 3D_Point);

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

34

Clases y selección dinámica u

u

Cada tipo extensible T tiene asociado otro tipo T’Class que comprende los valores de T y sus descendientes Las operaciones sobre objetos de este tipo se seleccionan durante la ejecución procedure General_Plot (P : Point’Class) is begin -- otras operaciones Plot (P); end General_Plot;

u

En sistemas de tiempo real hace más difícil el análisis del tiempo de respuesta

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

35

Diagramas de clases (1)

Coordinates

Waypoint

Point

3D_Point

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

36

Diagramas de clases (2) Coordinates

Waypoint

Update

Distance

Point X: Float Y:Float Plot

3D-Point Z: Float Plot

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

37

Tipos controlados u

u

Son derivados de un tipo predefinido Ada.Finalization.Controlled Se pueden definir subprogramas que se ejecutan automáticamente al – crear un objeto – destruir un objeto – asignar un valor a un objeto

Programación de sistemas grandes - 28/09/00

— Initialize — Finalize — Adjust

©1997-2000, Juan Antonio de la Puente

38

Contenido u u u u u u u

Introducción Ocultamiento de información Tipos abstractos de datos Compilación separada Objetos Reutilización Programación en C

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

39

Reutilización de software u

u

La reutilización de componentes mejora la productividad y la calidad del software El tipado fuerte es un inconveniente – por ejemplo, habría que repetir el paquete Queues para distintos tipos de elementos

u

u

Una solución es construir plantillas o componentes genéricos a partir de los cuales se pueden producir ejemplares concretos En Ada, los paquetes y subprogramas pueden ser genéricos

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

40

Ejemplo: colas genéricas generic type Element is private; -- tiene al menos las operaciones ":=" y "=" package Generic_Queues is -- tipo abstracto type Queue is limited private; -- operaciones primtivas procedure Create (Q : in out Queue); function Empty (Q : Queue) return Boolean; procedure Insert (Q : in out Queue; E : Element); procedure Remove (Q : in out Queue; E : out Element); private -- como antes end Generic_Queues;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

41

Ejemplares declare type Process_Id is ...; package Integer_Queues is new Generic_Queues (Integer); package Process_Queues is new Generic_Queues (Process_Id); use Integer_Queues; use Process_Queues; Value_Queue : Integer_Queues.Queue; Ready_Queue : Process_Queues.Queue; P : Process_Id; begin Create (Value_Queue); -- la operación se selecciona al compilar Create (Ready_Queue); ... Insert (Ready_Queue, P); ... end;

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

42

Parámetros genéricos u

Ada utiliza un modelo de contrato para los parámetros genéricos – Tipos » discretos » enteros » reales

type type type type

T T T T

is is is is

(); range (); digits (); delta ();

» formaciones » derivados, extensibles, privados, privados limitados

– Objetos – Subprogramas – Paquetes

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

43

Diagramas de módulos Integer

type Element

Integer Queues

Generic Queues

Process

Process Queues

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

44

Contenido u u u u u u u

Introducción Ocultamiento de información Tipos abstractos de datos Compilación separada Objetos Reutilización Programación en C

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

45

Programación de sistemas grandes en C u u u u

u

Se pueden construir módulos con ficheros .h y .c No hay relación formal entre ellos No hay tipado fuerte Los detalles de los tipos abstractos se ocultan mediante punteros No hay módulos genéricos

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

46

Ejemplo: cola (1) /* queue.h -- especificación */ typedef int element; struct queue_t; typedef struct queue_t *queue_ptr_t; queue_ptr_t int empty void insert void remove

create (); (queue_ptr_t Q); (queue_ptr_t Q, element E); (queue_ptr_t Q, element *E);

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

47

Ejemplo: cola (2) /* queue.c -- cuerpo */ #include "queue.h” struct queue_node_t { element contents; struct queue_node_t *next; }; struct queue_t { struct queue_node_t *front; struct queue_node_t *back, }; queue_ptr_t create () { queue_ptr_t Q; Q = (struct queue_t) malloc (sizeof(struct queue_t)); Q->front = NULL; Q->back = NULL; return Q; }; /* etc */ Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

48

Ejemplo: cola (3) /* uso del módulo */ #include "queue.h” main () { queue_ptr_t value_queue; element x, y; value_queue = create (); ... insert (value_queue, x); ... remove (value_queue, &y); ... }

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

49

Resumen u

u

El mecanismo básico de descomposición y abstracción es el módulo Los módulos permiten trabajar con – ocultamiento de información – tipos abstractos de datos – compilación separada

u

Otras técnicas asociadas a la programación basada en objetos son – extensión y herencia – iniciación, terminación y ajuste automáticos – selección dinámica de operaciones

u

Los componentes genéricos o plantillas facilitan la reutilización del software

Programación de sistemas grandes - 28/09/00

©1997-2000, Juan Antonio de la Puente

50

dit UPM

Sistemas cíclicos Juan Antonio de la Puente DIT/UPM

Objetivos ‹

Repasar algunos problemas concretos relacionados con la realización de sistemas de tiempo real

‹

Introducir un método de diseño de sistemas basado en una arquitectura síncrona – el elemento fundamental es un ejecutivo cíclico

‹

Evaluar las ventajas e inconvenientes de este tipo de arquitectura

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

1

Concurrencia – Los sistemas de tiempo real controlan actividades del mundo exterior que son simultáneas – Para ello deben ejecutar varias actividades o tareas en paralelo (concurrentemente) – La ejecución de las tareas se multiplexa en el tiempo en uno o varios procesadores

activa A

ejecutándose

inactiva

B C

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

2

Requisitos temporales Los requisitos de tiempo real suelen referirse a ‹

El principio del intervalo de ejecución (esquema de activación) – Tareas periódicas: se ejecutan a intervalos regulares – Tareas esporádicas:: se ejecutan cuando ocurren determinados sucesos (en instantes distribuidos irregularmente )

‹

El final del intervalo de ejecución – Se suele especificar un plazo (relativo al instante de activación) para terminar la ejecución

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

3

Tareas periódicas y esporádicas

T (período)

Tarea periódica T D

D (plazo)

fallo t

T (separación)

Tarea esporádica D

D (plazo)

t

©2001-2002 Juan Antonio de la Puente

STRL - 30/09/2002

4

Modelo de tareas cíclico ‹

Hay muchos sistemas de tiempo real que sólo tienen tareas periódicas – son más fáciles de construir – su comportamiento está completamente determinado

‹

Inicialmente consideramos que no hay comunicación entre tareas (tareas independientes) C

HRT-HOOD :

STRL - 30/09/2002

C

C

©2001-2002 Juan Antonio de la Puente

5

Arquitecturas de software ‹

Definen la estructura general de una clase de sistemas de tiempo real

‹

Hay dos tipos principales de arquitecturas – Arquitectura síncrona » las tareas se ejecutan según un plan de ejecución fijo (realizado por el diseñador) » el sistema operativo se reemplaza por un ejecutivo cíclico

– Arquitectura asíncrona » las tareas se reparten el procesador de forma dinámica (invisible para el diseñador) » cada tarea tiene una prioridad » en cada momento se ejecuta la tarea activa de mayor prioridad

©2001-2002 Juan Antonio de la Puente

STRL - 30/09/2002

6

Arquitectura síncrona reloj ejecutivo cíclico

tarea 1

STRL - 30/09/2002

tarea 2

©2001-2002 Juan Antonio de la Puente

tarea 3

7

Arquitectura asíncrona

tarea 1

tarea 2

tarea 3

sistema operativo

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

8

Planificación cíclica

‹ ‹

‹ ‹

STRL -

Si todas las tareas son periódicas, se puede confeccionar un plan de ejecución fijo Se trata de un esquema que se repite cada TM = mcm(Ti ) (ciclo principal) El ciclo principal se divide en ciclos secundarios, con (TM = k ⋅ TS) período TS En cada ciclo secundario se ejecutan las actividades correspondientes a determinadas tareas

©2001-2002 Juan Antonio de la Puente

9

Ejemplo 1 C

A

C

T= 20 ms D= 20 ms

B

T= 40 ms D= 40 ms

Plan cíclico: TM = 40 ms TS = 20 ms ciclo principal

ciclo principal

ciclo secundario

ciclo secundario

ciclo secundario

c

d

c

A 0

B 10

STRL - 30/09/2002

A 20

A 30

40

ciclo secundario

d B

50

A 60

©2001-2002 Juan Antonio de la Puente

70

80

10

Ejecutivo cíclico

procedure Cyclic_Executive is type Frame is mod 2; Index :Frame := 0; begin loop Wait_Clock_Interrupt; -- cada 20ms case Index is when 0 => A; B; when 1 => A; end case; Index := Index + 1; end loop; end Cyclic_Executive;

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

11

Plazos de respuesta

‹ ‹

Se comprueba que se cumplen los plazos directamente sobre el plan de ejecución Para ello hace falta conocer el tiempo de cómputo de cada tarea Ejemplo: A: B:

T = 20 ms T = 40 ms

A,B

0

A

DA

A

D = 20 ms D = 40 ms

C = 8 ms C = 12 ms

DA DB

B

A

10

20

30

40

©2001-2002 Juan Antonio de la Puente

STRL - 30/09/2002

12

Factor de utilización

‹

La cantidad U =

N

i =1

‹ ‹

Ci

∑T

i

se denomina factor de utilización del procesador Es una medida de la carga del procesador para un conjunto de tareas Para poder elaborar un plan de ejecución que garantice los plazos de todas las tareas, debe ser U ≤ 1

STRL -

©2001-2002 Juan Antonio de la Puente

13

Parámetros del plan cíclico

‹

Los períodos de los ciclos principal y secundario deben cumplir ciertas condiciones (Baker&Shaw, 1989) 1. TS ≥ max Ci 2. ∃i : Ti TS  − Ti TS = 0 3. ∀i : TS + [TS − mcd(TS ,Ti )] ≤ Di

‹

La última condición permite detectar fallos de tiempo de respuesta – hay un ciclo secundario completo entre la activación y el límite del plazo de respuesta de una tarea – a veces es aceptable exigir únicamente

∀i : TS + [TS − mcd(TS ,Ti )] ≤ Ti

©2001-2002 Juan Antonio de la Puente

STRL - 30/09/2002

14

Ejemplo 2

Tarea T1 T2 T3 T4

C 10 18 10 20

U = 0,76 TM = 200

STRL - 30/09/2002

T D 40 40 50 50 200 200 200 200

1) TS ≥ 20 2 ) TS ∈ {20,40,50,100,200} 3 ) 2TS − mcd(TS ,40 ) ≤ 40 2TS − mcd(TS ,50 ) ≤ 50 2TS − mcd(TS ,200 ) ≤ 200 TS = 20

©2001-2002 Juan Antonio de la Puente

15

Ejemplo 2: plan cíclico

T4 T3 T2 T1

T1 T3 0

T2

T1 40

T4

T2 80

T1

T2

T1

120

T1 160

T2 200

©2001-2002 Juan Antonio de la Puente

STRL - 30/09/2002

16

Tareas aperiódicas ‹ ‹ ‹

El ejecutivo cíclico sólo permite ejecutar tareas periódicas Las tareas esporádicas se ejecutan con un servidor de consulta (polling server) Es una tarea periódica que consulta si se ha producido el suceso esporádico o no – el período depende de la separación mínima entre eventos y del plazo de respuesta S suceso

C

servidor

START

suceso

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

17

Recursos compartidos

‹ ‹

Una tarea (o segmento) se ejecuta sin interrupción hasta que termina No es necesario proteger los recursos compartidos – la exclusión mutua es automática C

Pr

C

Se realiza como un objeto pasivo

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

18

Segmentación de tareas

‹ ‹ ‹

A veces no es posible confeccionar un plan cíclico que garantice los plazos Si U ≤ 1, es posible planificar la ejecución segmentando una o más tareas Los segmentos son secuencias de instrucciones de la tarea con un tiempo de cómputo conocido

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

19

Ejemplo 3

Tarea T1 T2 T3

C 40 4 10

T 80 20 40

1) TS ≥ 40 2 ) TS ∈ {40,80} 3 ) 2TS − mcd(TS ,80 ) ≤ 80

D 80 5 40

2TS − mcd(TS ,20 ) ≤ 5 2TS − mcd(TS ,40 ) ≤ 40

U = 0,95 TM = 80

‹ ‹

Ningún valor cumple (3) No hay solución aceptable

©2001-2002 Juan Antonio de la Puente

STRL - 30/09/2002

20

Ejemplo 3: segmentación

Tarea T1.1 T1.2 T1.3 T1.4 T2 T3

C 6 16 6 12 4 10

T 80 80 80 80 20 40

1) TS ≥ 16 2 ) TS ∈ {20,40,80} 3 ) 2TS − mcd(TS ,80 ) ≤ 80

D 80 80 80 80 5 40

2TS − mcd(TS ,20 ) ≤ 5 2TS − mcd(TS ,40 ) ≤ 40

U = 0,95 ‹

TM = 80

STRL - 30/09/2002

‹

Ningún valor cumple (3) Hay una solución aceptable con TS = 20

©2001-2002 Juan Antonio de la Puente

21

Ejemplo 3: plan de ejecución

T3 T2 T1

T2

T3

0

T1.1 T2 20

STRL - 30/09/2002

T1.2

T2 40

T3

T1.3 T2

T1.4

60

80

©2001-2002 Juan Antonio de la Puente

22

Ejemplo 3: ejecutivo cíclico

procedure Cyclic_Executive is type Frame is mod 4; Index :Frame := 0; begin loop Wait_clock_Interrupt; -- cada 20ms case Index is when 0 => T2; T3; T1_1; when 1 => T2; T1_2; when 2 => T2; T3; T1_3; when 3 => T2; T1_4; end case; end loop; end Cyclic_Executive;

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

23

Problemas de la segmentación

‹ ‹ ‹

A veces es difícil ajustar el tiempo de cómputo de los segmentos Si hay recursos compartidos, cada sección crítica debe estar incluida en un solo segmento Si se modifica una sola tarea hay que rehacer la planificación completa – y posiblemente volver a segmentar de otra manera

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

24

Construcción del plan cíclico ‹

En general, el problema es NP-duro – no hay algoritmos eficientes que resuelvan todos los casos

‹

Se usan algoritmos heurísticos – se construye un árbol de soluciones parciales – se puede empezar colocando las tareas más urgentes – se podan las ramas según algún criterio heurístico

‹

Es más fácil cuando el sistema es armónico – pero esto puede forzar una mayor utilización del procesador

‹

Cuando los períodos son muy dispares es más difícil – muchos ciclos secundarios en cada ciclo principal

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

25

Conclusiones ‹

Los sistemas cíclicos, con arquitectura síncrona, tienen muchas ventajas – implementación sencilla y robusta – determinismo temporal – es posible certificar que son seguros

‹

Pero tienen inconvenientes importantes – mantenimiento difícil y costoso » si se cambia algo hay que empezar desde el principio » la segmentación añade mucha complejidad

– es difícil incluir tareas esporádicas ‹

En general, es un método de bajo nivel

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

26

Bibliografía

‹

‹ ‹

Burns & Wellings, Real-Time Systems and Programming Languages, capítulos 7 y 13 Liu, Real-Time Systems, capítulo 5 Kopetz, Real-Time Systems, capítulo 11

STRL - 30/09/2002

©2001-2002 Juan Antonio de la Puente

27

dit UPM

Fiabilidad y tolerancia de fallos Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 5 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languuages, 3ª edición (2001)

Objetivos

‹

Veremos cuáles son los factores que afectan a la fiabilidad de un sistema

‹

También veremos algunas técnicas para tolerar fallos de software

STRL -30/05/01

©2001 Juan Antonio de la Puente

1

1

Índice ‹ ‹ ‹ ‹

Fiabilidad, averías y fallos Modos de fallo Prevención y tolerancia de fallos Redundancia estática y dinámica – Programación con N versiones – Bloques de recuperación

‹ ‹

Redundancia dinámica y excepciones Seguridad, fiabilidad y confiabilidad

STRL -30/05/01

©2001 Juan Antonio de la Puente

2

Fallos de funcionamiento ‹

Los fallos de funcionamiento de un sistema pueden tener su origen en – – – –

‹

Una especificación inadecuada Errores de diseño del software Averías en el hardware Interferencias transitorias o permanentes en las comunicaciones

Nos centraremos en el estudio de los errores de software

STRL -30/05/01

©2001 Juan Antonio de la Puente

3

2

Conceptos básicos ‹

‹

‹

‹

La fiabilidad (reliability) de un sistema es una medida de su conformidad con una especificación autorizada de su comportamiento Una avería (failure) es una desviación del comportamiento de un sistema respecto de su especificación Las averías se manifiestan en el comportamiento externo del sistema, pero son el resultado de errores (errors) internos Las causas mecánicas o algorítmicas de los errores se llaman fallos (faults)

©2001 Juan Antonio de la Puente

STRL -30/05/01

4

Fallos encadenados ‹

Los fallos pueden ser consecuencia de averías en los componentes del sistema (que son también sistemas)

avería avería

STRL -30/05/01

fallo fallo

error error

©2001 Juan Antonio de la Puente

avería avería

fallo fallo

5

3

Tipos de fallos ‹

Fallos transitorios – desaparecen solos al cabo de un tiempo – ejemplo: interferencias en comunicaciones

‹

Fallos permanentes – permanecen hasta que se reparan – ejemplo: roturas de hardware, errores de diseño de software

‹

Fallos intermitentes – fallos transitorios que ocurren de vez en cuando – ejemplo: calentamiento de un componente de hardware

Debe impedirse que los fallos de todos estos tipos causen averías ©2001 Juan Antonio de la Puente

STRL -30/05/01

6

Tipos de avería (failure modes)

nunca se avería

avería

valor

error de intervalo

STRL -30/05/01

tiempo

error de valor

pronto

nunca (omisión)

avería silenciosa

parada segura

©2001 Juan Antonio de la Puente

arbitrario

avería por retraso

avería incontrolada

avería controlada

7

4

Prevención y tolerancia de fallos ‹

Hay dos formas de aumentar la fiabilidad de un sistema: – Prevención de fallos » Se trata de evitar que se introduzcan fallos en el sistema antes de que entre en funcionamiento

– Tolerancia de fallos » Se trata de conseguir que el sistema continúe funcionando aunque se produzcan fallos

‹

En ambos casos el objetivo es desarrollar sistemas con tipos de averías bien definidos

©2001 Juan Antonio de la Puente

STRL -30/05/01

8

Prevención de fallos ‹

Se realiza en dos etapas: – Evitación de fallos » Se trata de impedir que se introduzcan fallos durante la construcción del sistema

– Eliminación de fallos » Consiste en encontrar y eliminar los fallos que se producen en el sistema una vez construido

STRL -30/05/01

©2001 Juan Antonio de la Puente

9

5

Técnicas de evitación de fallos ‹

Hardware – Utilización de componentes fiables – Técnicas rigurosas de montaje de subsistemas – Apantallamiento de hardware

‹

Software – – – –

Especificación de requisitos rigurosa o formal Métodos de diseño comprobados Lenguajes con abstracción de datos y modularidad Utilización de entornos de desarrollo con computador (CASE) adecuados para gestionar los componentes

©2001 Juan Antonio de la Puente

STRL -30/05/01

10

Técnicas de eliminación de fallos ‹

Comprobaciones – Revisiones de diseño – Verificación de programas – Inspección de código

‹

Pruebas (tests) – Son necesarias, pero tienen problemas: » » » »

STRL -30/05/01

no pueden ser nunca exhaustivas sólo sirven para mostrar que hay errores, no que no los hay a menudo es imposible reproducir las condiciones reales los errores de especificación no se detectan

©2001 Juan Antonio de la Puente

11

6

Limitaciones de la prevención de fallos ‹

Los componentes de hardware fallan, a pesar de las técnicas de prevención – La prevención es insuficiente si » la frecuencia o la duración de las reparaciones es inaceptable » no se puede detener el sistema para efectuar operaciones de mantenimiento

‹

Ejemplo: naves espaciales no tripuladas

‹

La alternativa es utilizar técnicas de tolerancia de fallos

STRL -30/05/01

©2001 Juan Antonio de la Puente

12

Grados de tolerancia de fallos ‹

Tolerancia completa (fail operational) – El sistema sigue funcionando, al menos durante un tiempo, sin perder funcionalidad ni prestaciones

‹

Degradación aceptable (fail soft, graceful degradation) – El sistema sigue funcionando con una pérdida parcial de funcionalidad o prestaciones hasta la reparación del fallo

‹

Parada segura (fail safe) – El sistema se detiene en un estado que asegura la integridad del entorno hasta que se repare el fallo

El grado de tolerancia de fallos necesario depende de la aplicación

STRL -30/05/01

©2001 Juan Antonio de la Puente

13

7

Ejemplo : control de tráfico aéreo funcionalidad funcionalidad completa completa yy tiempo tiempo de de respuesta respuesta correcto correcto

funcionalidad funcionalidad de de emergencia emergencia (sólo (sólo separación separación entre entre aviones aviones))

funcionalidad funcionalidad mínima mínima para para control control de de tráfico tráfico básico básico

sistema sistema de de reserva reserva para para fallos fallos catastróficos catastróficos

STRL -30/05/01

©2001 Juan Antonio de la Puente

14

Redundancia ‹

La tolerancia de fallos se basa en la redundancia

‹

Se utilizan componentes adicionales para detectar los fallos y recuperar el comportamiento correcto

‹

Esto aumenta la complejidad del sistema y puede introducir fallos adicionales

‹

Es mejor separar los componentes tolerantes del resto del sistema

STRL -30/05/01

©2001 Juan Antonio de la Puente

15

8

Redundancia en hardware ‹

Redundancia estática – Los componentes redundantes están siempre activos – Se utilizan para enmascarar los fallos – Ejemplo: » Redundancia modular triple (ó N), TMR/NMR

‹

Redundancia dinámica – Los componentes redundantes se activan cuando se detecta un fallo – Se basa en la detección y posterior recuperación de los fallos – Ejemplos: » sumas de comprobación » bits de paridad

©2001 Juan Antonio de la Puente

STRL -30/05/01

16

Tolerancia de fallos de software ‹

Técnicas para detectar y corregir errores de diseño

‹

Redundancia estática – Programación con N versiones

‹

Redundancia dinámica – Dos etapas: detección y recuperación de fallos – Bloques de recuperación » Proporcionan recuperación hacia atrás

– Excepciones » Proporcionan recuperación hacia adelante

STRL -30/05/01

©2001 Juan Antonio de la Puente

17

9

Programación con N versiones ‹

Diversidad de diseño – N programas desarrollados independientemente con la misma especificación – sin interacciones entre los equipos de desarrollo

‹

Ejecución concurrente – proceso coordinador (driver) » intercambia datos con los procesos que ejecutan las versiones

– todos los programas tienen las mismas entradas – las salidas se comparan – si hay discrepancia se realiza una votación

©2001 Juan Antonio de la Puente

STRL -30/05/01

18

Programación con N versiones

cordinador estado votos

versión 1

STRL -30/05/01

versión 2

©2001 Juan Antonio de la Puente

versión 3

19

10

Comparación consistente

X1

X2

X3 ‹

> x0

> x0 sí

no

‹

> x0

sí ‹

no > y0

> y0

> y0

La comparación de valores reales o texto no es exacta Cada versión produce un resultado correcto, pero diferente de las otras No se arregla comparando con x0+∆, y0+∆

sí

V1

STRL -30/05/01

V2

V3

©2001 Juan Antonio de la Puente

20

Problemas ‹

La correcta aplicación de este método depende de: – Especificación inicial » Un error de especificación aparece en todas las versiones

– Desarrollo independiente » No debe haber interacción entre los equipos » No está claro que distintos programadores cometan errores independientes

– Presupuesto suficiente » Los costes de desarrollo se multiplican ‹ ¿sería mejor emplearlos en mejorar una versión única? » El mantenimiento es también más costoso ‹

Se ha utilizado en sistemas de aviónica críticos.

STRL -30/05/01

©2001 Juan Antonio de la Puente

21

11

Redundancia dinámica en software Cuatro etapas: 1. Detección de errores » no se puede hacer nada hasta que se detecta un error

2. Evaluación y confinamiento de los daños » diagnosis: averiguar hasta dónde ha llegado la información errónea

3. Recuperación de errores » llevar el sistema a un estado correcto, desde el que pueda seguir funcionando (tal vez con funcionalidad parcial)

4. Reparación de fallos » Aunque el sistema funcione, el fallo puede persistir y hay que repararlo

©2001 Juan Antonio de la Puente

STRL -30/05/01

22

Detección de errores ‹

Por el entorno de ejecución – hardware (p.ej.. instrucción ilegal) – núcleo o sistema operativo (p.ej. puntero nulo)

‹

Por el software de aplicación – Duplicación (redundancia con dos versiones) – Comprobaciones de tiempo » watchdog timer » deadline checks

– – – –

Inversión de funciones Códigos detectores de error Validación de estado Validación estructural

STRL -30/05/01

©2001 Juan Antonio de la Puente

23

12

Evaluación y confinamiento de daños ‹

Es importante confinar los daños causados por un fallo a una parte limitada del sistema (firewalling)

‹

Se trata de estructurar el sistema de forma que se minimice el daño causado por los componentes defectuosos (compartimentos estancos, firewalls)

‹

Técnicas – Descomposición modular: confinamiento estático – Acciones atómicas: confinamiento dinámico

STRL -30/05/01

©2001 Juan Antonio de la Puente

24

Recuperación de errores ‹ ‹ ‹

Es la etapa más importante Se trata de situar el sistema en un estado correcto desde el que pueda seguir funcionando Hay dos formas de llevarla a cabo: – Recuperación directa (hacia adelante) (FER) » Se avanza desde un estado erróneo haciendo correcciones sobre partes del estado

– Recuperación inversa (hacia atrás) (BER) » Se retrocede a un estado anterior correcto que se ha guardado previamente

STRL -30/05/01

©2001 Juan Antonio de la Puente

25

13

Recuperación directa ‹ ‹ ‹ ‹

La forma de hacerla es específica para cada sistema Depende de una predicción correcta de los posibles fallos y de su situación Hay que dejar también en un estado seguro el sistema controlado Ejemplos – punteros redundantes en estructuras de datos – códigos autocorrectores

STRL -30/05/01

©2001 Juan Antonio de la Puente

26

Recuperación inversa ‹

Consiste en retroceder a un estado anterior correcto y ejecutar un segmento de programa alternativo (con otro algoritmo) – El punto al que se retrocede se llama punto de recuperación (recovery point) – La acción de guardar el estado se llama chekpointing

‹

No es necesario averiguar la causa ni la situación del fallo – Sirve para fallos imprevistos

‹

¡Pero no puede deshacer los errores que aparecen en el sistema controlado!

STRL -30/05/01

©2001 Juan Antonio de la Puente

27

14

Efecto dominó ‹

Cuando hay tareas concurrentes la recuperación se complica detección de error R11

R12

R13

T1

T2 R21

‹

STRL -30/05/01

R22

Solución: líneas de recuperación consistentes para todas las tareas ©2001 Juan Antonio de la Puente

28

Reparación de fallos ‹ ‹

La reparación automática es difícil y depende del sistema concreto Hay dos etapas – Localización del fallo » Se pueden utilizar técnicas de detección de errores

– Reparación del sistema » Los componentes de hardware se pueden cambiar » Los componentes de software se reparan haciendo una nueva versión » En algunos casos puede ser necesario reemplazar el componente defectuoso sin detener el sistema

STRL -30/05/01

©2001 Juan Antonio de la Puente

29

15

Bloques de recuperación ‹ ‹

Es una técnica de recuperación inversa integrada en el lenguaje de programación Un bloque de recuperación es un bloque tal que – su entrada es un punto de recuperación – a su salida se efectúa una prueba de aceptación » sirve para comprobar si el módulo primario del bloque termina en un estado correcto

– si la prueba de aceptación falla, » se restaura el estado inicial en el punto de recuperación » se ejecuta un módulo alternativo del mismo bloque

– si vuelve a fallar, se siguen intentando alternativas – cuando no quedan más, el bloque falla y hay que intentar al recuperación en un nivel más alto

©2001 Juan Antonio de la Puente

STRL -30/05/01

30

Esquema de recuperación

restaurar punto de recuperación entrada al bloque

establecer punto de recuperación

más

sí

ejecutar alternativa

no

error

test

ok

abandonar punto de recuperación

fallo del bloque

STRL -30/05/01

©2001 Juan Antonio de la Puente

31

16

Sintaxis ensure by

else by

else by

... else by

else error;

Puede haber bloques anidados – si falla el bloque interior, se restaura el punto de recuperación del bloque exterior

STRL -30/05/01

©2001 Juan Antonio de la Puente

32

Ejemplo: ecuación diferencial

ensure error 0, decrementa S en 1 Si S ≤ 0, la tarea se suspende hasta que S > 0 Incrementa S en 1

Down y Up son indivisibles ‹

Otros nombres comunes para las operaciones de un semáforo son: – Wait / Signal – P / V (passieren / vrijmachen) – Secure / Release,

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

10

Ejemplo ‹

Supongamos una definición como la siguiente (ojo, no está predefinida en Ada) package Semaphores is type Semaphore (Initial : Integer := 1) is limited private; procedure Down procedure Up

(S : in out Semaphore); (S : in out Semaphore);

private ... end Semaphores;

‹

La implementación debe garantizar las propiedades de Down y Up

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

11

Exclusión mutua con semáforos Mutex : Semaphore; -- iniciado a 1 por defecto

task T1; task body T1 is begin loop Wait(Mutex); -- sección crítica 1 Up(Mutex); ... end loop; end T1;

task T2; task body T2 is begin loop Wait(Mutex); -- sección crítica 2 Up(Mutex); ... end loop; end T2;

Mutex es un semáforo binario

©2001-2002 Juan Antonio de la Puente

STRL - Datos comunes - 01/10/2002

12

Sincronización condicional Condition : Semaphore(0); task T1; -- espera task body T1 is begin loop S1A; Down(Condition); S1B; end loop; end T1;

task T2; -- avisa task body T2 is begin loop S2A; -- establece condición Up(Condition); S2B; end loop; end T2;

S1B no se ejecuta hasta que T2 avisa que se cumple la condición

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

13

Productor y consumidor (1) package Buffer is -- objeto abstracto procedure Put(X: in Item); procedure Get(X: out Item); end Buffer; package body Buffer is Size : constant Positive := 32; -- por ejemplo subtype Index is mod Size; type Store is array (Index) of Item; Box : Store; First, Last : Index := Index’First; Mutex : Semaphore(1); -- exclusión mutua Full; : Semaphore(0); -- elementos ocupados Empty : Semaphore(Size); -- elementos libres

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

14

Productor y consumidor (2) procedure Put (X : in Item) is begin Down(Empty); Down(Mutex); Box(Last) := X; Last := Last + 1; Up(Mutex); Up(Full); end Put; procedure Get (X : out Item) is begin Down(Full); Down(Mutex); X := Box(First); First := First + 1; Up(Mutex); Up(Empty); end Get; end Buffer;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

15

Problemas de los semáforos ‹

Es fácil cometer errores – Un solo Down o Up mal colocado puede hacer que el programa funcione incorrectamente Ejemplos: Up(S); ... Up(S); -- no hay exclusión mutua Down(S); ... Down(S); -- interbloqueo Up(S); ... Down(S); -- depende

‹

Es mejor usar mecanismos más abstractos y fiables – regiones críticas – monitores – objetos protegidos

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

16

Interbloqueo (deadlock) ‹

Dos procesos están interbloqueados si cada uno de ellos espera un condición o un recurso que depende del otro X,Y : Semaphore;

task T1; task body T1 is begin loop Down(X); Down(Y); -- usar recursos Up(Y)); Up(X); end loop; end T1;

STRL - Datos comunes - 01/10/2002

task T2; task body T2 is begin loop Down(Y); Down(X); -- usar recursos Up(X); Up(Y); end loop; end T2;

©2001-2002 Juan Antonio de la Puente

17

Interbloqueos, bloqueos “vivos” e inanición ‹

Se pueden evitar los interbloqueos asignando los recursos de forma ordenada – no siempre es posible

‹

Se puede intentar asignar los recursos de forma más flexible – pueden aparecer otros problemas: » bloqueo “vivo” (livelock) » los procesos se ejecutan, pero ninguno consigue recursos » inanición (starvation) » los procesos se ejecutan, pero algunos no consiguen el recurso nunca

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

18

Regiones críticas condicionales ‹

Una región crítica es una secuencia de instrucciones que se ejecuta en exclusión mutua – el compilador produce el código de bajo nivel necesario – se identifica la variable compartida a la que se accede en una sección crítica

‹

La sincronización condicional se consigue mediante guardas en las regiones críticas – solo se puede entrar en la región crítica cuando la guarda es verdadera

Ejemplo (ojo, no es Ada): V : shared T; ... region V when condición is ... end region; STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

19

Productor y consumidor (1) package body Buffer is Size : constant Positive := 32; -- por ejemplo subtype Index is mod Size; subtype Count is Natural range 0..Size; type Store is array (Index) of Item; type Buffer_Type is record Box : Store; First, Last : Index := Index’First; Number : Count := 0; end record; Data : shared Buffer_Type;

STRL - Datos comunes - 01/10/2002

-- ¡no es Ada!

©2001-2002 Juan Antonio de la Puente

20

Productor y consumidor (2) procedure Put (X : in Item) is begin region Data when Data.Number < Size do -- ¡no es Ada! Data.Box(Data.Last) := X; Data.Last := Data.Last + 1; Data.Number := Data.Number + 1; end region; end Put; procedure Get (X : begin region Data when X := Data.First := Data.Number := end region; end Get;

out Item) is Data.Number > 0 do Data.Box(Data.First); Data.First + 1; Data.Number - 1;

-- ¡no es Ada!

end Buffer;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

21

Problemas de las regiones críticas ‹

Implementación complicada – cada vez que un proceso sale de una región crítica hay que volver a evaluar las guardas de los procesos que están esperando en otras regiones con la misma variable – para ello hay que reanudar el proceso que espera, que se puede volver a suspender si la guarda es falsa – potencialmente, muchos cambios de contexto

‹

No es obligatorio que estén confinadas en módulos – el programa puede ser difícil de comprobar y mantener

‹

Una solución mejor son los monitores

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

22

Monitores ‹

Un monitor es un módulo cuyas operaciones se ejecutan en exclusión mutua – el compilador produce el código de bajo nivel necesario

‹

La sincronización condicional se obtiene con variables de condición – dos operaciones primitivas: signal y wait » wait suspende el proceso de forma incondicional y lo pone en una cola asociada a la condición que espera » signal reanuda el primer proceso que espera en la señal » no hay memoria: si no espera nadie, la señal se pierde

– un proceso que espera una condición libera el monitor

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

23

Productor y consumidor (1) monitor Buffer is procedure Put(X: in Item); procedure Get(X: out Item); end Buffer; monitor body Buffer is

-- ¡ojo! no es Ada

-- ¡ojo! no es Ada

Size : constant Positive := 32; -- por ejemplo subtype Index is mod Size; subtype Count is Natural range 0..Size; type Store is array (Index) of Item Box First, Last Number Non_Full Non_Empty

STRL - Datos comunes - 01/10/2002

: : : : :

Store; Index := Index’First; Count := 0; Condition := True; -- ¡ojo! no es Ada Condition := False; -- ¡ojo! no es Ada

©2001-2002 Juan Antonio de la Puente

24

Productor y consumidor (2) procedure Put (X : in Item) is begin if Number = Size then Wait(Non_Full); end if; Box(Last) := X; Last := Last + 1; Number := Number + 1; Signal(Non_Empty); end Put; procedure Get (X : out Item) is begin if Number = 0 then Wait(Non_Empty); end if; X := Box(First); First := First + 1; Number := Number - 1; Signal(Non_Full); end Get; end Buffer;

STRL - Datos comunes - 01/10/2002

-- ¡ojo! no es Ada

-- ¡ojo! no es Ada

-- ¡ojo! no es Ada

-- ¡ojo! no es Ada

©2001-2002 Juan Antonio de la Puente

25

Problemas de los monitores ‹

Las variables de condición son un mecanismo de bajo nivel

‹

La semántica de signal presenta problemas: – Cuando un proceso hace signal puede haber dos procesos activos en el monitor – Hay varias formas de evitar que se viole la exclusión mutua » permitir signal solo si es la última instrucción de un subprograma » forzar una salida del monitor al hacer signal » suspender el proceso que hace signal si se reanuda otro proceso

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

26

Objetos protegidos en Ada ‹ ‹

Combinación de monitores y regiones críticas condicionales Un objeto protegido es un objeto compuesto cuyas operaciones se ejecutan en exclusión mutua – se pueden declarar tipos protegidos u objetos protegidos únicos – en ambos casos hay especificación y cuerpo. » la especificación contiene la interfaz visible desde otras unidades de programa.

– los tipos y objetos protegidos son unidades de programa, pero no de compilación. » deben estar declarados en una unidad de compilación (paquete o subprograma).

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

27

Ejemplo: entero compartido (1) protected type Shared_Integer(Initial_Value : Integer) is function Value return Integer; procedure Change(New_Value : Integer); private Data : Integer := Initial_Value; end Shared_Integer;

‹ ‹

Las operaciones (subprogramas) se declaran en la parte pública Los detalles de implementación del tipo van en la parte privada – solo son visibles en el cuerpo – no se pueden declarar tipos de datos

‹ ‹

Es parecido a un registro Puede tener discriminantes – tienen que ser de tipos discretos o acceso

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

28

Ejemplo: entero compartido (2) protected body Shared_Integer is function Value return Integer is begin return Data; end Value; procedure Change(New_Value : Integer) is begin Data := New_Value; end Change; end Shared_Integer;

‹ ‹

Los cuerpos de las operaciones van en el cuerpo del tipo protegido No se pueden declarar tipos ni objetos en el cuerpo

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

29

Ejemplo: entero compartido (3) declare X : Shared_Integer(0); Y : Shared_Integer(1); begin X.Change(Y.Value + 1); -- ahora X.Value es 2 end;

‹ ‹

No hay cláusula use para los objetos protegidos Las operaciones deben ir siempre cualificadas con el nombre del objeto

©2001-2002 Juan Antonio de la Puente

STRL - Datos comunes - 01/10/2002

30

Diagramas de procesos ‹

Se usan para representar la interacción entre tareas mediante objetos protegidos

T1 op1 op2

P

op3 T2

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

31

Subprogramas protegidos ‹

Con los objetos protegidos solo se pueden efectuar operaciones protegidas – Un procedimiento protegido da acceso exclusivo en lectura y escritura a los datos privados. – Una función protegida da acceso concurrente en lectura sólo a los datos privados

‹

‹

Se pueden ejecutar concurrentemente varias llamadas a una función protegida, pero no a un procedimiento protegido, ni a ambos a la vez. El núcleo de ejecución realiza la exclusión mutua mediante mecanismos más primitivos – ¡ojo! una tarea que está intentando acceder a un objeto protegido no se considera suspendida » la operaciones protegidas son cortas y no se pueden suspender

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

32

Entradas protegidas y sincronización condicional ‹

Una entrada es una operación protegida con una interfaz semejante a la de un un procedimiento entry E (...);

‹

En el cuerpo se le asocia una barrera booleana entry E (...) when B is ...

– si la barrera es falsa cuando se invoca la operación, la tarea que llama se suspende en una cola de espera – cuando la barrera es verdadera, la tarea puede continuar ‹

Las entradas se usan para realizar sincronización condicional

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

33

Ejemplo: productor y consumidor (1) -- tampón limitado Size : constant Positive := 10; -- por ejemplo type Index is mod Size; subtype Count is Natural range 0 .. Size; type Buffer_Store is array (Index) of Item; protected type Bounded_Buffer is entry Put(X : in Item); entry Get(X : out Item); private First : Index := Index’First; Last : Index := Index'Last; Number : Count := 0; Store : Buffer_Store; end Bounded_Buffer; Buffer : Bounded_Buffer;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

34

Productor y consumidor (2) protected body Bounded_Buffer is entry Put (X : in Item) when Number < Size is begin Last := Last + 1; Store(Last) := X; Number := Number + 1; end Put; entry Get (X : out Item) when Number > 0 is begin X := Store(First); First := First + 1; Number := Number - 1; end Get; end Bounded_Buffer;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

35

Productor y consumidor (3) procedure Producer_Consumer is task Producer; task Consumer; task body Producer is X : Item; begin loop Produce(X); Buffer.Put(X); end loop; end Producer; task body Consumer is X : Item; begin loop Buffer.Get(X); Consume(X); end loop; end Consumer; end Producer_Consumer;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

36

Evaluación de las barreras ‹

Las barreras se evalúan cuando – una tarea llama a una entrada y la barrera hace referencia a una variable que puede haber cambiado desde la última evaluación – una tarea termina la ejecución de un procedimiento o entrada y hay tareas esperando en entradas cuyas barreras hacen referencia a variables que pueden haber cambiado desde la última evaluación

‹

No se deben usar variables globales en las barreras

‹

La corrección de un programa no debe depender del momento en que se evalúan las barreras (se puede hacer con más frecuencia de lo indicado).

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

37

Ejemplo: control de recursos protected Resource_Control is entry Allocate; procedure Deallocate; private Free : Boolean := True; end Resource_Control; protected body Resource_Control is entry Allocate when Free is begin Free := False; end Allocate; procedure Deallocate is begin Free := True; end Deallocate; end Resource_Control;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

38

Exclusión mutua y barreras ‹

Las tareas esperando en barreras tienen preferencia sobre las que esperan acceder al objeto – de esta forma se evitan condiciones de carrera en la implementación

‹

Este modelo se llama cáscara de huevo (eggshell)

tareas esperando entrar tareas esperando en barreras una tarea dentro como máximo

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

39

Restricciones ‹

En el cuerpo de una operación protegida no se pueden ejecutar operaciones "potencialmente bloqueantes": – – – –

llamadas a entradas retardos creación o activación de tareas llamadas a subprogramas que contengan operaciones potencialmente bloqueantes

‹

Tampoco puede haber llamadas al mismo objeto

‹

El objetivo de estas restricciones es evitar que una tarea se quede suspendida indefinidamente en el acceso a un subprograma protegido

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

40

Ejemplo: radiado de mensajes (1)

protected type Broadcast is entry Receive (M : out Message); procedure Send (M : in Message); private New_Message : Message; Message_Arrived : Boolean := False; end Broadcast;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

41

Radiado de mensajes (2) protected body Broadcast is entry Receive (M : out Message) when Message_Arrived is begin M := New_Message; if Receive'Count = 0 then -- ¡el último cierra! Message_Arrived := False; end if; end Receive; procedure Send (M : in Message) is begin if Receive'Count > 0 then Message_Arrived := True; New_Message := M; end if; end Send; end Broadcast;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

42

Ejemplo: sucesos (1) package Events is type Event is limited private; procedure Wait (E : Event); procedure Signal (E : Event); private protected type Event is entry Wait; procedure Signal; private Occurred : Boolean := False; end Event; end Events;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

43

Sucesos (2) package body Events is protected body Event is entry Wait when Occurred is begin if Wait'Count = 0 then Occurred := False; end if; end Wait; procedure Signal is begin if Wait’Count > 0 then Occurred := True; end if; end Signal; end Event;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

44

Sucesos (3)

procedure Wait (E : Event) is begin E.Wait; end Wait; procedure Signal (E : Event) is begin E.Signal; end Signal; end Events;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

45

Ejemplo: tarea esporádica with Events; use Events; ... Button_Pressed : Event; ... task body Sporadic is begin loop Wait (Button_Pressed); -- acción esporádica end loop; end Sporadic; task body Event_Handler is begin ... Signal (Button_Pressed); -- puede activar varias tareas ... end Event_Handler;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

46

Objetos de suspensión ‹

Proporcionan una funcionalidad similar cuando sólo hay una tarea que espera

package Ada.Synchronous_Task_Control is type Suspension_Object is limited private; procedure Set_True (S : in out Suspension_Object); procedure Set_False (S : in out Suspension_Object); function Current_State (S : Suspension_Object) return Boolean; procedure Suspend_Until_True (S : in out Suspension_Object); -- Raises Program_Error if more than one task tries to -- suspend on S at once -- Sets S to False private ... end Ada.Synchronous_Task_Control;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

47

Ejemplo: tarea esporádica with Ada.Synchronous_Task_Control; use Ada.Synchronous_Task_Control; ... Button_Pressed : Suspension_Object; task body Sporadic is ... begin loop Suspend_Until_True (Button_Pressed); -- acción esporádica end loop; end Sporadic; task body Event_Handler is ... begin ... Set_To_True (Button_Pressed); ... end Event_Handler;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

48

Sincronización en C/POSIX.1c ‹

Hay dos mecanismos que permiten emular monitores con interfaz de procedimiento – Un mutex es una variable que proporciona exclusión mutua mediante dos operaciones, lock y unlock – una variable de condición proporciona sincronización condicional mediante dos operaciones, wait y signal

‹ ‹

Ambos tipos de variables pueden tener atributos Otras operaciones: crear y destruir, espera temporizada

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

49

Definiciones /* pthreads.h */ typedef ... pthread_mutext_t; typedef ... pthread_cond_t; ... int pthread_mutex_lock (pthread_mutext_t *mutex); int pthread_mutex_unlock(pthread_mutex_t *mutex); int pthread_cond_wait(pthread_cond_t *cond , pthread_mutext_t *mutex); /* espera y libera el mutex */ int pthread_cond_signal(pthread_cond_t *cond); /* puede reanudar más de un thread */ ...

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

50

Ejemplo: productor y consumidor (1)

#include #define BUFF_SIZE 10 typedef struct { pthread_mutext_t mutex; pthread_cond_t buffer_non_full; pthread_cond_t buffer_non_empty; int count, first, last; int store[BUFF_SIZE]; } buffer_t;

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

51

Productor y consumidor (2) int put(int item, buffer_t *buffer) { pthread_mutex_lock(&buffer->mutex); while (buffer->count == BUFF_SIZE) pthread_cond_wait(&buffer->non_full, &buffer->mutex); buffer[last] = item; last = (last++)%BUFF_SIZE; count++; pthread_cond_signal(&buffer->non_empty); pthread_mutex_unlock(&buffer->mutex); return 0; } int get(int *item, buffer_t *buffer) { pthread_mutex_lock(&buffer->mutex); while (buffer->number == 0) pthread_cond_wait(&buffer->non_empty, &buffer->mutex); item = buffer[first]; first = (first++)% BUFF_SIZE; count--; pthread_cond_signal(&buffer->non_full); pthread_mutex_unlock(&buffer->mutex); return 0; } /* ¡ojo! hay que iniciar el mutex y las variables de condición */

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

52

Resumen ‹ ‹ ‹

El acceso de dos o más tareas concurrentes a las variables comunes debe realizarse en exclusión mutua Otra forma de sincronización está ligada al cumplimento de una condición Algunos mecanismos que permiten conseguir ambas formas de sincronización son: – semáforos – regiones críticas condicionales – monitores

‹ ‹

Los objetos protegidos reúnen las ventajas de las regiones críticas condicionales y los monitores Los mutex y las variables condicionales de POSIX proporcionan un mecanismo similar a los monitores

STRL - Datos comunes - 01/10/2002

©2001-2002 Juan Antonio de la Puente

53

dit UPM

Comunicación mediante mensajes Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 9 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languages, 3ª edición (2001)

Objetivos

‹

Comprender los problemas relacionados con la comunicación entre procesos basada en el intercambio de mensajes

‹

Estudiar la forma de realizar este tipo de comunicación en Ada y C/POSIX

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

1

Comunicación mediante mensajes ‹ ‹ ‹ ‹

Las tareas se pueden comunicar y sincronizar mediante mensajes Esta forma de comunicación no necesita memoria común Se usan los mismos mecanismos para la sincronización y la comunicación Hay tres aspectos de interés: – Sincronización – Identificación del proceso emisor y receptor – Estructura de los mensajes

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

2

Diagramas de secuencia de mensajes

A

send

B

mensaje

STRL - Mensajes - 15/10/2002

‹

‹

Representan la interacción entre procesos mediante el intercambio de mensajes El tiempo va hacia abajo

receive

©2001-2002 Juan Antonio de la Puente

3

Sincronización en el envío de mensajes ‹ ‹

El proceso receptor siempre espera si el mensaje no ha llegado todavía. Para el proceso emisor hay tres modelos básicos: – Comunicación asíncrona: el emisor continúa su ejecución – Comunicación síncrona (cita): el emisor espera a que el receptor reciba el mensaje – Invocación remota (cita extendida): el emisor espera a que el receptor reciba el mensaje, y la respuesta de éste

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

4

Comunicación asíncrona ‹ A

– capacidad potencialmente ilimitada – si es limitado puede bloquearse el emisor

B

‹ send

Hace falta usar un tampón

mensaje

El emisor puede requerir un reconocimiento – diseño complicado

receive

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

5

Comunicación síncrona ‹ A

‹

B

No hace falta tampón Se puede construir a partir de la comunicación asíncrona: A send(m); receive(ack);

send

B receive(m); send(ack);

suspendido mensaje

STRL - Mensajes - 15/10/2002

receive

©2001-2002 Juan Antonio de la Puente

6

Invocación remota

A

B

‹ ‹

send

mensaje

suspendido

receive reply

STRL - Mensajes - 15/10/2002

No hace falta tampón Se puede construir a partir de la comunicación síncrona: A s_send(m);

B s_receive(m); preparar r s_receive(r); s_send(r);

©2001-2002 Juan Antonio de la Puente

7

Identificación del emisor y el receptor ‹

Identificación directa o indirecta » directa: el emisor identifica explíctamente el receptor send mensaje to proceso

» indirecta: se utiliza un intermediario (buzón, canal, tubería, etc.) send mensaje to buzón ‹

Simetría » Comunicación simétrica: el emisor identifica el receptor, y viceversa send mensaje to proceso (buzón) receive mensaje from proceso (buzón) » Comunicación asimétrica: el receptor acepta mensajes de cualquier emisor o buzón » Este tipo de comunicación es adecuado para realizar servidores

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

8

Estructura de los mensajes ‹ ‹

Deberían poderse enviar objetos de cualquier tipo Es difícil de conseguir en un entorno distribuido – diferentes representaciones de tipos de datos – problemas con punteros

‹

Se puede hacer con bibliotecas estándar de “aplanamiento” de tipos – convierten cualquier tipo en una secuencia de octetos

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

9

Índice ‹ ‹

Comunicación mediante mensajes Comunicación entre tareas en Ada – cita extendida – espera selectiva – llamada selectiva

‹

Comunicación entre threads en C/POSIX

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

10

Comunicación entre tareas en Ada ‹

Se basa en un mecanismo de cita extendida – invocación remota directa y asimétrica

‹

Una tarea puede recibir mensajes a través de entradas declaradas en su especificación – la especificación de una entrada es similar a la de un procedimiento – Ejemplo: task type Screen is entry Put (Char : Character; X,Y : Coordinate); end Screen; Display : Screen;

– otras tareas pueden llamar a la entrada Display.Put('A',50,24);

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

11

Entradas ‹

Puede haber entradas homónimas, siempre que tengan distintos parámetros

‹

Se pueden definir familias de entradas con un discriminante discreto

– También puede haber entradas homónimas con subprogramas type Channel is range 0..7; task Multiplexor is entry Get(Channel)(Data : Input_Data); end Multiplexor; ‹

Puede haber entradas privadas task type Telephone_Operator is entry Directory_Enquiry (Person : in Name; Phone : out Number); entry Report_Fault (Phone : in Number); private entry Allocate_Repair_Worker (Id : out Worker_Id); end Telephone_Operator;

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

12

Llamada

‹

Para llamar a una entrada hay que identificar la tarea receptora (no hay cláusula use) Display.Put('A',50,24); Multiplexor.Get(3)(X); Operator.Directory_Enquiry("Juan Pérez", No_de_Juan);

‹

Se puede renombrar una entrada como un procedimiento procedure Enquiry (Person : in Name; Phone : out Number) renames Operator.Directory_Enquiry;

‹

Si se llama a una entrada de una tarea que no está activa, se eleva la excepción Tasking_Error

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

13

Aceptación (1) ‹

Para que se lleve a cabo una cita, la tarea receptora debe aceptar la llamada al punto de entrada correspondiente accept Put(Char : Character; X,Y : Coordinate) do -- escribir Char en la posición (X,Y) end Put; accept Get(3)(Data : Input_Data) do -- leer Data del canal 3 end Get;

– Debe haber al menos un accept por cada entrada (puede haber más) – El índice identifica cuál de las entradas de una familia se acepta » debe haber un accept para cada miembro de la familia

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

14

Aceptación (2) ‹

Una instrucción accept se puede poner en cualquier lugar del cuerpo de una tarea – en particular, se puede poner dentro de otro accept (siempre que sea de distinta entrada) – no se pude poner en un procedimiento

‹

El cuerpo del accept especifica las acciones que se ejecutan cuando se acepta la llamada – La secuencia de instrucciones puede incluir manejadores de excepciones

‹

Si el cuerpo es nulo, se puede usar una forma simplificada: accept E;

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

15

Diagrama de procesos

T2.E

STRL - Mensajes - 15/10/2002

T1

E

T2

accept E

©2001-2002 Juan Antonio de la Puente

16

Ejecución de una cita extendida ‹

Las dos tareas deben estar listas para realizar la comunicación. – la que llega primero a la cita se suspende hasta que la otra ejecuta la instrucción complementaria (llamada o aceptación)

‹

Cuando las dos están listas – se pasan los parámetros de entrada a la tarea llamada – se ejecuta el cuerpo del accept – se copian los parámetros de salida al cliente

‹ ‹ ‹

A continuación, las dos continúan su ejecución asíncronamente. Si varias tareas invocan el mismo punto de entrada de otra tarea, se colocan en una cola Una tarea que espera para poder realizar una cita permanece suspendida durante el tiempo que dura la espera

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

17

Sincronización (1)

A

B.E(X,Y)

B

X accept E(X : in T; Y : out T) Y := X; end E;

Y

©2001-2002 Juan Antonio de la Puente

STRL - Mensajes - 15/10/2002

do

18

Sincronización (2)

A

B

accept E(X : in T; Y : out T) X B.E(X,Y) Y

STRL - Mensajes - 15/10/2002

do Y := X; end E;

©2001-2002 Juan Antonio de la Puente

19

Excepciones en citas ‹

Puede elevarse una excepción cuando se está ejecutando una cita – si hay un manejador en el cuerpo del accept, la cita termina normalmente – si la excepción no se maneja dentro del accept, » la cita termina inmediatamente » la excepción se vuelve a elevar en las dos tareas (puede ser anónima en la que llama)

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

20

Ejemplo accept Directory_Enquiry (Person : in Name; Phone : out Number) do Data_Base.Lookup (Person, Phone_Record); Phone := Phone_Record.Phone_Number; exception when Data_Base.Not_Found => Phone := No_Phone; end Directory_Enquiry;

– Si durante la ejecución de Lookup se produce la excepción Not_Found, se recupera el error dando un valor nulo al parámetro Phone y se termina la cita – El cliente y el servidor continúan normalmente – Si se produce cualquier otra excepción, la cita termina y la excepción se propaga en los dos, inmediatamente después de la llamada en el cliente, y de la aceptación en el servidor

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

21

Espera selectiva ‹ ‹

A menudo no es posible prever en qué orden se van a invocar las distintas entradas de una tarea Esto ocurre cuando sobre todo en las tareas servidoras – Un servidor es una tarea que acepta llamadas a una o más entradas, y ejecuta un servicio para cada una de ellas – un cliente es una tarea que solicita servicios llamando a las entradas de un servidor – Los servidores no saben en qué orden les van a llamar los clientes » deben estar dispuestos a aceptar cualquier llamada cuando no están ocupados

‹

Es necesario que una tarea pueda esperar simultáneamente llamadas en varias entradas

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

22

Aceptación selectiva en Ada ‹

Es una estructuraa de control que permite la espera selectiva en varias alternativas select accept entrada_1 do -- alternativa_1 ... end entrada_1; [secuencia_de_instrucciones] or accept entrada_2 do -- alternativa 2 ... end entrada_2; [secuencia_de_instrucciones] or ... end select;

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

23

Ejemplo

task body Telephone_Operator is begin loop select accept Directory_Enquiry (Person : in Name; Phone : out Number) do -- buscar el número y asignar el valor a Phone end Directory_Enquiry; or accept Report_Fault (Phone : Number) do -- avisar al servicio de mantenimiento end Report_Fault; end select; end loop; end Telephone_Operator;

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

24

Alternativas guardadas ‹

‹ ‹

A veces es necesario que alguna de las alternativas de una selección se acepte sólo en determinadas condiciones. Se pueden poner guardas en las alternativas. Una guarda es una expresión booleana. when condición => alternativa

‹

Las guardas se evalúan al ejecutar el select – Las alternativas cuyas guardas son verdaderas se tienen en cuenta para la selección. Se dice que estas alternativas están abiertas – Las alternativas cuyas guardas son falsas se ignoran. Se dice que estas alternativas están cerradas – Se considera un error que todas alternativas estén cerradas

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

25

Ejemplo

task body Telephone_Operator is begin loop select accept Directory_Enquiry(Person : in Name; Phone : out Number) do -- buscar el número y asignar el valor a Phone end Directory_Enquiry; or when Today in Weekday => accept Report_Fault (Phone : Number) do -- avisar al servicio de mantenimiento -- (sólo en días laborables) end Report_Fault; end select; end loop; end Telephone_Operator;

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

26

Selección condicional ‹

Una instrucción select puede tener una parte final de la forma: select alternativa {or alternativa} else secuencia_de_instrucciones end select;

– La parte else se ejecuta si al llegar al select no se puede aceptar inmediatamente ninguna otra alternativa – No puede haber parte else y alternativas temporizadas en un mismo select – La parte else no es una alternativa y, por tanto, no puede estar guardada STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

27

Alternativa terminate ‹

Una de las alternativas de un select puede tener la forma: terminate;

‹

Esta alternativa se selecciona cuando – el tutor de la tarea ha completado su ejecución – todas las tareas que dependen del mismo dueño están terminadas o esperando en un select con una alternativa terminate » En este caso terminan todas ellas simultáneamente

‹ ‹ ‹

Es conveniente que las tareas servidoras terminen así La alternativa terminate puede estar guardada Es incompatible con las alternativas temporizadas y con la parte else

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

28

Resumen de la aceptación selectiva ‹

Se evalúan las guardas; sólo se consideran las alternativas abiertas (guardas verdaderas) – si todas las alternativas están cerradas se eleva Program_Error

‹

Si hay llamadas en una o más alternativas abiertas, se elige una de forma indeterminista – se ejecuta el accept y la secuencia que le sigue, y termina el select

‹

Si no hay llamadas pendientes – si hay parte else se ejecuta inmediatamente y se termina el select – si no, la tarea se suspende hasta que llegue una llamada a una de las alternativas abiertas – si hay alternativa terminate y ya no se pueden recibir más llamadas, termina la tarea

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

29

Llamada condicional

‹

La llamada condicional permite que un cliente retire su petición si no es aceptada inmediatamente select llamada_a_entrada; [secuencia_de_instrucciones] else secuencia de instrucciones end select;

– Si la llamada no se acepta inmediatamente, se abandona y se ejecuta la parte else – Aquí tampoco puede haber más de una alternativa – Sólo se debe usar si la tarea puede realizar trabajo útil cuando no se acepta la llamada

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

30

Tareas y exclusión mutua ‹

Una tarea sólo puede ejecutar una instrucción accept en un momento dado. – Los cuerpos de las instrucciones accept están en exclusión mutua – Esto asegura la integridad de los recursos de las tareas servidoras – Se puede usar para emular un objeto protegido en Ada 83

Ejemplo task type Server is -- gestiona un recurso global entry S1(...); -- servicio S1 entry S2(...); -- servicio S2 ... -- etc. end Server;

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

31

Esquema de servidor task body Server is -- estructura de datos del recurso begin loop select accept S1 (...) do ... end S1; or accept S2 (...) do ... end S2; ... or ... end select; ... end loop; end Server;

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

32

Mensajes en C/POSIX.1c ‹ ‹ ‹ ‹

Las colas de mensajes permiten efectuar comunicación asíncrona, indirecta y simétrica entre threads o procesos Una cola de mensajes puede tener varios escritores y lectores Las colas tienen nombre Cada cola tiene un tampón asociado – si se llena, se bloquea el emisor (se puede anular) – el receptor se bloquea si el tampón está vacío – Si hay varios threads bloqueados se reanuda uno arbitrariamente » se puede especificar que se reanude el más prioritario

‹

Hay más opciones, bastante complicadas

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

33

Definiciones

/* mqueue.h */ typedef ... mqd_t; struct mq_attr { long mq_flags; long mq_maxmsg; long mq_msgsize; long mq_curmsgs }

/* message queue descriptor */ /* /* /* /*

message queue flags */ maximum number of messsages */ maximum message size */ number of messages queued */

mqdt_t mq_open(const char *name, int oflag); int mq_close(mqd_t mqdes); int mq_send(mqd_t mqdes, const char *msg_ptr, size_t msg_len, unsigned int msg_prio); sssize_t mq_receive(mqd_t mqdes, char *msg_ptr, size_t msg_len, unsigned int *msg_prio);

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

34

Resumen

‹

En Ada las tareas pueden comunicarse por medio de citas, según un modelo de clientes y servidores – Una tarea puede tener entradas, que se pueden llamar desde otras tareas – La tarea receptora debe aceptar la llamada para que se produzca la cita – La tarea que llama espera si la llamada todavía no se ha aceptado

‹

La aceptación selectiva permite: – Esperar simultáneamente llamadas en varias entradas – Ejecutar acciones alternativas cuando no hay llamadas pendientes – Terminar la ejecución de un servidor cuando ya no es necesario

‹ ‹

La llamada condicional permite evitar que una tarea se quede esperando la aceptación de una cita Las colas de mensajes de POSIX permiten efectuar comunicación asíncrona, indirecta y simétrica

STRL - Mensajes - 15/10/2002

©2001-2002 Juan Antonio de la Puente

35

dit dit UPM UPM

Sucesos asíncronos Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 10del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languages, 3ª edición (2001)

Sucesos asíncronos ‹

‹

Un suceso asíncrono es una señal generada por un proceso que requiere atención por parte de otro proceso, independientemente de lo que esté haciendo Dos formas de continuar después de atender el suceso: – reanudación » ej.: señales de POSIX

– terminación » ej.: transferencia de control asíncrona en Ada

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

2

1

Aplicaciones ‹

Recuperación de errores – cuando varios procesos colaboran la recuperación hay que hacerla conjuntamente

‹

Cambios de modo – debidos a cambios en el entrono o a averías

‹

Cómputo impreciso – se hace lo que se puede hasta que se agota el tiempo disponible

‹

Interrupciones del operador – a veces hay que dejar lo que se está haciendo y empezar de nuevo o cambiar de modo

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

3

Señales en POSIX.1 ‹

Una señal representa un suceso asíncrono que afecta a uno o más procesos o threads

‹

Una señal se puede producir o generar de varias formas, por ejemplo: – fallos de hardware – expiración de temporizadores – un acción explícita de otro proceso o thread, invocando la función kill u otra similar

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

4

2

Identificadores de señal ‹ ‹

‹

Cada tipo de señal se identifica mediante un número positivo Se definen constantes para dar nombres simbólicos a las señales Ejemplos: – SIGABRT – SIGALRM – SIGUSR1, SIGUSR2

STRL - sucesos asíncronos - 15/10/2002

Terminación anormal Temporizador Definidas por el usuario

©2001-2002 Juan Antonio de la Puente

5

Generación y entrega ‹ ‹

Una señal se genera cuando ocurre el suceso que la produce Una señal se entrega cuando se produce la acción asociada en el proceso o thread: – Ignorar la señal – Ejecutar la acción por defecto asociada a la señal (normalmente terminar el proceso) – Manejar la señal mediante una función definida por el programador

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

6

3

Bloqueo de señales

‹

Un proceso puede enmascarar o bloquear un tipo de señales – cada proceso o thread tiene una máscara que define las señales bloqueadas – la máscara se hereda inicialmente del padre

‹

Una señal bloqueada se acepta cuando se invoca una función sigwait – esta función se define en POSIX.1b

©2001-2002 Juan Antonio de la Puente

STRL - sucesos asíncronos - 15/10/2002

7

Esquema general

ignorar

terminar entregar

fin manejar

generar

thread

pendiente

STRL - sucesos asíncronos - 15/10/2002

aceptación

©2001-2002 Juan Antonio de la Puente

8

4

Señales de tiempo real (POSIX.1b) ‹

Tienen identificadores en el intervalo SIGRTMIN .. SIGRTMAX – como mínimo 32 señales

‹

Las señales de tiempo real tienen propiedades especiales: – se encolan – se aceptan en orden de prioridad (número de señal) – tienen un campo adicional de información

‹

Todas las señales se pueden aceptar de forma síncrona mediante la función sigwait – para ello deben estar enmascaradas (bloqueadas)

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

9

Señales y threads ‹ ‹ ‹ ‹

‹

Las señales generadas por un error de un thread se envían sólo a ese thread Las generadas por un suceso asíncrono (p.ej. E/S) se envían al proceso Las generadas por programa se pueden enviar a un thread o a todo un proceso Una señal generada para un thread en el que está bloqueda se queda pendiente hasta que se acepta con sigwait Una señal generada para un proceso que está bloqueada en todos los threads se envía a un solo thread de los que hacen sigwait en la señal

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

10

5

Conjuntos de señales

/* signal.h */ typedef ... sigset_t; int int int int int

sigemptyset sigfillset sigaddset sigdelset sigismember

(sigset_t *set); (sigset_t *set); (sigset_t *set, int signo); (sigset_t *set, int signo); (const sigset_t *set, int signo);

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

11

Bloqueo de señales /* signal.h */ int sigprocmask (int how, const sigset_t *set, sigset_t *oset); int pthread_sigmask (int how, const sigset_t *set, sigset_t *oset);

‹

how: indica qué operación se hace: – SIG_BLOCK : – SIG_UNBLOCK: – SIG_SETMASK:

‹ ‹

se bloquean las señales de set se desbloquean las señales de set se hace la máscara igual a set

oset: devuelve las señales que estaban bloqueadas antes set y oset pueden valer NULL

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

12

6

Envío y aceptación de señales /* signal.h */ int kill (pid_t pid, int sig); int pthread_kill (pthread_t thread, int sig);

/* signal.h */ int sigwait (const sigset_t *set, int *sig); int sigwaitinfo (const sigset_t *set, siginfo_t *siginfo); int sigtimedwait (const sigset_t *set, siginfo_t *siginfo, const struct timespec *timeout);

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

13

Ejemplo (1) /* thread que acepta SIGINT (^C) y escribe un mensaje */ #include #include void wait_sigint (void) { sigset_t set; int sig; int counter = 0; sigemptyset(&set); sigaddset(&set,SIGINT); pthread_sigmask(SIG_BLOCK, &set, NULL); /* bloquea SIGINT */ /* todos los demás threads deben bloquear también SIGINT */

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

14

7

Ejemplo (2) if (sigwait(&set, &sig) != 0) { /* error en sigwait */ pthread_exit( (void *)-1); } if (sig == SIGINT) { printf ("recibido SIGINT\n"); pthread_exit(0); } else { /* señal inesperada */ pthread_exit ((void *)-1); } }

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

15

Manejadores de señales /* signal.h */ struct sigaction { void (*)() sa_handler; sigset_t sa_mask; int sa_flags; void (*)(int, siginfo_t *, void *) sa_sigaction; } int sigaction (int sig, const struct sigaction *reaction, struct sigaction *old_reaction);

‹ ‹

sa_handler puede ser SIG_DFL, SIG_IGN o un puntero a una función sa_sigaction se usa con señales de tiempo real

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

16

8

Transferencia de control asíncrona en Ada ‹

Es una forma especial de select: select suceso; secuencia de instrucciones then abort secuencia de instrucciones end select;

‹

El suceso puede ser – Una llamada a una entrada Objeto.Entrada (...); -- puede ser una llamada a una tarea

– Un retardo delay ...;

STRL - sucesos asíncronos - 15/10/2002

©2001-2002 Juan Antonio de la Puente

17

9

dit UPM

Tiempo real Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 12 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languages, 3ª edición (2001)

Tiempo real ‹

Objetivo – Comprender el papel del tiempo en el diseño y realización de sistemas de tiempo real

‹

Contenido: – – – – –

Sistemas de referencia de tiempo Relojes, retardos y límites temporales (time-outs) Requisitos temporales Ámbitos temporales Tolerancia de fallos

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

1

Necesidades ‹

Acceso al tiempo real – leer el paso del tiempo en relojes – retrasar la ejecución de los procesos durante un tiempo – definir límites temporales para la ocurrencia de un suceso (time-outs)

‹

Representación de los requisitos temporales – períodos de activación – plazos de ejecución

‹

Análisis del cumplimiento de los requisitos temporales – lo veremos en el próximo tema

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

2

Tiempo universal ‹

TU ó UT (Universal Time) – tiempo solar medio en el meridiano 0 (Greenwich) » definido en 1884 (entonces se llamaba GMT)

1 s = 1/86 400 de un día solar medio » definición oficial hasta 1955

‹

Relativamente impreciso y difícil de determinar – la duración del día no es constante » pérdida de energía por las mareas » otros fenómenos irregulares

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Sistemas de referencia de tiempo - 3

Tiempo de efemérides ‹

Año trópico – tiempo transcurrido entre dos pasos de la Tierra por el punto γ 1s = 1/31 566 925,9747 del año trópico 1900 » definición oficial entre 1955 y 1967

‹

Correcciones del tiempo universal (UT0) – UT1: UT0 corregido por el movimiento de los polos – UT2: UT1 corregido por variaciones en la rotación de la Tierra

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Sistemas de referencia de tiempo - 4

Tiempo atómico ‹

Los relojes atómicos proporcionan medidas estables y precisas 1 s = 9 192 631 770 períodos de la radiación correspondiente a la transición entre los dos niveles hiperfinos del estado fundamental del átomo de Cesio 133 en reposo a una temperatura de 0 K » definición oficial (SI) desde 1967 » precisión del orden de 10-13 (1 s en 300 000 años)

‹

TAI (tiempo atómico internacional) – definido en 1970 – sincronizado con UT en 1958-01-01:00:00:00 » mantenido por una red coordinada por el BIPM (Bureau International de Poids et Mesures)

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Sistemas de referencia de tiempo - 5

Tiempo universal coordinado ‹

El TAI se aparta lentamente del UT » La duración del día solar medio va en aumento » En 2001, la diferencia es aproximadamente de 32 s

‹

UTC (Universal Time Coordinated) – Definido en 1972 – UTC = TAI + H » H se elige de forma que |UT2 - UTC| ≤ 0,9 s

– Se añade un segundo intercalar al UTC cuando es necesario. » 30 de junio o 31 de diciembre a las 24:00 » Lo decide el IERS (International Earth Rotation Service)

– La hora oficial (TO u OT) en cada país se basa en el UTC » TO = UTC + Z + C

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Sistemas de referencia de tiempo - 6

Segundos intercalares en el UTC ‹ ‹

Desde 1972 se ha añadido un segundo intercalar al UTC 21 veces La adición de un segundo intercalar se puede producir el 1 de enero o el 1 de julio a las 0h – Se anuncia en el Boletín C del IERS http://hpiers.obspm.fr/eop-pc/

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

7

Diferencias entre UT, UTC y TAI

0,0000 -5,0000

UT-TAI (s)

-15,0000

UTC-TA I (s)

-10,0000

-25,0000

-20,0000

-30,0000 -35,0000 1960

1965

1970

1975

1980

1985

1990

1995

2000

2005

Año

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

Sistemas de referencia de tiempo - 8

El calendario ‹

Calendarios antiguos: solares y lunares – año, mes, semana

‹

Calendario juliano – 1 año = 365,25 días » un día adicional (año bisiesto) cada 4 años

‹

Calendario gregoriano (1582) – 1 año = 365,2425 días » se suprimen 3 días cada 400 años » sólo los múltiplos de 100 que también lo son de 400 son bisiestos

– se mantiene un error de 1 día cada 2500 años, aproximadamente

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Sistemas de referencia de tiempo - 9

Referencias de tiempo ‹ ‹

El UTC es adecuado para la comunicación con personas Pero presenta saltos (segundos intercalares) que lo hacen inadecuado para medidas de tiempo precisas – peor todavía si consideramos el calendario y la hora oficial

‹ ‹

EL TAI es una referencia más adecuada para controlar la ejecución de tareas de tiempo real Lo que hace falta es una referencia de tiempo – estable: sin variaciones grandes a lo largo del tiempo – exacta: diferencia con el TAI acotada » excepto una constante: puede tener una época (origen) cualquiera

– precisa: la diferencia entre dos lecturas sucesivas está acotada – monótona no decreciente: sin saltos hacia atrás

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Sistemas de referencia de tiempo -10

Relojes ‹ ‹ ‹

Los relojes son módulos de hardware y software que permiten medir el tiempo real. Pueden ser internos o externos Características importantes: – Características estáticas (representación del tiempo) » Resolución » Intervalo de valores

– Características dinámicas » Granularidad » Exactitud » Estabilidad variación o movimiento

STRL - 29/10/2002

1− ρ ≤

τ (t ′) − τ (t ) t′ −t

©2001-2002 Juan Antonio de la Puente

≤ 1+ ρ

Relojes - 11

Relojes en Ada

‹

En Ada hay dos paquetes predefinidos que proporcionan funciones de reloj: Ada.Calendar – Define un tipo abstracto Time – La función Clock da un valor de tiempo para uso externo – Los intervalos de tiempo se representan con el tipo predefinido Duration

‹

Ada.Real_Time – Define un tipo abstracto Time – La función Clock da un valor monótono, sin saltos – Los intervalos de tiempo se representan con el tipo abstracto Time_Span

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 12

Intervalos de tiempo ‹

El tipo Duration representa intervalos de tiempo en segundos

‹

Es un tipo de coma fija: type Duration is delta ... range ...; – Su resolución, Duration’Small, no debe ser mayor que 20ms (se recomienda que no sobrepase los 100µs) – El intervalo de valores debe comprender ±1 día (-86_400.0 .. +86_400.0)

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 13

Ada.Calendar (1) package Ada.Calendar is type Time is private; subtype subtype subtype subtype

Year_Number Month_Number Day_Number Day_Duration

is is is is

Integer Integer Integer Duration

range range range range

1901..2099; 1..12; 1..31; 0.0..86_400.0;

function Clock return Time; function function function function

Year (Date Month (Date Day (Date Seconds(Date

: : : :

procedure Split(Date Year Month Day Seconds

Time) Time) Time) Time)

return return return return

: : : : :

Time; Year_Number; Month_Number; Day_Number; Day_Duration);

in out out out out

Year_Number; Month_Number; Day_Number; Day_Duration;

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

Relojes en Ada- 14

Ada.Calendar (2) function Time_Of (Year : Year_Number; Month : Month_Number; Day : Day_Number; Seconds : Day_Duration := 0.0) return Time; function function function function

"+" "+" "-" "-"

(Left (Left (Left (Left

function function function function

"="

: : : :

(Left, (Left, (Left, (Left,

Time; Duration; Time; Time; Right Right Right Right

: : : :

Right Right Right Right

Time) Time) Time) Time)

: : : :

Duration) Time) Duration) Time)

return return return return

return return return return

Time; Time; Time; Duration;

Boolean; Boolean; Boolean; Boolean;

Time_Error : exception; end Ada.Calendar;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 15

Comentarios a Ada.Calendar

‹

Los valores del tipo Time combinan la fecha y la hora

‹

La hora se da en segundos desde medianoche – cuando hay un segundo intercalar se llega a 86_400.0

‹

El reloj se supone sincronizado con una referencia externa (UTC o TO) – los detalles se dejan para el entorno (SO)

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 16

Ejemplo

declare use Ada.Calendar; Start, Finish : Time; Interval : Duration; begin Start := Clock; -- instrucciones cuya duración se mide Finish := Clock; Interval := Finish - Start; end;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 17

Ada.Real_Time (1) package Ada.Real_Time is type Time is Time_First : Time_Last : Time_Unit :

private; constant Time; constant Time; constant := -- real number;

type Time_Span is private; Time_Span_First : constant Time_Span_Last : constant Time_Span_Zero : constant Time_Span_Unit : constant

Time_Span; Time_Span; Time_Span; Time_Span;

Tick : constant Time_Span; function Clock return Time; function function function function

"+" "+" "-" "-"

(Left (Left (Left (Left

: : : :

function function function function

"="

(Left, (Left, (Left, (Left,

Time; Time_Span; Time; Time; Right Right Right Right

: : : :

Right Right Right Right

Time) Time) Time) Time)

: : : :

Time_Span) return Time; Time) return Time; Time_Span) return Time; Time) return Time_Span;

return return return return

Boolean; Boolean; Boolean; Boolean;

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

Relojes en Ada- 18

Ada.Real_Time (2) function "+" (Left, Right : Time_Span) return Time_Span; function "-" (Left, Right : Time_Span) return Time_Span; function "-" (Right : Time_Span) return Time_Span; function "*" (Left : Time_Span; Right : Integer) return Time_Span; function "*" (Left : Integer; Right : Time_Span)return Time_Span; function "/" (Left, Right : Time_Span) return Integer; function "/" (Left : Time_Span; Right : Integer) return Time_Span; function "abs" (Right : Time_Span) return Time_Span; function function function function

"="

(Left, (Left, (Left, (Left,

Right Right Right Right

: : : :

Time_Span) Time_Span) Time_Span) Time_Span)

return return return return

Boolean; Boolean; Boolean; Boolean;

function To_Duration (TS : Time_Span) function To_Time_Span (D : Duration)

return Duration; return Time_Span;

function Nanoseconds (NS : integer) function Microseconds (US : integer) function Milliseconds (MS : integer)

return Time_Span; return Time_Span; return Time_Span;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 19

Ada.Real_Time (3)

type Seconds_Count is new Integer range ...; procedure Split (T : SC : TS : function Time_Of (SC return Time;

Time; out Seconds_Count; out Time_Span); : Seconds_Count; TS : Time_Span)

end Ada.Real_Time;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 20

Comentarios sobre Ada.Real_Time (1) ‹

El tipo Time representa valores de tiempo absolutos. – Un valor T de tipo Time representa un intervalo de duración [E + T ·Time_Unit, E + (T+1) · Time_Unit] » Time_Unit no debe ser mayor de 20ms.. » El valor de E no está definido

– El intervalo de valores del tipo Time debe alcanzar al menos 50 años desde el arranque del sistema. ‹

El tipo Time_Span representa intervalos de tiempo. – Un valor S de tipo Time_Span representa un intervalo de duración igual a S · Time_Span_Unit . » Time_Span_Unit =Time_Unit » Duration’Small debe ser un múltiplo entero de Time_Span_Unit.

– El intervalo de valores del tipo Time_Span debe abarcar por lo menos -3600..+3600 s . STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 21

Comentarios sobre Ada.Real_Time (2) ‹

La función Clock proporciona el tiempo absoluto transcurrido desde la época.

‹

Tick es el valor medio del intervalo durante el cual el valor de Clock permanece constante. No debe ser mayor de 1ms – Se recomienda que el valor de Tick sea igual al de Time_Span_Unit, o un múltiplo exacto de éste.

‹

El valor de Clock no debe disminuir en ningún momento (es decir, el reloj es monótono no decreciente).

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 22

Ejemplo

declare use Ada.Real_Time; Start, Finish : Time; Frame : Time_Span := Milliseconds(10); begin Start := Clock; -- instrucciones Finish := Clock; if Finish - Start > Frame then raise Time_Error; -- excepción definida por el programador end if; end;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 23

Medida del tiempo de ejecución ‹ ‹

Se usa una técnica de doble bucle Sólo es válido si la secuencia de instrucciones se ejecuta de una vez (sin ceder el procesador a otras tareas o al núcleo)

declare begin

end;

T0, T1, T2 : Ada.Real_Time.Time; Execution_Time : Ada.Real_Time.Time_Span; N : constant Positive := ...; T0 := Ada.Real_Time.Clock; for i in 1 .. N loop -- secuencia de instrucciones end loop; T1 := Ada.Real_Time.Clock; for i in 1 .. N loop null; end loop; T2 := Ada.Real_Time.Clock; Execution_Time = ((T1 - T0) - (T2 - T1))/N;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 24

Relojes en Java ‹

Reloj de hora del día (Java) – java.lang.System.currentTimeMillis da el número de milisegundos transcurridos desde UT 1970-01-01:00:00 – java.util.Date usa este valor para dar la fecha y hora del día » muchos detalles complicados (por ejemplo, el mes va de 0 a 11)

‹

Tipos de datos de alta resolución (RT Java) – representación del tiempo con resolución de 1 ns

‹

Relojes y temporizadores (RT Java) – adecuados para sistemas de tiempo real

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Java -

25

Tiempo de alta resolución public abstract class HighResolutionTime implements java.lang.Comparable { ...} public class AbsoluteTime extends HighResolutionTime {...} public class RelativeTime extends HighResolutionTime {...} public class RationalTime extends RelativeTime {...}

‹ ‹ ‹ ‹

Un valor de tiempo se compone de un número entero de milisegundos y un número entero de nanosegundos El tiempo absoluto se cuenta desde 1970-01-01:00:00:00 Un valor de tiempo racional representa un intervalo compuesto de subintervalos con una frecuencia determinada Las definiciones de estas clases contienen constructores, operaciones aritméticas y otras

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Java -

26

Relojes public abstract class Clock { public Clock(); public static Clock getRealtimeClock(); public abstract RelativeTime getResolution(); public AbsoluteTime getTime(); public abstract void setTime(AbsoluteTime time); public abstract void setResolution(RelativeTime resolution); }

‹ ‹

Siempre hay disponible al menos un reloj de tiempo real Puede haber clases derivadas que definen relojes especializados

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Java -

27

Ejemplo

AbsoluteTime start, finish; RelativeTime interval; Clock clock = Clock.getRealtimeClock(); start = clock.getTime(); // secuencia de instrucciones finish = clock.getTime(); interval = finish.subtract(start);

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

Relojes en Ada- 28

Temporizadores public abstract class Timer extends AsyncEvent { protected Timer(HighResolutionTime t, Clock c, AsyncEventHandler handler); ... public void reschedule(HighResolutionTime time); public void start(); } public class OneShotTimer extends Timer {...} public class PeriodicTimer extends Timer {...}

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

29

Relojes en C / POSIX ‹

Hay también dos tipos Reloj calendario (ANSI C) – Proporciona valores de tiempo con resolución de 1s

‹

Relojes de tiempo real (POSIX) – Se pueden definir distintos relojes – Por lo menos debe haber uno denominado CLOCK_REALTIME – La resolución de la representación es de 1ns – La granularidad depende de la implementación » como máximo 20 ms

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

30

Reloj-calendario ‹

Proporciona una medida de tiempo con resolución de 1s #include time_t time (time_t *tloc);

‹ ‹ ‹

El tipo time_t representa un número entero de segundos El tiempo se mide desde las 0h UT del 1 de enero de 1970 Hay otras operaciones y otros tipos que facilitan el uso de unidades corrientes (año, mes, día, hora, ...)

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

31

Relojes de tiempo real en POSIX ‹

El tiempo se representa mediante el tipo timespec struct timespec { time_t tv_sec; long tv_nsec }

‹ ‹ ‹ ‹

/* segundos */ /* nanosegundos */

El tipo clockid_t sirve para identificar distintos relojes CLOCK_REALTIME es una constante de este tipo La resolución máxima del reloj es de 20ms Puede haber otros relojes

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

32

Operaciones con relojes ‹

Leer la hora: #include int clock_gettime (clockid_t clockid, struct timespec *tp);

‹

Poner en hora #include int clock_settime (clockid_t clockid, const struct timespec *tp);

‹

Resolución del reloj #include int clock_getres (clockid_t clockid, struct timespec *res);

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

33

Índice ‹ Medida

del tiempo y relojes ‹ Retardos ‹ Límites temporales (time-outs) ‹ Requisitos temporales ‹ Tolerancia de fallos

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

34

Retardos ‹

Un retardo suspende la ejecución de una tarea durante un cierto tiempo

‹

Hay dos tipos – Retardo relativo: la ejecución se suspende durante un intervalo de tiempo relativo al instante actual – Retardo absoluto: la ejecución se suspende hasta que se llegue a un instante determinado de tiempo absoluto

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

35

Retardo relativo en Ada ‹

En Ada hay una instrucción delay expresión;

‹ ‹

que suspende la ejecución de la tarea que la invoca durante un intervalo de tiempo La expresión es de tipo Duration Una instrucción delay con argumento cero o negativo no produce ningún retardo

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

36

Retardo relativo en C/POSIX ‹

La función unsigned int sleep (unsigned int seconds);

‹

suspende el thread que la invoca durante un número entero de segundos La función #include int nanosleep (const struct timespec *rqtp, struct timespec *rmtp;)

permite especificar retardos con mayor precisión La duración del retardo es *rqtp

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

37

Retardo absoluto en Ada ‹

La instrucción delay until expresión;

‹

suspende la ejecución de la tarea que la invoca hasta que el valor del reloj sea igual al especificado por la expresión La expresión es de uno de estos tipos: – Ada.Calendar.Time – Ada.Real_Time.Time

‹ ‹

Se usa el reloj correspondiente al tipo Time utilizado Si se especifica un tiempo anterior al valor actual del reloj, no se produce ningún retardo

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

38

Aproximación con retardo relativo ‹

La instrucción delay until T;

se puede aproximar mediante delay (T - Clock); ‹

pero el efecto no es exactamente el mismo La expresión (T - Clock) tendría que ejecutarse de forma atómica

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

39

Retardos en RT Java ‹

En Java hay un método sleep con características similares al sleep de Posix

‹

En RT Java hay un sleep de alta resolución (definido en la clase RealtimeThread) public static void sleep (HighResolutionTime time) throws Interrupted Exception;

‹

El retardo puede ser absoluto o relativo, según la clase a la que pertenezca el parámetro time

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

40

Ejecución de un retardo el retardo termina aquí

instrucción de retardo

retardo especificado

STRL - 29/10/2002

error de interrupción granularidad inhibida preparado

©2001-2002 Juan Antonio de la Puente

ejecución

41

Índice ‹ Medida

del tiempo y relojes ‹ Retardos ‹ Límites temporales (time-outs) ‹ Requisitos temporales ‹ Tolerancia de fallos

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

42

Limitación del tiempo de espera ‹ ‹

A menudo conviene limitar el tiempo durante el cual se espera que ocurra un suceso Ejemplos: – Acceso a una sección crítica: La espera está limitada por la duración de la sección crítica – Sincronización condicional » Ada: Llamada a una entrada protegida con barreras » POSIX: Espera en variable de condición o un semáforo

– Cita entre dos tareas – Ejecución de una acción

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

43

Ejemplo task Controller is entry Call (T : Temperature); end Controller; task body Controller is -- declaraciones begin loop accept Call (T : Temperature) do New_Temp := T; end Call; -- otras acciones end loop; end Controller;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

44

Aceptación temporizada ‹

Se puede especificar una acción alternativa en caso de que la llamada no se reciba dentro de un cierto intervalo mediante una aceptación temporizada: select accept Call (T : Temperature) do New_Temp := T; end Call; or delay 10.0; -- acción alternativa end select;

‹

El retardo puede ser también absoluto

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

45

Llamada temporizada ‹

Se puede limitar el tiempo que tarda en aceptarse la llamada mediante una llamada temporizada loop -- leer el nuevo valor de T select Controller.Call(T); or delay 0.5; -- acción alternativa end select; end loop;

‹

Aquí también puede usarse un retardo absoluto

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

46

Llamada condicional ‹

Se usa cuando se quiere ejecutar una acción alternativa si la llamada no se acepta inmediatamente select Controller.Call(T); else -- acción alternativa end select;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

47

Entradas protegidas ‹

La llamada temporizada se puede usar para limitar el tiempo de espera en una entrada protegida select P.E(...); -- P es un objeto protegido or delay 0.5; end select;

‹

También se pueden hacer llamadas condicionales a entradas protegidas

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

48

Acciones temporizadas ‹

Se puede usar una transferencia asíncrona de control (ATC) para limitar el tiempo de ejecución de una acción: select delay 0.1; then abort -- acción end select;

‹

Es útil para detectar y recuperar fallos

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

49

Aplicación al cómputo impreciso ‹

Se trata de ejecutar rápidamente un parte obligatoria de un cálculo, y de iterar sobre una parte opcional que mejora el resultado mientras haya tiempo begin -- parte obligatoria select delay until Completion_Time; then abort loop -- mejorar el resultado end loop; end select; end;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

50

Espera temporizada en C/POSIX (1) ‹

La función #include int pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);

‹

permite limitar el tiempo durante el cual se espera una condición El límite es absoluto y su valor es *abstime

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

51

Espera temporizada en C/POSIX (2) ‹

Para limitar el tiempo de espera de una señal se usa #include int sigtimedwait (const sigset_t *set, siginfo_t *info, const struct timespec *timeout);

‹

Aquí timeout es un intervalo de tiempo relativo

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

52

Temporizadores en POSIX ‹ ‹ ‹

Se pueden crear temporizadores asociados a relojes Cada temporizador se identifica mediante un valor del tipo timer_t El tiempo de espera se especifica mediante un valor de tipo itimerspec: struct itimerspec { struct timespec it_interval; /* período */ struct timespec it_value} /* expiración */

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

53

Creación y destrucción de temporizadores ‹

La función #include #include int timer_create (clockid_t clock_id, struct sigevent *evp, timer_t *timerid);

crea un temporizador asociado al reloj clock_id – *evp indica el tipo de notificación que se produce al expirar el temporizador – el identificador del temporizador se devuelve en *timer_id ‹

Se puede destruir un temporizador con int timer_delete (timer_t timerid);

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

54

Armar un temporizador ‹

Se usa la función int timer_settime (timer_t timerid, int flags, const struct itimerspec *value, struct itimerspec *ovalue);

‹ ‹ ‹

La temporización puede ser relativa o absoluta, según el valor de flag El funcionamiento se repite periódicamente si value.it_period > 0 En *ovalue se devuelve el valor que quedaba de la temporización anterior

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

55

Índice ‹ Medida

del tiempo y relojes ‹ Retardos ‹ Límites temporales (time-outs) ‹ Requisitos temporales ‹ Tolerancia de fallos

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

56

Requisitos temporales Hay dos formas de enfocar este tema: ‹ Métodos formales: – Especificar las propiedades temporales con un modelo formal – Validar la especificación – Comprobar que la implementación satisface las propiedades temporales ‹

Métodos analíticos: – Analizar las propiedades temporales desde el punto de vista de la planificación de las tareas

Seguiremos en detalle este último enfoque

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

57

Atributos temporales ‹

Los atributos temporales de una secuencia de instrucciones definen un marco temporal para su ejecución

suceso de activación tiempo de respuesta R latencia c1

c2

tiempo de cómputo C = c1 + c2

tr

tf

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

58

Parámetros temporales ‹

‹

Parámetros D

Plazo de respuesta (R ≤ D)

L Jmin Jmax C

Tiempo límite (tf ≤ L) Latencia mínima Latencia máxima Tiempo de cómputo máximo

T O

Período Fase Irregular, a ráfagas, estocástica Separación mínima

Activación – Periódica – Aperiódica – Esporádica

STRL - 29/10/2002

T

©2001-2002 Juan Antonio de la Puente

59

Requisitos temporales de tareas ‹ ‹

Los marcos temporales suelen ir asociados a tareas o procesos Generalmente se trata de – Ejecutar tareas periódicas – Ejecutar tareas esporádicas cuando ocurren los sucesos correspondientes – Completar la ejecución de todas las tareas dentro de su plazo de respuesta

‹

A veces se exige que la entrada o salida de una tarea se efectúe a intervalos regulares La desviación se llama variación o jitter

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

60

Criticidad Una tarea de tiempo real puede ser ‹ Crítica (hard) : No se puede admitir que se sobrepase el plazo de respuesta especificado ni una sola vez ‹ Acrítica (soft) : Es admisible que se sobrepase el plazo ocasionalmente ‹ Firme (firm) : El plazo no es crítico, pero una respuesta tardía no sirve para nada ‹ Interactiva : No se especifican plazos de respuesta, sino tiempos de respuesta medios

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

61

Tareas periódicas en Ada Se construyen con un retardo absoluto: use Ada.Real_Time; task body Periodic is Period : constant Time_Span := ...; Next_Time : Time := ...; begin -- iniciación loop delay until Next_Time; -- acción periódica Next_Time := Next_Time + Period; end loop; end Periodic;

©2001-2002 Juan Antonio de la Puente

STRL - 29/10/2002

62

Ejecución de una tarea periódica

instante inicial delay until 0 delay until 100

delay until 200

40ms

delay until 300

60ms

75ms

t 0

STRL - 29/10/2002

60

100

140

200 225

©2001-2002 Juan Antonio de la Puente

300

63

Tarea periódica con límite de tiempo use Ada.Real_Time; task body Periodic is Period : constant Time_Span := ...; Budget : constant Time_span := ...; Next_Time, Limit : Time := ...; Overrun : exception; begin -- iniciación loop delay until Next_Time; Limit := Clock + Budget; select delay until Limit; raise Overrun; then abort -- acción periódica end select; Next_Time := Next_Time + Period; end loop; exception when Overrun => ...; end Periodic;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

64

Tareas esporádicas en Ada (1) El suceso de activación se implementa mediante un objeto protegido protected type Event is procedure Signal; entry Wait; private Occurred : Boolean := False; end Event;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

65

Tareas esporádicas en Ada (2) protected body Event is procedure Signal is begin Occurred := True; end Signal; entry Wait when Occurred is begin Occurred := False; end Wait; end Event;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

66

Tareas esporádicas en Ada (3) La tarea esporádica se activa cuando ocurre el suceso:

Activation : Event; task body Sporadic is begin -- iniciación loop Activation.Wait; -- acción esporádica end loop; end Sporadic;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

67

Separación mínima (1)

use Ada.Real_Time.Time; ... protected type Event is procedure Signal; entry Wait (Event_Time : out Time); private Occurred : Boolean := False; Occurrence_Time : Time; end Event;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

68

Separación mínima (2)

protected body Event is procedure Signal is begin Occurred := True; Occurrence_Time := Clock; end Signal; entry Wait (Event_Time : out Time) when Occurred is begin Occurred := False; Event_Time := Occurrence_Time; end Wait; end Event;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

69

Separación mínima (3)

Activation : Event; task body Sporadic is Separation : Time_Span; Next_Time, Activation_Time : Time; begin -- iniciación loop Activation.Wait (Activation_Time); Next_Time := Activation_Time + Separation; -- acción esporádica delay until Next_Time; end loop; end Sporadic;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

70

Tareas periódicas en C/POSIX (1) ‹

Se pueden realizar con temporizadores #include #include #include void * periodic { struct timespec period; struct itimerspec timer_parameters; timer_t timer_id; struct sigevent event; sigset signals; int t_signal, r_signal;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

71

Tareas periódicas en C/POSIX (2)

Iniciación de datos y creación del temporizador period.tv_sec = ...; period.tv_nsec = ...; timer_parameters.it_interval = period; timer_parameters.it_value = period; t_signal = ...; event.sigev_notify = SIGEV_SIGNAL; event.sigevent_signo = t_signal; sigemptyset (&signals); sigaddset (&signals, t_signal); pthread_sigmask (SIG_BLOCK, &signals, NULL); timer_create (CLOCK_REALTIME, event, &timer_id); timer_settime(timer_id,0,&timer_parameters,NULL);

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

72

Tareas periódicas en C/POSIX (3) Parte cíclica del thread periódico while (1) { sigwait (&signals, &r_signal); /* acción periódica */ } }

/* end periodic */

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

73

Tareas periódicas en C/POSIX (4)

main () { pthread_t periodic_id; pthread_attr_t periodic_attr; sigset_t signals; int t_signal; t_signal = ...; /* ¡la misma de antes! */ sigemptyset (&signals); sigaddset (&signals, t_signal; pthread_sigmask (SIG_BLOCK, &signals, NULL); pthread_attr_init (&periodic_attr); pthread_create (&periodic_id, &periodic_attr, periodic, NULL); pthread_join (&periodic_id); }

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

74

Tareas de tiempo real en RT

‹

Objetos que implementan la interfaz Schedulable

‹

Para cada objeto se especifica: – requisitos de memoria, con la clase MemoryParameters – requisitos de planificación, con la clase ScheduingParameters – requisitos de tiempo con la clase ReleaseParameters y sus extensiones (para tareas periódicas y esporádicas)

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

75

Release Parameters public abstract class ReleaseParameters { protected ReleaseParameters( RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler); public RelativeTime getCost(); public AsyncEventHandler getCostOverrunHandler(); public RelativeTime getDeadline(); public AsyncEventHandler getDeadlineMissHandler(); public void setCost(RelativeTime cost); public void setCostOverrunHandler(AsyncEventHandler handler); public void setDeadline(RelativeTime deadline); public void setDeadlineMissHandler(AsyncEventHandler handler); }

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

76

Parámetros temporales ‹

Un objeto puede tener asociados: – un coste (tiempo de ejecución máximo) – un plazo

‹

Si el objeto está en ejecución y se sobrepasa el coste o el plazo, se ejecutan los manejadores asociados – no se exige que el núcleo vigile el tiempo de ejecución – pero sí que se detecten los fallos de plazo – no está bien definido cómo se ejecutan las hebras esporádicas y aperiódicas – se puede especificar un manejador nulo si no se quiere hacer nada cuando se pierde un plazo

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

77

Periodic Parameters public class PeriodicParameters extends ReleaseParameters { public PeriodicParameters( HighResolutionTime start, RelativeTime period, RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler);

}

public public public public

STRL - 29/10/2002

RelativeTime getPeriod(); HighResolutionTime getStart(); void setPeriod(RelativeTime period); void setStart(HighResolutionTime start);

©2001-2002 Juan Antonio de la Puente

78

Aperiodic & Sporadic Parameters public class AperiodicParameters extends ReleaseParameters { public AperiodicParameters( RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler); } public class SporadicParameters extends AperiodicParameters { public SporadicParameters( RelativeTime minInterarrival, RelativeTime cost, RelativeTime deadline, AsyncEventHandler overrunHandler, AsyncEventHandler missHandler);

}

public RelativeTime getMinimumInterarrival(); public void setMinimumInterarrival(RelativeTime minimum);

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

79

Real-Time Threads (resumen) public class RealtimeThread extends java.lang.Thread implements Schedulable { public RealtimeThread(SchedulingParameters s, ReleaseParameters r); ... // methods for implementing the Schedulable interface public synchronized void addToFeasibility(); ... public static RealtimeThread currentRealtimeThread(); public synchronized void schedulePeriodic(); // add the thread to the list of schedulable objects public synchronized void deschedulePeriodic(); // remove the thread from the list of schedulable object // when it next issues a waitForNextPeriod public boolean waitForNextPeriod() throws ...; public synchronized void interrupt(); // overrides java.lang.Thread.interrupt()

}

public static void sleep(Clock c, HighResolutionTime time) throws ...;

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

80

Tarea periódica public class Periodic extends RealtimeThread { public Periodic( PriorityParameters PP, PeriodicParameters P) { ... }; public void run() { while(true) { // code to be run each period ... waitForNextPeriod(); } } } STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

81

Tarea periódica (continuación) { AbsoluteTime A = new AbsoluteTime(...); PeriodicParameters P = new PeriodicParameters( A, // start new RelativeTime(10,0), // period new RelativeTime(1,0), // cost new RelativeTime(5,0), // deadline null, null ); // handlers PriorityParameters PP = new PriorityParameters(...); Periodic ourThread = new Periodic(PP, P); //create thread ourThread.start();

// release it

} STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

82

Fallos temporales Una tarea puede incumplir su plazo por varias razones, por ejemplo: ‹ El tiempo de cómputo no está bien calculado ‹ El análisis de tiempos de respuesta no es realista ‹ Las herramientas de análisis contienen errores ‹ No se cumplen las hipótesis de diseño (por ejemplo, separación mínima entre eventos) En estos casos hay que detectar los fallos Si el sistema es crítico, debe recuperarse

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

83

Detección de fallos temporales ‹

Fallos que se refieren al tiempo transcurrido (por ejemplo, incumplimiento de plazo) : – Transferencia de control temporizada (Ada) – Temporizador con manejador de señal (POSIX)

‹

Fallos que se refieren al tiempo de cómputo – Hace falta un reloj de tiempo de cómputo – No es estándar en Ada ni en POSIX – Hay soluciones particulares en algunos sistemas operativos

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

84

Recuperación de fallos ‹ ‹

Se aplican esquemas de recuperación directa o inversa Esquema: Grupos de recuperación – Generalmente varias tareas cooperan para conseguir una funcionalidad común – Grupo de recuperación: Conjunto de tareas primarias con una tarea de recuperación común – Cuando hay un fallo se terminan todas las tareas primarias y se arranca la tarea de recuperación – Esta proporciona una funcionalidad degradada – Si falla otra vez, se activa una tarea de recuperación global del sistema

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

85

Resumen ‹

Hay cuatro aspectos importantes relacionados con el tratamiento del tiempo – – – –

‹

medida del tiempo mediante relojes retardos limitación del tiempo de espera especificación de requisitos temporales

Los atributos más importantes de un marco temporal (generalmente asociado a una tarea) son: – – – –

esquema de activación (periódico, esporádico) plazo de terminación latencia de activación tiempo de cómputo máximo

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

86

Índice ‹ Medida

del tiempo y relojes ‹ Retardos ‹ Límites temporales (time-outs) ‹ Requisitos temporales ‹ Tolerancia de fallos

STRL - 29/10/2002

©2001-2002 Juan Antonio de la Puente

87

dit UPM

Esquemas de tareas de tiempo real Juan Antonio de la Puente DIT/UPM

Objetivos ‹

Reconocer un conjunto de esquemas básicos para construir sistemas de tiempo real – – – –

‹

Tareas periódicas Tareas esporádicas Recursos compartidos Sincronización

Veremos esquemas basados en HRT-HOOD – También algunos esquemas más generales

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

1

HRT-HOOD ‹

Un sistema de tiempo real se representa mediante un conjunto de objetos – Objetos no terminales: se descomponen en otros más simples – Objetos terminales: no se pueden descomponer más

‹

Un objeto se caracteriza por sus: – Operaciones: que pueden invocar otros objetos (modelo de llamada a procedimiento) – Comportamiento » Activo (cíclico, esporádico) / pasivo / protegido » Restricciones en las operaciones ‹ Sincronización ‹ Estado

©2001 Juan Antonio de la Puente

STRL - 29/10/2002

2

Objetos y relaciones

C

op1

El objeto parent contiene los objetos child_1 y child_2

parent

A

child_1

datos

uncle

op

op2

excepción Pr PSER

op

child_2

parent usa uncle child_1 usa child_2 y uncle child_1.op implementa parent.op1 child_2.op implementa parent.op2 child_2.op tiene una restricción de sincronización

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

3

Objeto cíclico

C

Name

Name

thread

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

4

Objeto cíclico: realización with Ada.Real_Time; use Ada.Real_Time; with System; use System; package Name is Start_Time : Time := ... ; Period : Time_Span := ... ; Thread_Priority : Priority := ... ; pragma Elaborate_Body (Name); end Name;

‹

‹

‹

No hay operaciones visibles – Elaborate_Body indica que el paquete tiene cuerpo Atributos temporales – Start_Time – Period – Thread_Priority No se detecta si se excede el plazo de ejecución o el tiempo de cómputo STRL - 29/10/2002

with Ada.Real_Time; use Ada.Real_Time; -- other context clauses package body Name is task Thread is pragma Priority (Thread_Priority); end Thread; task body Thread is Next_Time : Time := Start_Time ; begin -- thread initialization loop delay until Next_Time; Periodic_Action; Next_Time := Next_Time + Period; end loop; end Thread; begin -- package initialization end Name;

©2001 Juan Antonio de la Puente

5

Objeto esporádico Name

S

Name

thread Start

START

Wait_Start

Start

Control

©2001 Juan Antonio de la Puente

STRL - 29/10/2002

6

Objeto esporádico: realización with System; use System; package Name is Thread_Priority : Priority

:= ... ;

task Thread is pragma Priority (Thread_Priority); end Thread;

procedure Start; end Name;

Control : Suspension_Object;

‹

La única operación visible es Start

‹

No se vigila el cumplimiento de la separación mínima entre sucesos No se detecta si se excede el plazo de ejecución o el tiempo de cómputo

‹

STRL - 29/10/2002

with Ada.Synchronous_Task_Control; use Ada.Synchronous_Task_Control; -- other context clauses package body Name is

task body Thread is begin -- thread initialization loop Suspend_Until_True(Control); Sporadic_Action; end loop; end Thread; procedure Start is begin Set_True (Control); end Start; begin -- package initialization end Name;

©2001 Juan Antonio de la Puente

7

Objeto esporádico: Sincronización con objeto protegido (1) private

with System; use System; package Name is Thread_Priority : Priority Control_Priority: Priority

:= ... ; := ... ;

procedure Start;

protected Control is pragma Priority (Control_Priority); procedure Start; entry Wait_Start; private Started : Boolean := False; end Control; procedure Start renames Control.Start; end Name;

‹ ‹ ‹ ‹

El objeto de sincronización se sustituye por un objeto protegido Funcionalmente es equivalente, aunque menos eficiente Es fácil de extender para tener en cuenta la separación mínima entre sucesos Permite poner parámetros en las operaciones

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

8

Objeto esporádico: Sincronización con objeto protegido (2) with System; use System; package body Name is task Thread is pragma Priority (Thread_Priority); end Thread; task body Thread is begin -- thread initialization loop Control.Wait_Start; Sporadic_Action; end loop; end Thread;

STRL - 29/10/2002

protected body Control is procedure Start is begin Started := True; end Start; entry Wait_Start when Started is begin Started := False; end Wait_Start; end Control; begin -- package initialization end Name;

©2001 Juan Antonio de la Puente

9

Objeto esporádico: Separación mínima (1) private

with Ada.Real_Time; use Ada.Real_Time; with System; use System; package Name is

protected Control is pragma Priority (Control_Priority); procedure Start; entry Wait_Start (Start_Time : out Time); private Started : Boolean := False; Event_Time : Time; end Control;

Separation : Time_Span := ... ; Thread_Priority : Priority := ... ; Control_Priority: Priority := ... ; procedure Start;

procedure Start renames Control.Start; end Name;

‹

El objeto Control registra el tiempo en que se hace Start (no es necesariamente el mismo en que se ejecuta la acción esporádica)

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

10

Objeto esporádico: Separación mínima (2) protected body Control is procedure Start is begin Started := True; Event_Time := Ada.Real_Time.Clock; end Start;

with Ada.Real_Time; use Ada.Real_Time; with System; use System; package body Name is task Thread is pragma Priority (Thread_Priority); end Thread; task body Thread is Start_Time : Time; begin -- thread initialization loop Control.Wait_Start(Start_Time); Sporadic_Action; delay until Start_Time + Separation; end loop; end Thread;

‹

entry Wait_Start (Start_Time : out Time) when Started is begin Started := False; Start_Time := Event_Time; end Wait_Start; end Control; begin -- package initialization end Name;

Inconveniente: dos cambios de contexto –

si se está seguro de la separación mínima es mejor el esquema anterior

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

11

Objeto protegido

Name Pr

Name Op1

Op1 Op2 ...

Op2

Control

...

©2001 Juan Antonio de la Puente

STRL - 29/10/2002

12

Objeto pasivo

Name Pa

Name Op1

Op1 Op2 ...

STRL - 29/10/2002

Op2 ...

©2001 Juan Antonio de la Puente

13

Ejemplo: control de una bomba de agua operador arranca/para

bomba

Sistema de control

motor

nivel alto nivel bajo

arqueta

©2001 Juan Antonio de la Puente

STRL - 29/10/2002

14

Diseño con HRT-HOOD (1) A

Pump controller

Motor

Pr set pump

A HL Water sensor high sensor low sensor

set pump

Motor Hw

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

15

Diseño con HRT-HOOD (2) A

High Low Water Sensor Pr

HLW controller

sensor high IH sensor low IH high sensor low sensor S

HLW handler start

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

motor

16

Realización: Motor (1) package Motor is -- protected object type Pump_Status is (On, Off); procedure Set_Pump (To : Pump_Status); end Motor;

with Motor.HW; package body Motor is -- protected object protected Control is procedure Set_Pump (To : Pump_Status); private Motor_Status : Pump_Status := Off; end Control; procedure Set_Pump (To : Pump_Status) is begin Control.Set_Pump (To); end Set_Pump

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

17

Realización: Motor (2) protected body Control is procedure Set_Pump (To : Pump_Status) is begin case To is when On => Motor.HW.Start; Control.Motor_Status := On; when Off => Motor.HW.Stop; Control.Motor_Status := Off; end case; end Set_Pump; end Control; end Motor;

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

18

Realización: HLW Controller (1) package HLW_Controller is -- protected object procedure Sensor_High_IH; procedure Sensor_Low_IH; end HLW_Controller;

with HLW_Handler; ... package body HLW_Controller is -- protected object protected Control is procedure Sensor_High_IH; procedure Sensor_Low_IH; -- we will see later how to attach these procedures -- to interrupt sources end Control;

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

19

Realización: HLW Controller (2)

protected body Control is procedure Sensor_High_IH is begin HLW_Handler.Start (High); end Sensor_High_IH; procedure Sensor_Low_IH is begin HLW_Handler.Start (Low); end Sensor_Low_IH; end Control; end HLW_Controller ;

©2001 Juan Antonio de la Puente

STRL - 29/10/2002

20

Realización: HLW Handler (1) package HLW_Handler is -- sporadic object type Water_Mark is (High,Low); procedure Start (Level : Water_Mark); end HLW_Handler;

package body HLW_Handler is -- sporadic object procedure Sporadic_Code (Level : Water_Mark) is begin case Level is when High => Motor.Set_Pump(On); when Low => Motor.Set_Pump(Off); end case; end Sporadic_Code; task Thread;

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

21

Realización: HLW Handler (2) protected Control is procedure Start (Level : Water_Mark); entry Wait_Start (Level : out Water_Mark); private Started : Boolean := False; Water : Water_Mark; end Control; task body Thread is Level : Water_Mark; begin loop Control.Wait_Start(Level); Sporadic_Code(Level); end loop; end Thread;

©2001 Juan Antonio de la Puente

STRL - 29/10/2002

22

Realización: HLW Handler (3) protected body Control is procedure Start (Level : begin Water := Level; Started := True; end Start;

Water_Mark) is

entry Wait_Start (Level : out Water_Mark) when Started is begin Level := Water; Started := False; end Wait_Start; end Control; end HLW_Handler;

STRL - 29/10/2002

©2001 Juan Antonio de la Puente

23

Realización: procedimiento principal with Motor, HLW_Controller, HLW_Handler; procedure Pump_Control_System is begin null; end Pump_Control_System;

‹ ¡El procedimiento principal no hace nada! ‹ La tarea de entorno elabora los paquetes – al elaborar HLW_Handler arranca la tarea esporádica

y luego llama al procedimiento principal ‹ ¡Una tarea de Ada no termina hasta que han terminado todos sus descendientes! – la tarea de entorno espera que termine la tarea esporádica STRL - 29/10/2002

©2001 Juan Antonio de la Puente

24

dit

UPM

Planificación de tareas Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 13 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languages, 3ª edición (2001)

Objetivos


Veremos cómo planificar el uso de los recursos para poder garantizar los requisitos temporales


Un método de planificación tiene dos aspectos importantes:

– Un algoritmo de planificación que determina el orden de acceso de las tareas a los recursos del sistema (en particular al procesador) – Un método de análisis que permite calcular el comportamiento temporal del sistema » Así se pude comprobar si los requisitos temporales están garantizados en todos los casos posibles » En general se estudia el peor comportamiento posible

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 1

1

Índice


Introducción
Planificación con ejecutivos cíclicos
Multiprogramación – – – – –

Planificación con prioridades fijas Tareas periódicas independientes Tareas esporádicas y aperiódicas Interacción entre tareas y bloqueos Modelo de tareas generalizado


Realización de sistemas con prioridades

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 2

Planificación de tareas


Un método de planificación puede ser – estático: el análisis se puede hacer antes de la ejecución – dinámico: el análisis se hace durante la ejecución


Un método estático muy utilizado es el de

planificación con prioridades fijas y desalojo – La prioridad es un parámetro relacionado con la urgencia o la importancia de la tarea – En cada momento se ejecuta la tarea con mayor prioridad de todas las ejecutables

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 3

2

Modelo de tareas Inicialmente consideraremos un modelo simple: – El conjunto de tareas es estático – Todas las tareas son periódicas – Las tareas son independientes unas de otras – Los plazos de respuesta de todas las tareas son iguales a los períodos respectivos – El tiempo de ejecución máximo de cada tarea es conocido – Las operaciones del núcleo de multiprogramación son instantáneas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 4

Parámetros de planificación N T C D R P

Número de tareas Período de activación Tiempo de ejecución máximo Plazo de respuesta Tiempo de respuesta máximo Prioridad

En el modelo anterior, para todas las tareas τi : Ci ≤ Di = Ti

Se trata de asegurar que Ri ≤ Di

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 5

3

Hiperperíodo


En el modelo de tareas simple, el valor H = mcm (Ti )

se denomina hiperperíodo del sistema


El comportamiento temporal se repite cada hiperperíodo

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 6

Planificación con ejecutivos cíclicos

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 7

4

Planificación cíclica


Si todas las tareas son periódicas, se puede confeccionar



un plan de ejecución fijo Se trata de un esquema que se repite cada TM = mcm(Ti )

(ciclo principal) El ciclo principal se divide en ciclos secundarios, con período (TM = k ⋅ TS)

TS


En cada ciclo secundario se ejecutan las actividades correspondientes a determinadas tareas

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 8

Ejemplo Tarea A B C D E

T C 25 10 25 8 50 5 50 4 100 2

– El sistema es armónico – El ciclo principal dura 100ms – Se compone de 4 ciclos secundarios de 25ms cada uno TM = 100ms

Ts = 25ms

A 0

STRL -11/11/2003

B

C

A 25

B

D E

A

B

50

©2001-2002 Juan Antonio de la Puente

C

A 75

B

D 100

Planificación - 9

5

Ejecutivo cíclico procedure Cyclic_Executive is type Cycle is mod 4; Frame : Cycle := 0; begin loop Wait_for_Interrupt; case Frame is when 0 => A; B; C; when 1 => A; B; D; E; when 2 => A; B; C; when 3 => A; B; D; end case; Frame := Frame + 1; end loop; end Cyclic_Executive;

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 10

Propiedades


No hay concurrencia en la ejecución – Cada ciclo secundario es una secuencia de invocaciones de procedimientos


Los procedimientos pueden compartir datos

– No hace falta usar mecanismos de exclusión mutua


Los períodos deben ser armónicos

– Puede ser necesario utilizar períodos más cortos de lo necesario


No hace falta analizar el comportamiento temporal – El sistema es correcto por construcción

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 11

6

Problemas


Las tareas esporádicas son difíciles de tratar – Se puede utilizar un servidor de consulta


El plan cíclico es difícil de construir – Si los períodos son de diferentes órdenes de magnitud el número de ciclos secundarios se hace muy grande – Puede ser necesario partir una tarea en varios procedimientos – En el caso más general es NP-duro


Es poco flexible y difícil de mantener

– Cada vez que se cambia una tarea hay que rehacer toda la planificación

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 12

Multiprogramación con prioridades fijas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 13

7

Multiprogramación




Las tareas se realizan como procesos concurrentes Una tarea puede estar en varios estados Las tareas ejecutables se despachan para su ejecución de acuerdo con un método de planificación:

suspendida activar

– prioridades fijas (fixed-priority scheduling, FPS) – primero el más urgente (earliest deadline first, EDF) – primero el más valioso (value-based scheduling, VBS)

STRL -11/11/2003

suspender ejecutable despachar

desalojar

ejecutándose activa

©2001-2002 Juan Antonio de la Puente

Planificación - 14

Planificación con prioridades fijas


Es el método más corriente en sistemas operativos de


tiempo real Cada tarea tiene una prioridad fija – planificación estática


Las tareas ejecutables se despachan para su ejecución


en orden de prioridad El despacho puede hacerse – con desalojo – sin desalojo – con desalojo limitado


En general supondremos prioridades fijas con desalojo – mejor tiempo de respuesta para las tareas de alta prioridad

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 15

8

Primero el más urgente


Las tareas ejecutables se despachan por orden de sus



respectivos tiempos límite (plazos absolutos) La primera tarea que se ejecuta es la más urgente (aquélla cuyo plazo vence antes) Los tiempos límites se calculan durante la ejecución – planificación dinámica

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 16

Primero el más valioso


Cuando hay posibilidad de sobrecargas los métodos anteriores no son suficientes

– métodos de planificación adaptativos


Se asigna un valor a cada tarea, y se de decida sobre la marcha qué tarea se despacha primero mediante un método de planificación basado en el valor de las tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 17

9

Prioridades monótonas en frecuencia


La asignación de mayor prioridad a las tareas de menor período (rate monotonic scheduling) es óptima para el modelo de tareas simple – tareas periódicas, – independientes, – con plazos iguales a los períodos

Si se pueden garantizar los plazos de un sistema de tareas con otra asignación de prioridades, se pueden garantizar con la asignación monótona en frecuencia

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 18

Análisis del factor de utilización


La cantidad U =

∑ CT N

i

i =1





i

es el factor de utilización del procesador Es una medida de la carga del procesador para un conjunto de tareas En un sistema monoprocesador debe ser

U ≤ 1

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 19

10

Condición de garantía de los plazos basada en la utilización


Para el modelo simple, con prioridades monótonas en frecuencia, los plazos están garantizados si

U =

∑ CT N

i =1

i

≤ N ⋅ ( 21 N − 1)

i


La cantidad U0 (N ) = N ⋅ ( 21 N − 1)

es la utilización mínima garantizada para N tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 20

Utilización mínima garantizada

N 1 2 3 4 5

U0 1,000 0,828 0,779 0,756 0,743

limn→∞ U0 (N ) = log 2 ≈ 0,693

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 21

11

Ejemplo 1

Tarea

T

C P

τ1 τ2 τ3

30 40 50

10 3 10 2 12 1

El sistema no cumple la prueba de utilización (U > 0,779) La tarea 3 falla en t = 50

U 0,333 0,250 0,240 0,823

τ1 τ2

¡fallo!

τ3 0

20

40

60

80

100

120

140

160

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 22

Ejemplo 2

Tarea

T

C P

τ1 τ2 τ3

16 40 80

4 3 5 2 32 1

Este sistema está garantizado (U < 0,779)

U 0,250 0,125 0,400 0,775

τ1 τ2 τ3 0

STRL -11/11/2003

10

20

30

40

50

60

©2001-2002 Juan Antonio de la Puente

70

80

Planificación - 23

12

Ejemplo 3

Tarea

T

C P

τ1 τ2 τ3

20 40 80

5 3 10 2 40 1

Este sistema no pasa la prueba (U > 0,779), pero se cumplen los plazos

U 0,250 0,250 0,500 1,000

τ1 τ2 τ3 0

10

20

30

40

50

60

70

80

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 24

Factor de utilización con EDF


Los plazos están garantizados si y sólo si U=

∑ CT N

i =1

i

≤1

i


EDF permite una mayor utilización del procesador – pero tiene inconvenientes » » » »

STRL -11/11/2003

más difícil de realizar el núcleo de multiprogramación es más complejo tiene un comportamiento imprevisible en caso de sobrecarga requiere que todas las tareas tengan plazos asignados (FPS es más flexible en esto)

©2001-2002 Juan Antonio de la Puente

Planificación - 25

13

Ejemplo 1 - EDF

Tarea

T

C P

τ1 τ2 τ3

30 40 50

10 3 10 2 12 1

Con planificación EDF los plazos están garantizados (U < 1,0)

U 0,333 0,250 0,240 0,823

τ1 τ2 τ3 0

STRL -11/11/2003

20

40

60

80

100

120

©2001-2002 Juan Antonio de la Puente

140

160

Planificación - 26

Problemas del análisis de utilización


La prueba del factor de utilización no es exacta, ni se

puede generalizar a modelos de tareas más complejos – pero es eficiente, O(N)


Veremos una prueba basada en el cálculo del tiempo de respuesta de cada tarea

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 27

14

Análisis del tiempo de respuesta


Es un método más completo y flexible que el del factor de utilización para FPS

– es fácil de generalizar a otros modelos de tareas – proporciona una condición necesaria y suficiente para que los plazos estén garantizados


Se trata de calcular el tiempo de respuesta en el peor

caso de cada tarea, Ri, y comprobar directamente que es menor que el plazo correspondiente:

Ri ≤ Di

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 28

Ecuación del tiempo de respuesta

τj τi Ri

Ri = Ci + Ii

El tiempo de respuesta de una tarea es la suma de su tiempo de cómputo más la interferencia que sufre por la ejecución de tareas más prioritarias

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 29

15

Instante crítico


La interferencia es máxima cuando todas las tareas se activan a la vez – el instante inicial se denomina instante crítico Cj

τj

Cj

Cj

Cj

τi Ri Cj

τj

Cj

Cj

Cj

τi Ri ©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 30

Cálculo de la interferencia τj

Cj

Cj

τi Ri




El número de veces que una tarea de prioridad superior τj se ejecuta durante el intervalo [0,Ri) es: R  i   T  j   

función techo: x  = min k ∈ Z : k ≥ x

Por tanto, el valor de la interferencia de τj sobre τi es

Ii j = STRL -11/11/2003

R  i     Tj  

⋅ Cj ©2001-2002 Juan Antonio de la Puente

Planificación - 31

16

Cálculo del tiempo de respuesta


La interferencia total que sufre τi es Ii =

∑

hp(i ) = {j : 1..N | Pj > Pi }

R  i   ⋅C j T j ∈hp (i )   j  


La ecuación del tiempo de respuesta queda así: Ri = Ci +

∑

R i  j ∈ hp ( i )   Tj

   

⋅ Cj

– La ecuación no es continua ni lineal – No se puede resolver analíticamente

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 32

Iteración lineal


La ecuación del tiempo de respuesta se puede resolver mediante la relación de recurrencia

w in +1 = Ci +

∑

w n  i   ⋅Cj T j ∈hp ( i )   j  

K K

– la sucesión (w i0 ,w i1, w in , ) es monótona no decreciente – un valor inicial aceptable es w i0 = Ci – se termina cuando » a) win+1 = win (y entonces Ri = win), o bien » b) win+1 > Ti (no se cumple el plazo)

– converge siempre que U < 100%

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 33

17

Ejemplo 4

Tarea

T

C P

τ1 τ2 τ3

7 12 20

3 3 5

3 2 1

w 30 = 5

R 3 6 20

w 32 = 5 +

R1 = 3

w 33 = 5 +

w 20 = 3 3  ⋅3 7  6 = 3 +   ⋅3 7

5   5   ⋅3 +   ⋅ 3 = 11 7  12  11  11   ⋅3 +   ⋅ 3 = 14 7 12  14  14    ⋅3 +   ⋅ 3 = 17  7  12  17  17  ⋅ 3 +   ⋅ 3 = 20  7   12    20   20  ⋅ 3 +   ⋅ 3 = 20  7    12  

w 31 = 5 + 

w 12 = 3 + 

=6

w 34 = 5 +

w 22

= 6; R2 = 6

w 35 = 5 +

R3 = 20

Todas las tareas tienen sus plazos garantizados

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 34

Ejemplo 3 (repaso) Tarea

T

C P

τ1 τ2 τ3

20 40 80

5 10 40

3 2 1

U 0,250 0,250 0,500 1,000

R1 = 5 w = 10 0 2

w = 10 + 1 2

w = 10 + 2 2

 10    ⋅5  20   15   20  ⋅ 5  

R 5 15 80

w 30 = 40  40   40  ⋅5 +   ⋅ 10  20   40 

= 60

 60   60   ⋅ 5 +  40  ⋅ 10 20    

= 75

 75   75   ⋅ 5 +  40  ⋅ 10 20    

= 80

 80   80   ⋅ 5 +  40  ⋅ 10  20   

= 80 R3 = 80

w 31 = 40 + 

= 15 = 15; R 2 = 15

w 32 = 40 +  w 33 = 40 +  w 34 = 40 + 

Todas las tareas tienen sus plazos garantizados STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 35

18

Propiedades del análisis de tiempo de respuesta


Proporciona una condición necesaria y suficiente para la garantía de los plazos

∀i Ri ≤ Di


Permite un análisis del comportamiento temporal del


sistema más exacto que la prueba del factor de utilización El elemento crítico es el cálculo del tiempo de cómputo de cada tarea – optimista: los plazos puedes fallar aunque el análisis sea positivo – pesimista: él análisis puede ser negativo aunque los plazos no fallen en realidad

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 36

Tiempo de cómputo


Interesa el tiempo de ejecución en el peor caso


(WCET, worst case execution time) Hay dos formas de obtener el WCET de una tarea: – Medida del tiempo de ejecución » no es fácil saber cuándo se ejecuta el peor caso posible

– Análisis del código ejecutable » se descompone el código en un grafo de bloques secuenciales » se calcula el tiempo de ejecución de cada bloque » se busca el camino más largo

Puede ser muy pesimista » es difícil tener en cuenta los efectos de los dispositivos de hardware (caches, pipelines, estados de espera de la memoria, etc..) » hace falta tener un modelo adecuado del procesador

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 37

19

Análisis estático del WCET


Generalmente se hace en tres pasos: 1. Descomposición del código en un grafo dirigido compuesto por bloques básicos (secuencias) 2. Cálculo del WCET de cada bloque básico a partir del código de máquina y del modelo del procesador 3. Cálculo del WCET total a partir del camino más largo del grafo

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 38

Mejora con información semántica


Ejemplo: for I in 1.. 10 loop if Cond then -- bloque básico con coste 100 else -- bloque básico con coste 10 end if; end loop; – Sin más información, el coste peor es 10 × 100 = 1000 – Si sabemos que Cond sólo es verdadera 3 veces, entonces el coste es 3×100 + 7×10 = 370

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 39

20

Restricciones en el código


Para poder calcular el tiempo de cómputo hay que evitar utilizar estructuras con tiempo de cómputo no acotado, como: – – – –

bucles no acotados recursión no acotada objetos dinámicos tareas dinámicas


Para construir sistemas de tiempo real estricto se utilizan subconjuntos del lenguaje de programación que no usan estos elementos Ejemplos: » SPARK (parte secuencial de Ada) » Ravenscar (parte concurrente)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 40

Tareas esporádicas y aperiódicas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 41

21

Tareas esporádicas


Para incluir tareas esporádicas hace falta modificar el modelo simple de tareas:

– El parámetro T representa la separación mínima entre dos sucesos de activación consecutivos – Suponemos que en el peor caso la activación es pseudoperiódica (con período T) – El plazo de respuesta puede ser menor que el período (D ≤ T)


El análisis de tiempo de respuesta sigue siendo válido
Funciona bien con cualquier orden de prioridad STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 42

Prioridades monótonas en plazos Cuando los plazos son menores o iguales que los períodos, la asignación de mayor prioridad a las tareas de menor plazo de respuesta (deadline monotonic scheduling) es óptima


El tiempo de respuesta se calcula de la misma forma que con la asignación monótona en frecuencia – se termina cuando win+1 = win, – o cuando win+1 > Di

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 43

22

Ejemplo 5 Tarea

T

D

C P

τ1 τ2 τ3 τ4

20 15 10 20

5 7 10 20

3 3 4 3

4 3 2 1

R 3 6 10 20

Con prioridades monótonas en frecuencia los plazos no están garantizados: Tarea

T

D

C P

τ3 τ2 τ1 τ4

10 15 20 20

10 7 5 20

4 3 3 3

STRL -11/11/2003

4 3 2 1

R 4 7 10 20

©2001-2002 Juan Antonio de la Puente

Planificación - 44

Tareas críticas y acríticas


A menudo los tiempos de cómputo en el peor caso de las tareas esporádicas son mucho más altos que los medios – interrupciones en rachas, tratamiento de errores – planteamiento demasiado pesimista


No todas las tareas esporádicas son críticas – Deben garantizarse los plazos de todas las tareas en condiciones “normales” » con separación entre activaciones y tiempos de cómputo medios

Puede haber una sobrecarga transitoria – Deben garantizarse los plazos de las tareas críticas en las peores condiciones » con separación entre activaciones y tiempos de cómputo peores

Esto asegura un comportamiento correcto en caso de sobrecarga transitoria STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 45

23

Tareas aperiódicas


Son tareas acríticas sin separación mínima
Se pueden ejecutar con prioridades más bajas que las tareas críticas (periódicas y esporádicas)

– el tiempo de respuesta puede ser muy largo – en condiciones normales sobra tiempo de cómputo de las tareas críticas


Es mejor utilizar un servidor

– el servidor asegura que las tareas críticas tienen asegurados sus recursos – pero asignan los recursos que no se utilizan a las tareas acríticas

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 46

Servidor esporádico


Un servidor esporádico (SS, sporadic server) es un proceso periódico

– Parámetros: período Ts, tiempo de cómputo Cs, prioridad máxima » Cs es la capacidad inicial del servidor » Ts y Cs se eligen de forma que las tareas críticas estén garantizadas

– Cuando se activa una tarea aperiódica, se ejecuta con prioridad máxima mientras quede capacidad disponible – Cuando se agota la capacidad se ejecuta con prioridad baja – La capacidad se rellena cuando ha pasado un tiempo Ts desde la activación de la tarea aperiódica

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 47

24

Interacción entre tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 48

Interacción entre tareas


En la mayoría de los sistemas de interés práctico las tareas interaccionan mediante – datos comunes (protegidos) – citas o mensajes


En todos estos casos puede ocurrir que una tarea tenga



que esperar un suceso de otra menos prioritaria Esta situación se denomina bloqueo, bloqueo y produce una inversión de prioridad indeseable La inversión de prioridad no se puede eliminar completamente, pero es posible limitar su duración

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 49

25

Ejemplo 6

τ1

τ2

τ3

X

Y

Tarea P ta τ1 τ2 τ3 τ4

4 3 2 1

τ4

4 2 2 0

N: ejecución de código propio X: ejecución con acceso a X Y: ejecución con acceso a Y (durante 1 unidad de tiempo)

Acciones NNXYN NYYN NN NXXXXN

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 50

Ejemplo 6 : inversión de prioridad

bloqueo

τ1 τ2 τ3 τ4 0

STRL -11/11/2003

2

4

6

8

10

12

©2001-2002 Juan Antonio de la Puente

14

16

18

Planificación - 51

26

Herencia de prioridad


Una forma de reducir la duración de los bloqueos es variar



dinámicamente la prioridad de las tareas Cuando una tarea está bloqueando a otra más prioritaria, hereda la prioridad de ésta La prioridad dinámica de una tarea es el máximo de – su prioridad básica – las prioridades de todas las tareas bloqueadas por ella


La herencia de prioridad es transitiva

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 52

Ejemplo 6 : herencia de prioridad

4

τ1 3

4

3

τ2 2

τ3 1

4

1

τ4 0

STRL -11/11/2003

2

4

6

8

10

12

©2001-2002 Juan Antonio de la Puente

14

16

18

Planificación - 53

27

Duración máxima del bloqueo


Con el protocolo de herencia de prioridad, una tarea se pude bloquear como máximo

– una vez por cada recurso – una vez por cada tarea de prioridad inferior


La duración total máxima de los bloqueos es Bi = K u(k,i)

∑ u (k , i ) ⋅ C ( k ) K

k =1

Ck

número de secciones críticas 1 si algún τj, Pj < Pi, accede a k 0 si no tiempo de ejecución de la sección crítica k

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 54

Ejemplo 6 : cálculo del bloqueo K =4 B1 B2 B3 B4

( X1,Y1,Y2, X 4 ) = 0 ⋅ 1 + 0 ⋅ 1 + 1 ⋅ 2 + 1⋅ 4 = 0 ⋅ 1 + 0 ⋅ 1 + 0 ⋅ 2 + 1⋅ 4 = 0 ⋅ 1 + 0 ⋅ 1 + 0 ⋅ 2 + 1⋅ 4 = 0 ⋅1+ 0 ⋅1+ 0 ⋅ 2 + 0 ⋅ 4

=6 =4 =4 =0

– Una tarea puede bloquearse por recursos a los que no accede (por ejemplo, τ2) – Una tarea puede sufrir bloqueo aunque no acceda a recursos compartidos (por ejemplo, τ3) – La tarea de menor prioridad (τ4) no sufre bloqueo

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 55

28

Tiempo de respuesta con bloqueos


Cuando hay bloqueos, la ecuación del tiempo de respuesta queda así: Ri = Ci + Bi +

∑

j ∈hp(i)

R  i   T   j  

⋅ Cj

La solución se obtiene mediante la relación de recurrencia w in + 1 = Ci + Bi +

∑

j ∈hp(i)

w n  i   T   j  

⋅ Cj

¡Ahora el cálculo puede ser pesimista!

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 56

Protocolos de techo de prioridad


El techo de prioridad de un recurso es la máxima prioridad de las tareas que lo usan


El protocolo del techo de prioridad (CPP) consiste en : – la prioridad dinámica de una tarea es el máximo de su prioridad básica y las prioridades de las tareas a las que bloquea – una tarea sólo puede usar un recurso si su prioridad dinámica es mayor que el techo de todos los recursos en uso por otras tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 57

29

Ejemplo 6 : techo de prioridad

4

τ1 3

τ2 2

τ3 1

3

1

1

4

τ4 0

2

4

6

8

10

12

14

16

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

18

Planificación - 58

Propiedades


Cuando se usa el protocolo del techo de prioridad en un sistema monoprocesador,

– Cada tarea se puede bloquear una vez, como máximo, en cada ciclo – No puede haber interbloqueos – No puede haber bloqueos encadenados


La duración máxima del bloqueo es ahora Bi = max u ( k , i ) ⋅ C k K ∈(1 ..K )

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 59

30

Protocolo del techo de prioridad inmediato (ICPP)


Con este protocolo, una tarea que accede a un recurso

hereda inmediatamente el techo de prioridad del recurso – la prioridad dinámica de una tarea es el máximo de su prioridad básica y los techos de prioridad de los recursos que usa


Las propiedades son las mismas que las del protocolo del techo de prioridad, y además,

– si una tarea se bloquea, lo hace al principio del ciclo


La duración máxima del bloqueo es igual que en CPP: Bi = max u ( k , i ) ⋅ C k K ∈(1 ..K )

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 60

Ejemplo 6 : techo de prioridad inmediato

4

τ1 3

4

3

τ2 2

τ3 1

4

1

τ4 0

STRL -11/11/2003

2

4

6

8

10

12

©2001-2002 Juan Antonio de la Puente

14

16

18

Planificación - 61

31

Ejemplo 6 : cálculo del bloqueo con ICPP

K =4 B1 B2 B3 B4

STRL -11/11/2003

( X1,Y1,Y2, X 4 ) = max (0 ⋅ 1, 0 ⋅ 1, 1⋅ 2, 1⋅ 4) = max (0 ⋅ 1, 0 ⋅ 1, 0 ⋅ 2, 1⋅ 4 ) = max (0 ⋅ 1, 0 ⋅ 1, 0 ⋅ 2, 1⋅ 4 ) = max (0 ⋅ 1, 0 ⋅ 1, 0 ⋅ 2, 0 ⋅ 4 )

=4 =4 =4 =0

©2001-2002 Juan Antonio de la Puente

Planificación - 62

CPP e ICPP


Los dos protocolos tienen las mismas propiedades,pero – ICPP es más fácil de realizar » no hay que seguir las relaciones de bloqueo transitivas

– ICPP produce menos cambios de contexto » el bloqueo se produce antes de la ejecución

– ICPP produce más cambios de prioridad » se hereda la prioridad techo aunque no haya bloqueo


El protocolo ICPP se conoce también con otros nombres: – – – –

Ceiling Locking (Ada 95) Priority Protect Protocol (POSIX) Priority Ceiling Emulation (RT Java) Highest Locker

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 63

32

Ejemplo 7 τ1

τ2

P1

τ3

τ4

P2

τ5

P3

FPS ICPP Atributos temporales

τ

T

C

D

Acceso a OP P1

P2

P3

τ1

S

120

2

5

1

—

—

τ2

P

50

10

50

—

—

1

τ3

P

30

6

30

—

1

—

τ4

S

300

16

32

—

2

—

τ5

S

120

12

15

2

—

2

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 64

Ejemplo 7 — Prioridades



Las prioridades de las tareas se asignan por DMS (más prioridad a las tareas de menor plazo) El techo de prioridad de cada objeto protegido es la prioridad máxima de las tareas que lo usan Atributos temporales

τ

Acceso a OP

P

T

C

D

P1

P3

P2

1

—

—

τ1

S

5

120

2

5

τ5

S

4

120

12

15

2

2

—

τ3

P

3

30

6

30

—

—

1

τ4

S

2

300

16

32

—

—

2

τ2

P

1

50

10

50

—

1

—

5

4

3

CP

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 65

33

Ejemplo 7 — Bloqueos Bi = max u (k , i ) ⋅ C k K ∈(1..K )

Atributos temporales

τ

P

T

C

B

Acceso a OP D

P1

P3

P2

τ1

S

5

120

2

2

5

1

—

—

τ5

S

4

120

12

1

15

2

2

—

τ3

P

3

30

6

2

30

—

—

1

τ4

S

2

300

16

1

32

—

—

2

τ2

P

1

50

10

0

50

—

1

—

5

4

3

CP

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 66

Ejemplo 7 — Tiempos de respuesta R1 = C1 + B1 = 2 + 2 = 4  R5  ·C1  T1 

R5 = C5 + B5 + 

R5  ·2  120  

= 12 + 1 + 

 R3   R3  ·C5 ·C1 +   T1   T5 

= 6+2+ 

R4  R4  ·C1 +  ·C 5  T1   T5 

+

 R2  R2  ·C1 +  ·C5  T1   T5 

+

R3 = C3 + B3 + 

R 4 = C 4 + B4 +  R2 = C2 + B2 + 

R3   R3  ·2 +  ·12 120  120  

R4  ·C 3  T3 

= 16 + 1 + 

 R2  ·C3  T3 

+

R4  R  R  ·2 +  4 ·12 +  4 ·6  120  120   30  

 R2  ·C 4  T4 

R  R  R   R  = 10 + 0 +  2 ·2 +  2 ·12 +  2 ·6 +  2 ·16 120  120   30   300 

Atributos temporales

τ

Acceso a OP

P

T

C

B

R

D

P1

P3

P2

τ1

S

5

120

2

2

4

5

1

—

—

τ5

S

4

120

12

1

15

15

2

2

—

τ3

P

3

30

6

2

22

30

—

—

1

τ4

S

2

300

16

1

43

32

—

—

2

τ2

P

1

50

10

0

52

50

—

1

—

5

4

3

CP STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 67

34

Modelo de tareas generalizado

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 68

Generalización el modelo de tareas


El modelo de tareas básico que hemos visto incluye – tareas periódicas, esporádicas y aperiódicas – plazos menores o iguales que los períodos – interacción mediante secciones críticas


El análisis del tiempo de respuesta se puede extender con – – – – – –

planificación cooperativa variación (jitter) en el esquema de activación plazos arbitrarios (también mayores que los períodos) tolerancia de fallos desfases (offsets) asignación de prioridades óptima

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 69

35

Planificación cooperativa






En sistemas críticos a veces no es aceptable la planificación con desalojo – el desalojo introduce indeterminismo

La planificación cooperativa es una alternativa – las tareas se segmentan en bloques de duración igual o menor que BMAX (el bloqueo máximo con desalojo) – al final de cada bloque se ofrece un cambio de contexto (si hay alguna tarea más prioritaria) – las secciones críticas se meten dentro de un solo bloque

Ventajas: – se pueden garantizar sistemas que no están garantizados con desalojo » el último bloque no sufre interferencia




– se puede hacer un cálculo de WCET más exacto

Inconveniente – el coste de ofrecer un cambio de contexto puede ser alto (e innecesario)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 70

Tiempo de respuesta con planificación cooperativa


El último bloque de una tarea no puede sufrir interferencia
La ecuación del tiempo de respuesta queda así: w in +1 = BMAX + C i − Fi +

∑

w n  i   ⋅C j T j∈hp ( i )   j  

Ri = w in + Fi , para w in +1 = w in

Fi es el tiempo de cómputo del último bloque

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 71

36

Activación irregular (release jitter)


Es importante en sistemas distribuidos – Por ejemplo, sea una tarea esporádica activada por un suceso producido por una tarea periódica situada en otro procesador » el tiempo de respuesta de la tarea periódica puede variar entre Cp y Rp T

τP CP

RP

T - (RP - CP)

J = Rp-Cp

τS 0

2

4

6

8

10

12

14

16

18

20

22

24

26

28

30

32

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

34

36

Planificación - 72

Tareas esporádicas con jitter


En el peor caso, la tarea esporádica se activa en 0, T-J,


2T-J, ... La tarea τs interfiere a otra tarea cualquiera τi: – 1 vez si Ri ∈ [0, T-J) – 2 veces si Ri ∈[T-J, 2T-J), – etc.

o Ri + J ∈ [0, T) o Ri + J ∈ [T, 2T)


La ecuación del tiempo de respuesta queda así: w

n+1 i

= Ci + Bi +

∑

j ∈hp(i)

 w in +  Tj 

Jj   

⋅ Cj

Ri = w in , para w in + 1 = w in STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 73

37

Tareas periódicas con jitter


Las tareas periódicas no suelen tener jitter
Puede haberlo si la planificación se hace con una


granularidad apreciable El tiempo de respuesta se calcula con w

n +1 i

= Ci + Bi +

∑

j ∈hp(i)

 w in +  Tj  

Jj    

⋅ Cj

Ri = w in + Ji , para w in + 1 = w in

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 74

Plazos arbitrarios


Si el plazo es mayor que el período, puede haber varias ejecuciones de una tarea pendientes en un ciclo

– suponemos que no se activa una ejecución hasta que termina la anterior


Para analizar esta situación construimos una sucesión de


ventanas wi(q), donde q + 1 es el número de activaciones de τi pendientes Para cada ventana se obtiene un valor de Ri con w in + 1(q) = (q + 1) ⋅ Ci + Bi +

∑

j ∈hp(i)

 w n(q) i   T   j  

⋅ Cj

Ri(q) = w in(q) − q ⋅ Ti STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 75

38

Tiempo de respuesta máximo


Se calcula Ri(q) para q = 0, 1, ... , qmax, donde qmax es el menor valor que cumple

Ri(qmax) ≤ Ti En esta situación ya no hay solape con la siguiente activación


El tiempo de respuesta en el peor caso es Ri = max Ri (q ) q = 0,..qmax

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 76

Caso general


Si consideramos plazos arbitrarios y jitter, el tiempo de respuesta se obtiene con

w in + 1(q) = (q + 1) ⋅ Ci + Bi +

∑

i ∈hp(i)

 w in(q) +  Tj  

Jj    

⋅ Cj

Ri(q) = w in(q) − q ⋅ Ti + Ji

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 77

39

Tolerancia de fallos


Cuando hay tolerancia de fallos, el tiempo de cómputo en el peor caso es mayor

– por ejemplo, manejadores de excepciones


Los plazos deben estar garantizados incluso son cierto nivel de fallos

– esto se llama modelo de fallos


El tiempo de respuesta se calcula con Ri = Bi + Ci +

∑

R i  j∈hp ( i )  T j

 Cj  

+ max C fj j∈hep ( i )

– hep(i) es el conjunto de tareas con prioridad igual o mayor que Pi – Cjf es el tiempo de cómputo de la parte de recuperación de fallos de τj

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 78

Tolerancia de fallos múltiples


Si se pueden tolerar F fallos del mismo tipo, Ri = Bi + Ci +

∑

R  i  Cj T j∈hp ( i )   j  

+ max FC fj j ∈hep ( i )


Si los fallos ocurren en ráfagas y se puede especificar un tiempo mínimo entre fallos Tf, Ri = Bi + Ci +

STRL -11/11/2003

∑

R i  j∈hp ( i )  Tj

 Cj  

 R  f i C j j∈hep ( i ) T  j   

+ max  

©2001-2002 Juan Antonio de la Puente

   

Planificación - 79

40

Fase inicial


Hasta ahora hemos supuesto que la fase inicial (offset) de todas las tareas es nulo

t r (k ) = (k − 1) ⋅ T + O


Si no lo es, se puede mejorar la planificación – en algunos casos no hay instantes críticos – los tiempos de respuesta son más cortos


El análisis es muy complejo (NP-duro) – pero algunos sistemas se pueden analizar de forma eficiente

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 80

Ejemplo 7 Tarea

T

D

C P

a b c

8 20 20

5 10 12

4 4 4

R 4 8 16

3 2 1

¡La tarea c falla !

a b c

0

4

STRL -11/11/2003

8

12

16

20

24

©2001-2002 Juan Antonio de la Puente

28

32

36

Planificación - 81

41

Ejemplo 7: fase > 0

0

Tarea

T

D

C O P

a b c

8 20 20

5 10 12

4 4 4

4

8

12

0 3 0 2 10 1

16

R 4 8 8

20

¡Con O = 10, la tarea c no falla!

24

28

32

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

36

Planificación - 82

Ejemplo 7: análisis


Las tareas b y c equivalen a una tarea ficticia con T = Tb / 2 = Tc / 2 C = max (Cb ,Cc ) D = min(Db , Dc )

P = max (Pb , Pc )


También se pueden analizar otros tipos de sistemas con desfases

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 83

42

Asignación de prioridades


Con el modelo general que hemos, la ordenación de


prioridades monótona en frecuencia (RMS) o en plazos no es óptima Se aplica el siguiente teorema: Si una tarea τ cumple su plazo con la prioridad más baja del sistema, y existe un orden de prioridades admisible para todo el sistema, entonces hay un orden de prioridades que garantiza todas las tareas en el cual τ tiene la prioridad más baja

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 84

Algoritmo procedure Assign_Priority (System: in out Task_Set; N : Natural; OK : out Boolean) is begin for k in 1 .. N loop for next in k ..N loop Swap (System, k, next); Test (System, k, OK); exit when OK; end loop; exit when not OK; -- no hay ninguna tarea garantizada end loop; end Assign_Priority;

System(1) tiene la prioridad mínima y System(N) la máxima Test comprueba el plazo de la tarea System (k)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 85

43

Planificación dinámica

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 86

Sistemas dinámicos


Hay sistemas de tiempo real en los que no se conocen de antemano los tiempos de cómputo ni los esquemas de activación – las tareas se crean y se destruyen durante la ejecución – hay que hacer el análisis sobre la marcha


El algoritmo EDF es óptimo y se adapta bien a los sistemas dinámicos

– pero funciona mal en caso de sobrecarga


Se complementa con un módulo de control de admisión – cuando llega una tarea nueva se decide si se admite o no – el objetivo es garantizar el buen funcionamiento del método EDF


Criterios de admisión

– evitar sobrecargas – maximizar el valor de las tareas que se ejecutan

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 87

44

Asignación de valor a las tareas


Se puede hacer de varias formas: – asignación estática: cada ejecución de la misma tarea tiene el mismo valor – asignación dinámica: el valor de la ejecución de una tarea se calcula en el momento de su activación – asignación adaptativa: el valor cambia durante la ejecución de la tarea


Hay que encontrar un compromiso entre lo que se gana

con la planificación dinámica y lo que se pierde en términos del tiempo necesario para tomar las decisiones

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 88

Realización de sistemas planificados con prioridades

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 89

45

Planificación de tareas en Ada


En el anexo de tiempo real se define un modelo de


planificación con prioridades y desalojo La prioridad de una tarea es de un subtipo definido en el paquete System subtype Any_Priority is Integer range intervalo; subtype Priority is Any_Priority range Any_Priority’First .. valor; subtype Interrupt_Priority is Any_Priority range Priority’Last + 1 .. Any_Priority’Last;


Los valores mayores denotan prioridades más altas
Debe haber al menos 30 valores de Priority y 1 de Interrupt_Priority

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 90

Prioridad básica


La prioridad básica de una tarea o un tipo tarea se especifica con un pragma Priority

task Controller is pragma Priority (10); end Controller; task type Server (Task_Priority : System.Priority) is entry Service_1 (...); ... pragma Priority (Task_Priority); end Server;

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 91

46

Techo de prioridad inmediato


Cada objeto protegido tiene una prioridad techo (ceiling

priority) mayor o igual que la prioridad de las tareas que usan el objeto – por omisíón es System.Priority'Last


Cuando una tarea llama a una operación de un objeto protegido, hereda la prioridad techo del objeto

– si la prioridad de la tarea es mayor que el techo se eleva Program_Error


El protocolo del techo de prioridad inmediato basta para asegurar la exclusión mutua en un monoprocesador

– si una tarea que quiere ejecutar una operación protegida se está ejecutando, el objeto no puede estar ocupado STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 92

Prioridad techo


Para usar el protocolo del techo de prioridad inmediato hay que poner un pragma de configuración pragma Locking_Policy (Ceiling_Locking);

– afecta a todo el programa (con GNAT se pone en gnat.adc)


El techo de prioridad de un objeto o un tipo protegido se especifica mediante un pragma Priority

protected type Resource(Ceiling : System.Priority)is ... pragma Priority (Ceiling); end Resource;

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 93

47

Ejecución de operaciones protegidas


Cuando se usa el protocolo del techo de prioridad

inmediato se pueden implementar las barreras de forma muy eficiente (proxy model): – cuando termina un procedimiento o entrada protegida se ejecutan las entradas que se puedan haber abierto como consecuencia – esto se hace con el mismo flujo de control de la tarea que llama a la primera operación – se reduce el número de cambios de contexto – todo esto es posible porque las operaciones se ejecutan con prioridad elevada

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 94

Ejemplo protected Gate_Control is pragma Priority(28); entry Stop_And_Close; procedure Open; private Gate : Boolean := False; end Gate_Control; protected body Gate_Control is entry Stop_And_Close when Gate is begin Gate := False; end; procedure Open is begin Gate := True; end; end Gate_Control;

STRL -11/11/2003










Supongamos que – una tarea T (prioridad = 20) llama a Stop_and_Close y se suspende – otra tarea S (prioridad =27) llama a Open

La hebra de S ejecuta: – el código de Open – la evaluación de la barrera – el código de Stop_and Close (por cuenta de T) – la evaluación de la barrera otra vez – la vuelta al punto donde S llamó a Open

No hay cambio de contexto

©2001-2002 Juan Antonio de la Puente

Planificación - 95

48

Prioridad activa


La prioridad activa de una tarea es el máximo de su prioridad básica y la prioridad heredada de otras


Una tarea puede heredar prioridad de varias formas : – cuando ejecuta una operación protegida hereda el techo de prioridad del objeto – cuando ejecuta una instrucción accept hereda la prioridad de la tarea que llama al punto de entrada – durante su activación hereda la prioridad de su progenitor

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 96

Protocolo de despacho


Se puede especificar un protocolo de despacho mediante un pragma de configuración:

pragma Task_Dispatching_Policy (FIFO_within_Priority);

– Hay una cola conceptual por cada nivel de prioridad – El núcleo de ejecución despacha la primera tarea de la cola de mayor prioridad que no esté vacía – Cuando una tarea se activa se coloca al final de la cola correspondiente a su prioridad activa – Las tareas desalojadas se colocan al principio de su cola


Puede haber otros protocolos de despacho, pero no son obligatorios

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 97

49

Otros mecanismos de planificación


Prioridades dinámicas (que se pueden cambiar por el


programa) Colas ordenadas por prioridades en puntos de entrada pragma Queuing_Policy (Priority_Queuing);


Identificadores y atributos de tareas
Control síncrono y asíncrono de tareas
Aborto inmediato
Restricciones para facilitar el análisis de tiempos
Requisitos sobre documentación de tiempos STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 98

Planificación en POSIX


POSIX



define un modelo de planificación con prioridades y desalojo La prioridad básica de una tarea se puede cambiar dinámicamente Se puede especificar el protocolo de despacho FIFO (como en Ada) – otros: Round-Robin, Sporadic Server, ... – debe al menos 32 prioridades distintas


Se puede especificar que todos los threads de un sistema se planifiquen globalmente (system contention)

– la política de planificación se puede ajustar por procesos o por threads

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 99

50

Ámbito de planificación


El ámbito de la planificación se define con #include int pthread_attr_setscope (pthread_attr_t *attr, int contentionscope);


También hay que especificar si los atributos de planificación son específicos de cada thread:

int pthread_attr_setinheritsched ( pthread_attr_t *attr, int inheritsched);


Normalmente se pone – PTHREAD_SCOPE_SYSTEM para contentionscope – PTHREAD_EXPLICIT_SCHED para inheritsched STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 100

Política de planificación


La política de planificación dentro del mismo nivel de prioridad se define con

int pthread_attr_setschedpolicy ( pthread_attr_t *attr, int policy);


El parámetro policy puede ser – SCHED_FIFO (orden de llegada) – SCHED_RR (turno circular con rodajas de tiempo) – SCHED_OTHER (dependiente de la implementación)


En general, hay que poner SCHED_FIFO

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 101

51

Prioridades


La prioridad de un thread es un parámetro de planificación:

#include struct sched_param { int sched_priority; ... }

y se especifica con int pthread_attr_setschedparam ( const pthread_attr_t *attr, const struct sched_param *param);


Los atributos se usan para crear el thread STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 102

Protocolo de acceso a mutex


Se puede especificar un protocolo de acceso con #include int pthread_mutexattr_setprotocol ( pthread_mutex_attr_t *attr, int *protocol);

El protocolo puede ser – PTHREAD_PRIO_INHERIT (herencia de prioridad) – PTHREAD_PRIO_PROTECT (techo de prioridad inmediato) – PTHREAD_PRIO_NONE (no hay herencia de prioridad)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 103

52

Prioridad techo


Se especifica con int pthread_mutexattr_setprioceiling ( pthread_mutexattr_t *attr, int prioceiling);

Los atributos se usan para iniciar el mutex

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 104

Servidor esporádico


Un servidor esporádico es un thread que tiene una

capacidad limitada para ejecutar tareas esporádicas con prioridad alta – si se agota la capacidad se sigue ejecutando con prioridad baja – parámetros: capacidad, intervalo de relleno, prioridades alta y baja

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 105

53

Planificación en RT Java


Interfaz Schedulable – implementada por RealtimeThread, NoHeapRealtimeThread AsyncEventHandler y otros


Planificación con prioridades y desalojo – al menos 28 valores de prioridad – los threads que no son de tiempo real van pro debajo – los threads desalojados no se ponen al principio de la cola


En general, enfoque más dinámico que en Ada y POSIX

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 106

Interfaz Schedulable public Interface Schedulable extends java.lang.Runnable { public void addToFeasibility(); public void removeFromFeasibility(); public MemoryParameters getMemoryParameters(); public void setMemoryParameters(MemoryParameters memory); public ReleaseParameters getReleaseParameters(); public void setReleaseParameters(ReleaseParameters release); public SchedulingParameters getSchedulingParameters(); public void setSchedulingParameters( SchedulingParameters scheduling); public Scheduler getScheduler(); public void setScheduler(Scheduler scheduler); } STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 107

54

Scheduling Parameters public abstract class SchedulingParameters { public SchedulingParameters(); } public class PriorityParameters extends SchedulingParameters { public PriorityParameters(int priority); public int getPriority(); // at least 28 priority levels public void setPriority(int priority) throws IllegalArgumentException; ... } public class ImportanceParameters extends PriorityParameters { public ImportanceParameters(int priority, int importance); public int getImportance(); public void setImportance(int importance); ... } STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 108

Planificación de alto nivel


La clase Scheduler permite definir un planificador de alto nivel

– decidir se se pueden admitir nuevos objetos planificables (threads) – ajustar las prioridades de los objetos planificables

Todo ello de acuerdo con un algoritmo de aceptación (feasibility algorithm)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 109

55

Scheduler public abstract class Scheduler { public Scheduler(); protected abstract void addToFeasibility(Schedulable s); protected abstract void removeFromFeasibility(Schedulable s); public abstract boolean isFeasible(); // checks the current set of schedulable objects public boolean changeIfFeasible(Schedulable schedulable, ReleaseParameters release, MemoryParameters memory); public static Scheduler getDefaultScheduler(); public static void setDefaultScheduler(Scheduler scheduler); public abstract java.lang.String getPolicyName(); } STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 110

Priority Scheduler class PriorityScheduler extends Scheduler { public PriorityScheduler() protected void addToFeasibility(Schedulable s); ... public void fireSchedulable(Schedulable schedulable); public int getMaxPriority(); public int getMinPriority(); public int getNormPriority(); public static PriorityScheduler instance(); ... }

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 111

56

Otros mecanismos


Herencia de prioridades y techo de prioridad (priority ceiling emulation)


Threads periódicos y aperiódicos – grupos de threads aperiódicos


Colas ordenadas por prioridades

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 112

Resumen


Un método de planificación tiene dos partes: – un algoritmo de reparto de recursos – un método de análisis del comportamiento temporal


El método tradicional se basa en un ejecutivo cíclico – el análisis es inmediato (por construcción) – es poco flexible y de bajo nivel


Un método mejor se basa en el uso de prioridades fijas – las prioridades se asignan por orden de períodos, plazos o de forma arbitraria – se puede analizar el tiempo de respuesta de las tareas – se pueden analizar tareas con interacción si se usa un protocolo de herencia o techo de prioridad

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 113

57

dit

UPM

Planificación de tareas Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 13 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languages, 3ª edición (2001)

Objetivos


Veremos cómo planificar el uso de los recursos para poder garantizar los requisitos temporales


Un método de planificación tiene dos aspectos importantes:

– Un algoritmo de planificación que determina el orden de acceso de las tareas a los recursos del sistema (en particular al procesador) – Un método de análisis que permite calcular el comportamiento temporal del sistema » Así se pude comprobar si los requisitos temporales están garantizados en todos los casos posibles » En general se estudia el peor comportamiento posible

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 1

1

Índice


Introducción
Planificación con ejecutivos cíclicos
Multiprogramación – – – – –

Planificación con prioridades fijas Tareas periódicas independientes Tareas esporádicas y aperiódicas Interacción entre tareas y bloqueos Modelo de tareas generalizado


Realización de sistemas con prioridades

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 2

Planificación de tareas


Un método de planificación puede ser – estático: el análisis se puede hacer antes de la ejecución – dinámico: el análisis se hace durante la ejecución


Un método estático muy utilizado es el de

planificación con prioridades fijas y desalojo – La prioridad es un parámetro relacionado con la urgencia o la importancia de la tarea – En cada momento se ejecuta la tarea con mayor prioridad de todas las ejecutables

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 3

2

Modelo de tareas Inicialmente consideraremos un modelo simple: – El conjunto de tareas es estático – Todas las tareas son periódicas – Las tareas son independientes unas de otras – Los plazos de respuesta de todas las tareas son iguales a los períodos respectivos – El tiempo de ejecución máximo de cada tarea es conocido – Las operaciones del núcleo de multiprogramación son instantáneas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 4

Parámetros de planificación N T C D R P

Número de tareas Período de activación Tiempo de ejecución máximo Plazo de respuesta Tiempo de respuesta máximo Prioridad

En el modelo anterior, para todas las tareas τi : Ci ≤ Di = Ti

Se trata de asegurar que Ri ≤ Di

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 5

3

Hiperperíodo


En el modelo de tareas simple, el valor H = mcm (Ti )

se denomina hiperperíodo del sistema


El comportamiento temporal se repite cada hiperperíodo

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 6

Planificación con ejecutivos cíclicos

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 7

4

Planificación cíclica


Si todas las tareas son periódicas, se puede confeccionar



un plan de ejecución fijo Se trata de un esquema que se repite cada TM = mcm(Ti )

(ciclo principal) El ciclo principal se divide en ciclos secundarios, con período (TM = k ⋅ TS)

TS


En cada ciclo secundario se ejecutan las actividades correspondientes a determinadas tareas

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 8

Ejemplo Tarea A B C D E

T C 25 10 25 8 50 5 50 4 100 2

– El sistema es armónico – El ciclo principal dura 100ms – Se compone de 4 ciclos secundarios de 25ms cada uno TM = 100ms

Ts = 25ms

A 0

STRL -11/11/2003

B

C

A 25

B

D E

A

B

50

©2001-2002 Juan Antonio de la Puente

C

A 75

B

D 100

Planificación - 9

5

Ejecutivo cíclico procedure Cyclic_Executive is type Cycle is mod 4; Frame : Cycle := 0; begin loop Wait_for_Interrupt; case Frame is when 0 => A; B; C; when 1 => A; B; D; E; when 2 => A; B; C; when 3 => A; B; D; end case; Frame := Frame + 1; end loop; end Cyclic_Executive;

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 10

Propiedades


No hay concurrencia en la ejecución – Cada ciclo secundario es una secuencia de invocaciones de procedimientos


Los procedimientos pueden compartir datos

– No hace falta usar mecanismos de exclusión mutua


Los períodos deben ser armónicos

– Puede ser necesario utilizar períodos más cortos de lo necesario


No hace falta analizar el comportamiento temporal – El sistema es correcto por construcción

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 11

6

Problemas


Las tareas esporádicas son difíciles de tratar – Se puede utilizar un servidor de consulta


El plan cíclico es difícil de construir – Si los períodos son de diferentes órdenes de magnitud el número de ciclos secundarios se hace muy grande – Puede ser necesario partir una tarea en varios procedimientos – En el caso más general es NP-duro


Es poco flexible y difícil de mantener

– Cada vez que se cambia una tarea hay que rehacer toda la planificación

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 12

Multiprogramación con prioridades fijas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 13

7

Multiprogramación




Las tareas se realizan como procesos concurrentes Una tarea puede estar en varios estados Las tareas ejecutables se despachan para su ejecución de acuerdo con un método de planificación:

suspendida activar

– prioridades fijas (fixed-priority scheduling, FPS) – primero el más urgente (earliest deadline first, EDF) – primero el más valioso (value-based scheduling, VBS)

STRL -11/11/2003

suspender ejecutable despachar

desalojar

ejecutándose activa

©2001-2002 Juan Antonio de la Puente

Planificación - 14

Planificación con prioridades fijas


Es el método más corriente en sistemas operativos de


tiempo real Cada tarea tiene una prioridad fija – planificación estática


Las tareas ejecutables se despachan para su ejecución


en orden de prioridad El despacho puede hacerse – con desalojo – sin desalojo – con desalojo limitado


En general supondremos prioridades fijas con desalojo – mejor tiempo de respuesta para las tareas de alta prioridad

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 15

8

Primero el más urgente


Las tareas ejecutables se despachan por orden de sus



respectivos tiempos límite (plazos absolutos) La primera tarea que se ejecuta es la más urgente (aquélla cuyo plazo vence antes) Los tiempos límites se calculan durante la ejecución – planificación dinámica

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 16

Primero el más valioso


Cuando hay posibilidad de sobrecargas los métodos anteriores no son suficientes

– métodos de planificación adaptativos


Se asigna un valor a cada tarea, y se de decida sobre la marcha qué tarea se despacha primero mediante un método de planificación basado en el valor de las tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 17

9

Prioridades monótonas en frecuencia


La asignación de mayor prioridad a las tareas de menor período (rate monotonic scheduling) es óptima para el modelo de tareas simple – tareas periódicas, – independientes, – con plazos iguales a los períodos

Si se pueden garantizar los plazos de un sistema de tareas con otra asignación de prioridades, se pueden garantizar con la asignación monótona en frecuencia

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 18

Análisis del factor de utilización


La cantidad U =

∑ CT N

i

i =1





i

es el factor de utilización del procesador Es una medida de la carga del procesador para un conjunto de tareas En un sistema monoprocesador debe ser

U ≤ 1

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 19

10

Condición de garantía de los plazos basada en la utilización


Para el modelo simple, con prioridades monótonas en frecuencia, los plazos están garantizados si

U =

∑ CT N

i =1

i

≤ N ⋅ ( 21 N − 1)

i


La cantidad U0 (N ) = N ⋅ ( 21 N − 1)

es la utilización mínima garantizada para N tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 20

Utilización mínima garantizada

N 1 2 3 4 5

U0 1,000 0,828 0,779 0,756 0,743

limn→∞ U0 (N ) = log 2 ≈ 0,693

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 21

11

Ejemplo 1

Tarea

T

C P

τ1 τ2 τ3

30 40 50

10 3 10 2 12 1

El sistema no cumple la prueba de utilización (U > 0,779) La tarea 3 falla en t = 50

U 0,333 0,250 0,240 0,823

τ1 τ2

¡fallo!

τ3 0

20

40

60

80

100

120

140

160

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 22

Ejemplo 2

Tarea

T

C P

τ1 τ2 τ3

16 40 80

4 3 5 2 32 1

Este sistema está garantizado (U < 0,779)

U 0,250 0,125 0,400 0,775

τ1 τ2 τ3 0

STRL -11/11/2003

10

20

30

40

50

60

©2001-2002 Juan Antonio de la Puente

70

80

Planificación - 23

12

Ejemplo 3

Tarea

T

C P

τ1 τ2 τ3

20 40 80

5 3 10 2 40 1

Este sistema no pasa la prueba (U > 0,779), pero se cumplen los plazos

U 0,250 0,250 0,500 1,000

τ1 τ2 τ3 0

10

20

30

40

50

60

70

80

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 24

Factor de utilización con EDF


Los plazos están garantizados si y sólo si U=

∑ CT N

i =1

i

≤1

i


EDF permite una mayor utilización del procesador – pero tiene inconvenientes » » » »

STRL -11/11/2003

más difícil de realizar el núcleo de multiprogramación es más complejo tiene un comportamiento imprevisible en caso de sobrecarga requiere que todas las tareas tengan plazos asignados (FPS es más flexible en esto)

©2001-2002 Juan Antonio de la Puente

Planificación - 25

13

Ejemplo 1 - EDF

Tarea

T

C P

τ1 τ2 τ3

30 40 50

10 3 10 2 12 1

Con planificación EDF los plazos están garantizados (U < 1,0)

U 0,333 0,250 0,240 0,823

τ1 τ2 τ3 0

STRL -11/11/2003

20

40

60

80

100

120

©2001-2002 Juan Antonio de la Puente

140

160

Planificación - 26

Problemas del análisis de utilización


La prueba del factor de utilización no es exacta, ni se

puede generalizar a modelos de tareas más complejos – pero es eficiente, O(N)


Veremos una prueba basada en el cálculo del tiempo de respuesta de cada tarea

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 27

14

Análisis del tiempo de respuesta


Es un método más completo y flexible que el del factor de utilización para FPS

– es fácil de generalizar a otros modelos de tareas – proporciona una condición necesaria y suficiente para que los plazos estén garantizados


Se trata de calcular el tiempo de respuesta en el peor

caso de cada tarea, Ri, y comprobar directamente que es menor que el plazo correspondiente:

Ri ≤ Di

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 28

Ecuación del tiempo de respuesta

τj τi Ri

Ri = Ci + Ii

El tiempo de respuesta de una tarea es la suma de su tiempo de cómputo más la interferencia que sufre por la ejecución de tareas más prioritarias

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 29

15

Instante crítico


La interferencia es máxima cuando todas las tareas se activan a la vez – el instante inicial se denomina instante crítico Cj

τj

Cj

Cj

Cj

τi Ri Cj

τj

Cj

Cj

Cj

τi Ri ©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 30

Cálculo de la interferencia τj

Cj

Cj

τi Ri




El número de veces que una tarea de prioridad superior τj se ejecuta durante el intervalo [0,Ri) es: R  i   T  j   

función techo: x  = min k ∈ Z : k ≥ x

Por tanto, el valor de la interferencia de τj sobre τi es

Ii j = STRL -11/11/2003

R  i     Tj  

⋅ Cj ©2001-2002 Juan Antonio de la Puente

Planificación - 31

16

Cálculo del tiempo de respuesta


La interferencia total que sufre τi es Ii =

∑

hp(i ) = {j : 1..N | Pj > Pi }

R  i   ⋅C j T j ∈hp (i )   j  


La ecuación del tiempo de respuesta queda así: Ri = Ci +

∑

R i  j ∈ hp ( i )   Tj

   

⋅ Cj

– La ecuación no es continua ni lineal – No se puede resolver analíticamente

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 32

Iteración lineal


La ecuación del tiempo de respuesta se puede resolver mediante la relación de recurrencia

w in +1 = Ci +

∑

w n  i   ⋅Cj T j ∈hp ( i )   j  

K K

– la sucesión (w i0 ,w i1, w in , ) es monótona no decreciente – un valor inicial aceptable es w i0 = Ci – se termina cuando » a) win+1 = win (y entonces Ri = win), o bien » b) win+1 > Ti (no se cumple el plazo)

– converge siempre que U < 100%

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 33

17

Ejemplo 4

Tarea

T

C P

τ1 τ2 τ3

7 12 20

3 3 5

3 2 1

w 30 = 5

R 3 6 20

w 32 = 5 +

R1 = 3

w 33 = 5 +

w 20 = 3 3  ⋅3 7  6 = 3 +   ⋅3 7

5   5   ⋅3 +   ⋅ 3 = 11 7  12  11  11   ⋅3 +   ⋅ 3 = 14 7 12  14  14    ⋅3 +   ⋅ 3 = 17  7  12  17  17  ⋅ 3 +   ⋅ 3 = 20  7   12    20   20  ⋅ 3 +   ⋅ 3 = 20  7    12  

w 31 = 5 + 

w 12 = 3 + 

=6

w 34 = 5 +

w 22

= 6; R2 = 6

w 35 = 5 +

R3 = 20

Todas las tareas tienen sus plazos garantizados

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 34

Ejemplo 3 (repaso) Tarea

T

C P

τ1 τ2 τ3

20 40 80

5 10 40

3 2 1

U 0,250 0,250 0,500 1,000

R1 = 5 w = 10 0 2

w = 10 + 1 2

w = 10 + 2 2

 10    ⋅5  20   15   20  ⋅ 5  

R 5 15 80

w 30 = 40  40   40  ⋅5 +   ⋅ 10  20   40 

= 60

 60   60   ⋅ 5 +  40  ⋅ 10 20    

= 75

 75   75   ⋅ 5 +  40  ⋅ 10 20    

= 80

 80   80   ⋅ 5 +  40  ⋅ 10  20   

= 80 R3 = 80

w 31 = 40 + 

= 15 = 15; R 2 = 15

w 32 = 40 +  w 33 = 40 +  w 34 = 40 + 

Todas las tareas tienen sus plazos garantizados STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 35

18

Propiedades del análisis de tiempo de respuesta


Proporciona una condición necesaria y suficiente para la garantía de los plazos

∀i Ri ≤ Di


Permite un análisis del comportamiento temporal del


sistema más exacto que la prueba del factor de utilización El elemento crítico es el cálculo del tiempo de cómputo de cada tarea – optimista: los plazos puedes fallar aunque el análisis sea positivo – pesimista: él análisis puede ser negativo aunque los plazos no fallen en realidad

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 36

Tiempo de cómputo


Interesa el tiempo de ejecución en el peor caso


(WCET, worst case execution time) Hay dos formas de obtener el WCET de una tarea: – Medida del tiempo de ejecución » no es fácil saber cuándo se ejecuta el peor caso posible

– Análisis del código ejecutable » se descompone el código en un grafo de bloques secuenciales » se calcula el tiempo de ejecución de cada bloque » se busca el camino más largo

Puede ser muy pesimista » es difícil tener en cuenta los efectos de los dispositivos de hardware (caches, pipelines, estados de espera de la memoria, etc..) » hace falta tener un modelo adecuado del procesador

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 37

19

Análisis estático del WCET


Generalmente se hace en tres pasos: 1. Descomposición del código en un grafo dirigido compuesto por bloques básicos (secuencias) 2. Cálculo del WCET de cada bloque básico a partir del código de máquina y del modelo del procesador 3. Cálculo del WCET total a partir del camino más largo del grafo

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 38

Mejora con información semántica


Ejemplo: for I in 1.. 10 loop if Cond then -- bloque básico con coste 100 else -- bloque básico con coste 10 end if; end loop; – Sin más información, el coste peor es 10 × 100 = 1000 – Si sabemos que Cond sólo es verdadera 3 veces, entonces el coste es 3×100 + 7×10 = 370

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 39

20

Restricciones en el código


Para poder calcular el tiempo de cómputo hay que evitar utilizar estructuras con tiempo de cómputo no acotado, como: – – – –

bucles no acotados recursión no acotada objetos dinámicos tareas dinámicas


Para construir sistemas de tiempo real estricto se utilizan subconjuntos del lenguaje de programación que no usan estos elementos Ejemplos: » SPARK (parte secuencial de Ada) » Ravenscar (parte concurrente)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 40

Tareas esporádicas y aperiódicas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 41

21

Tareas esporádicas


Para incluir tareas esporádicas hace falta modificar el modelo simple de tareas:

– El parámetro T representa la separación mínima entre dos sucesos de activación consecutivos – Suponemos que en el peor caso la activación es pseudoperiódica (con período T) – El plazo de respuesta puede ser menor que el período (D ≤ T)


El análisis de tiempo de respuesta sigue siendo válido
Funciona bien con cualquier orden de prioridad STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 42

Prioridades monótonas en plazos Cuando los plazos son menores o iguales que los períodos, la asignación de mayor prioridad a las tareas de menor plazo de respuesta (deadline monotonic scheduling) es óptima


El tiempo de respuesta se calcula de la misma forma que con la asignación monótona en frecuencia – se termina cuando win+1 = win, – o cuando win+1 > Di

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 43

22

Ejemplo 5 Tarea

T

D

C P

τ1 τ2 τ3 τ4

20 15 10 20

5 7 10 20

3 3 4 3

4 3 2 1

R 3 6 10 20

Con prioridades monótonas en frecuencia los plazos no están garantizados: Tarea

T

D

C P

τ3 τ2 τ1 τ4

10 15 20 20

10 7 5 20

4 3 3 3

STRL -11/11/2003

4 3 2 1

R 4 7 10 20

©2001-2002 Juan Antonio de la Puente

Planificación - 44

Tareas críticas y acríticas


A menudo los tiempos de cómputo en el peor caso de las tareas esporádicas son mucho más altos que los medios – interrupciones en rachas, tratamiento de errores – planteamiento demasiado pesimista


No todas las tareas esporádicas son críticas – Deben garantizarse los plazos de todas las tareas en condiciones “normales” » con separación entre activaciones y tiempos de cómputo medios

Puede haber una sobrecarga transitoria – Deben garantizarse los plazos de las tareas críticas en las peores condiciones » con separación entre activaciones y tiempos de cómputo peores

Esto asegura un comportamiento correcto en caso de sobrecarga transitoria STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 45

23

Tareas aperiódicas


Son tareas acríticas sin separación mínima
Se pueden ejecutar con prioridades más bajas que las tareas críticas (periódicas y esporádicas)

– el tiempo de respuesta puede ser muy largo – en condiciones normales sobra tiempo de cómputo de las tareas críticas


Es mejor utilizar un servidor

– el servidor asegura que las tareas críticas tienen asegurados sus recursos – pero asignan los recursos que no se utilizan a las tareas acríticas

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 46

Servidor esporádico


Un servidor esporádico (SS, sporadic server) es un proceso periódico

– Parámetros: período Ts, tiempo de cómputo Cs, prioridad máxima » Cs es la capacidad inicial del servidor » Ts y Cs se eligen de forma que las tareas críticas estén garantizadas

– Cuando se activa una tarea aperiódica, se ejecuta con prioridad máxima mientras quede capacidad disponible – Cuando se agota la capacidad se ejecuta con prioridad baja – La capacidad se rellena cuando ha pasado un tiempo Ts desde la activación de la tarea aperiódica

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 47

24

Interacción entre tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 48

Interacción entre tareas


En la mayoría de los sistemas de interés práctico las tareas interaccionan mediante – datos comunes (protegidos) – citas o mensajes


En todos estos casos puede ocurrir que una tarea tenga



que esperar un suceso de otra menos prioritaria Esta situación se denomina bloqueo, bloqueo y produce una inversión de prioridad indeseable La inversión de prioridad no se puede eliminar completamente, pero es posible limitar su duración

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 49

25

Ejemplo 6

τ1

τ2

τ3

X

Y

Tarea P ta τ1 τ2 τ3 τ4

4 3 2 1

τ4

4 2 2 0

N: ejecución de código propio X: ejecución con acceso a X Y: ejecución con acceso a Y (durante 1 unidad de tiempo)

Acciones NNXYN NYYN NN NXXXXN

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 50

Ejemplo 6 : inversión de prioridad

bloqueo

τ1 τ2 τ3 τ4 0

STRL -11/11/2003

2

4

6

8

10

12

©2001-2002 Juan Antonio de la Puente

14

16

18

Planificación - 51

26

Herencia de prioridad


Una forma de reducir la duración de los bloqueos es variar



dinámicamente la prioridad de las tareas Cuando una tarea está bloqueando a otra más prioritaria, hereda la prioridad de ésta La prioridad dinámica de una tarea es el máximo de – su prioridad básica – las prioridades de todas las tareas bloqueadas por ella


La herencia de prioridad es transitiva

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 52

Ejemplo 6 : herencia de prioridad

4

τ1 3

4

3

τ2 2

τ3 1

4

1

τ4 0

STRL -11/11/2003

2

4

6

8

10

12

©2001-2002 Juan Antonio de la Puente

14

16

18

Planificación - 53

27

Duración máxima del bloqueo


Con el protocolo de herencia de prioridad, una tarea se pude bloquear como máximo

– una vez por cada recurso – una vez por cada tarea de prioridad inferior


La duración total máxima de los bloqueos es Bi = K u(k,i)

∑ u (k , i ) ⋅ C ( k ) K

k =1

Ck

número de secciones críticas 1 si algún τj, Pj < Pi, accede a k 0 si no tiempo de ejecución de la sección crítica k

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 54

Ejemplo 6 : cálculo del bloqueo K =4 B1 B2 B3 B4

( X1,Y1,Y2, X 4 ) = 0 ⋅ 1 + 0 ⋅ 1 + 1 ⋅ 2 + 1⋅ 4 = 0 ⋅ 1 + 0 ⋅ 1 + 0 ⋅ 2 + 1⋅ 4 = 0 ⋅ 1 + 0 ⋅ 1 + 0 ⋅ 2 + 1⋅ 4 = 0 ⋅1+ 0 ⋅1+ 0 ⋅ 2 + 0 ⋅ 4

=6 =4 =4 =0

– Una tarea puede bloquearse por recursos a los que no accede (por ejemplo, τ2) – Una tarea puede sufrir bloqueo aunque no acceda a recursos compartidos (por ejemplo, τ3) – La tarea de menor prioridad (τ4) no sufre bloqueo

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 55

28

Tiempo de respuesta con bloqueos


Cuando hay bloqueos, la ecuación del tiempo de respuesta queda así: Ri = Ci + Bi +

∑

j ∈hp(i)

R  i   T   j  

⋅ Cj

La solución se obtiene mediante la relación de recurrencia w in + 1 = Ci + Bi +

∑

j ∈hp(i)

w n  i   T   j  

⋅ Cj

¡Ahora el cálculo puede ser pesimista!

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 56

Protocolos de techo de prioridad


El techo de prioridad de un recurso es la máxima prioridad de las tareas que lo usan


El protocolo del techo de prioridad (CPP) consiste en : – la prioridad dinámica de una tarea es el máximo de su prioridad básica y las prioridades de las tareas a las que bloquea – una tarea sólo puede usar un recurso si su prioridad dinámica es mayor que el techo de todos los recursos en uso por otras tareas

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 57

29

Ejemplo 6 : techo de prioridad

4

τ1 3

τ2 2

τ3 1

3

1

1

4

τ4 0

2

4

6

8

10

12

14

16

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

18

Planificación - 58

Propiedades


Cuando se usa el protocolo del techo de prioridad en un sistema monoprocesador,

– Cada tarea se puede bloquear una vez, como máximo, en cada ciclo – No puede haber interbloqueos – No puede haber bloqueos encadenados


La duración máxima del bloqueo es ahora Bi = max u ( k , i ) ⋅ C k K ∈(1 ..K )

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 59

30

Protocolo del techo de prioridad inmediato (ICPP)


Con este protocolo, una tarea que accede a un recurso

hereda inmediatamente el techo de prioridad del recurso – la prioridad dinámica de una tarea es el máximo de su prioridad básica y los techos de prioridad de los recursos que usa


Las propiedades son las mismas que las del protocolo del techo de prioridad, y además,

– si una tarea se bloquea, lo hace al principio del ciclo


La duración máxima del bloqueo es igual que en CPP: Bi = max u ( k , i ) ⋅ C k K ∈(1 ..K )

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 60

Ejemplo 6 : techo de prioridad inmediato

4

τ1 3

4

3

τ2 2

τ3 1

4

1

τ4 0

STRL -11/11/2003

2

4

6

8

10

12

©2001-2002 Juan Antonio de la Puente

14

16

18

Planificación - 61

31

Ejemplo 6 : cálculo del bloqueo con ICPP

K =4 B1 B2 B3 B4

STRL -11/11/2003

( X1,Y1,Y2, X 4 ) = max (0 ⋅ 1, 0 ⋅ 1, 1⋅ 2, 1⋅ 4) = max (0 ⋅ 1, 0 ⋅ 1, 0 ⋅ 2, 1⋅ 4 ) = max (0 ⋅ 1, 0 ⋅ 1, 0 ⋅ 2, 1⋅ 4 ) = max (0 ⋅ 1, 0 ⋅ 1, 0 ⋅ 2, 0 ⋅ 4 )

=4 =4 =4 =0

©2001-2002 Juan Antonio de la Puente

Planificación - 62

CPP e ICPP


Los dos protocolos tienen las mismas propiedades,pero – ICPP es más fácil de realizar » no hay que seguir las relaciones de bloqueo transitivas

– ICPP produce menos cambios de contexto » el bloqueo se produce antes de la ejecución

– ICPP produce más cambios de prioridad » se hereda la prioridad techo aunque no haya bloqueo


El protocolo ICPP se conoce también con otros nombres: – – – –

Ceiling Locking (Ada 95) Priority Protect Protocol (POSIX) Priority Ceiling Emulation (RT Java) Highest Locker

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 63

32

Ejemplo 7 τ1

τ2

P1

τ3

τ4

P2

τ5

P3

FPS ICPP Atributos temporales

τ

T

C

D

Acceso a OP P1

P2

P3

τ1

S

120

2

5

1

—

—

τ2

P

50

10

50

—

—

1

τ3

P

30

6

30

—

1

—

τ4

S

300

16

32

—

2

—

τ5

S

120

12

15

2

—

2

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 64

Ejemplo 7 — Prioridades



Las prioridades de las tareas se asignan por DMS (más prioridad a las tareas de menor plazo) El techo de prioridad de cada objeto protegido es la prioridad máxima de las tareas que lo usan Atributos temporales

τ

Acceso a OP

P

T

C

D

P1

P3

P2

1

—

—

τ1

S

5

120

2

5

τ5

S

4

120

12

15

2

2

—

τ3

P

3

30

6

30

—

—

1

τ4

S

2

300

16

32

—

—

2

τ2

P

1

50

10

50

—

1

—

5

4

3

CP

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 65

33

Ejemplo 7 — Bloqueos Bi = max u (k , i ) ⋅ C k K ∈(1..K )

Atributos temporales

τ

P

T

C

B

Acceso a OP D

P1

P3

P2

τ1

S

5

120

2

2

5

1

—

—

τ5

S

4

120

12

1

15

2

2

—

τ3

P

3

30

6

2

30

—

—

1

τ4

S

2

300

16

1

32

—

—

2

τ2

P

1

50

10

0

50

—

1

—

5

4

3

CP

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 66

Ejemplo 7 — Tiempos de respuesta R1 = C1 + B1 = 2 + 2 = 4  R5  ·C1  T1 

R5 = C5 + B5 + 

R5  ·2  120  

= 12 + 1 + 

 R3   R3  ·C5 ·C1 +   T1   T5 

= 6+2+ 

R4  R4  ·C1 +  ·C 5  T1   T5 

+

 R2  R2  ·C1 +  ·C5  T1   T5 

+

R3 = C3 + B3 + 

R 4 = C 4 + B4 +  R2 = C2 + B2 + 

R3   R3  ·2 +  ·12 120  120  

R4  ·C 3  T3 

= 16 + 1 + 

 R2  ·C3  T3 

+

R4  R  R  ·2 +  4 ·12 +  4 ·6  120  120   30  

 R2  ·C 4  T4 

R  R  R   R  = 10 + 0 +  2 ·2 +  2 ·12 +  2 ·6 +  2 ·16 120  120   30   300 

Atributos temporales

τ

Acceso a OP

P

T

C

B

R

D

P1

P3

P2

τ1

S

5

120

2

2

4

5

1

—

—

τ5

S

4

120

12

1

15

15

2

2

—

τ3

P

3

30

6

2

22

30

—

—

1

τ4

S

2

300

16

1

43

32

—

—

2

τ2

P

1

50

10

0

52

50

—

1

—

5

4

3

CP STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 67

34

Modelo de tareas generalizado

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 68

Generalización el modelo de tareas


El modelo de tareas básico que hemos visto incluye – tareas periódicas, esporádicas y aperiódicas – plazos menores o iguales que los períodos – interacción mediante secciones críticas


El análisis del tiempo de respuesta se puede extender con – – – – – –

planificación cooperativa variación (jitter) en el esquema de activación plazos arbitrarios (también mayores que los períodos) tolerancia de fallos desfases (offsets) asignación de prioridades óptima

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 69

35

Planificación cooperativa






En sistemas críticos a veces no es aceptable la planificación con desalojo – el desalojo introduce indeterminismo

La planificación cooperativa es una alternativa – las tareas se segmentan en bloques de duración igual o menor que BMAX (el bloqueo máximo con desalojo) – al final de cada bloque se ofrece un cambio de contexto (si hay alguna tarea más prioritaria) – las secciones críticas se meten dentro de un solo bloque

Ventajas: – se pueden garantizar sistemas que no están garantizados con desalojo » el último bloque no sufre interferencia




– se puede hacer un cálculo de WCET más exacto

Inconveniente – el coste de ofrecer un cambio de contexto puede ser alto (e innecesario)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 70

Tiempo de respuesta con planificación cooperativa


El último bloque de una tarea no puede sufrir interferencia
La ecuación del tiempo de respuesta queda así: w in +1 = BMAX + C i − Fi +

∑

w n  i   ⋅C j T j∈hp ( i )   j  

Ri = w in + Fi , para w in +1 = w in

Fi es el tiempo de cómputo del último bloque

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 71

36

Activación irregular (release jitter)


Es importante en sistemas distribuidos – Por ejemplo, sea una tarea esporádica activada por un suceso producido por una tarea periódica situada en otro procesador » el tiempo de respuesta de la tarea periódica puede variar entre Cp y Rp T

τP CP

RP

T - (RP - CP)

J = Rp-Cp

τS 0

2

4

6

8

10

12

14

16

18

20

22

24

26

28

30

32

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

34

36

Planificación - 72

Tareas esporádicas con jitter


En el peor caso, la tarea esporádica se activa en 0, T-J,


2T-J, ... La tarea τs interfiere a otra tarea cualquiera τi: – 1 vez si Ri ∈ [0, T-J) – 2 veces si Ri ∈[T-J, 2T-J), – etc.

o Ri + J ∈ [0, T) o Ri + J ∈ [T, 2T)


La ecuación del tiempo de respuesta queda así: w

n+1 i

= Ci + Bi +

∑

j ∈hp(i)

 w in +  Tj 

Jj   

⋅ Cj

Ri = w in , para w in + 1 = w in STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 73

37

Tareas periódicas con jitter


Las tareas periódicas no suelen tener jitter
Puede haberlo si la planificación se hace con una


granularidad apreciable El tiempo de respuesta se calcula con w

n +1 i

= Ci + Bi +

∑

j ∈hp(i)

 w in +  Tj  

Jj    

⋅ Cj

Ri = w in + Ji , para w in + 1 = w in

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 74

Plazos arbitrarios


Si el plazo es mayor que el período, puede haber varias ejecuciones de una tarea pendientes en un ciclo

– suponemos que no se activa una ejecución hasta que termina la anterior


Para analizar esta situación construimos una sucesión de


ventanas wi(q), donde q + 1 es el número de activaciones de τi pendientes Para cada ventana se obtiene un valor de Ri con w in + 1(q) = (q + 1) ⋅ Ci + Bi +

∑

j ∈hp(i)

 w n(q) i   T   j  

⋅ Cj

Ri(q) = w in(q) − q ⋅ Ti STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 75

38

Tiempo de respuesta máximo


Se calcula Ri(q) para q = 0, 1, ... , qmax, donde qmax es el menor valor que cumple

Ri(qmax) ≤ Ti En esta situación ya no hay solape con la siguiente activación


El tiempo de respuesta en el peor caso es Ri = max Ri (q ) q = 0,..qmax

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 76

Caso general


Si consideramos plazos arbitrarios y jitter, el tiempo de respuesta se obtiene con

w in + 1(q) = (q + 1) ⋅ Ci + Bi +

∑

i ∈hp(i)

 w in(q) +  Tj  

Jj    

⋅ Cj

Ri(q) = w in(q) − q ⋅ Ti + Ji

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 77

39

Tolerancia de fallos


Cuando hay tolerancia de fallos, el tiempo de cómputo en el peor caso es mayor

– por ejemplo, manejadores de excepciones


Los plazos deben estar garantizados incluso son cierto nivel de fallos

– esto se llama modelo de fallos


El tiempo de respuesta se calcula con Ri = Bi + Ci +

∑

R i  j∈hp ( i )  T j

 Cj  

+ max C fj j∈hep ( i )

– hep(i) es el conjunto de tareas con prioridad igual o mayor que Pi – Cjf es el tiempo de cómputo de la parte de recuperación de fallos de τj

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 78

Tolerancia de fallos múltiples


Si se pueden tolerar F fallos del mismo tipo, Ri = Bi + Ci +

∑

R  i  Cj T j∈hp ( i )   j  

+ max FC fj j ∈hep ( i )


Si los fallos ocurren en ráfagas y se puede especificar un tiempo mínimo entre fallos Tf, Ri = Bi + Ci +

STRL -11/11/2003

∑

R i  j∈hp ( i )  Tj

 Cj  

 R  f i C j j∈hep ( i ) T  j   

+ max  

©2001-2002 Juan Antonio de la Puente

   

Planificación - 79

40

Fase inicial


Hasta ahora hemos supuesto que la fase inicial (offset) de todas las tareas es nulo

t r (k ) = (k − 1) ⋅ T + O


Si no lo es, se puede mejorar la planificación – en algunos casos no hay instantes críticos – los tiempos de respuesta son más cortos


El análisis es muy complejo (NP-duro) – pero algunos sistemas se pueden analizar de forma eficiente

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 80

Ejemplo 7 Tarea

T

D

C P

a b c

8 20 20

5 10 12

4 4 4

R 4 8 16

3 2 1

¡La tarea c falla !

a b c

0

4

STRL -11/11/2003

8

12

16

20

24

©2001-2002 Juan Antonio de la Puente

28

32

36

Planificación - 81

41

Ejemplo 7: fase > 0

0

Tarea

T

D

C O P

a b c

8 20 20

5 10 12

4 4 4

4

8

12

0 3 0 2 10 1

16

R 4 8 8

20

¡Con O = 10, la tarea c no falla!

24

28

32

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

36

Planificación - 82

Ejemplo 7: análisis


Las tareas b y c equivalen a una tarea ficticia con T = Tb / 2 = Tc / 2 C = max (Cb ,Cc ) D = min(Db , Dc )

P = max (Pb , Pc )


También se pueden analizar otros tipos de sistemas con desfases

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 83

42

Asignación de prioridades


Con el modelo general que hemos, la ordenación de


prioridades monótona en frecuencia (RMS) o en plazos no es óptima Se aplica el siguiente teorema: Si una tarea τ cumple su plazo con la prioridad más baja del sistema, y existe un orden de prioridades admisible para todo el sistema, entonces hay un orden de prioridades que garantiza todas las tareas en el cual τ tiene la prioridad más baja

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 84

Algoritmo procedure Assign_Priority (System: in out Task_Set; N : Natural; OK : out Boolean) is begin for k in 1 .. N loop for next in k ..N loop Swap (System, k, next); Test (System, k, OK); exit when OK; end loop; exit when not OK; -- no hay ninguna tarea garantizada end loop; end Assign_Priority;

System(1) tiene la prioridad mínima y System(N) la máxima Test comprueba el plazo de la tarea System (k)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 85

43

Planificación dinámica

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 86

Sistemas dinámicos


Hay sistemas de tiempo real en los que no se conocen de antemano los tiempos de cómputo ni los esquemas de activación – las tareas se crean y se destruyen durante la ejecución – hay que hacer el análisis sobre la marcha


El algoritmo EDF es óptimo y se adapta bien a los sistemas dinámicos

– pero funciona mal en caso de sobrecarga


Se complementa con un módulo de control de admisión – cuando llega una tarea nueva se decide si se admite o no – el objetivo es garantizar el buen funcionamiento del método EDF


Criterios de admisión

– evitar sobrecargas – maximizar el valor de las tareas que se ejecutan

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 87

44

Asignación de valor a las tareas


Se puede hacer de varias formas: – asignación estática: cada ejecución de la misma tarea tiene el mismo valor – asignación dinámica: el valor de la ejecución de una tarea se calcula en el momento de su activación – asignación adaptativa: el valor cambia durante la ejecución de la tarea


Hay que encontrar un compromiso entre lo que se gana

con la planificación dinámica y lo que se pierde en términos del tiempo necesario para tomar las decisiones

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 88

Realización de sistemas planificados con prioridades

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 89

45

Planificación de tareas en Ada


En el anexo de tiempo real se define un modelo de


planificación con prioridades y desalojo La prioridad de una tarea es de un subtipo definido en el paquete System subtype Any_Priority is Integer range intervalo; subtype Priority is Any_Priority range Any_Priority’First .. valor; subtype Interrupt_Priority is Any_Priority range Priority’Last + 1 .. Any_Priority’Last;


Los valores mayores denotan prioridades más altas
Debe haber al menos 30 valores de Priority y 1 de Interrupt_Priority

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 90

Prioridad básica


La prioridad básica de una tarea o un tipo tarea se especifica con un pragma Priority

task Controller is pragma Priority (10); end Controller; task type Server (Task_Priority : System.Priority) is entry Service_1 (...); ... pragma Priority (Task_Priority); end Server;

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 91

46

Techo de prioridad inmediato


Cada objeto protegido tiene una prioridad techo (ceiling

priority) mayor o igual que la prioridad de las tareas que usan el objeto – por omisíón es System.Priority'Last


Cuando una tarea llama a una operación de un objeto protegido, hereda la prioridad techo del objeto

– si la prioridad de la tarea es mayor que el techo se eleva Program_Error


El protocolo del techo de prioridad inmediato basta para asegurar la exclusión mutua en un monoprocesador

– si una tarea que quiere ejecutar una operación protegida se está ejecutando, el objeto no puede estar ocupado STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 92

Prioridad techo


Para usar el protocolo del techo de prioridad inmediato hay que poner un pragma de configuración pragma Locking_Policy (Ceiling_Locking);

– afecta a todo el programa (con GNAT se pone en gnat.adc)


El techo de prioridad de un objeto o un tipo protegido se especifica mediante un pragma Priority

protected type Resource(Ceiling : System.Priority)is ... pragma Priority (Ceiling); end Resource;

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 93

47

Ejecución de operaciones protegidas


Cuando se usa el protocolo del techo de prioridad

inmediato se pueden implementar las barreras de forma muy eficiente (proxy model): – cuando termina un procedimiento o entrada protegida se ejecutan las entradas que se puedan haber abierto como consecuencia – esto se hace con el mismo flujo de control de la tarea que llama a la primera operación – se reduce el número de cambios de contexto – todo esto es posible porque las operaciones se ejecutan con prioridad elevada

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 94

Ejemplo protected Gate_Control is pragma Priority(28); entry Stop_And_Close; procedure Open; private Gate : Boolean := False; end Gate_Control; protected body Gate_Control is entry Stop_And_Close when Gate is begin Gate := False; end; procedure Open is begin Gate := True; end; end Gate_Control;

STRL -11/11/2003










Supongamos que – una tarea T (prioridad = 20) llama a Stop_and_Close y se suspende – otra tarea S (prioridad =27) llama a Open

La hebra de S ejecuta: – el código de Open – la evaluación de la barrera – el código de Stop_and Close (por cuenta de T) – la evaluación de la barrera otra vez – la vuelta al punto donde S llamó a Open

No hay cambio de contexto

©2001-2002 Juan Antonio de la Puente

Planificación - 95

48

Prioridad activa


La prioridad activa de una tarea es el máximo de su prioridad básica y la prioridad heredada de otras


Una tarea puede heredar prioridad de varias formas : – cuando ejecuta una operación protegida hereda el techo de prioridad del objeto – cuando ejecuta una instrucción accept hereda la prioridad de la tarea que llama al punto de entrada – durante su activación hereda la prioridad de su progenitor

©2001-2002 Juan Antonio de la Puente

STRL -11/11/2003

Planificación - 96

Protocolo de despacho


Se puede especificar un protocolo de despacho mediante un pragma de configuración:

pragma Task_Dispatching_Policy (FIFO_within_Priority);

– Hay una cola conceptual por cada nivel de prioridad – El núcleo de ejecución despacha la primera tarea de la cola de mayor prioridad que no esté vacía – Cuando una tarea se activa se coloca al final de la cola correspondiente a su prioridad activa – Las tareas desalojadas se colocan al principio de su cola


Puede haber otros protocolos de despacho, pero no son obligatorios

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 97

49

Otros mecanismos de planificación


Prioridades dinámicas (que se pueden cambiar por el


programa) Colas ordenadas por prioridades en puntos de entrada pragma Queuing_Policy (Priority_Queuing);


Identificadores y atributos de tareas
Control síncrono y asíncrono de tareas
Aborto inmediato
Restricciones para facilitar el análisis de tiempos
Requisitos sobre documentación de tiempos STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 98

Planificación en POSIX


POSIX



define un modelo de planificación con prioridades y desalojo La prioridad básica de una tarea se puede cambiar dinámicamente Se puede especificar el protocolo de despacho FIFO (como en Ada) – otros: Round-Robin, Sporadic Server, ... – debe al menos 32 prioridades distintas


Se puede especificar que todos los threads de un sistema se planifiquen globalmente (system contention)

– la política de planificación se puede ajustar por procesos o por threads

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 99

50

Ámbito de planificación


El ámbito de la planificación se define con #include int pthread_attr_setscope (pthread_attr_t *attr, int contentionscope);


También hay que especificar si los atributos de planificación son específicos de cada thread:

int pthread_attr_setinheritsched ( pthread_attr_t *attr, int inheritsched);


Normalmente se pone – PTHREAD_SCOPE_SYSTEM para contentionscope – PTHREAD_EXPLICIT_SCHED para inheritsched STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 100

Política de planificación


La política de planificación dentro del mismo nivel de prioridad se define con

int pthread_attr_setschedpolicy ( pthread_attr_t *attr, int policy);


El parámetro policy puede ser – SCHED_FIFO (orden de llegada) – SCHED_RR (turno circular con rodajas de tiempo) – SCHED_OTHER (dependiente de la implementación)


En general, hay que poner SCHED_FIFO

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 101

51

Prioridades


La prioridad de un thread es un parámetro de planificación:

#include struct sched_param { int sched_priority; ... }

y se especifica con int pthread_attr_setschedparam ( const pthread_attr_t *attr, const struct sched_param *param);


Los atributos se usan para crear el thread STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 102

Protocolo de acceso a mutex


Se puede especificar un protocolo de acceso con #include int pthread_mutexattr_setprotocol ( pthread_mutex_attr_t *attr, int *protocol);

El protocolo puede ser – PTHREAD_PRIO_INHERIT (herencia de prioridad) – PTHREAD_PRIO_PROTECT (techo de prioridad inmediato) – PTHREAD_PRIO_NONE (no hay herencia de prioridad)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 103

52

Prioridad techo


Se especifica con int pthread_mutexattr_setprioceiling ( pthread_mutexattr_t *attr, int prioceiling);

Los atributos se usan para iniciar el mutex

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 104

Servidor esporádico


Un servidor esporádico es un thread que tiene una

capacidad limitada para ejecutar tareas esporádicas con prioridad alta – si se agota la capacidad se sigue ejecutando con prioridad baja – parámetros: capacidad, intervalo de relleno, prioridades alta y baja

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 105

53

Planificación en RT Java


Interfaz Schedulable – implementada por RealtimeThread, NoHeapRealtimeThread AsyncEventHandler y otros


Planificación con prioridades y desalojo – al menos 28 valores de prioridad – los threads que no son de tiempo real van pro debajo – los threads desalojados no se ponen al principio de la cola


En general, enfoque más dinámico que en Ada y POSIX

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 106

Interfaz Schedulable public Interface Schedulable extends java.lang.Runnable { public void addToFeasibility(); public void removeFromFeasibility(); public MemoryParameters getMemoryParameters(); public void setMemoryParameters(MemoryParameters memory); public ReleaseParameters getReleaseParameters(); public void setReleaseParameters(ReleaseParameters release); public SchedulingParameters getSchedulingParameters(); public void setSchedulingParameters( SchedulingParameters scheduling); public Scheduler getScheduler(); public void setScheduler(Scheduler scheduler); } STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 107

54

Scheduling Parameters public abstract class SchedulingParameters { public SchedulingParameters(); } public class PriorityParameters extends SchedulingParameters { public PriorityParameters(int priority); public int getPriority(); // at least 28 priority levels public void setPriority(int priority) throws IllegalArgumentException; ... } public class ImportanceParameters extends PriorityParameters { public ImportanceParameters(int priority, int importance); public int getImportance(); public void setImportance(int importance); ... } STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 108

Planificación de alto nivel


La clase Scheduler permite definir un planificador de alto nivel

– decidir se se pueden admitir nuevos objetos planificables (threads) – ajustar las prioridades de los objetos planificables

Todo ello de acuerdo con un algoritmo de aceptación (feasibility algorithm)

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 109

55

Scheduler public abstract class Scheduler { public Scheduler(); protected abstract void addToFeasibility(Schedulable s); protected abstract void removeFromFeasibility(Schedulable s); public abstract boolean isFeasible(); // checks the current set of schedulable objects public boolean changeIfFeasible(Schedulable schedulable, ReleaseParameters release, MemoryParameters memory); public static Scheduler getDefaultScheduler(); public static void setDefaultScheduler(Scheduler scheduler); public abstract java.lang.String getPolicyName(); } STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 110

Priority Scheduler class PriorityScheduler extends Scheduler { public PriorityScheduler() protected void addToFeasibility(Schedulable s); ... public void fireSchedulable(Schedulable schedulable); public int getMaxPriority(); public int getMinPriority(); public int getNormPriority(); public static PriorityScheduler instance(); ... }

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 111

56

Otros mecanismos


Herencia de prioridades y techo de prioridad (priority ceiling emulation)


Threads periódicos y aperiódicos – grupos de threads aperiódicos


Colas ordenadas por prioridades

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 112

Resumen


Un método de planificación tiene dos partes: – un algoritmo de reparto de recursos – un método de análisis del comportamiento temporal


El método tradicional se basa en un ejecutivo cíclico – el análisis es inmediato (por construcción) – es poco flexible y de bajo nivel


Un método mejor se basa en el uso de prioridades fijas – las prioridades se asignan por orden de períodos, plazos o de forma arbitraria – se puede analizar el tiempo de respuesta de las tareas – se pueden analizar tareas con interacción si se usa un protocolo de herencia o techo de prioridad

STRL -11/11/2003

©2001-2002 Juan Antonio de la Puente

Planificación - 113

57

dit UPM

Sistemas distribuidos Alejandro Alonso Juan Antonio de la Puente DIT/UPM

Objetivos ‹

Comprender los problemas que se plantean en la realización de sistemas de tiempo real estricto distribuidos

‹

Conocer los protocolos y métodos de análisis más adecuados para este tipo de sistemas

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

1

Sistemas distribuidos ‹

Un sistema distribuido está formado por un conjunto de computadores autónomos conectados para conseguir un objetivo común Ventajas: – – – –

‹

rendimiento fiabilidad cercanía a los elementos del entorno físico flexibilidad

Los sistemas de tiempo real distribuidos (STRD) tienen requisitos temporales – como siempre, esto añade complejidad

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

2

Arquitectura de STRD ‹

Conjunto de nodos conectados por redes de comunicación – cada nodo puede ser un multiprocesador conectado por buses

‹

Sólo consideraremos sistemas débilmente acoplados – los nodos no tienen memoria común – comunicación por mensajes

‹

Se suelen estructurar jerárquicamente, para reflejar la diversidad en – la escala de tiempos – la información tratada – los requisitos de cada procesador

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

3

Ejemplo: sistemas de fabricación Procesamiento de información

Centro de Proceso de Datos

Control de planta

Control de planta

Control de área

Control de área Control de Celda Robots

Control de celda

Control de Celda

PLCs

PLCs

Control de máquina

Robots

Los requisitos temporales son tanto más estrictos cuanto menor es el grado de abstracción ©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

4

Ejemplo: sistema de aviónica avión

S

S

A

votación

procesador

Nodo 1

S

A

A

votación

procesador

procesador

votación

Nodo 2

bus ARINC

Sistemas con requisitos de seguridad críticos – redundancia activa (sistema modular triple, bus duplicado, etc.) – requisitos de tiempo real estrictos STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

5

Requisitos temporales y planificación ‹

Tiempo global – relojes – requisitos temporales

‹

Asignación de tareas a procesadores

‹

Planificación – requisitos temporales globales – planificación local y global – planificación de los mensajes

‹

Tolerancia de fallos

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

6

Tiempo global ‹

Los componentes de un sistema distribuido deben tener una visión global del tiempo – referencia de tiempo común » se mantienen los requisitos de monotonicidad y variación acotada » tiempo del sistema o TAI » acceso a reloj global (p.e. GPS) o relojes locales sincronizados

– requisitos de tiempo globales (end-to-end) » requisitos temporales asociados a transacciones (conjunto de actividades que constituyen la respuesta a un suceso)

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

7

Sincronización de relojes ‹

Los relojes locales tienen variaciones que obligan a sincronizarlos – movimiento ρ : 1− ρ ≤

τ (t ′) − τ (t ) t′ −t

≤ 1+ ρ

– relojes de cuarzo: ρ ≈ 2·10-6 (1 s en 6 días) » si la granularidad del tiempo es del orden de 1 ms hay que sincronizar los relojes cada 8 min

– sincronización «suave» » para adelantar ƒ aumentar la frecuencia ƒ incremento acotado del valor del reloj » para retrasar ƒ disminuir la frecuencia ƒ mantener el valor durante un tiempo acotado

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

8

Algoritmos de sincronización de relojes ‹

Sincronización centralizada – un computador actúa como servidor de hora – el servidor radia periódicamente la hora a los demás – problema: si falla el servidor se pierde la sincronización

‹

Sincronización distribuida – buscar un consenso distribuido sobre el valor del tiempo » hay varios algoritmos para esto

– requisitos » diferencia entre dos relojes cualesquiera acotada » diferencia con el tiempo real acotada ‹

Granularidad del algoritmo de sincronización – ∆ : máxima diferencia entre dos relojes cualesquiera

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

9

Requisitos de tiempo globales ‹

Los plazos de respuesta se asocian a las transacciones – actividades que constituyen la respuesta a un suceso Ejemplo: procesador A

DSP

SAD

procesador B

red local

entorno

» La respuesta comienza con la lectura de un dato (en SAD) » Termina cuando se actúa sobre el sistema físico (en el procesador 2) » El tiempo de respuesta dura desde la lectura hasta el final STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

10

Distribución de la carga ‹

Asignación de tareas a procesadores – estática: al diseñar el sistema – dinámica: durante la ejecución Consideraremos, en general que la asignación es estática

‹

Criterios de asignación: – recursos disponibles y requisitos de utilización – distribución geográfica – replicación de tareas

‹

Problema muy complejo (NP-duro) – más fácil con asignación estática » DMS, EDF son óptimos en cada nodo » hay que tener en cuenta el tiempo de transmisión de los mensajes

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

11

Planificación y análisis temporal ‹

Para poder analizar el tiempo de respuesta global de una transacción hay que conocer – los tiempos de cómputo máximos de cada tarea que interviene en la transacción – los tiempos de transmisión máximos de los mensajes

‹

Hace falta que el tiempo de transmisión esté acotado – protocolos de comunicación deterministas – los mensajes tienen atributos temporales (período, plazo) » la planificación de los mensajes es importante

– se considera el tiempo de transmisión completo » desde que una tarea envía el mensaje hasta que otra tarea lo recibe » se incluyen los tiempos de espera en colas, tampones, etc.

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

12

Protocolos de acceso deterministas ‹

CSMA/CD no es adecuado para sistemas de tiempo real – En general no se puede acotar el tiempo de trasmisión de los mensajes – Pero se puede superponer un protocolo de acceso determinista (por ejemplo TDMA) sobre una red IEEE 802.3.

‹

Es mejor usar un protocolo de comunicación determinista Ejemplos: – TDMA (time-division multiple access) – Paso de testigo temporizado – Protocolos de acceso con prioridades

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

13

TDMA ‹

Equivalente del ejecutivo cíclico para sistemas distribuidos – todos los procesadores tienen relojes sincronizados entre sí – el acceso al medio se divide en rodajas de tiempo – cada procesador tiene asignadas rodajas específicas durante las cuales puede enviar mensajes

‹

La planificación del medio es estática – no puede haber colisiones – el tiempo máximo de transmisión está acotado

‹

Este protocolo es predecible y determinista – sin embargo, es poco flexible y difícil de mantener – se puede desaprovechar la red

‹

Se usa en TTA (Time-Triggered Architecture) – para sistemas de alta integridad con planificación cíclica – tolerancia de fallos por redundancia activa

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

14

Paso de testigo temporizado

‹ ‹ ‹

Se usa con redes rápidas, como FDDI El ancho de banda se asigna cíclicamente Cada nodo dispone de un tiempo para enviar mensajes cuando tiene el testigo – el tiempo de envío debe ser suficiente para enviar los mensajes en su plazo – no puede haber colisiones

‹

El tiempo de rotación del testigo está acotado

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

15

Acceso al medio con prioridad ‹

Los mensajes tienen asociada un prioridad

‹

Cuando varios procesadores intentan transmitir, hay un mecanismo que resuelve la contienda a favor del mensaje de mayor prioridad

‹

Hace falta un intervalo de prioridades sufciente

‹

Ejemplo: CAN (controlled area network)

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

16

CAN (ISO 11898) ‹

Bus para conectar dispositivos inteligentes – – – –

‹

originalmente para automóviles medio físico: par retorcido, longitud máxima 40 m velocidad 1 Mbit/s longitud máxima de los mensajes: 64 bits (8 octetos útiles)

El control de acceso al medio se basa en prioridades – cada mensaje tiene un identificador que indica la prioridad del mensaje » » » »

‹

11 bits, 2047 valores de prioridad si dos nodos intentan transmitir a la vez se produce una colisión las colisiones se resuelven dinámicamente por hardware gana el mensaje con prioridad más alta (valor más bajo)

Todos los nodos reciben todos los mensajes – cada uno selecciona los que le interesan

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

17

Estructura de mensajes comienzo

arbitraje longitud

datos

CRC

ACK fin

1

STRL - 03/12/2003

12

6

max 64

16

2

7

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

18

Protocolo de acceso al medio ‹

Se usa el campo de arbitraje del mensaje – identificador + bit de petición remota

‹

Cada vez que se transmite un bit – si trasmite un 0, continúa con el siguiente bit – si transmite un 1 y recibe un 1, continúa con el siguiente bit – si transmite un 1 y recibe un 0, se detiene y no vuelve a empezar hasta que el bus está libre

El bit 0 es dominante y el bit 1 es recesivo – es como un AND ‹ ‹

Cada mensaje tiene un identificador único No hay dos nodos transmitiendo con el mismo identificador

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

19

Ejemplo

Nodo 1

0101101001

0

1

0

0 1

0

Colisión

Nodo 2

0101111010 Bus libre

STRL - 03/12/2003

1 1

0

1

0

1 1

1

0

1

0

1 1

0 1

0

Bus

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

20

Análisis del tiempo de envío Se puede aplicar el análisis de tiempo de respuesta para planificación con prioridades fijas – se planifica el tiempo de uso del bus, no del procesador – pero la planificación se hace sin desalojo » se modela como un bloqueo de duración igual al tiempo de transmisión del mensaje más largo BBUS = 0,13 ms

– se supone que el controlador transmite siempre que hay mensajes pendientes – se supone que no hay errores de transmisión

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

21

Cálculo del tiempo de envío Para mensajes generados por tareas periódicas – – – –

T: C: BBUS: R:

Período Tiempo de transmisión Bloqueo por exclusión mutua Tiempo de envío en el peor caso

R i = Ci + BBUS +

STRL - 03/12/2003

 Ri   ⋅C j  j

∑( )  T

j ∈hp i

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

22

Planificación holística ‹

Se trata de integrar el análisis de tiempo de respuesta de los procesadores y de la red de comunicaciones – las tareas se planifican con prioridades fijas en cada procesador – la red se planifica con prioridades (CAN) o con otro método determinista (TDMA, paso de testigo) – las relaciones de precedencia se modelan con jitter

‹

Consideramos un modelo lineal suceso-respuesta – un suceso da lugar a una respuesta formada por una secuencia de sucesos internos y acciones (tareas o mensajes) – el conjunto constituye una transacción

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

23

Modelo lineal P1 e1

a1

red e12

P2 e23

a2

a3

d12 D12 ED13

‹

Sucesos

‹

– externos(ej. e1) – internos (ej. e12) ‹

Plazos – locales (ej. d12) – globales (ej. D13) – de principio a fin (ej. ED13)

Sucesos periódicos – todos con el mismo período, T1

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

24

Ejemplo e1

R13

a1 J12

e12

a2 J13

e23

r13

a3

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

25

Tiempo de respuesta ‹

El tiempo de respuesta global es Rij =

∑r

k ∈Aij

ik

donde rik es el tiempo de respuesta local de ak relativo a su activación para ei Aij es el conjunto de acciones de la respuesta a ei previas a aj ‹

Los tiempos de respuesta locales se calculan de forma independiente – en general el análisis es pesimista » el peor caso no se da a la vez en todas las acciones

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

26

Tiempos de respuesta locales ‹

Aplicamos la ecuación generalizada:  w ijn (q ) + J ik  w (q ) = (q + 1) ⋅ C j + B j + ∑   ⋅ Ck Tk k ∈hp ( i )   Se termina cuando w ij (q ) ≤ (q + 1)T j n +1 ij

(

rij = max w in (q ) − q ⋅ T j q = 0,1,2,K

‹

)

Para el jitter de activación se toma: J ik ≈ Rik −1

(para la primera acción J es nulo)

– en general dependen unos de otros – inicialmente todos los Jik valen 0 – se va iterando hasta converger STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

27

Ejemplo P1 e1 (T=30)

red e12

a1

a2

e56

a6

a5

P2 e23

a3

e45

a4

e4 (T=40)

Acción

T

C

P

D

a1

30

5

H

30

a2

30

2

L

—

a3

30

20

L

60

a4

40

5

H

—

a5

40

10

H

—

a6

40

10

L

70

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

28

Tiempos de respuesta

STRL - 03/12/2003

Acción

T

C

P

R

D

a1

30

5

H

5

30

a2

30

2

L

17

—

a3

30

20

L

42

60

a4

40

5

H

5

—

a5

40

10

H

15

—

a6

40

10

L

30

70

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

29

Técnicas avanzadas ‹

Asignación de prioridades – recocido simulado

‹

Análisis de tiempo de respuesta – fases dinámicas

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

30

Referencias ‹

Ken Tindell y John Clark “Holistic Schedulability Analysis for Distributed Real-Time Systems” Microprocessing and Microprogramming, 50, 2-3,April 1994

‹

Javier Gutiérrez, Carlos Palencia y Michael González Harbour “Schedulability Analysis of Distributed Hard Real-Time Systems with Multiple-Event Synchronization” Proc. ECRTS’2000

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

31

dit UPM

Sistemas distribuidos Alejandro Alonso Juan Antonio de la Puente DIT/UPM

Objetivos ‹

Comprender los problemas que se plantean en la realización de sistemas de tiempo real estricto distribuidos

‹

Conocer los protocolos y métodos de análisis más adecuados para este tipo de sistemas

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

1

Sistemas distribuidos ‹

Un sistema distribuido está formado por un conjunto de computadores autónomos conectados para conseguir un objetivo común Ventajas: – – – –

‹

rendimiento fiabilidad cercanía a los elementos del entorno físico flexibilidad

Los sistemas de tiempo real distribuidos (STRD) tienen requisitos temporales – como siempre, esto añade complejidad

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

2

Arquitectura de STRD ‹

Conjunto de nodos conectados por redes de comunicación – cada nodo puede ser un multiprocesador conectado por buses

‹

Sólo consideraremos sistemas débilmente acoplados – los nodos no tienen memoria común – comunicación por mensajes

‹

Se suelen estructurar jerárquicamente, para reflejar la diversidad en – la escala de tiempos – la información tratada – los requisitos de cada procesador

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

3

Ejemplo: sistemas de fabricación Procesamiento de información

Centro de Proceso de Datos

Control de planta

Control de planta

Control de área

Control de área Control de Celda Robots

Control de celda

Control de Celda

PLCs

PLCs

Control de máquina

Robots

Los requisitos temporales son tanto más estrictos cuanto menor es el grado de abstracción ©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

4

Ejemplo: sistema de aviónica avión

S

S

A

votación

procesador

Nodo 1

S

A

A

votación

procesador

procesador

votación

Nodo 2

bus ARINC

Sistemas con requisitos de seguridad críticos – redundancia activa (sistema modular triple, bus duplicado, etc.) – requisitos de tiempo real estrictos STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

5

Requisitos temporales y planificación ‹

Tiempo global – relojes – requisitos temporales

‹

Asignación de tareas a procesadores

‹

Planificación – requisitos temporales globales – planificación local y global – planificación de los mensajes

‹

Tolerancia de fallos

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

6

Tiempo global ‹

Los componentes de un sistema distribuido deben tener una visión global del tiempo – referencia de tiempo común » se mantienen los requisitos de monotonicidad y variación acotada » tiempo del sistema o TAI » acceso a reloj global (p.e. GPS) o relojes locales sincronizados

– requisitos de tiempo globales (end-to-end) » requisitos temporales asociados a transacciones (conjunto de actividades que constituyen la respuesta a un suceso)

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

7

Sincronización de relojes ‹

Los relojes locales tienen variaciones que obligan a sincronizarlos – movimiento ρ : 1− ρ ≤

τ (t ′) − τ (t ) t′ −t

≤ 1+ ρ

– relojes de cuarzo: ρ ≈ 2·10-6 (1 s en 6 días) » si la granularidad del tiempo es del orden de 1 ms hay que sincronizar los relojes cada 8 min

– sincronización «suave» » para adelantar ƒ aumentar la frecuencia ƒ incremento acotado del valor del reloj » para retrasar ƒ disminuir la frecuencia ƒ mantener el valor durante un tiempo acotado

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

8

Algoritmos de sincronización de relojes ‹

Sincronización centralizada – un computador actúa como servidor de hora – el servidor radia periódicamente la hora a los demás – problema: si falla el servidor se pierde la sincronización

‹

Sincronización distribuida – buscar un consenso distribuido sobre el valor del tiempo » hay varios algoritmos para esto

– requisitos » diferencia entre dos relojes cualesquiera acotada » diferencia con el tiempo real acotada ‹

Granularidad del algoritmo de sincronización – ∆ : máxima diferencia entre dos relojes cualesquiera

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

9

Requisitos de tiempo globales ‹

Los plazos de respuesta se asocian a las transacciones – actividades que constituyen la respuesta a un suceso Ejemplo: procesador A

DSP

SAD

procesador B

red local

entorno

» La respuesta comienza con la lectura de un dato (en SAD) » Termina cuando se actúa sobre el sistema físico (en el procesador 2) » El tiempo de respuesta dura desde la lectura hasta el final STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

10

Distribución de la carga ‹

Asignación de tareas a procesadores – estática: al diseñar el sistema – dinámica: durante la ejecución Consideraremos, en general que la asignación es estática

‹

Criterios de asignación: – recursos disponibles y requisitos de utilización – distribución geográfica – replicación de tareas

‹

Problema muy complejo (NP-duro) – más fácil con asignación estática » DMS, EDF son óptimos en cada nodo » hay que tener en cuenta el tiempo de transmisión de los mensajes

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

11

Planificación y análisis temporal ‹

Para poder analizar el tiempo de respuesta global de una transacción hay que conocer – los tiempos de cómputo máximos de cada tarea que interviene en la transacción – los tiempos de transmisión máximos de los mensajes

‹

Hace falta que el tiempo de transmisión esté acotado – protocolos de comunicación deterministas – los mensajes tienen atributos temporales (período, plazo) » la planificación de los mensajes es importante

– se considera el tiempo de transmisión completo » desde que una tarea envía el mensaje hasta que otra tarea lo recibe » se incluyen los tiempos de espera en colas, tampones, etc.

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

12

Protocolos de acceso deterministas ‹

CSMA/CD no es adecuado para sistemas de tiempo real – En general no se puede acotar el tiempo de trasmisión de los mensajes – Pero se puede superponer un protocolo de acceso determinista (por ejemplo TDMA) sobre una red IEEE 802.3.

‹

Es mejor usar un protocolo de comunicación determinista Ejemplos: – TDMA (time-division multiple access) – Paso de testigo temporizado – Protocolos de acceso con prioridades

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

13

TDMA ‹

Equivalente del ejecutivo cíclico para sistemas distribuidos – todos los procesadores tienen relojes sincronizados entre sí – el acceso al medio se divide en rodajas de tiempo – cada procesador tiene asignadas rodajas específicas durante las cuales puede enviar mensajes

‹

La planificación del medio es estática – no puede haber colisiones – el tiempo máximo de transmisión está acotado

‹

Este protocolo es predecible y determinista – sin embargo, es poco flexible y difícil de mantener – se puede desaprovechar la red

‹

Se usa en TTA (Time-Triggered Architecture) – para sistemas de alta integridad con planificación cíclica – tolerancia de fallos por redundancia activa

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

14

Paso de testigo temporizado

‹ ‹ ‹

Se usa con redes rápidas, como FDDI El ancho de banda se asigna cíclicamente Cada nodo dispone de un tiempo para enviar mensajes cuando tiene el testigo – el tiempo de envío debe ser suficiente para enviar los mensajes en su plazo – no puede haber colisiones

‹

El tiempo de rotación del testigo está acotado

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

15

Acceso al medio con prioridad ‹

Los mensajes tienen asociada un prioridad

‹

Cuando varios procesadores intentan transmitir, hay un mecanismo que resuelve la contienda a favor del mensaje de mayor prioridad

‹

Hace falta un intervalo de prioridades sufciente

‹

Ejemplo: CAN (controlled area network)

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

16

CAN (ISO 11898) ‹

Bus para conectar dispositivos inteligentes – – – –

‹

originalmente para automóviles medio físico: par retorcido, longitud máxima 40 m velocidad 1 Mbit/s longitud máxima de los mensajes: 64 bits (8 octetos útiles)

El control de acceso al medio se basa en prioridades – cada mensaje tiene un identificador que indica la prioridad del mensaje » » » »

‹

11 bits, 2047 valores de prioridad si dos nodos intentan transmitir a la vez se produce una colisión las colisiones se resuelven dinámicamente por hardware gana el mensaje con prioridad más alta (valor más bajo)

Todos los nodos reciben todos los mensajes – cada uno selecciona los que le interesan

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

17

Estructura de mensajes comienzo

arbitraje longitud

datos

CRC

ACK fin

1

STRL - 03/12/2003

12

6

max 64

16

2

7

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

18

Protocolo de acceso al medio ‹

Se usa el campo de arbitraje del mensaje – identificador + bit de petición remota

‹

Cada vez que se transmite un bit – si trasmite un 0, continúa con el siguiente bit – si transmite un 1 y recibe un 1, continúa con el siguiente bit – si transmite un 1 y recibe un 0, se detiene y no vuelve a empezar hasta que el bus está libre

El bit 0 es dominante y el bit 1 es recesivo – es como un AND ‹ ‹

Cada mensaje tiene un identificador único No hay dos nodos transmitiendo con el mismo identificador

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

19

Ejemplo

Nodo 1

0101101001

0

1

0

0 1

0

Colisión

Nodo 2

0101111010 Bus libre

STRL - 03/12/2003

1 1

0

1

0

1 1

1

0

1

0

1 1

0 1

0

Bus

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

20

Análisis del tiempo de envío Se puede aplicar el análisis de tiempo de respuesta para planificación con prioridades fijas – se planifica el tiempo de uso del bus, no del procesador – pero la planificación se hace sin desalojo » se modela como un bloqueo de duración igual al tiempo de transmisión del mensaje más largo BBUS = 0,13 ms

– se supone que el controlador transmite siempre que hay mensajes pendientes – se supone que no hay errores de transmisión

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

21

Cálculo del tiempo de envío Para mensajes generados por tareas periódicas – – – –

T: C: BBUS: R:

Período Tiempo de transmisión Bloqueo por exclusión mutua Tiempo de envío en el peor caso

R i = Ci + BBUS +

STRL - 03/12/2003

 Ri   ⋅C j  j

∑( )  T

j ∈hp i

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

22

Planificación holística ‹

Se trata de integrar el análisis de tiempo de respuesta de los procesadores y de la red de comunicaciones – las tareas se planifican con prioridades fijas en cada procesador – la red se planifica con prioridades (CAN) o con otro método determinista (TDMA, paso de testigo) – las relaciones de precedencia se modelan con jitter

‹

Consideramos un modelo lineal suceso-respuesta – un suceso da lugar a una respuesta formada por una secuencia de sucesos internos y acciones (tareas o mensajes) – el conjunto constituye una transacción

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

23

Modelo lineal P1 e1

a1

red e12

P2 e23

a2

a3

d12 D12 ED13

‹

Sucesos

‹

– externos(ej. e1) – internos (ej. e12) ‹

Plazos – locales (ej. d12) – globales (ej. D13) – de principio a fin (ej. ED13)

Sucesos periódicos – todos con el mismo período, T1

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

24

Ejemplo e1

R13

a1 J12

e12

a2 J13

e23

r13

a3

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

25

Tiempo de respuesta ‹

El tiempo de respuesta global es Rij =

∑r

k ∈Aij

ik

donde rik es el tiempo de respuesta local de ak relativo a su activación para ei Aij es el conjunto de acciones de la respuesta a ei previas a aj ‹

Los tiempos de respuesta locales se calculan de forma independiente – en general el análisis es pesimista » el peor caso no se da a la vez en todas las acciones

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

26

Tiempos de respuesta locales ‹

Aplicamos la ecuación generalizada:  w ijn (q ) + J ik  w (q ) = (q + 1) ⋅ C j + B j + ∑   ⋅ Ck Tk k ∈hp ( i )   Se termina cuando w ij (q ) ≤ (q + 1)T j n +1 ij

(

rij = max w in (q ) − q ⋅ T j q = 0,1,2,K

‹

)

Para el jitter de activación se toma: J ik ≈ Rik −1

(para la primera acción J es nulo)

– en general dependen unos de otros – inicialmente todos los Jik valen 0 – se va iterando hasta converger STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

27

Ejemplo P1 e1 (T=30)

red e12

a1

a2

e56

a6

a5

P2 e23

a3

e45

a4

e4 (T=40)

Acción

T

C

P

D

a1

30

5

H

30

a2

30

2

L

—

a3

30

20

L

60

a4

40

5

H

—

a5

40

10

H

—

a6

40

10

L

70

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

STRL - 03/12/2003

28

Tiempos de respuesta

STRL - 03/12/2003

Acción

T

C

P

R

D

a1

30

5

H

5

30

a2

30

2

L

17

—

a3

30

20

L

42

60

a4

40

5

H

5

—

a5

40

10

H

15

—

a6

40

10

L

30

70

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

29

Técnicas avanzadas ‹

Asignación de prioridades – recocido simulado

‹

Análisis de tiempo de respuesta – fases dinámicas

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

30

Referencias ‹

Ken Tindell y John Clark “Holistic Schedulability Analysis for Distributed Real-Time Systems” Microprocessing and Microprogramming, 50, 2-3,April 1994

‹

Javier Gutiérrez, Carlos Palencia y Michael González Harbour “Schedulability Analysis of Distributed Hard Real-Time Systems with Multiple-Event Synchronization” Proc. ECRTS’2000

STRL - 03/12/2003

©1998-2003 Alejandro Alonso y Juan Antonio de la Puente

31

dit UPM

Programación de bajo nivel Juan Antonio de la Puente DIT/UPM

Transparencias basadas en el capítulo 15 del libro de A. Burns y A. Wellings Real-Time Systems and Programming Languages, 3ª edición (2001)

Objetivos ‹ ‹ ‹ ‹

Los sistemas de tiempo real suelen tener dispositivos de entrada y salida especiales Los manejadores de dispositivos forman parte del software de aplicación Veremos cómo controlar los dispositivos de hardware en un lenguaje de alto nivel Veremos también cómo incluir los manejadores de dispositivos en el modelo de tareas de tempo real

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

1

Índice ‹ ‹

Mecanismos de hardware para entrada y salida y manejadores de dispositivos Mecanismos de bajo nivel en Ada – – – –

‹ ‹

cláusulas de representación manejo de interrupciones ejemplo código de máquina

Programación de dispositivos en C Planificación con manejadores de dispositivos

©2001-2002 Juan Antonio de la Puente

STRL - 20/11/2002

2

Arquitecturas de entrada-salida

datos memoria

datos CPU

dispositivo

direcciones

dispositivo

Bus de E/S separado del de memoria

direcciones datos CPU

memoria

dispositivo

direcciones

STRL - 20/11/2002

dispositivo

Bus único para E/S y memoria (memory mapped)

©2001-2002 Juan Antonio de la Puente

3

Interfaz con los dispositivos de entrada y salida ‹

‹

‹

Los dispositivos de entrada-salida se conectan a los otros elementos del computador mediante controladores que presentan una interfaz homogénea El procesador intercambia datos e información de control y estado con los controladores mediante registros de hardware La forma concreta de hacerlo depende de la arquitectura de entrada y salida

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

4

Entrada y salida en lenguaje de máquina Bus de E/S separado ‹ Registros en espacio de direcciones de E/S (direcciones de puerto) ‹ Se leen y escriben mediante instrucciones de E/S específicas

Bus de memoria Registros en el espacio de direcciones de memoria

‹

‹

in r, port out r, port ‹

mov r, address mov address, r

Ejemplo: Intel 486 & Pentium

STRL - 20/11/2002

Se leen y escriben mediante instrucciones de transferencia de datos

‹

Ejemplo: M 68000, PowerPC

©2001-2002 Juan Antonio de la Puente

5

Sincronización Por consulta (status driven) ‹ El procesador interroga al controlador para comprobar el estado del dispositivo. Operaciones – test – control – E/S ‹ ‹

Complicado e ineficiente A veces es la única opción (en sistemas muy críticos es posible que no se permita usar interrupciones)

Por interrupción (interrupt driven) ‹ El controlador presenta una interrupción en determinadas circunstancias ‹ Un manejador de interrupción se encarga de tomar la acción adecuada ‹ Varios tipos – controlado por programa – acceso directo a memoria – controlado por canal ‹

Puede ser difícil estimar el tiempo de computo – robo de ciclos al procesador

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

6

Mecanismos de interrupción (1) ‹

Cambio de contexto – se guarda el estado del procesador antes de la interrupción – se carga el estado del manejador de interrupción – cuando se completa el manejador, se restaura el estado anterior

Soporte de hardware – básico: sólo se guarda el contador de programa (PC) – parcial: PC y PSW (registro de estado) – completo: todo el contexto – Puede hacer falta hacer una parte en software

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

7

Mecanismos de interrupción (2) ‹

Identificación del dispositivo que interrumpe – por vector de interrupción: array asociado al hardware de interrupción que contiene direcciones de memoria con manejadores de interrupción y otros datos (p.e. palabra de estado) – por estado: cada interrupción tiene una palabra de estado asociada que indica cuál es el origen de la misma – por consulta: un manejador general consulta a los dispositivos para averiguar cuál ha interrumpido

‹

Identificación de la causa de la interrupción – consultando el estado del dispositivo – con diferentes interrupciones para el mismo dispositivo

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

8

Mecanismos de interrupción (3) ‹

Control de interrupciones Las interrupciones de un dispositivo pueden estar permitidas (enabled) o inhibidas (disabled) – mediante indicadores (flags) en registros de estado – mediante una máscara (mask), con un bit por dispositivo – mediante un nivel de prioridad de hardware » cada dispositivo tiene un nivel asociado » si el nivel del procesador es mayor o igual que el de un dispositivo, no se aceptan interrupciones de éste

‹

Control de prioridad – – – –

a veces se asocia una prioridad a cada fuente de interrupciones la prioridad indica la urgencia relativa de la interrupción puede ser estática o dinámica normalmente está relacionada con los niveles de prioridad del procesador

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

9

Ejemplo de sistema de entrada y salida ‹ ‹

Suponemos una arquitectura con E/S por bus de memoria, con interrupciones (como la M68000) Cada dispositivo tiene dos tipos de registros – Registros de control y estado (CSR), que contienen información sobre el dispositivo y el control de interrupciones – Registros de datos (DBR), que contienen los datos que se transmiten al dispositivo o desde él

‹ ‹

Un mismo dispositivo puede tener varios CSR o DBR Cuando se produce una interrupción, se guarda el estado (PC y PSW) en la pila, y se carga el nuevo estado del vector de interrupción correspondiente – Las interrupciones y el procesador tienen asociada una prioridad – Una interrupción puede desalojar a un manejador con prioridad más baja

©2001-2002 Juan Antonio de la Puente

STRL - 20/11/2002

10

Estructura de los registros

15

CSR

14

13

12

errors B R I E 15

B

9

8

unit

7

6

5

4

R

I

reserved function E

14

13

12

11

10

9

8

7

6

5

3

4

unused 15

STRL - 20/11/2002

10

2

1

0

device busy device ready / done interrupt enable device enable

DBR

PSW

11

14

13

mode

12

11

3

2

1

0

2

1

0

data 10

9

unused

8

7

6

5

priority

4

3

condition codes

©2001-2002 Juan Antonio de la Puente

11

Manejadores de dispositivos Para realizar manejadores de dispositivos hace falta: – Un modelo abstracto de la gestión de dispositivos » procesos sincronizados por interrupciones

– Manipular registros de hardware y direcciones » un registro se puede representar como una variable, un objeto o un canal de comunicación

– Enlazar interrupciones con código. Algunas posibilidades son: » » » » »

llamada a procedimiento activación de proceso esporádico suceso asíncrono sincronización con variable de condición mensaje

Todos estos métodos (excepto la llamada a procedimiento) requieren un cambio de contexto STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

12

Manejadores de dispositivos en Ada ‹

Modelo abstracto de dispositivos: tareas en hardware

‹

Las tareas que usan el dispositivo se tienen que comunicar y sincronizar con las tareas de hardware – acceso a registros de hardware – sincronización con interrupciones

‹

Manejador: subsistema que controla el acceso al dispositivo – objeto protegido: abstracción de comunicación y sincronización – registros como variables en memoria – interrupciones asociadas a procedimientos protegidos

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

13

Esquema general software

manejador

hardware

interrupción

tarea cliente

registros

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

14

Mecanismos de bajo nivel en Ada Ada 95 tiene varios mecanismos de bajo nivel que permiten acceder a registros, direcciones e interrupciones – cláusulas de representación » permiten especificar la representación de tipos y objetos en la arquitectura de hardware ‹ representación de atributos (tamaño, dirección, alineación) ‹ representación de tipos enumerados ‹ representación de registros

– manejadores de interrupciones » permiten asociar una interrupción a un procedimiento protegido

– subprogramas en lenguaje de máquina » permiten un control total sobre la arquitectura de hardware

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

15

Cláusulas de representación de atributos ‹

Tamaño type Data_Register is mod 2**8; for Data_Register'Size use 16; -- los objetos de tipo Data_Register ocupan 16 bits

‹

Dirección Data_Buffer : Data_Register; for Data_Buffer'Address use System.Storage_Elements.To_Address(8#177560#); -- Data_Buffer se ubica en la dirección 177560 octal

‹

Alineación for Data_Register'Alignment use 2; -- los objetos de tipo Data_Register se tienen que ubicar -- en direcciones múltiplo de 2

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

16

Otras cláusulas de representación

‹

Codificación interna de los valores de un tipo enumerado type Flag is (On, Off); for Flag use (On => 1, Off => 0); -- representación numérica de los valores del tipo Flag

‹

Orden de bits en los objetos de un tipo de datos type Register is mod 256; for Register'Bit_Order use Low_Order_First; -- el bit 0 es el menos significativo

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

17

Cláusulas de representación de registros ‹

Orden, posición y tamaño de los componentes de un tipo registro type Control_Register is record Enable : Flag; Done : Flag; Busy : Flag; Error : Error_Type; end record; for Control_Register use record Enable at 0 range 0 .. 0; Done at 0 range 7 .. 7; Busy at 0 range 11 .. 11; Error at 0 range 12 .. 15; end record;

STRL - 20/11/2002

©2001-2002 Juan Antonio de la Puente

18

System (1) package System is ... -- storage-related declarations type Address is implementation-defined; Null_Address : constant Address; Storage_Unit : constant := implementation-defined; Word_Size : constant := implementation-defined * Storage_Unit; Memory_Size : constant := implementation-defined; -- address comparison function "