TEMA 2jossan/doct/cystr/fich/Tema2_x6.pdf · 2013-03-11 · 1 1 TEMA 2 Programación de...
Transcript of TEMA 2jossan/doct/cystr/fich/Tema2_x6.pdf · 2013-03-11 · 1 1 TEMA 2 Programación de...
1
1
TEMA 2
Programación de aplicaciones en tiempo real
2
Programación de aplicaciones en T.R.
Lenguajes para aplicaciones en tiempo realProgramación a pequeña escalaProgramación a gran escalaProgramación concurrenteSistemas operativos
3
Lenguajes para aplicaciones en tiempo real
4
Proyecto.
Conjunto de tareas y actividades, limitadas en el tiempo, encaminadas a alcanzar un objetivo bien definido, en un plazo determinado y con unos recursosdados (humanos, materiales, presupuestarios, etc.).Etapas en la gestión de proyectos:
Iniciación del proyecto: objetivos y plazo de ejecución.Calificación del proyecto: evaluación global
Estimación de cargas y costeEstimación de riesgosAceptación o rechazo de emprender el proyecto
Desarrollo del proyecto: realización y control del desarrolloPlanificación y descomposición en etapas y tareasLanzamiento del proyecto: ejecución y desarrolloSeguimiento y control del proyecto.Cierre de etapas
Cierre del proyecto.
5
Proyectos informáticos.
La aplicación de los métodos de ingeniería a los proyectos informáticos ha dado lugar a un conjunto de técnicas conocidas como Ingeniería del Software:
Aplicación práctica del conocimiento científico al diseño y construcción de programas, y la documentación necesaria para el desarrollo, operación y mantenimiento de los mismos.
Etapas en la gestión de proyectos informáticos:Definición: especificaciones y requisitos.Diseño: preliminar, detallado y técnico. Desarrollo: codificaciones y pruebas.Integración: implantación, operación y mantenimiento.
6
ANÁLISIS
CODIFICACIÓNEL CICLO DE VIDA
MODELOS DE CICLO DE VIDA:
CASCADA TRANSFORMACIONESPROTOTIPOS EN ESPIRALVERSIONES SUCESIVAS
2
7
REQUISITOS
DEFINICIÓNSOFTWARE
ANALISIS
DISEÑO
PROGRAMAS
CODIFICACION
PRUEBAS
IMPLANTACIÓN
ESPECIFICACIÓN
DISEÑO
DESARROLLO
INTEGRACIÓN
OPERACIÓN
SISTEMA
8
DISEÑO DE DATOS
DISEÑO ARQUITECTÓNICO
DISEÑO DE PROCEDIMIENTOS
DISEÑO DE INTERFACES
DISEÑO PRELIMINAR
DISEÑO DETALLADODISEÑO DE GESTIÓN
DISEÑO TÉCNICO
9
Coste totaldel sw
nº de módulos
Cos
te o
esf
uerz
o
Coste de lasinterfaces
Región de coste mínimo
Coste por módulo
10
Lenguajes para aplicaciones T.R.
La elección de un lenguaje tiene implicaciones en la seguridad, fiabilidad y coste del sistema final.
Requisitos de un buen lenguaje para desarrollo de aplicaciones en tiempo realCaracterísticas que ayudan a la construcción de software seguro y fiable.Técnicas de programación modular.Facilidades para soportar concurrencia.
11
Lenguajes para aplicaciones T.R.
Los sistemas de tiempo real frecuentemente son sistemas grandes y complejos, lo cual implica que su desarrollo y mantenimiento sea costoso. Además, estos sistemas tienen que responder a eventos externos garantizando un mínimo de tiempo de respuesta, utilizando un amplio rango de dispositivos de interfaz, incluyendo dispositivos que no son estándar. En muchas aplicaciones, la eficiencia en la utilización del hardware del computador es vital para conseguir la velocidad de operación necesaria.
12
Lenguajes para aplicaciones T.R.
Para conseguir una utilización más eficiente de la CPU y acceso a los dispositivos de interfaz e interrupciones, los primeros sistemas de tiempo real fueron programados utilizando lenguajes a nivel de ensamblador. Estos aún se sigue utilizando, sobre todo para sistemas pequeños con requisitos de velocidad de cálculo altos.
Pero la programación en ensamblador no es nada atractiva, de forma que la insatisfacción con los lenguajes ensambladores supuso el desarrollo de lenguajes de alto nivel. De esta forma, se desarrollaron lenguajes como FORTRAN, RTL, PASCAL, MODULA o C. Pero la limitación de todos ellos es que, esencialmente, estaban diseñados para producir programas secuenciales.
3
13
Lenguajes para aplicaciones T.R.
Existen especificaciones relativas a los STR que deben ser cumplidas por estos lenguajes.
Técnicas para que la aplicación sea separada en módulos.Facilidades relacionadas con el soporte de la concurrencia.
El ciclo de vida en el desarrollo de una aplicación tiene las siguientes etapas:
Análisis.Diseño e implantación.Mantenimiento.
14
Lenguajes para aplicaciones T.R.
Hay que detectar los errores en las primeras etapas de desarrollo. Participan muchas personas en su desarrollo por lo que resulta interesante la separación de la aplicación en módulos que serán desarrollados por equipos, teniendo en cuenta su relación e interacción con otros módulos.
En los STR vamos a tener varias tareas y tenemos que que representar la concurrencia de estas tareas. Para ello necesitamos soporte para la construcción de módulos, para la construcción y manejo de tareas, interrupciones, gestión de excepciones,…
15
Lenguajes. Elementos básicos
Variables y constantes.Tipos de datos.Estructuras de control.Reglas de ámbito y visibilidad.Métodos de modularidad y compilación.Gestión de excepciones.
16
Lenguajes. Soporte de concurrencia
Construcción de módulosCreación y gestión de tareasGestión de interrupciones y dispositivosComunicación entre tareasExclusión mútua.Gestión de excepciones.
17
Lenguajes. Características deseables
SeguridadLegibilidadFlexibilidadSimplicidadPortabilidadEficiencia
18
La seguridad de un lenguaje se mide en términos de la efectividad en la detección automática de errores. Hay una serie de características del lenguaje que ayudan a detectar los errores :
soporte de modularidad (compilación y verificación independiente)
declaración forzada de variables
un rango de tipos de datos adecuado, incluyendo tipos sub-rango
tipado de variables
sintaxis no ambigua.
Los errores pueden ser lógicos o de sintaxis. Los segundos pueden ser detectados por el compilador.
Seguridad
4
19
No es posible probar exhaustivamente el software, por lo que la seguridad intrínseca del lenguaje es básica para el desarrollo de programas fiables.
Desarrollo cruzado: el desarrollo (edición, compilación y depuración) se realiza en un computador diferente al de ejecución
Económicamente es importante detectar errores en la etapa de compilación en vez de en tiempo de ejecución.
Las comprobaciones realizadas en tiempo de compilación no generan sobrecargas en tiempo de ejecución. (El programa se va a ejecutar muchas más veces de lo que se ha compilado).
Seguridad
20
Es la medida de la facilidad con que se puede entender la operación de un programa sin comentarios adicionales y sin tener que recurrir a documentación externa, como diagramas o descripciones en el lenguaje natural.
La idea es que los programas se van a escribir una vez pero se van a leer muchas veces para que se puedan adaptar a las necesidades.
Legibilidad
21
Las ventajas que se obtienen haciendo programas fácilmente entendibles son:
Reducción de los costes de documentación. Mucha de la documentación está dada por el propio código. Se ha de tener en cuenta que, además, las personas que van a realizar el mantenimiento de la aplicación no suelen ser los mismos que la desarrollaron.
Una detección de errores más fácil.
Un mantenimiento más fácil.
Legibilidad
22
Para conseguir un programa entendible es necesario la colaboración del programador, ya que es posible escribir programas ilegibles en cualquier lenguaje.
El problema de la legibilidad es que cada programador tiene su forma de escribir programas. Por lo tanto se necesita que el lenguaje sea muy estricto y que exista una planificación que ponga énfasis en la estructura y en la elección de los nombre de variables.
Otro inconveniente de la legibilidad es que el código fuente se hace grande, y cuesta más tiempo escribirlo, pero es un pequeño coste que hay que pagar por la seguridad y el mantenimiento del software.
Legibilidad
23
Un lenguaje debe proporcionar todas las características necesarias para expresar todas las operaciones que se requieran sin tener que utilizar complicadas construcciones o recurrir a código ensamblador. La flexibilidad es una medida de esta capacidad.
Para sistemas de tiempo real es particularmente importante ya que es normal tener que controlar dispositivos de entrada/salida no estándar.
La flexibilidad y la seguridad suelen entrar en conflicto. En los lenguajes modernos este compromiso se consigue proporcionando alta flexibilidad y, por medio del concepto de módulo o paquete, se proporciona un medio por el cual las operaciones a bajo nivel (es decir, la no seguras) se pueden ocultar en un número limitado de secciones autocontenidas del programa.
Flexibilidad
24
Al igual que en otras áreas, lo simple es preferido a lo complejo. La simplicidad contribuye a la seguridad. Cuanto más simple es un lenguaje, más fácil es entender cada una de las instrucciones del programa, menor es el coste de aprendizaje y más difícil es cometer errores, por lo que se incrementa la seguridad. Además reduce el coste y los errores de programación, así como el tamaño del compilador, el cual proporciona un código objeto más eficiente.
La simplicidad no tiene que llevar a inconsistencias que reduzcan la seguridad. Un buen lenguaje no debe imponer restricciones arbitrarias en la utilización de ninguna de sus características
Simplicidad
5
25
La portabilidad es difícil de conseguir en la práctica, aunque es deseable como un medio de acelerar el desarrollo de aplicaciones, reduciendo el coste y aumentando la seguridad. Consiste en que una aplicación se pueda trasladar de una máquina a otra sin o con mínimos cambios. No solamente ha de ser portable en código fuente sino que hay que tener en cuenta las características de hardware de la máquina.
Portabilidad
26
En forma de código fuente es posible transferir un programa de un computador a otro, compilando y ejecutándolo en el computador al cual ha sido transferido. Pero aún así hay problemas, por ejemplo, la longitud de palabra de la dos máquinas pueden ser diferentes y pueden dar problemas con el rango y la precisión con la que son representados los números. Otro problema es el direccionamiento de información (convenios little endian y big endian).
Portabilidad
27
En los sistemas de tiempo real la portabilidad es aún más difícil de conseguir, ya que con frecuencia hay que utilizar características específicas del hardware del computador y del sistema operativo.
En los STR, generalmente las aplicaciones no son portables. Una solución utilizada en la práctica es aceptar que un sistema de tiempo real no es directamente portable y restringir las partes no portablesa unos módulos. Las aplicaciones se desarrollan pensando que se van a ejecutar en una máquina virtualy se desarrollan las partes de aplicación dependientes del hardware en forma de módulos dependientes del hardware, que se añaden enlazándolos a la aplicación.
Portabilidad
28
Define las prestaciones de un STR. En sistemas de tiempo real, que deben garantizar un cierto funcionamiento junto con unas restricciones temporales, la eficiencia es importante. En los primeros computadores para sistemas de control, el mayor énfasis se hizo en la eficiencia del código, tanto en términos de tamaño del código objeto, como en la velocidad de operación. Pero al bajar el costo del hardware y aumentar la velocidad de cálculo, los criterios de eficiencia han cambiado.
Eficiencia
29
En muchas aplicaciones de tiempo real el concepto de lenguaje eficiente ha cambiado para incluir consideraciones de la seguridad y coste de escritura y mantenimiento del programa, quedando como de segunda importancia en muchas aplicaciones la velocidad y compactación del código. Aunque hay aún áreas de aplicaciones donde sigue siendo primordial la velocidad y compactación, por ejemplo en el control de sistemas electromecánicos, control aeronáutico y en general en el campo de procesamiento de señales, en las que todavía es importante el desarrollo en ensamblador de ciertas partes muy relacionadas con el hardware.
Eficiencia
30
EnsambladorLenguajes de alto nivelMontadorCargadorPuesta a punto
Herramientas de desarrollo
6
31
ENSAMBLADOR
Es un programa que acepta código fuente y produce código máquina.
Relación 1:1 Instrucción fuente - instrucción microCampos en el código fuente ensamblador
Etiqueta: Referencia simbólica de una posición en memoriaCódigo de operación
Mnemónico de una instrucciónDirectiva del ensamblador (p.e. ORG)
OperandosNombre de registrosConstantes numérica o simbólicasEtiquetasExpresiones agebraicas
Comentarios32
ENSAMBLADOR
Ensambladores absolutosEl fichero fuente con directiva de localizaciónProduce código ejecutable que se puede cargar en el procesador de destinoPb: fichero fuente con todo el código o bien cálculo de ocupaciones y direcciones
Ensambladores relocalizablesFicheros fuente sin directivas de localizaciónLa salida no es código ejecutable → fichero objetoNecesidad de un montador de enlaces
33
LENGUAJES DE ALTO NIVEL
Lenguajes de alto nivelDesarrollo más rápido (↑ abstracción)
Codificación más rápida y seguraPuesta a punto de la lógica del programa más sencilla=> disminución de costes
↓ eficiencia↑ ocupación en memoriaReescritura de algunas partes críticas en ensamblador
Disminución de la ocupación de memoriaAumento de las prestaciones
34
LENGUAJES DE ALTO NIVEL
Requisitos de un lenguaje para la programación de μC
Acceso directo a memoria y hardware para lectura y escritura
Programación de periféricos
Posibilidad de llamar a rutinas en ensamblador o insertar código máquinaConexión directa con interrupciones
La mayoría de la aplicaciones basarán gran parte de su funcionamiento en interrupcionesPrestaciones, carácter asíncrono de los eventos
Generación de código eficiente en ocupación de memoria y velocidad de ejecución
Se dispone de poca memoria
35
LENGUAJES DE ALTO NIVEL
Ada95Incluye concurrencia, tiempo real, acceso a recursos de bajo nivel y un potente tratamiento de las excepcionesTransportabilidad, Legibilidad, Eficiencia, Seguridad (chequeos del compilador)Genera código excesivamente extensoEn el futuro se dispondrá de compiladores que contemplen un perfil mínimo del lenguaje
CANSI C -> estándarAlto nivel que retiene el contacto con el hardware ( ↓abstracción, facilidad programación periféricos)Generación de código muy optimizableExtensiones para cumplir todos los requisitos Concurrencia => kernel
Actualmente la industria emplea mayoritariamente el C para el desarrollo de sistemas empotrados
36
LENGUAJES DE ALTO NIVEL, EL C
Sistema empotrado ≠ computador con SO + E/S estándar
No funciones de E/SNo printfNo ficheros ...
Código y datos en posiciones concretas de memoriaROM, RAM, EEPROM,...No código ejecutable relocalizable (<= no SO)
Directivas de posicionamiento + Linker
Programación de periféricosAcceso a registros físicosServicio de interrupciones
7
37
LENGUAJES DE ALTO NIVEL, EL C
Acceso al bajo nivelEnlace con ensambladorP.e. CLIManejo de bits
Ejecución sobre máquina desnudaSe viste la máquina mediante ficheros de cabeceraFunciones específicas de acceso al hardware
DirectivasExpansión en línea (inline)Intercalado de instrucciones en ensambladorRutinas de servicio de interrupciónPosicionamiento absoluto
38
EL MONTADOR
Sólo necesario cuando el compilador genera código relocalizableFunciones
Establecer las referencia cruzadas entre módulosEnlazar con libreríasAsignar valor absoluto a símbolos, etiquetasEstablecer las direcciones de cargaValor inicial del puntero de pila
Cargador
Microcontrolador
Objeto Relocalizable
Fichero Configuración
Librerías
Fuente C
Ejecutable No Relocalizable
Máscara
Ensamblador Cruzado
Compilador Cruzado
Montador de Enlaces
Objeto Relocalizable
Fuente Ensamblador
39
EL CARGADOR
Carga del programa ejecutable en la memoria del microcontrolador
Sistema operativoCarga por línea serie, ethernet, ...
PosibilidadesMonitorHardware
Memoria RAMMemoria EPROM/EEPROM
Existen micros que se autograban
Grabador de la memoria PROMMáscara
40
PUESTA A PUNTO
DebuggersDos posibles niveles
Código fuenteCódigo máquina
Paso a pasoVisualizado de los efectos de la ejecución
BreakpointsDetención de la ejecución del programa -> control al debuggerLa instrucción donde debe detenerse el programa es cambiada por un interrupción software
Visualizado y alteración de registros y memoriaUn fichero de listado es imprescindible
Código fuente + ensamblador generado + Tabla de
41
PUESTA A PUNTO
Posibilidades clasificadas por potencia:Simuladores
La memoria y registros pueden ser observados y alteradosNo interrupciones, ni hardware adicional. No tiempo real
Debuggers residentesPrograma de aplicación y monitor conviven en el μC
No ejecución simultáneaVisualización y actualización de memoria, breakpoints, …
EmuladoresHardware que “emula” al μC y además permite obtener información y actuar sobre la aplicación sin gastar recursos del μC ni alterar la evolución temporalAnalizadores lógicos
42
Programación a pequeña escala
8
43
Entre las características de los lenguajes de alto nivel podemos distinguir aquellas que ayudan al proceso de descomposición y aquellas que facilitanla programación de componentes bien definidos. Estas dos conjuntos se describen como:
•Soporte para la programación a gran escala.
•Soporte para la programación a pequeñaescala.
44
Cuestiones a tener en cuenta cuando se escribenprogramas:
Recuerda que tu código puede ser analizado porotras personas (al menos un 40% de las líneas de un programa deben ser comentarios)
Usa nombres de variables con significado.
Los comentarios incrementan la comprensión de un programa.
Programación a pequeña escala
45
Puntos básicos
Sintaxis y legibilidadDeclaración e inicialiación de variables y constantesModularidad y variablesCompilación y programas modularesTipos de datosEstructuras de control del flujo de ejecución
46
Sintaxis y legibilidad
BEGINNST = TICKS ( ) + ST;T = TICKS ( ) + ST;LOOPWHILE TICKS ( ) < NST DO (*NADA*) END;T := TICKS ( );CC;NST : = T + ST;IF KEYPRESSED ( ) THEN EXIT;END;END;END;
47
Sintaxis y legibilidad
BEGINNextSampleTime = TICKS ( ) + SampleTime;Time = TICKS ( ) + SampleTime;LOOP
WHILE TICKS ( ) < NextSampleTime DO(*NADA*)
END;Time := TICKS ( );ControlCalculations;NextSampleTime : = Time + SampleTime;IF KEYPRESSED ( ) THEN
EXIT;END;
END;END; 48
Declaración e inicialización
Declaración de entidades:Necesidades de almacenamientoNombres explícitos
100 ERROR=0.....
200 IF X=Y THEN GOTO 300250 EROR = 1300 ...
...400 IF ERROR=0 GOTO 1000
...
9
49
Ejemplo de Fortran (mala convención léxica)
DO 20 I = 1, 100Bucle iterando I desde 1 hasta 100
En la sonda Viking Venus, un programador escríbió
DO 20 I = 1. 100
El compilador interpretó esto como una sentencia de asignación pues, ignorando los espacios, se tiene:
DO20I = 1.100
En Fortran, las variables no necesitan declararse, y aquellas que empiezan porD se asumen como de tipo realy y 1.100 es, literalmente, un número real.
50
Declaración e inicialización
Inicialización de entidades:Dar un valor inicial cuando es declaradaNo deja al compilador tomar la decisión.
ConstantesValores de entidades físicas o matemáticas deben permanecer fijos en la ejecución del programa.Inicializar una variable no es seguro. Puede modificarse sin querer en otro punto del probrama.const en C
51
Ambito y visibilidad
El ámbito de una variable se define como la región de un programa en la que la variable es potenciable accesible o modificable.La región donde es realmente accesible o modificable define la visibilidad.
52
Asignación dinámica de memoria
Problemas:las variables declaradas en un procedimiento no pueden usarse para mantener valores en la siguiente entrada al procedimiento”.
En C existen las variables static.Si un procedimiento se llama recursivamente es posible que el programa pueda fallar debido a que no haya memoria disponible.
Crecimiento incontrolado de la pilamalloc() y free()
53
Variables globales y locales
Existen argumentos a favor y en contra de ambas.Variables locales: es una buena práctica declarar entidades cerca de donde van a ser usadas, y se limita el ámbito y la visibilidad de la entidad.Variables globales: es la única forma de garantizar la consistencia y el control del nombre de entidades en sistemas grandes que son desarrollados por equipos de programadores.Compromiso: declarar como globales a las entidades que están directamente relacionadas con el mundo exterior, y locales al resto.
54
Tipos de datos
La asignación de un tipo a una entidad define:El conjunto de valores que puede tomar la entidad.El conjunto de operaciones que se puede realizar con la entidad.
La riqueza de tipos y la rigurosidad con que se impone la compatibilidad de tipos en un lenguaje tienen una gran influencia en la seguridad.Fuertemente tipados: imponen rigurosamente la compatibilidad de tipos.Débilmente tipados: no imponen compatibilidad de tipos.
10
55
Tipificación de Datos
Un lenguaje con tipificación de datos requiere que cada variable y/o constante sea de un tipo específico (entero, real, carácter, etc.) declarado antes de usar la variable.
Diferentes niveles de comprobación de tipos:Sin tipos (Ej: BASIC)Conversión automática de tipos (Ej: C)Comprobación de tipos fuerte (Ej: ADA)
Dentro de los lenguajes con tipificación de datos, puede realizarse:
comprobación estática de tipos (en tiempo de compilación)comprobación dinámica de tipos (en tiempo de ejecución)
56
Conversión de Tipos en el Lenguaje C
Conversión Automática de Tipos: Cuando un operador tiene operandos de tipos diferentes, éstos se convierten a un tipo común “razonable”:
Las reglas se complican al considerar enteros y charscon y sin signo (resultado depende muchas veces de la máquina).
char
shortint float double long double
57
Conversión de Tipos en el Lenguaje C
Ejemplos de conversión automática:Operaciones
int i,j; double k;i = j + k;k = i + j;
Llamada a funcionesfunción definida como: double sqrt(double)invocación: k = sqrt(i);
Casting: Conversión Explícita de Tipos (es bueno explicitarla siempre!)
58
El lenguaje C
Es secuencialLa principal unidad de estructuración son lasfunciones (aunque los ficheros pueden usarse paraayudar a la compilación separada)Estructurado en bloques (llamados declaracionescompuestas){
< parte declarativa >
< secuencia de sentencias >}
La parte declarativa no puede contener funcionesLa secuencia de sentencias puede contenerdeclaraciones compuestas
59
Ejemplo en C
int mayor(vector X, int len)
{
int max = 0;
int i;
for (i = 0; i < len; i++) {
if(X[i] > max) max = X[i];
}
return max;
}
Asignación es =
Igualdad es = =
60
Tipos Discretos
Ada Java C
Integer int int
short short
long long
byte
Boolean boolean
Character char
Wide_Character char wchar_t
Enumeration types None typedef enum
11
61
Tipos Discretos
• Ada y Java son fuertemente tipados, y soportan la conversión explícita de tipos; sin embargo, C no es tán seguroen cuanto a tipos, por ejemplo:
int a; float b;a = b;
•C y Ada permiten duplicación de tipos o la definición de nuevos tipos basada en tipos básicos.
62
Tipos Discretos
/* en C */Typedef int newint;Typedef enum {xplane, yplane, xzplane} dimension
/* en Ada */Type Dimension is (Xplane, Yplane);Type map is (Xplane, Yplane)Line, Force : Dimension,Grid : Map;
63
Tipos de datos estructurados
Java soporta arrays,
Ada y C soportan arrays y registros (estructuras)
--AdaMax: Const Integer:=10;Type Reading_T is array(0..Max-1) of Float;Size: Const Integer:=Max-1;Type Switches_T is array(0..Size, 0..Size) of Boolean;Reading: Reading_T;Switches: Switches_T;
64
Estructuras de Control
Estructuras secuencialesEn Java, C, y Ada una secuencia se indica con {}En Ada es necesario establecer explícitamente unasecuencia vacía:
begin –Adanull;
end;Esto no es necesario en C y Java
65
Estructuras de Control
Estructuras de decisión :If, if then else
BuclesIteraciónRecursión
For--Ada /* C y Java*/for I in 0..9 loop for (i=0;i<=9;i++){
A(I):=I, A[i] = i;end loop; }
66
Estructuras de Control
while--Ada /* C and Java*/while<expresión booleana >loop while (expresion){
<sentencias> <sentencias>end loop; }
12
67
Programar
TRANSFORMAR EL DISETRANSFORMAR EL DISEÑÑO EN UN PROGRAMA O EN UN PROGRAMA EJECUTABLE EN UNA PLATAFORMA ESPECEJECUTABLE EN UNA PLATAFORMA ESPECÍÍFICAFICACaracterísticas de una buena programación:
la estructura arquitectónica definida durante el diseño es fácilmente reconocible en el códigolos niveles de abstracción del diseño se conservanlas interfaces entre partes del programa son descritas explícitamentela consistencia de objetos y operaciones puede ser probada por el propio compilador
Alcanzar estas características depende de:la programación estructuradala elección del lenguaje de programaciónla elección del entorno de programaciónel estilo de programación 68
Programación estructurada
Dijkstra: “GOTO statement considered harmful”Calidad de un programa es inversamente proporcional al número de sentencias GOTO utilizadas.
Programa Estructuradoprograma = secuencia de construcciones lógicasconstrucciones lógicas = secuencia, condición, repeticióncada construcción tiene 1 entrada y 1 salida
69
Programación estructurada
Características del código resultantenúmero mínimo de GOTO’sutiliza bloques para estructurarminimiza el número de variables no locales
Técnicas para eliminar los GOTO’sduplicación de códigointroducción de procedimientosutilización de variables auxiliaresutilización de banderas
70
Reglas para estructurar un diagrama de flujo
1) Mover el punto de destino del salto (donde se reunifica el flujo) y duplicar las acciones que quedan en medio.
BEGIN
A1
A2
B1
A3
B2
A4
END
BEGIN
A1
A2
B1
A3
B2
A4
END
A1
71
Reglas para estructurar un diagrama de flujo
2) Mover el punto de destino del salto más alláde los chequeos de condiciones añadiendo instrucciones adicionales que hagan innecesario el chequeo de condiciones.
BEGIN
A1
A2
B1
A3
BEGIN
A1
B2
A2
END
B1A3
B2
END
B2:= TRU
T
T
F
F
T
T
F
F
72
Alternativa a los diagramas de flujo
Diagramas de Flujofomentan uso de “GOTO”impiden expresar estructuras de control de alto nivel
Diagrama de Nassi-Schneiderman o de cajasimpiden el uso de “GOTO”se determina fácilmente el ámbito de datos locales o globalesrecursividad se representa fácilmente
13
73
Alternativa a los diagramas de flujo
cond.F Tparteelse
partethen
cond. de bucle
partedo-while
parterepeat-
until
cond. de bucle
REPETICIÓN
SECUENCIA IF-THEN-ELSE:
acción 1acción 2
...acción n
74
Alternativa a los diagramas de flujo
Principales desventajasdifíciles de modificar”“Fundamentalista”: no permiten expresar ningún GOTO
caso de condición
valor
partecase
...
...
valor
partecase
SELECCIÓN (“switch-case”)
75
Alternativa a los diagramas de flujo
/*Ejemplo: itoa: convierte n a caracteres en texto */void itoa(int n, char texto[]){
int i, signo;
if ((signo = n) < o) /*guardo el signo */n = -n; /*hago n positivo */
i = 0;do { /* genero dígitos en orden inverso */
texto[i++] = n % 10 + ‘0’;} while (( n /=10 ) >0); if ( signo <0) /*agrego signo de menos? */
texto[i++] = ‘-’;texto[i] = ‘\0’;invertir(texto);
}76
Inconvenientes y ventajas
el código resultante puede ser más largoel código resultante puede ser menos eficientealgún “gurú” se puede reir de nuestros programas
más entendible; más fácil de leermayor confiabilidadmás fácil de modificarmayor localidadmás fácil de chequearquien ríe último, ríe mejor!
ES MUCHO MES MUCHO MÁÁS FS FÁÁCIL OPTIMIZARCIL OPTIMIZARUN PROGRAMA CORRECTO UN PROGRAMA CORRECTO
QUEQUECORREGIR UN PROGRAMA OPTIMIZADOCORREGIR UN PROGRAMA OPTIMIZADO
QUE CONTIENE ERRORESQUE CONTIENE ERRORES
77
GOTOs útiles
Para realizar estructuras de control no disponibles (por ejemplo en ensamblador)Para interrumpir iteraciones“break” y “continue” en el lenguaje C:
/*trim: elimina blancos, tabuladores y NL al final*/int trim(char texto[]){
int n;for (n = strlen(texto)-1; n >=0; n --)
if (texto[n] !=‘ ‘ && texto[n] !=‘\t’ && texto[n] !=‘\n’)break;
texto[n+1] = ‘\0’;return n;
}78
GOTOs útiles
Para salir rápidamente de dentro de varios niveles de iteraciónbuscar un elemento en una matriz y abandonar la búsqueda inmediatamente después de encontrado
Para optimizar programas estructurados
14
79
Estilo de programación
Los programas se escriben una sola vez, pero se leen (y modifican) muchas veces...⇒Vale la pena escribirlos de modo que sean
entendibles!
Elementos de un buen estilo:EstructuraElocuenciaForma externaUso de comentarios
80
Estilo de programación
Estructuraelegir instrucciones adecuadas
Ejemplo: Tres instrucciones equivalentes en “C”:n = n * 8;n *= 010; /* constante en octal */n <<=3;
en lo posible proceder de acuerdo a los criterios de la prog. estructurada (... pero sin fundamentalismos!)
81
Estilo de programación
Elocuencia: Elección de nombres apropiados para objetos y operaciones
Ser elocuente y consecuente, aún cuando los nombres sean largosUtilizar abreviaturas usuales
Ejemplo: CBCPJP = Controlador de la Bomba de Calor,Programador: Juan Pérez
No mezclar distintos idiomasUtilizar
palabras principales para valores (ancho, tecla,....)expr. con verbos para actividades (calc_ancho, lee_tecla...)expr. con adjetivos para condiciones (valido, muy_alto,...)
82
Estilo de programación
Elocuencia (cont.)Utilizar convenciones
Ejemplo: Tipos definidos por el usuario: comenzar con “T_”, TODO MAYÚSCULA: T_PERSONAConstantes: TODO_ MAYÚSCULAVariables globales: comienzan con “gbl_”: gbl_unEjemploPunteros: comenzar con “ptr_”: ptr_unPunteroVariables locales y funciones: todo minúsculaNombres compuestos por varias palabras: separarConMayuscula
83
Estilo de programación
Forma externaseparación de declaraciones e instruccionesdeclaraciones con una estructura sistemática:
constantes, tipos de datos variables
organización de la descripción de la interfaz (lista de parámetros) en
variables de entradavariables de salidavariables de entrada/salida
separación de textos de programa y comentariosutilizar indentación para resaltar estructura del programa
84
Comentarios
Comentarios de prólogoEncabezado de cada móduloFormato1. Propósito, función del módulo2. Descripción de la interfaz, incluyendo:
ejemplo de una “secuencia de llamada”descripción de cada uno de los argumentoslista de todos los módulos subordinados
3. Explicaciones pertinentes, como por ejemplovariables importantes y su usomodo de funcionamiento (algoritmos)restricciones y limitaciones
4. Historia del desarrollo, incluyendoautor, revisor y fecha.fecha y descripción de las modificaciones
15
85
Comentarios
Comentarios descriptivosDeben proporcionar información adicional (si no, más vale ahorrárselos!)Deben ser correctos... un comentario no actualizado puede hacer perder mucho tiempo!En general, es mejor comentar bloques que líneas de código.
86
Desde código fuente en C hasta el ejecutable
Código FuenteHeaders del Sistema
Headers del Sistema
Headers del Usuario
Headers del Usuario
pre-procesador
compilador
Código Fuente C preprocesado
inclusión de archivossubstitución de macroscompilación condicional
una o dos pasadas
ensamblador
link-loader
Código fuente en ensamblador
Código objeto
EJECUTABLE
Código objeto
Otros archivos decódigo objeto
Otros archivos decódigo objeto
Bibiliotecas del Sistema
Bibiliotecas del Sistema
Bibiliotecas del usuario
Bibiliotecas del usuario
87
Dicen los que saben...
Que es bueno evitar “programar astutamente”Que hay que evitar las variables globales
pueden ser manipuladas desde cualquier ladouna modificación puede tener efectos inesperados
Que es mejor evitar los “efectos colaterales”Que los programas son en primer lugar un medio de comunicación con otros programadoresprimero correcto, después eficienteprimero pensar, después compilar
antes de compilar, “ejecutar mentalmente” el programarealizar inspecciones, explicarle a otros
88
Dicen los que saben...
Que es posible escribir programas de buena calidad usando lenguajes no estructuradosQue es posible escribir programas malos utilizando lenguajes buenosQue hay que evitar muchos niveles de if-then-else
máximo 3 nivelesQue los programadores buenos lo son independientemente del lenguaje de programaciónQue los programadores malos lo son independientemente del lenguaje de programación
89
Programación a gran escala
90
Descomposición y Abstracción
Decomposición — división sistemática de un sistema complejo en partes cada vez máspequeñas hasta que los componentes seanaislados y se puedan entender y manipular porindividuos o pequeños grupos.
TOP DOWN DESIGN
Abstracción — especificación de la parte esencial del componente para una posterior consideración de los detalles del mismo
BOTTOM UP DESIGN
16
91
Modulos
Colección de objetos y operaciones lógicamenterelacionados.Encapsulación — técnica para aislar unafunción del sistema dentro de un módulo con una especificación precisa del interfaz
ocultación de informacióncompilación separadatipos de datos abstractos
¿Como deberían descomponerse grandessistemas en módulos?
La respuesta está en la Ingeniería del Software!92
Ocultación de Información
Una estructura modular soporta visibilidad reducidapermitiendo que la información sea ocultada en sucuerpo.La especificación y el cuerpo de un módulo puede darsepor separado. Idealmente, la especificación debería ser compilable sin haber escrito el cuerpoP. Ej., en Ada hay una especificación de package y un cuerpo de package; relación formal; errores en tiempode compilación.En C, los módulos no están tan bien formalizados. Habitualmente, los programadores crean un fichero .h que contiene el interfaz a un módulo, y un fichero .c parael cuerpo. No hay relación formal. Los errores se detectan en tiempo de enlace (link)
93
Tipos abstractos de datos
Existen lenguajes de programación que permiten crear nuevos tipos de datos, más específicos que los tipos de datos generales previstos en el lenguaje. Un tipo abstracto de datos se especifica indicando:
su dominio (es decir, los datos que lo integran)los servicios disponibles para operar sobre la estructura de datoslas propiedades de dichos servicios.
94
Tipos abstractos de datos
Ejemplo de especificación de un tipo abstracto de datos:
TIPO: STACK[X]
FUNCIONES:empty: STACK[X] -> BOOLEANnew: -> STACK[X] push: X x STACK[X] -> STACK[X]pop: STACK[X] -> STACK[X]
PRECONDICIONES:pre pop(s: STACK[X]) = not empty(s)
AXIOMAS:Para todo x:X, s: STACK[X]:
empty(new())not empty(push(x,s))pop(push(x,s)) = s
95
Tipos abstractos de datos: Ejemplos (1)
Definición del tipo de datos “COMPLEJO” en ADA:
package NUMEROS_COMPLEJOS is
type COMPLEJO is
record
REAL: FLOAT:= 0.0;
IMAG: FLOAT:= 0.0;
end record;
function EQUAL (X,Y: COMPLEJO) return BOOLEAN;
function ¨+¨ (X,Y: COMPLEJO) return COMPLEJO;
function ¨-¨ (X,Y: COMPLEJO) return COMPLEJO;
function ¨*¨ (X,Y: COMPLEJO) return COMPLEJO;
function ¨/¨ (X,Y: COMPLEJO) return COMPLEJO;
end; -- fin de la especificación del tipo96
Tipos abstractos de datos: Ejemplos (1)
Definición del tipo de datos “COMPLEJO” en ADA (cont.):
package body NUMEROS_COMPLEJOS is
function EQUAL (X,Y: COMPLEJO) return BOOLEAN is
begin
if (X.REAL = Y.REAL) and (X.IMAG = Y.IMAG)
then return TRUE;
else return FALSE;
end if;
end EQUAL;
... siguen las demás operaciones....
17
97
Tipos abstractos de datos: Ejemplos (2)
Definición del tipo de datos “COMPLEJO” en ANSI C:archivo complejos.h:
typedef struct
{
float real;
float imag;} COMPLEJO;
int c_equal(COMPLEJO x, COMPLEJO y);
COMPLEJO c_add(COMPLEJO x, COMPLEJO y);
COMPLEJO c_sub(COMPLEJO x, COMPLEJO y);
COMPLEJO c_mul(COMPLEJO x, COMPLEJO y);
COMPLEJO c_div(COMPLEJO x, COMPLEJO y);
/* fin de complejos.h */
98
Tipos abstractos de datos: Ejemplos (2)
Definición del tipo de datos “COMPLEJO” en ANSI C:archivo complejos.c:
#include “complejos.h”
int c_equal(COMPLEJO x, COMPLEJO y)
{
return
((x.real == y.real) && (x.imag == y.imag));
} /* c_equal */
... siguen las demás operaciones....
99
Mecanismos de paso de parámetros
por valor:
function abs(x: integer)begin
if x < 0 thenreturn -x
elsereturn x
end
antes - llamada - después subrutina:
b=abs(A)-5A:0 b:
-5A:
5b:
por referencia o por dirección:antes - llamada - después
function abs(var x: integer)begin
if x < 0 thenreturn -x
elsereturn x
end
subrutina:
b=abs(A)-5A:0 b:
5A:
5b:
100
Recursividad
Mecanismo por el cual un procedimiento puede auto-referenciarse.Ejemplo:
void mcd(int x,y);{
if (y == 0)printf(”mcd = %d”,x);
elsemcd(y, (x % y) );
}Elegante pero, e
n general,
muy inefici
ente!!
void mcd(int x,y);{
int z;while (y != 0){
z=y;y=x % y;x=z;
}printf(”mcd = %d”,x);
}
Procedim
iento iterativo
equivalente
101
Rutinas Re-entrantes
Una rutina re-entrante es aquella que puede ser utilizada por varias tareas que se ejecutan en forma concurrente, en un sistema multitarea. Un lenguaje de programación permite escribir rutinas re-entrantes, pero que una rutina lo sea o no depende del programador!
Ejemplo : int flag=0; */ var. global */
int no_reentrante(){
printf(¨flag vale %i¨, flag);if (flag == 0)
func1(); flag = 1;else
func2(); flag = 0;}
102
Asignación dinámica de memoria
Consiste en la capacidad de asignar memoria a un proceso durante la ejecución del mismo.Necesaria para la construcción y mantenimiento de los stacks necesarios en cualquier SO de tiempo real.Alternativa: stacks de tamaño fijo: debo conocer de antemano su tamaño máximo.
Compromiso:USO EFICIENTE USO EFICIENTE DEL RECURSO vs. DEL RECURSO MEMORIA CPU
18
103
Asignación dinámica de memoria
Funciones en C para reserva y liberación de memoria:malloc() reserva memoriafree() la libera
PASCAL: sentencias NEW y DISPOSEAlternativa a la administración manual de memoria: “Garbage Collection”, usual en lenguajes orientados a objetos tales como Eiffel, JAVA y Smalltalk
104
Modularidad
Consiste en dividir al software en componentes con nombres y ubicaciones determinados, que se denominan módulos y que se integran para satisfacer los requisitos del problema.Sea:
C(p): complejidad del problema pE(p): esfuerzo requerido para resolver el problema p
Evidencias empíricas: C(p1) > C(p2) => E(p1) > E(p2)C(p1 + p2) > C(p1) + C(p2)Si el número de módulos crece mucho, entonces el
esfuerzo asociado con el manejo de sus interfaces compensa la ventaja de particionar el problema en módulos!
105
Modularidad
Modularidad y Lenguajes de Programación:Un Módulo debe ser compilable separadamenteUn Módulo consta de:
una interfaz públicauna realización privada
Ejemplo: “Package” de ADA
Un lenguaje de programación puede
ayudar a lograr buenas propiedades
de modularidad, pero el solo hecho de
usarlo no alcanza para lograrlo!!!
106
Orientación a Objetos
Definición: Un sistema de
software orientado a objetos es aquel
que está construido como una colección
estructurada de realizaciones de tipos abstractos de
datos.
cada mcada móódulo serdulo seráá la realizacila realizacióón de un tipo abstracto n de un tipo abstracto de datos, que se denomina CLASE.de datos, que se denomina CLASE.
Las clases son unidades autLas clases son unidades autóónomas, que colaboran nomas, que colaboran para lograr satisfacer los requerimientos del sistemapara lograr satisfacer los requerimientos del sistema
Existen relaciones entre las clases, a saber:Existen relaciones entre las clases, a saber:•• CLIENTECLIENTE--SERVIDORSERVIDOR•• HERENCIAHERENCIA
Polimorfismo: posibilidad de definir una funciónque tenga distintos efectos según el tipo de objetoa que se le aplique.
OO y Tiempo RealOO y Tiempo Real: • dynamic binding• garbage collection
Ejemplos :Ejemplos :C++C++
SmalltalkSmalltalkEiffelEiffelJavaJava
Ada95Ada95
107
Manejo de excepciones
Existen lenguajes que ofrecen facilidades para expresar cómo debe reaccionarse frente a un error u otra condición anormal que se dé durante la ejecución del programa. Estas situaciones se llaman EXCEPCIONESEl código invocado si ocurre una excepción se llama rutina de atención a la excepción (“exception handler”)Algunas excepciones están previstas (y son detectadas) por el propio microprocesador. El programador debe suministrar la rutina de atención a la excepción.
Ejemplo: división por ceroEjemplo de lenguajes que tienen previsto el tratamiento de excepciones: ADA, Eiffel, JAVA.
108
1.- Lenguaje Ensamblador (Assembler)
No posee casi ninguna de las características discutidas, que son propias de los lenguajes de alto nivelno estructuradoinherentemente no portabledifícil de aprender, tedioso, favorece erroresLa existencia de buenos compiladores hace que en general se obtengan programas más eficaces si se escriben en lenguajes de alto nivel que “optimizando assembler a mano”
Provee control directo sobre el hardwarePuede ser la única manera de optimizar al máximo una pequeña rutina que tiene gran incidencia en la respuesta temporal del sistema.En sistemas muy pequeños (ej: Microcontroladores de 8 bits), puede ocurrir que los recursos necesarios para usar un lenguaje de alto nivel no estén disponibles.
19
109
2.- Lenguaje PASCAL (estándar)
Diseñado en 1968 para enseñar programación, no para uso profesional!!!No posee variables estáticasStandard I/O es defectuosa y no se puede sustituir (el estándar es cerrado)No posee elementos que permitan la construcción de programas grandes. En particular, carece de la noción de módulo compilableseparadamenteNo es fácilmente extensible
(estas son algunas de las críticas formuladas por Kernigham, uno de los autores del lenguaje C)
Lenguaje Elegante y Simple, ideal para enseñar programación estructurada.Estándar ANSI/IEEEtipificación de datos fuerterecursiónestructuras de datos dinámicastipos enumeradosfomenta la estructuración de los programas (“GOTO” considered harmful)
110
3.- Lenguaje C
No ayuda a seguir los principios de la ingeniería de software: en C “está todo permitido”Manejo de punteros es difícil de aprender y provoca numerosos errores, aún entre programadores experimentados.No existen chequeos automáticos (por ejemplo, del índice de un array)control de tipos muy débil
Estandarizado, existen compiladores de dominio público para cualquier plataforma hardware importanteNo es paternalista: en C “está todo permitido”asignación dinámica de memoriacompilación separada de módulosActualmente, es “el”lenguaje de programación para aplicaciones de tiempo real no militares.
111
4.- Lenguaje ADA
Sólo es utilizable en sistemas que disponen de una cierta cantidad de recursosNo existen compiladores de costo accesible para todas las plataformasLenguaje más bien extenso, difícil de comprender y aprender en su totalidadLa introducción de la orientación a objeto en ADA95 aparece como un tanto forzada
EstandarizadoPromueve la creación de programas confiables: Confiabilidad
tipificación fuerterun-time checkings
Soporta muy bien la modularidadseparación de especificación y realización de los módulos módulos y packages compilables por separado
Promueve un buen estilo de programación: Tipos abstractos de datos, Manejo de excepcionesEspecíficamente diseñado para aplicaciones de tiempo real.Primitivas de sincronización de tareas
La condesa Ada Augusta Byron (Ada Lovelace) fue matemática y la única hija legítima del poeta Lord Byron.Trabajó con Charles Babbage en su Máquina de Diferencias, y es considerada la primera programadora de la historia. Lady Lovelace murió en 1852 a la edad de 36 años.
112
5.- Lenguaje JAVA
Solo es utilizable en sistemas que disponen de una cierta cantidad de recursosLa “máquina virtual de JAVA”no está disponible (aún?) para todas las plataformasLos compiladores actuales producen código muy ineficiente
Orientado a objetos, SimpleAmbientes de desarrollo en el dominio públicoSuprime aspectos más polémicos de C++ manteniendo su sintaxis básicaLenguaje de la “era internet”tipificación mucho más fuerte que C, C++run-time checkingsaborda el problema de privacidadmulti-tareas, sincronización y comunicación entre tareasmanejo de excepcionesgarbage collection
113
Programaciónconcurrente
114
Programación Concurrente
Nombre dado a la notación y técnicas de programación que permiten expresar el paralelismo potencial y resolver los problemas resultante de sincronización y comunicación.
La implementación (hardware y software) del paralelismo es un tema esencialmente independiente de la programación concurrente.
La programación concurrente proporciona una visión abstracta para estudiar el paralelismo sin entrar en los detalles de su implementación.
20
115
Para permitir la expresión del paralelismo potencial de tal forma que se pueda emplear más de un computador para resolver el problema.
Para maximizar la utilización del procesador
¿Porqué es necesaria?
116
Para modelar el paralelismo en el mundo real
Virtualmente, todos los sistemas de tiempo real son concurrentes por naturaleza.Las actividades en el mundo real evolucionan simultáneamente.
Esta es la principal razón para usar concurrencia
¿Porqué es necesaria?
117
Una alternativa consiste en utilizar técnicas de programación secuencialEl programador debe construir el sistema de tal manera que implique la ejecución cíclica de una secuencia de programa para gestionar varias actividades concurrentes. Esto complica la ya de por sí difícil tarea del programador e implica la consideración de estructuras que son irrelevantes para el control de las actividades que tiene entre manos. Los programas resultantes son más oscuros y menos elegantesComplica la descomposición del problemaLa ejecución paralela del programa en más de un procesador podría ser mucho más difícil de conseguir.La escritura de código para el tratamiento de fallos es más problemático.
¿Porqué es necesaria?
118
Terminología
Procesos concurrentes: Se dice que dos o más procesos son concurrentes si pueden ejecutarse en paralelo, de forma que alguno de ellos comience a ejecutarse antes que termine algún otro.
Programa concurrente: Conjunto de procesos secuenciales autónomos, que se ejecutan (lógicamente) en paralelo o, de forma equivalente, un programa cuya ejecución se realiza según varios flujos de control que avanzan en paralelo.
Cada proceso tiene su propio flujo de control. A veces se habla de procesos con varios flujos de control (threads)Las instrucciones de los procesos se ejecutan intercalándose unas con otras (paralelismo lógico)
119
Terminología
La ejecución de la colección de procesos concurrentes se puede realizar de tres formas:
Multiprogramación: Un único procesador va alternando la ejecución de los diversos procesos (entrelazado)
Multiprocesamiento: Cada proceso se ejecuta en un procesador diferente con acceso a una zona de memoria común (datos comunes). Sistema fuertemente acoplado
Procesamiento distribuido: Los procesos multiplexan su ejecución en varios procesadores que no comparten memoria.
120
Concurrencia
Los elementos empleados en la programación concurrente deben permitir:
la creación de procesos concurrentesla sincronización de procesosla comunicación entre procesos
En función de la interacción (sincronización y comunicación ) entre procesos estos pueden ser:
Independientes : no se comunican ni sincronizanCooperativos: para realizar alguna acción comúnCompetitivos: para acceder a recursos compartidos
Los procesos que cooperan o compiten necesitan comunicarse y sincronizar sus actividades
21
121
Ejecución concurrente
Características del modelo de concurrencia:Estructura
Estática: nº de procesos fijo conocido a priori en tiempo de compilación
Dinámica: creación dinámica en tiempo de ejecución
Nivel de paralelismoAnidado: los procesos se definen en cualquier nivel. Se
pueden definir procesos dentro de otros procesos, lo que permite crear jerarquías de procesos
Plano: los procesos se definen en el nivel más externo del programa.
GranularidadGrueso: pocos procesos de larga duración con gran
variedad de accionesFino: muchos procesos sencillos y efímeros
122
Ejecución concurrente
Características del modelo de concurrencia:Inicialización (información relacionada con su ejecución)
Por paso de parámetros en la creación del procesoComunicación explícita (IPC) con el proceso una vez creado
Finalización del procesoPor llegar al final del cuerpo del procesoSuicidio por ejecución de una sentencia de autofinalizaciónAborto mediante una acción explícita de otro procesoOcurrencia de una condición de error (excepción) sin manejarNunca (bucle infinito)Cuando ya no son necesarios (si no tiene procesos dependientes de él)
123
Ejecución concurrente
Jerarquía y relaciones entre procesosPara un proceso, es útil distinguir entre el proceso (o bloque) que es responsable de su creación, y el proceso (o bloque) que es afectado por su finalización.Relación padre/hijo
Un proceso (padre) crea a otro (hijo)El padre ha de esperar mientras el hijo se crea e inicializa
Relación tutor/pupilo o guardián/dependienteUn proceso (pupilo) puede depender del propio proceso tutor o de un bloque interno de éste.El tutor no puede terminar hasta que todos los procesos dependientes él (pupilos) hayan terminadoEl tutor puede ser: el padre, otro proceso o un bloque interno del padre o de otro proceso. 124
Sincronización ycomunicación
125
Sección Crítica y Exclusión Mutua
SECCIÓN CRÍTICA: secuencia de instrucciones que debe ser ejecutada indivisiblementeEXCLUSIÓN MUTUA: sincronización necesaria para proteger una sección crítica
abc.txtejemp.psejemp2.ps
45
6
7
Proc A
Proc B
out = 4
in = 7
Cola de Impresión:
126
Propiedades de la Sincronización
Ausencia de deadlocks (bloqueos)Condiciones necesarias para un deadlock:
los procesos pretenden acceso exclusivo a los recursos (mutual exclusion condition)los procesos mantienen los recursos obtenidos mientras esperan por otros (wait for condition; only serially reusable resources)a los procesos no se les puede quitar un recurso hasta que ellos lo liberen voluntariamente (no preemption condition)existe una cadena cerrada de procesos y recursos, en la cual los procesos esperan por recursos que están siendo ocupados por otro proceso (circular wait condition)
22
127
Propiedades de la Sincronización
Ejemplo de Deadlock:Cruce de dos calles• sin semáforos• única regla de preferencia:
“pasa primero el que viene por la derecha”
128
Propiedades de la Sincronización
Ausencia de livelocks (inanición)Ejemplo:
Se inician las tareas en orden A, B, C.Los recursos se obtienen todos juntos, o no se obtienen
el proceso B tiene un livelock por la conspiración de A y C:Tarea A
Solicitar Lector
Lector Asignado
Leer 100 Unidades
Liberar Lector
Tarea B
Solicitar Lector e Impresora
Lector e Impresora Asignados
Leer 200 Unidades
Imprimir 5 Formularios
Liberar Lector e Impresora
Tarea C
Solicitar Impresora
Impresora Asignada
Imprimir 10 Formularios
Liberar Impresora
Respetar las capacidades límites– no sacar, cuando está vacío– no poner, cuando está lleno
(PROBLEMA PRODUCTOR/CONSUMIDOR)
129
P3
P1
P2
R2
R3
R1
130
P3
P1
P2
R2
R3
R1
131
Entrelazado y operaciones atómicas
Posibles ejecuciones:(P1; P2; Q1; Q2)(P1; Q1; P2; Q2)(Q1; P1; P2; Q2)...
Entrelazado
Proceso P ;x,y: entero ;
P1: x:=1 ;P2: y:=x+2 ;
fin P ;
Proceso Q ;z,u: entero ;
Q1: z:=3 ;Q2: u:=z+1 ;
fin Q ;
132
Entrelazado
Cada instrucción de alto nivel: varias instrucciones código máquina.
Por ejemplo: x := y + z ; copiar y, r1copiar z, r2sumar r1, r2copiar r2, x
Operaciones atómicas.
23
133
Comunicación y Sincronización
La dificultad de la programación concurrente estriba en las interacciones de los procesos:
Cooperación para un fin comúnCompetencia por el uso de recursos
Son necesarias operaciones de comunicación y sincronización entre procesos:
Sincronización: cumplir restricciones sobre el orden en el que se ejecutan sus accionesComunicación: paso de información de un proceso a otro
Hay dos formas de realizarlo:Datos compartidosPaso de mensajes 134
Compartición de una variable
Ejemplo: dos procesos (contador y escritor) comparten una variable n.
proceso contador;principiorepetiresperar pulso;n:=n+1;
fin repetir;fin;
proceso escritor;principiorepetiresperar 1 hora;escribir n;n:=0;
fin repetir;fin;
VARIABLE COMPARTIDAn : entero := 0;
ERROR: el resultado depende del ordenen que se intercalen las instrucciones
135
Compartición de una variable
Posibles trazas:(escribir n; n:=0; n:=n+1)(escribir n; n:=n+1; n:=0) --> Pérdida de pulso(n:=n+1; escribir n; n:=0)
n := n + 1 ;copiar n, r1sumar r1, 1 / (escritor) n:=0;copiar r1, n => Pérdida de la puesta a cero de n
Problema: entrelazado de las instrucciones en el acceso a la variable común. Solución: garantizar la exclusión mutua en el acceso al elemento compartido.
136
Compartición de una variable
Sección crítica: Se garantiza que dos procesos no estarán ejecutando a la vez una misma región crítica
Monitores, mutex, Test_and_set
Ejemplo: dos procesos (contador y escritor) comparten una variable n.
proceso contador;principiorepetiresperar pulso;region n hacern:=n+1;
fin;fin repetir;
fin;
proceso escritor;principiorepetiresperar 1 hora;region n hacerescribir n;n:=0;
fin;fin repetir;
fin;
VARIABLE COMPARTIDAn : entero := 0;
137
Exclusión mutua
Dos procesos compiten cuando comparten:un recursouna variable (comunicación)
El acceso al recurso o a la variable debe ser en exclusión mutua.
Sección crítica: secuencia de instrucciones que debe ejecutarse en exclusión mutua
Mecanismos de sincronizaciónEspera ocupada (busy waiting)SemáforosMonitores 138
Sección crítica no expulsable
Evitar expulsiones cuando se ejecuta una sección críticaEnmascarar interrupciones
No entra el núcleo, ni el reloj, ...Elevar al máximo la prioridad del código
Posibilidad de cambiar en tiempo de ejecución la prioridad de un tarea
void Servicio (...) {Mask_all_Interrupts () ;Service_Code() ; /* sección critica */Unmask_all_Interrupts () ;return ;
}void Servicio (...) {Nominal = Get_Priority () ;Set_Priority (HIGH) ;Service_Code() ; /* sección critica */Set_Priority (Nominal) ;return ;
}
24
139
Espera ocupada (Busy waiting)
Puede usarse un indicador compartido si el acceso al mismo es atómico
Test_and_Set: operación atómica que bloquea un indicador y devuelve el valor que tenía antes
proceso P1;principiorepetirmientras Test_and_Set(Bloqueado) nada;
fin mientras;< sección crítica >Bloqueado := false ;< otras cosas >
fin repetir;fin ;
Test_and_Set:load r1, 1swap r1, flagreturn r1
atómica
INDICADOR COMPARTIDO Bloqueado: booleano:= false;
140
Exclusión Mutua - “busy waiting”
Problema:Dos tareas requieren la utilización exclusiva de un recurso¿Cómo garantizar que en el tiempo que transcurre desde que una tarea consulta si el recurso está siendo utilizado hasta que lo comienza a utilizar, este recurso no es tomado por la otra tarea?
Características de la soluciónno asumir orden fijo de ejecuciónun proceso fuera de su sección crítica no debe bloquear a otros procesosningún proceso debe esperar indefinidamente para entrar en su sección crítica
141
Exclusión Mutua - “busy waiting”
Ejemplo:2 personas quieren acceder a un ÁREA CRÍTICA con exclusividad.Desde fuera no se puede saber si el área crítica estáocupada, pero existen garitas desde las cuales se pueden ver banderas que se utilizan dentro del área crítica para pasar información.
Garita 1 Garita 2
ventanas
ÁÁREA CRREA CRÍÍTICATICA persona1loop
<prot. entrada><sección crít.><prot. salida><sección no
crítica>
142
Exclusión Mutua - “busy waiting”
Solución 1: Quien está saliendo iza una bandera con el número de la persona que puede entrar
Análisis de la soluciónSatisface requerimiento de exclusión mutuaNo hay posibilidad de deadlocksNo hay posibilidad de livelocks (asumiendo estancia finita en área crítica)Procesos fuertemente entrelazados (se “van pasando” el derecho a entrar)
secuencia estricta de entrada: una vez cada unosi un proceso termina, el otro queda en deadlock.
143
Exclusión Mutua - “busy waiting”
Solución 1: Quien está saliendo iza una bandera con el número de la persona que puede entrar
Análisis de la solución
Garita 1 Garita 2
ÁÁREA CRREA CRÍÍTICATICA
1/2
Loop de persona1:
esperar<sección crít.>
flag = 2<sección no crítica>
flag !=1
144
Exclusión Mutua - “busy waiting”
Solución 2: Objetivo: Evitar los problemas de solución 1Cada persona tiene su propia bandera, para que la ponga en la garita. Para entrar P1:
alza su bandera (1) para indicarloLUEGO chequea el estado de la bandera del otro lado (2)
si (2) está baja, entra al área crítica, y al salir baja su bandera.si (2) está alta, se queda en la garita esperando hasta que P2 salga, y entonces entra
Análisis de la soluciónLa solución no está libre de deadlocks!¿En qué caso?
25
145
Exclusión Mutua - “busy waiting”
Solución 2:
Análisis de la soluciónLa solución no está libre de deadlocks!¿En qué caso?
Garita 1 Garita 2
ÁÁREA CRREA CRÍÍTICATICA
1 2
Loop de persona1:
flag1 = UPflag2 == UP
esperar<sección crít.>
flag1 = DOWN<sección no crítica>
146
Exclusión Mutua - “busy waiting”
Solución 3 (Algoritmo de Dekker): Objetivo: Evitar el deadlock de la solución anteriorSe agrega una bandera de prioridad que se usa solo en el caso que ambas personas soliciten entradas simultáneamente (en otro caso, vale la solución 2).La bandera de prioridad indica cuál de las 2 personas tiene prioridad para insistir.
entra a la zona crítica.al salir cambia el No. en la bandera de prioridades.
Análisis de la soluciónSolución elegante de la exclusión mutua, sin utilizar primitivas especiales.Protocolos difíciles de diseñar, entender y verificar (probar extender esto para más de 2 tareas)Busy wait...
147
Exclusión Mutua - “busy waiting”
Solución 3 (Algoritmo de Dekker):
Análisis de la solución...proceso “perverso” puede utilizar mal las variables compartidas y corromper todo el sistemaSe ha asumido que entre chequear el estado de una bandera y entrar al área de exclusión no ocurre nada!
Garita 1 Garita 2
ÁÁREA CRREA CRÍÍTICATICA
1 2
1
Bandera deprioridad
Loop de persona1:
flag1 = UP
flag2 == UP && prio ==2)
esperar<sección crít.>
flag1 = DOWN<sección no crítica>
prio = 2
148
Semáforo
Es una variable que toma valores enteros no negativos(counting semaphore)
Las operaciones signal y wait son atómicas.Los semáforos tienen asociada una cola de procesos suspendidos en espera.Los semáforos son gestionados por el núcleo de ejecución
S : semaphore := valor_inicial ; wait(S): si S > 0, S := S - 1 si no, suspender el proceso signal(S): si hay procesos esperando, pasar uno de ellos a preparado si no, S := S + 1
149
Sincronización condicional
Sincronización condicional: una acción de un proceso sólo se puede ejecutar si otro proceso está en un cierto estado o si ha ejecutado ciertas acciones.Un semáforo binario inicializado a cero sirve para comunicar que se cumple la condición
La parte 1b no se ejecuta hasta que P2 avisa que se cumple la condición necesaria
proceso P1; --esperaprincipiorepetir
<parte 1a> Wait(condicion) ;<parte 1b>
fin repetir;fin P1 ;
condicion: semaphore := 0 ;
proceso P2; -- avisaprincipiorepetir<parte 2a> Signal(condicion)<parte 2b>
fin repetir;fin P2 ;
150
Semáforo: exclusión mútua
La exclusión mutua puede asegurarse con un semáforo binario, inicializado a uno
mutex (MUTual EXclusion)
proceso P1;principiorepetirWait(mutex) ;<sección crítica>
Signal(mutex)<sección no crítica>
fin repetir;fin P1 ;
mutex: semaphore := 1 ;
proceso P2;principiorepetirWait(mutex) ;<sección crítica>
Signal(mutex)<sección no crítica>
fin repetir;fin P2 ;
CUIDADO: si un proceso olvida liberar el mutex, el recurso queda bloqueado
26
151
Semáforo: exclusión mútua
SNC SNC
SC
SNC
SC
SNC
mutex
wait
signal
wait
signal
152
Cuidado con los bloqueos
Cuando se comparten recursos entre procesos, es posible que aparezcan bloqueos mutuos:
proceso P1;
Wait(recurso1) ;Wait(recurso2) ;....Signal(recurso2) ;
Signal(recurso1) ;
proceso P2;
Wait(recurso2) ;Wait(recurso1) ;....Signal(recurso1) ;
Signal(recurso2) ;
Bloqueo
proceso P1;
Wait(recurso1) ;Wait(recurso2) ;....Signal(recurso2) ;
Signal(recurso1) ;
proceso P2;
Wait(recurso1) ;Wait(recurso2) ;....Signal(recurso2) ;
Signal(recurso1) ;Correcto
recurso1, recurso2: semaphore := 1 ;
153
Buffer LimitadoBuffer Limitado
Comunicación
154
Buffer Buffer IlimitadoIlimitado
Productor/consumidor
buffer
Productor Consumidor
155
Buffer LimitadoBuffer Limitado
Productor/consumidor
buffer
Productor Consumidor
tamaño156
Lectores/escritores
Lector1
Lector2
Escritor1
Escritor2
2
2
2
2
Problema : inanición de los escritores
27
157
Lectores/escritores
Lector1
Lector2
Escritor1
Escritor2
2
2
158
Semáforos: RESUMEN
VentajasMecanismo simple y eficientePermite exclusión mutua y sincronización condicionalEvita las esperas ocupadas (busy waiting)
InconvenientesMecanismo de bajo nivel: poco estructuradoSu uso queda disperso por los procesosEs fácil cometer errores: un solo wait o signal mal colocado puede ser fatalEs mejor utilizar mecanismos más abstractos y fiables como los monitores
159
Monitor
Es un módulo que encapsula las secciones críticas asociadas a una variable o un dispositivo físico en forma de procedimientos que son llamados por los procesos
Sólo se puede acceder al elemento compartido a través de los procedimientos del monitorLas llamadas a los procedimientos del monitor se ejecutan en exclusión mutua.
Monitor Contador;n: entero := 0 ;
procedimiento incrementa;principion:=n+1;
fin;
procedimiento escribe_borra;principioescribir n;n:=0;
fin;
fin Contador ; 160
Monitor
Hay lenguajes que soportan monitoresej: protected de Ada 95
Pueden programarse mediante semáforos
/* fichero contador.h */
void incrementa(void) ;void escribe_borra(void) ;
/* fichero contador.c */#include “contador.h”#include <semaphore.h>
/* variables privadas del monitor */ static semaphore mutex_contador ;static int n = 0 ;
void incrementa(void) {wait(mutex_contador) ;n:=n+1;
signal(mutex_contador) ;}
void escribe_borra(void) {wait(mutex_contador) ;escribir(n);n:=0;
signal(mutex_contador) ;}
161
Exclusión mutua e interrupciones
Las rutinas de servicio de interrupciones (ISR) se ejecutan en concurrencia con el resto de procesos.
Exclusión mutua => inhibir interrupciones
static int n = 0 ;
void rutina_interrupcion(void) {n:=n+1;
}
void escribe_borra(void) {inhibir_interrupciones() ;escribir(n);n:=0;
activar_interrupciones() ;}
162
Comunicación mediante mensajes
Las tareas se pueden comunicar o sincronizar mediante paso de mensajesNo requiere memoria compartida
Puede usarse en sistemas distribuidos
Según el tipo de sincronización emisor-receptor:Comunicación asíncrona (buzón, semáforo)
El emisor envía el mensaje y continúaComunicación síncrona (cita)
El emisor espera a que el receptor reciba el mensajeInvocación remota (cita extendida)
El emisor espera a que el receptor reciba el mensaje, lo procese y envíe una respuesta
28
163
Comunicación
AsAsííncronancrona
SSííncronancronaInvocaciInvocacióónn
remotaremota
EmisorEmisor
ReceptorReceptor
164
Buzón
Comunicación asíncrona o por mensajesUn proceso P produce y envía una secuencia de datos a otro proceso C que los recibe y consume. Los datos son transmitidos en porciones discretas denominadas mensajes.Es posible que P produzca un mensaje cuando C no estéen disposición de recibirlo. Para evitar que P espere se introduce un área de almacenamiento de mensajes donde P puede colocar sus mensajes hasta que C los lea: BUZON o COLA DE MENSAJES
Es posible que un buzón tenga varios procesos emisores y varios receptores.
P CB
165
Manejo de buzones:
La política de manejo de un buzón puede ser:Si al enviar un mensaje el buzón está lleno:
el emisor espera hasta que haya espacio el emisor espera, con un tiempo máximoel mensaje se descartase descarta otro mensaje (p.ej. el más antiguo)
Si al solicitar un mensaje el buzón está vacío:el receptor espera hasta que haya mensajeel receptor espera, con un tiempo máximose le indica que no hay mensaje y puede continuar
Buzón
B : buffer max of T
send(M,B) receive(M,B)
166
Buzón: ejemplos de uso
Desacoplar una tarea rápida de una tarea lenta
Servidor con varios clientesLas peticiones indican el buzón de respuesta
TareaControl
TareaPantallaAvisos
Buzón
TareaCliente 1
Peticiones
TareaCliente 2
Buzones
Respuestas
Respuestas
TareaServidor
167
Sistemas operativos
168
Uno de los aspectos más relevantes que debemos tener en cuenta a la hora de desarrollar sistemas de tiempo real es el sistema operativo o núcleo ejecutivo.
El sistema operativo debe proporcionar soporte básico para tareas de tiempo real, tolerancia a fallos, predictibilidad, etc.
29
169
Los actuales sistemas operativos de tiempo real:
poseen un cambio de contexto rápido,poseen un tamaño adaptable a la aplicación que se desea desarrollar pudiendo llegar a un sistema mínimo con una funcionalidad restringida,responden a las interrupciones externas de una forma rápida,minimizan los tiempos en los que las interrupciones están deshabilitadas,proporcionan esquemas de gestión de memoria basados en particiones fijas o particiones variables (nunca memoria virtualpara tareas con restricciones estrictas de tiempo real)proporcionan archivos especiales que son capaces de almacenar datos a gran velocidad.
170
Para garantizar las especificaciones temporales: poseen un reloj de tiempo real,proporcionan mecanismos de planificación basados en prioridades,
proporcionan alarmas y timeouts, y
las tareas pueden hacer uso de llamadas para bloquearse durante determinados intervalos de tiempo.
171
Sistema Informático de propósito general
Hardware - proveé los componentes básicos de cómputo (CPU, memoria, dispositivos de E/S).Sistema Operativo - controla y coordina el uso del hardware entre los varios programas de aplicación para los diferentes usuarios.Programas de Aplicación - define las formas en que los recursos del sistema son utilizados para resolver los problemas de cómputo de los usuarios (compiladores, bases de datos, juegos de video, programas de negocios).Usuarios (gente, máquinas, otras computadoras).
Componentes del sistema informático
172
Componentes del sistema informático
Aplicaciones del usuario
Soporte
de
lenguaje
UtilidadesGestión de ficheros
E/S
Planifi-cadorDespa-
chadorGestión
de INT
CPU
E/S
Subsist.
S.O.
HW
SW
173
Gestión de tareas: (Scheduling) asignación de tiempo de procesador a las tareas. Decide que tarea pasa a ejecutarse.
Gestión de memoria: control de asignación de memoria.
Gestión de recursos: Controla los recursos compartidos diferentes a memoria y tiempo de procesador. Almacena la información asociada a los recursos compartidos por parte de las tareas. Se refiere a los canales de comunicación entre tareas.
Gestión y comunicación entre tareas. Suministra los mecanismos que dan soporte a la comunicación segura entre tareas y a la sincronización de sus actividades. Creación de tareas y mantenimiento de la información asociada a tareas, así como la eliminación de esta información. Una tarea puede crearse por invocación de otras tarea
Objetivos del S.O.
174
Sistemas operativos de tiempo real (SOTR)
30
175
No se trata de que los SOTR sean sistemas rNo se trata de que los SOTR sean sistemas ráápidos sino pidos sino de que sean fiables.de que sean fiables.
debe satisfacer las restricciones temporales explícitas de modo que si no se cumpliesen, se darían en el sistema consecuencias de riesgo severo incluso el fallo totaldiseñar el SOTR pensando más en el peor caso que en optimizar el rendimiento medio.atender con una alta prioridad a las señales externas (interrupciones) provenientes del sistema , ya que pueden informarnos de un cambio de estado en el sistema.minimizar todo aquello que conlleve un alto precio en el tiempo de la CPU
176
Sistema operativo mínimo
S.O.
HW
SW
Software de aplicación
E/S
CPU
Kernel o núcleo
177
El núcleo (kernel) de un SOTR
Requisitos generales para el kernel subyacente en un SOTR:Multitarea.Planificación (Scheduling) por desalojo.Cambio de contexto rápido. Tamaño pequeño.Rapidez y flexibilidad en la comunicación y sincronización entre tareas.Facilidad de comunicación entre tareas y niveles de interrupción.Capacidad de responder rápidamente a interrupciones externas.Límite de ejecución. Dotación de particiones fijas o variables para la gestión de memoriaMinimizar los intervalos durante los que las interrupciones están deshabilitadas.Capacidad de bloquear acceso al código o a datos de memoria. El kernel ha de mantener un reloj de tiempo real.
178
El núcleo (kernel) de un SOTR
Funcionalidades generales incluidas en los kernels de sistemas empotrados para aplicaciones específicas de TR:
Gestión eficiente de recursos.Planificación (Scheduling) de tareas y comunicaciones. Multitarea con baja sobrecarga por cambios de contexto.Equilibrado de carga de trabajo.Reconfiguración y recuperación dinámica.Operación de dispositivos. E/S síncrona y asíncrona. Respuesta rápida a interrupciones externas.Primitivas IPC (memoria compartida, semáforos, eventos asíncronos).Posibilidad de bloqueo y desbloqueo de memoria.Uso limitado de memoria virtual.Soporte de tiempo real para cumplimiento de plazos de respuesta:planificación basada en prioridades, relojes de tiempo real, alarmas especiales, primitivas para retardar, parar o reanudar tareas, etc.Tamaño ajustable a las necesidades de empotramiento.
179
Requisitos actuales de los SOTR
Determinismo Capacidad para responder a sucesos rápidamente Control del sistema por parte del usuario Gestión de prioridades Fiabilidad Gestión de Memoria Comunicación entre tareas Código Reentrante Tamaño reducido de código SOTR distribuidos ConfigurabilidadAdaptabilidad 180
Requisitos actuales de los SOTR
Determinismo tendencia que tiene el sistema a realizar una determinada acción en un tiempo predefinido. El minimizar el tiempo de respuesta a interrupciones garantiza un mayor nivel de determinismo.
Capacidad para responder a eventos rápidamentedistinguiendo entre sucesos síncronos y asíncronos. Necesita una rutina de interrupciones para dar una respuesta “inmediata” a los sucesos asíncronos. Requiere que el desalojo y realojamiento de procesos de la CPU se haga con rapidez.
Control del sistema por parte del usuario de modo que los usuarios puedan conmutar entre distintos modos de ejecución. Por ejemplo, un operario que acciona un botón de emergencia de una máquina.
31
181
Requisitos actuales de los SOTR
Gestión de prioridades En los sistemas operativos tradicionales la prioridad es dinámica, el propio sistema operativo va incrementando o decrementando la prioridad conforme pasa el tiempo. En los SOTR la prioridad debe ser estática con prioridades determinadas, al menos para varios procesos especialmente críticos. Las interrupciones procedentes del exterior tienen una prioridad fija, que no depende de tiempos de espera o ejecución. Además, se ha de analizar si la tarea se realiza según los plazos (seguimiento preventivo y predictivo) y cómo interfiere con las demás
Fiabilidad en caso de fallo hardware ha de haber una solución de tipo software. Deben estar contempladas todas las respuestas que daríamos a cada uno de los posibles fallos que se pudiesen dar. 182
Requisitos actuales de los SOTR
Gestión de Memoria ha de ser más estricta que en los sistemas operativos tradicionales. Cuanta mayor facilidad se trata de dar al usuario mayor va a ser el kernel. En los SOTR el kernel debe ser lo menor posible.
Comunicación entre tareas debe ser muy rápida. Suele ser explícita, la tiene que hacer el usuario.
Código Reentrante se refiere a la posibilidad de que dos procesos puedan emplear un mismo código de programa, sin tener que tener una copia del mismo para cada uno y sin que haya problemas de interferencias entre ellos al manejar el mismo código.
183
Requisitos actuales de los SOTR
Tamaño reducido de código conviene que el repertorio de rutinas empleado sea lo menor posible, a costa de mayor coste de programación por parte del usuario, de modo que se minimice el número de primitivas y el kernel.
SOTR distribuidos Se trata de minimizar los tiempos de respuesta por parte de la red: buses de campo, redes industriales, han de minimizar el tiempo desde que se recoge algo en un sensor hasta que llega a un actuador para ejecutar la orden que corresponda, pasando por el gestor de la red. Otros problemas son considerar que puede haber sobrecarga en la red y problemas de sincronización de los relojes de los distintos elementos del sistema distribuido.
184
Requisitos actuales de los SOTR
ConfigurabilidadConsiste en que el SOTR sirva para una amplia gama de sistemas: desde pequeños sistemas empotrados hasta sistemas donde cada nodo de la red es un supercomputador.
Adaptabilidad necesidad de adaptación a cambios que se producen en el entorno de operación del sistema de tiempo de ejecución. Los tipos básicos de adaptación son la preventiva y la reactiva. La adaptación preventiva trata de garantizar un nivel de prestaciones y funcionalidad del software de operación haciendo hipótesis sobre el comportamiento futuro del sistema basándose en su comportamiento presente. La adaptación reactiva se realiza en respuesta a eventos inesperados.
185
Household Appliances;Consumer Electronics
Footprint (Memory Size) HighLow
Complex
Simple
Inte
grat
ed D
evel
opm
ent E
nviro
nmen
t(fo
rmat
of e
mbe
dded
sof
twar
e)
PersonalComputers
Military; AerospaceAutomotive; Medical
Telecom; Datacom;Office Products
Source: Lehman Brothers
HARD RTOS SOFT RTOS
MicrotecMicrotecVRTXVRTX
Sun MicrosystemsSun MicrosystemsJavaOSJavaOSJChorusOSJChorusOS
MicrosoftMicrosoft
WindowsWindowsCECE
WindowsWindows98, NT, XP98, NT, XP
Wind River SystemsWind River SystemsTornado, Tornado, VxWorksVxWorks
IntegratedIntegratedSystemsSystemspRISMpRISM+;+;MATRIXxMATRIXx
LynxLynxLynxOSLynxOS
MicrowareMicrowareOSOS--9 RTOS9 RTOS
QNX SoftwareQNX SoftwareQNXQNX 3COM3COM
Palm ComputingPalm Computing
SymbianSymbianEPOC16 RTOSEPOC16 RTOS
LucentLucentInfernoInferno
SONYSONYNanoNano OS, OS, AperiosAperios
Sistemas Operativos de Tiempo Real
186
Hard Real-Time vs. Soft Real-Time
Hard Real Time•• real timereal time•• deterministicdeterministic•• time criticaltime critical•• failure can be catastrophicfailure can be catastrophic
RTOS
Soft Real Time•• less real timeless real time•• less deterministicless deterministic•• not as time criticalnot as time critical•• failure can be overcomefailure can be overcome
Commercial•• Wind RiverWind River•• Integrated SystemsIntegrated Systems•• QNXQNX•• SymbianSymbian•• LucentLucent
In-house
•• LynxLynx•• TRONTRON•• MicrowareMicroware•• MicrotecMicrotec•• VenturcomVenturcom
General Purpose OS
Commercial•• Microsoft (CE)Microsoft (CE)•• Sun Microsystems (Java)Sun Microsystems (Java)•• GeoworksGeoworks
Source: Lehman Brothers
32
187
Estrategias de planificación
188
Planificación cíclica
Las tareas se van ejecutando de forma cíclica, de acuerdo con una cola de tareas.
Ventana de Tiempo
······Tarea Acompleta
Tar. Bcomp.
Tarea Ccompleta
Tarea Acompleta
Tarea Ncomplet
189
Planificación cíclica
Las ventajas son que se minimizan los cambios de contexto y que es fácil diseñar un planificador para una tarea conociendo el caso peor. La ventana de tiempo tiene que ser suficientemente pequeña para que su constante de tiempo sea menor que la de la planta pero suficientemente grande para contener las tareas a ejecutar. Las tareas se van ejecutando siempre en el mismo orden. Cada ventana de tiempo se repite indefinidamente, como por ejemplo, en los autómatas programables.
Entre los inconvenientes está el que es difícil la comunicación entre tareas. No hay posibilidad de comunicación con eventos externos, por lo que no es posible el tratamiento por interrupciones: la interrupción ha de esperar a su ventana de tiempo. No hay desalojo, por lo que si una tarea entra en un bucle infinito, no desocupará nunca la CPU. Otro inconveniente es que si se cambian las especificaciones, hay quemodificar la ventana de tiempos.
190
Planificación por desalojo (preemptive)
Se trata de una estrategia no única, puede tener variantes. Las tareas son desalojadas en el momento en que haya otra tarea con mayor prioridad. Se produce por invocación de nuevas tareas, por interrupción o por temporización. Cuando entra el planificador, comprueba si la tarea que se está ejecutando tiene menos prioridad que los que están en espera. En este caso, la desaloja. Por lo tanto, una tarea puede ser desalojada antes de terminar su ejecución
• round-robin
• Con asignación de prioridades
• estática
• dinámica
Mecanismos deplanificación por
desalojo
191
Planificación por desalojo (preemptive)
El planificador tiene que activarse cada cierto tiempo. Cuando se activa, comprueba si la tarea actual debe seguir ejecutándose en función de su prioridad. En cada intervalo de tiempo puede activarse una nueva tarea con una prioridad mayor o menor que las actuales. El tiempo del planificador es tiempo no útil para las tareas.
Sea cual sea la estrategia de planificación escogida, el sistema de gestión de tareas ha de permitir el tratamiento de interrupciones. Éstas pueden ser interrupciones hardware causadas por eventos externos, o interrupciones software generadas por una tarea que se está ejecutando. Una interrupción fuerza el cambio de contexto. El proceso de tratamiento de interrupciones pasa a ejecución desbancando a la tarea que se está ejecutando. Debido a esto, es lógico pensar que en manipulador de interrupciones ha de ser breve. Una vez que ha terminado se restaurará la tarea que fue desalojada de la CPU o bien el planificador decidirá qué tarea pasa a ejecución (esto depende de cómo se haya implementado el SOTR).
192
Estructuras de prioridad
33
193
Niveles de prioridad
PRIO
RID
AD
NIVEL INTERRUPCIÓN
NIVEL DE RELOJ
NIVEL BASE
niveles de prioridad
prioridad del planificador del Nivel de Reloj
niveles de prioridad
niveles de prioridad
prioridad del planificador del Nivel Base
194
Nivel de interrupción
En este nivel de prioridad se encuentran las rutinas de atención o de servicio para las tareas o dispositivos que requieren una respuesta muy rápida (en torno a milisegundos). Una de éstas tareas es el planificador de tareas del Nivel de Reloj.
Generalmente las rutinas de atención tendrán una prioridad superior al resto de las tareas puesto que lo que se pretende es que la interrupción sea atendida rápidamente. Las interrupciones pueden tener la misma o distinta prioridad (cada interrupción tendría un nivel de prioridad diferente), dependiendo del sistema. En este último caso, una interrupción puede desalojar a otra.
La rutina de atención a la interrupción tiene que tener un código optimizado de forma que consuma el mínimo tiempo posible de CPU, ya que si una rutina de interrupción es llamada muchas veces, puede introducir un retardo importante.
195
Nivel de reloj
Tareas que tiene alguna restricción temporal. Estas tareas se pueden activar de forma periódica. Por ejemplo, muestreo de señales, de control,… Encontraríamos tareas estrictas y no estrictas. El planificador de tareas decide qué tarea debe ejecutarse en función de las prioridades. Dentro de las tareas de reloj, encontramos dos tipos:
cíclicas
de retardo.
196
Nivel de reloj
Cíclicas. Son las tareas que precisan una sincronización de elevada precisión con el mundo exterior. Su mayor requisito es que su activación periódica se ejecute con precisión. De esta forma, cada tarea cíclica tiene asociado un periodo exacto para su activación. Se puede retardar la ejecución dentro de su periodo si es bloqueada por otra más prioritaria. El planificador sólo considera que cada tarea se tiene que ejecutar dentro de cada periodo.
activación
197
Nivel de reloj
Ej. Tres tareas cíclicas A(20, 5), B(40, 5), C(80, 5):Prioridad A > B > C :
Prioridad C > A > B :
C
B
A
C
B
A
20
198
Nivel de reloj
Ej. Tres tareas cíclicas A(20, 1), B(40, 6), C(80, 25) con planificación basada en prioridad sin desalojo:
Prioridad A > B > C :
C
B
A
20
34
199
Nivel de reloj
Ej. Tres tareas cíclicas A(20, 1), B(40, 6), C(80, 25) con planificación basada en prioridad con desalojo:
Prioridad A > B > C :
C
B
A
20
200
Nivel de reloj
De retardo. La tarea tiene asociado un retardo desde que termina hasta que comienza. El planificador tiene que disponer una lista de tareas teniendo en cuenta cuando cada tarea debe activarse. Cuando una tarea pasa de ready a delayed, entonces el watch-dogdel sistema sabe cuando debe despertarse. Puede ser o no periódica ya que la activación se va a producir un intervalo después de su finalización. De esta forma, desde una ejecución a la siguiente se garantiza un tiempo durante el cual no se va a ejecutar la tarea. Los instantes de activación no tiene porque estar desplazados el mismo tiempo. Controlando este tiempo de retardo,la tarea se puede convertir en periódica.
activación
201
Nivel base
No hay ninguna restricción temporal, sólo se requiere que se ejecuten correctamente. Se activan bajo demanda en vez de a intervalos de tiempo predeterminados.
Hay varias formas de planificar tareas de nivel base. Una de ellas sería utilizar un algoritmo round-robin con rodajas de tiempo. Otros planificadores: FIFO (First In, First Out), SJF (Shortest Job First)....
La mayoría de los sistemas de tiempo real emplean estrategias de prioridad incluso para las tareas de nivel base. La prioridad puede ser fija (con el inconveniente de determinar las prioridades correctas para una operación satisfactoria), o dinámica (que permitiría la adaptación a circunstancias particulares). La asignación dinámica de prioridades puede realizarse mediante un planificador de altonivel, o bien ad-hoc desde las propias tareas.
202
Gestión de tareas
203
Gestión de tareas
Hay tareas que pueden estar o no activas, con prioridades o no, que tenemos que ejecutar con un esquema periódico o con retardo. El módulo gestor de tareas es el encargado de realizar todo esto. Sus funciones básicas son:
Conocer el estado de cada tarea
Planificar la asignación de tiempo de CPU a cada tarea
Realizar el cambio de contexto entre tareas
PLANIFICADOR(Scheduler)
DESPACHADOR(Dispatcher)
204
Estados de las tareas
No existente
Existente
Preparada
Suspendida
En ejecución
Crear
Destruir
Desactivar
Desactivar
Terminar
Iniciar
Suspender
Activar
Ejecutar
Suspender
35
205
Estados de las tareas
En ejecución (active, running): la tarea tiene el control de la CPU y del resto de los recursos que necesite. Normalmente será la tarea con mayor prioridad de las que están preparadas para ejecutarse.
Preparada (ready, runnable, on): Puede haber más de una tarea en este estado. La tarea no ha de estar esperando por ningún recurso.
Suspendida (suspended, locked out, waiting, delayed): La ejecución de las tareas que se encuentran en este estado ha sido suspendida porque
la tarea ha solicitado algún recurso que no se encuentra disponible,
la tarea está esperando alguna señal de la planta (p.ej. una entrada de un convertidor A/D),
la tarea está esperando el transcurso del tiempo. en general se puede decir que están a la espera de un evento.
206
Estados de las tareas
Existente (existent, dormant, off): El sistema operativo es consciente de la existencia de esta tarea pero aún no se le ha asignado una prioridad y no se ha convertido en ejecutable.
No existente (non-existent, terminated): El sistema operativo no es consciente de la existencia de estas tareas, a pesar de que pueden estar residiendo en la memoria del computador. Es decir, el código está en memoria esperando a que se le asigne una zona de datos.
207
Descriptor de tareas
Descriptor de tareas (TD), descriptor de procesos (PD), bloque de control de tareas (TCB)...
Identificación de la tarea (ID).
Prioridad de cada tarea(P).
Estado de la tarea
Zona de almacenamiento del entorno volátil.
Puntero a siguiente tarea en la lista de tareas
208
Planificador
El planificador (scheduler) se activa en los siguientes casos:
Interrupción del reloj de tiempo real y cualquier interrupción que indique la finalización de una petición de E/S.
Suspensión de una tarea debido a:
retardo de tarea.
finalización de tarea.
solicitud de una transferencia E/S.
En ambos casos, el planificador busca la tarea más prioritaria entre las que estén listas para ejecución.