TEMA 2 - UVajossan/doct/cystr/fich/Tema2_x2.pdf · TEMA 2 Programación de aplicaciones en tiempo real 2 ... La flexibilidad y la seguridad suelen entrar en conflicto. En los lenguajes

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

2

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.

3

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

4

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

5

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.

6

11


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


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.

7

13


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


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,…

8

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.

9

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

10

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

11

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

12

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

13

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

14

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

15

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

16

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

Comentarios

32

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

17

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


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

18

35


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

19

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

20

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

21

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

22

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

23

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;

24

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

...

25

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

26

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()

27

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.

28

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

29

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

30

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

31

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;

32

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

33

65


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


while--Ada /* C and Java*/while<expresión booleana >loop while (expresion){

<sentencias> <sentencias>end loop; }

34

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

35

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

36

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

37

73


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


Principales desventajasdifíciles de modificar”“Fundamentalista”: no permiten expresar ningún GOTO

caso de condición

valor

partecase

...

...

valor

partecase

SELECCIÓN (“switch-case”)

38

75


/*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

39

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

40

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


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!)

41

81


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


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

42

83


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

43

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

44

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

45

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

46

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)

47

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

48

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 tipo

96


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....

49

97


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


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....

50

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

51

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


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

52

103


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!

53

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

54

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.

55

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.

56

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

57

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.

58

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


59

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.


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)

60

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

61

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


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)

62

123


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

63

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)

64

127


Ejemplo de Deadlock:Cruce de dos calles• sin semáforos• única regla de preferencia:

“pasa primero el que viene por la derecha”

128


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)

65

129

P3

P1

P2

R2

R3

R1

130

P3

P1

P2

R2

R3

R1

66

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.

67

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;principio

repetiresperar 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

68

135


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


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;principio

repetiresperar 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;

69

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 ;

}

70

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

71

141


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


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.

72

143


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


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?

73

145


Solución 2:

Análisis de la soluciónLa solución no está libre de deadlocks!¿En qué caso?

Garita 1 Garita 2


1 2

Loop de persona1:

flag1 = UPflag2 == UP


flag1 = DOWN<sección no crítica>

146


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...

74

147


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


1 2

1

Bandera deprioridad

Loop de persona1:

flag1 = UP

flag2 == UP && prio ==2)


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

75

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>


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>


mutex: semaphore := 1 ;

proceso P2;principiorepetirWait(mutex) ;<sección crítica>

Signal(mutex)<sección no crítica>


CUIDADO: si un proceso olvida liberar el mutex, el recurso queda bloqueado

76

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;


Signal(recurso2) ;

Bloqueo

proceso P1;


Signal(recurso1) ;

proceso P2;


Signal(recurso1) ;Correcto

recurso1, recurso2: semaphore := 1 ;

77

153

Buffer LimitadoBuffer Limitado

Comunicación

154

Buffer Buffer IlimitadoIlimitado

Productor/consumidor

buffer

Productor Consumidor

78

155

Buffer LimitadoBuffer Limitado

Productor/consumidor

buffer

Productor Consumidor

tamaño

156

Lectores/escritores

Lector1

Lector2

Escritor1

Escritor2

2

2

2

2

Problema : inanición de los escritores

79

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

80

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) ;}

81

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

82

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

83

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

84

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.

85

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.

86

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

87

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)

88

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

89

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.

90

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


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.

91

181


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


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.

92

183


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


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.

93

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

94

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

95

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

96

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

97

193

Niveles de prioridadPR

IOR

IDA

D

NIVEL INTERRUPCIÓN

NIVEL DE RELOJ

NIVEL BASE

niveles de prioridad

prioridad del planificador del Nivel de Reloj



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.

98

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

99

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

100

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

101

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

102

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

103

205


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


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.

104

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.

Documents

TEMA 2 - UVajossan/doct/cystr/fich/Tema2_x2.pdf · TEMA 2 Programación de aplicaciones en tiempo real 2 ... La flexibilidad y la seguridad suelen entrar en conflicto. En los lenguajes