Strap Un Tes

SISTEMAS TIEMPO REAL
Tema 1, Introducción.
Cualquier actividad o sistema de proceso de información que tiene que responder a un estímulo de
entrada generado externamente en un periodo finito y especificado. En informática cuando hablamos
de tiempo real significa que la salida del programa está acotada.
La corrección de un STR no depende solo del resultado lógico sino también del tiempo en el que se
producen los resultados (La cota temporal no debe ser necesariamente corta). Failure to respond is as
bad as the wrong response
STR estrictos (hard). systems where it is absolutely imperative that responses occur within the
required deadline. Control de vuelo.
STR no estrictos (soft). systems where deadlines are important but which will still function correctly
if deadlines are occasionally missed. Sistema de adquisición de datos.
STR firme (firm real-time). Sistemas no estrictos, el tiempo límite puede no cumplirse
ocasionalmente, en los cuales no hay beneficio por entregar tarde un servicio. Una respuesta tardía
no tiene valor ninguno. Sistema video conferencia.
A single system may have hard, soft and firm real-time subsystems. In reality many systems will have
a cost function associated with missing each deadline
• Time-aware — system makes explicit reference to time (eg. open vault door at 9.00)
• Reactive — system must produce output within deadline (as measured from input)
• Time-triggered — computation is triggered by the passage of time (cada 25 ms).
• Event-trigger — computation is triggered by an external or internal event
1
Culex. Sistemas Tiempo Real (2017- 2018)
El papel del computador en sistema más grandes hace que se les conozca como sistemas embebidos.
Son sistemas de propósito específico con un limitado número de instrucciones.
Características STR.
Grande y complejo. Pero no es obligatorio.

Manipulación números reales.
Fiable y seguro. embedded systems typically control the environment in which they operate;
failure to control can result in loss of life, damage to environment or economic loss.
Control concurrencia. Concurrent control of separate system components devices operates
in parallel in the real-world; better to model this parallelism by concurrent entities in the
program
Funcionalidades de tiempo real (predictibilidad). we need to be able to predict with
confidence the worst-case response times for systems; efficiency is important but
predictability is essential. Debemos garantizar tiempo respuesta.
Interaccion interfaces hardware.
Implementación eficiente.
CICLOS DE DESARROLLO DE SISTEMAS DE TIEMPO REAL

construcción de un diseño consistente que satisfaga una especificación acreditada de los requisitos.
Metodología descendente (top-down).
Fases de diseño:
1. Especificación de requisitos. Define la funcionalidad del Sistema. Comportamiento
temporal, en caso de fallos, requisitos de fiabilidad. Se usan estrategias como la
Descomposición: partición en partes más pequeñas y la Abstracción: proporciona una
visión simplificada del Sistema obviando los detalles.
2. Diseño de la arquitectura.
3. Diseño detallado.
4. Implementación.
2
5. Prueba y validación. Pruebas exigentes.
3
Tema 2, Fiabilidad y tolerancia a fallos.
Tema 2, Prevención de fallos y Tolerancia a fallos.

Los requisitos de fiabilidad y seguridad de los STR y embebidos son muchos más estrictos que en
otros sistemas informáticos.
Four sources of faults which can result in system failure:
• Inadequate specification (durante la especificación de requisitos).

• Design errors in software (durante la fase de diseño).
• Processor failure (errores del hardware).
• Interference on the communication subsystem (errores de la red de comunicación).
Uno de los principales requisitos, por lo tanto, para cualquier lenguaje de programación de tiempo
real es que debe facilitar la construcción de sistemas altamente fiables.
The reliability (fiabilidad) of a system is a measure of the success with which it conforms to an
authoritative specification of its behaviour. When the behaviour of a system deviates from that which
is specified for it, this is called a failure (fallo). Failures result from unexpected problems internal
to the system that eventually manifest themselves in the system's external behaviour. These problems
are called errors and their mechanical or algorithmic cause are termed faults (defectos).
Systems are composed of components which are themselves systems so: > failure -> fault -> error
-> failure -> fault
5.1 Fiabilidad, fallo y defectos.

Transient fault (transitorios) starts at a particular time, remains in the system for some period
and then disappears; e.g. hardware components which have an adverse reaction to
radioactivity. Many faults in communication systems are transient
Permanent faults remain in the system until they are repaired; e.g., a broken wire or a
software design error
Intermittent faults are transient faults that occur from time to time; e.g. a hardware
component that is heat sensitive, it works for a time, stops working, cools down and then starts
to work again
SOFTWARE FAULTS
Called Bugs; Heisenbugs (a heisenbug is a software bug that seems to disappear or alter its behavior
when one attempts to study it): only active under rare conditions. Bohrbugs (A bohrbug, by
opposition, is a "good, solid bug. they do not change their behavior and are relatively easily detected):
reproducible identifiable.
Software doesn’t deteriorate with age: it is either correct or incorrect but faults can remain dormant
for long periods
Usually related to resource usage; e.g. memory leaks
4
5.2 Modos de fallo.
Both approaches attempt to produces systems which have well-defined failure modes
Fault prevention, attempts to eliminate any possibility of faults creeping into a system before it goes
operational.
Fault avoidance(evitacion). Fault avoidance attempts to limit the introduction of faults
during system construction; e.g. componentes hardware de calidad.
Fault removal(eliminación): procedures for finding and removing the causes of errors;
Fault tolerance, enables a system to continue functioning even in the presence of faults.
System testing can never be exhaustive and remove all potential faults. A test can only be used to
show the presence of faults, not their absence. It is sometimes impossible to test under realistic
conditions. Most tests are done with the system in simulation mode and it is difficult to guarantee that
the simulation is accurate. Requirements errors during the system's development may not manifest
themselves until the system goes operational.
Design errors (hardware and software) will exist. In spite of all the testing and verification techniques,
hardware components will fail; the fault prevention approach will therefore be unsuccessful when:
either the frequency or duration of repair times are unacceptable, or the system is inaccessible for
maintenance and repair activities (An extreme example of the latter is the crewless spacecraft
Voyager, currently at 11 billion miles from the sun!).
SO, THE ALTERNATIVE IS FAULT TOLERANCE.
5
• Full Fault Tolerance: the system continues to operate in the presence of faults, just for a limited
period, with no significant loss of functionality or performance.
• Graceful Degradation (Degradacion controlada. Fail soft): the system continues to operate in the
presence of errors, accepting a partial degradation of functionality or performance during recovery or
repair.
• Fail Safe: the system maintains its integrity while accepting a temporary halt in its operation.
All fault-tolerant techniques rely on extra elements introduced into the system to detect & recover
from faults. The aim is minimising redundancy while maximising reliability.
Warning: the added components inevitably increase the complexity of the overall system. This itself
can lead to less reliable systems; e.g. first launch of the space shuttle (El lanzamiento fue abortado
debido a un problema de sincronización de los computadores replicados).
It is advisable to separate out the fault-tolerant components from the rest of the system.
HARDWARE FAULT TOLERANCE
Two types: static (or masking) and dynamic redundancy.
Static: redundant components are used inside a system to hide the effects of faults; e.g.
Triple Modular Redundancy (TMR).
TripleModularRedundancy — 3 identical subcomponents and majority voting
circuits; the outputs are compared and if one differs from the other two, that output is
masked out. It assumes the fault is not common (such as a design error) but is either
transient or due to component deterioration.
To mask faults from more than one component requires NmodularRedundancy.
Dynamic: redundancy supplied inside a component which indicates that the output is in
error; provides an error detection facility; recovery must be provided by another
component; e.g. communications checksums (códigos de redundancia cíclica) and
memory parity bite
5.4 Software fault tolerance (N-Versiones).

N-Version Programming (estática). Se la denomina frecuentemente ‘Design diversity’.
The independent generation of N (N > 2) functionally equivalent programs from the same initial
specification. No interactions between groups. The programs execute concurrently with the
same inputs and their results are compared by a driver process.
6
The results (VOTES) should be identical, if different the consensus result, assuming there is one,
is taken to be correct.
En la programación de N-versiones resulta crucial la eficiencia y la facilidad con la que el programa
director compara los votos y decide cuándo existe un desacuerdo. Desafortunadamente, no todos los
resultados son de una naturaleza exacta. En concreto, en aquellos votos que requieren cálculos con
números reales, será difícil que diferentes versiones produzcan exactamente el mismo resultado.
Las técnicas utilizadas en la comparación de estos tipos de resultados se denominan votación inexacta.
Otra dificultad asociada a la aritmética de precisión finita es el llamado problema de la comparación
consistente. Este problema se da cuando una aplicación tiene que realizar una comparación basada
en un valor finito dado en la especificación ya que al acercarnos al valor umbral una pequeña
variación puede modificar el resultado de la comparación determinando entonces el curso de la
acción.
N-version programing depens on: initial specification (the majority of software faults comes from
inadequate specification), independence of design (diferentes programadores y lenguajes) and
adequate budget.
ALTERNATIVE TO STATIC REDUNDANCY IS DINAMIC REDUNDANCY: It has four phases.
• Error detection (en el entorno o en la propia aplicación).
Hardware; e.g. illegal instruction, desbordamiento.
O.S/RTS; e.g. null pointer, valor fuera de rango.
Coding checks (redundant data, e.g. checksums).
Timing checks (e.g. temporizador guardián como el pedal del hombre muerto en los trenes).
Reasonableness checks (e.g. assertion).
Structural checks (e.g. redundant pointers in linked list).
• Damage confinement and assessment; To what extent has the system been corrupted? (the delay
between a fault occurring and the detection of the error means erroneous information could have
spread throughout the system).
7
Damage confinement is concerned with structuring the system to minimise the damage
caused by a faulty component (also known as firewalling). Modular decomposition
provides static damage confinement; allows data to flow through well-define pathways.
Atomic actions provide dynamic damage confinement; they are used to move the system
from one consistent state to another.
• Error recovery; Techniques should aim to transform the corrupted system into a state from which it
can continue its normal operation.
Forward error recovery continues from an erroneous state by making selective corrections
to the system state; e.g. Redundant pointers in data structures and the use of self-
correcting codes such as Hamming Codes.
Backward error recovery, restoring the system to a previous safe state (checkpoint) and
executing an alternative section of the program. Advantage: the erroneous state is cleared
and it does not rely on finding the location or cause of the fault. Disadvantage: it cannot
undo errors in the environment!
La restauración no resulta tan simple como se ha descrito cuando se trata de procesos concurrentes
que interacciona entre sí.
• Fault treatment and continued service - an error is a symptom of a fault; although the damage is
repaired, the fault may still exist. So, the error may happen again; the final phase of Fault Treatment
is to eradicate the fault from the system.
5.6 La estrategia de los bloques de recuperación en la tolerancia fallos software.

Los bloques de recuperación son bloques en el sentido normal de los lenguajes de programación,
excepto que en la entrada del bloque se encuentra un punto de recuperación automático, y en la salida
un test de aceptación. The acceptance test provides the error detection mechanism; it is crucial to the
efficacy(overload) of the RB scheme. Por eso se habla de resultados aceptables en lugar de exactos.
8
RECOVERY BLOCK SYNTAX
5.7 N-Version vs recovery blocks.

• Static (NV) versus dynamic redundancy (RB).
• Design overheads, both require alternative algorithms, NV requires driver, RB requires acceptance
test.
• Runtime overheads, NV requires N * resources, RB requires establishing recovery points
• Diversity of design, both susceptible to errors in requirements
• Error detection, vote comparison (NV) versus acceptance test(RB)
• Atomicity, NV votes before it outputs to the environment, RB must be structure to only output
following the passing of an acceptance test.
5.8 Redundancia dinámica y excepciones.

Exception handling is a forward error recovery mechanism, as there is no roll back to a previous state;
instead control is passed to the handler so that recovery procedures can be initiated
9
Exception handling can be used to:
Cope with abnormal conditions arising in the environment.
Enable program design faults to be tolerated.
Provide a general-purpose error-detection and recovery facility.
5.10 Seguridad, fiabilidad y confiabilidad (SAFETY AND RELIABILITY)

Aunque la fiabilidad y la seguridad suelen considerarse como sinónimos, existe una diferencia en
el énfasis. La fiabilidad ha sido definida como la medida del éxito con el cual un sistema se ajusta a
la especificación de su comportamiento. To ensure the safety requirements of an embedded system,
system safety analysis must be performed throughout all stages of its life cycle development.
Fiabilidad del software: probabilidad de que un programa dado funcione correctamente en un entorno
concreto durante un determinado periodo de tiempo.
Reliability: a measure of the success with which a system conforms to some authoritative
specification of its behaviour.
Confiabilidad (dependiability): propiedad del sistema que permite calificar, justificadamente, como
fiable al servicio que proporciona.
10
Diapos resumen 1 y 2 del capítulo 2
Tema 3, Excepciones y manejo de expceciones.

Una excepción es; la indicación de un problema → está asociada con una condición de error → debe
ser manejada para continuar con la ejecución. Permite montar sistemas tolerantes a fallos.
Requisitos generales mecanismos manejo excepciones;
El mecanismo debe ser fácil de comprender y utilizar.
El código de manejo de excepciones no debiera complicar el flujo del programa en ausencia
de errores.
El mecanismo deberá diseñarse de modo que sólo suponga una sobrecarga en la ejecución
cuando se maneja una excepción. There is no such thing as a free lunch.
El mecanismo deberá permitir un tratamiento uniforme de las excepciones con
independencia de si son detectadas por el entorno o por el programa
El mecanismo de excepciones deberá permitir la programación de acciones de recuperación.
11
Una excepción se puede detectar desde;
• El entorno (ArrayIndexOutOfBoundsException, ArithmeticException).
• La aplicación (Error en comprobación de aserción).
Pueden ser; Síncronas, se producen inmediatamente como resultado de un código que intenta una
operación inapropiada o Asíncronas, aparecen algún tiempo después de la operación que provoca el
error. Las excepciones asíncronas suelen recibir el nombre de señales y se suelen emplear en
programación concurrente.
Según el lenguaje de programación se pueden declarar de forma diversa. En Ada se definen como
constantes, que deben ser declaradas explícitamente. En Java/C++ son objetos de un tipo particular y
que pueden o no haber sido declarados explícitamente
6.2 Manejo de excepciones moderno. Dominio y propagación de una Excepción.

Dentro de un programa, puede haber diferentes manejadores para una excepción en particular
Cada manejador lleva asociado un dominio que especifica la zona del código en la que será
activado si se lanza la excepción.
La precisión con la que se puede definir un dominio afectara a la detección de la fuente del
error.
En un lenguaje estructurado en bloques, como Ada, el dominio es normalmente el bloque
declare
subtype Temperature is Integer range 0 . . 100;
begin
−− read temperature sensor and calculate its value
exception
−− handler for Constraint Error
end ;
En Java no todos los bloques pueden tener manejador de excepciones, hay que definir explícitamente
el bloque en el que se podrá lanzar una excepción.
try {
// statements which may raise exceptions
} catch ( ExceptionType e) {
// handler for e
12
¿Qué ocurre si no hay manejador?
Considerarlo un error del programador y notificarlo en tiempo de compilación. a veces
una excepción solo puede ser manejada en el contexto en que el procedimiento fue
invocado, eg. excepción como resultado de una aserción que involucra a los parámetros.
Propagar la excepción, una excepción no atrapada provocara la terminación de un
programa secuencial. Si hay más de un proceso, normalmente se aborta el proceso en el que
aparece la excepción no manejada (no está claro si la excepción debe propagarse al proceso
padre).
¿Qué ocurre con el flujo de programa?, continuar o no con la ejecución

Modelo de continuación/reanudación. El problema de esta aproximación es la
dificultad a la hora de reparar errores generados por el entorno de ejecución. Por ejemplo, un
desbordamiento aritmético en medio de una secuencia compleja de expresiones podría
ocasionar que varios de los registros contuvieran evaluaciones parciales. Al llamar al
manejador, es probable que se sobrescriban dichos registros. Cuando realmente se nota la
ventaja del modelo de reanudación es cuando la excepción ha sido generada asíncronamente,
y por tanto tiene poco que ver con la ejecución actual del proceso.
El modelo de reanudación se entiende mucho mejor si contemplarnos el manejador como un
procedimiento que se invoca implícitamente al generar la excepción.
Con el modelo de continuación/reanudación, el invocador de la excepción se reanuda la
sentencia posterior a la que provocó la excepción
Modelo de terminación. En el modelo de terminación, tras llamar al manejador para que
atienda cierta excepción, el control no retorna al punto donde apareció la excepción, sino que
se finaliza el bloque o procedimiento que contiene el manejador y se pasa el control al bloque
o al procedimiento de llamada. De este modo, un procedimiento invocado puede terminar en
varias condiciones de terminación, siendo una de ellas la condición normal, y las restantes
condiciones de excepción.
Con el modelo de terminación, el bloque o procedimiento que contiene el manejador es
terminado, y se pasa el control al bloque procedimiento que lo llamó. El control no se devuelve
al invocador.
Modelo híbrido. El manejador decide si el error es recuperable, Si es así, el manejador puede
devolver un valor, y la semántica sería la misma que en el modelo de reanudación.
13
6. 3 Manejo de Excepciones (para procesos secuenciales).
ADA: declaración explicita de excepciones, modelo de terminación, propagación de
excepciones y un paso de parámetros limitado (solo permite cadenas de texto). Se declara con
la palabra clave exception ó con el paquete predefinido Ada.Exceptions, que define un tipo
privado Exception Id. Todas las excepciones declaradas con exception tienen asociado un
Exception Id, que se puede acceder con el atributo predefinido Identity.
Una excepción generada en un manejador de excepción no puede ser manejada por ése u otros
manejadores del mismo bloque (o procedimiento). En lugar de esto, se termina el bloque y se
busca un manejador en el bloque exterior o en el punto de llamada de un subprograma
Si no hay manejador en el bloque, la excepción se propaga; para un bloque, se genera en el

bloque que lo contiene, o en el subprograma; para un subprograma, en el punto de invocación
al mismo; para una sentencia accept tanto en el invocador como en la tarea que se invoca.
14
JAVA: Java soporta un modelo de terminación, está integrado en el modelo de programación
OO. Todas las excepciones en Java son subclases de java.lang.Throwable. El lenguaje define
otras como por ejemplo Error, Exception y RuntimeException.
Cada método debe definir una lista de excepciones throwable que puede lanzar. Deben ser
subclases de Exception. El método puede lanzar estas excepciones y las tipo unchecked. Si
un método intenta arrojar una excepción que no se ha declarado, aparece un error de
compilación.
Un bloque catch(Exception E) se puede considerar equivalente a la sentencia when others de
Ada.
Podemos usar finally como parte de una sentencia try. El código se ejecuta, en cualquier caso,
exista excepción o no.
public class ErrorRestriccionEntero extends Exception
……………
public void ponValor(int V) throws ErrorRestriccionEntero, OtroError
{
…………;
}
…………….
void comprueba (int valor) throws ErrorRestriccionEntero
{
if valor > 100 || valor < 0 ) {
throw new ErrorRestriccionEntero(0, 100, valor);
};
}
Aquí throw new ErrorRestriccionEntero (0, 100, valor) crea y lanza un objeto del tipo
(ErrorRestriccionEntero) con los valores adecuados de sus variables de instancia.
Un manejador con un parámetro de tipo T, atrapara una excepción que es de tipo E, si T y E

son del mismo tipo o si E es una subclase de T.
15
En el lenguaje C no hay definido mecanismo alguno de manejo de excepciones.
Para implementar en C un modelo de terminación, es preciso guardar el estatus de los registros
del programa y demás información a la entrada del dominio de una excepción, para
restaurarlos si acaece una excepción. Tradicionalmente se ha asociado C con UNIX, de modo
que para este fin se pueden utilizar las primitivas de POSIX setjmp y longjmp. La rutina setjmp
almacena el estatus del programa y devuelve un 0; la rutina longjmp restaura el estatus del
programa y provoca que el programa abandone su ejecución actual reiniciándose desde la
posición donde se invocó setjmp.
16
C++ es similar a Java, excepto en que no requiere una declaración explícita de excepciones.
Más bien, puede lanzarse como excepción cualquier instancia de una clase. No existen
excepciones predefinidas.
Tema 4, Programación concurrente.

Virtualmente, los sistemas de tiempo real son inherentemente concurrentes. La implementación real
de un conjunto de procesos tiene lugar de tres formas. Los procesos pueden:
Multiplexar sus ejecuciones sobre un único procesador (multiprogramación).
Multiplexar sus ejecuciones en un sistema multiprocesador con memoria compartida
(multiprocesamiento)
Multiplexar sus ejecuciones en diversos procesadores que no comparten memoria (sistemas
distribuidos).
La programación concurrente debe proporcionar los siguientes servicios básicos:
La expresión de ejecución concurrente mediante la noción de proceso. Expresar el paralelismo
potencial.
La sincronización de procesos (actividades concurrentes). Resolver problemas sincronización
y comunicación entre procesos.
Primitivas de soporte a comunicación entre procesos actividades concurrentes).
Al considerar la interacción entre procesos, es útil distinguir entre tres tipos de comportamiento:
Independiente, cooperativo y competitivo.
Las variaciones en los modelos de concurrencia (noción de tarea) se deben a los siguientes elementos:
Estructura: Estática / Dinámica
Nivel: Anidado / Plano
Granularidad.
Inicialización (paso parámetros / IPC)
Finalización.
Un programa secuencial contiene un solo camino para una ejecución mientras que un programa
concurrente es una colección de procesos secuenciales autónomos en paralelo que tienen diferentes
caminos de ejecución.
Un proceso, tiene su propio hilo de control, se ejecuta en su propia máquina virtual. Los SO
proporcionan mecanismos para crearlos
Una hebra o tarea, tiene acceso no restringido a la memoria compartida, es conocido y
gestionado por el SO
17
Una fibra (In computer science, a fiber is a particularly lightweight thread of execution), es
invisible al SO. Se implementa a nivel de aplicación.
Un objeto (paradigma O.O.) es Activo, ejecuta acciones espontaneas | Reactivo, es invocado por otros
objetos
Cuatro tipos de entidades:
Pasiva, reactivo sin restricciones de sincronización. Necesita un hilo de control externo.
Recurso Protegido, reactivo con restricciones de sincronización.
Activa, con una hebra interna explícita o implícita.
Servidor, activo con restricciones de sincronización compartido por varios hilos.
Mecanismos básicos para representar la ejecución concurrente
fork/join. La instrucción fork (bifurca) especifica que una rutina deberá ejecutarse
concurrentemente con el invocador. La instrucción join (reúne) hace que el invocador espere
a la finalización de la rutina invocada.
Cobegin. es una forma estructurada de denotar la ejecución concurrente de un conjunto de

instrucciones
Declaración explicita de tareas (estándar a día de hoy). La
estructura del programa es más clara y fácil de entender. No
define cuando se ejecutará.
18
Concurrencia en ADA
La unidad de concurrencia es la tarea (task). Las tareas deben ser declaradas explícitamente. Las
tareas se crean implícitamente en el momento en que se entra en su ámbito de visibilidad.
Una tarea puede terminar de varias formas; Si completa la ejecución de su código, Si ejecuta
terminate, si es abortada (todas las dependientes también).
Concurrencia en Java.
Creación de hilos mediante la clase java.lang.Thread. También se define una interfaz estándar
runnable (Cualquier clase que desee expresar una ejecución concurrente debe implementar esta
interfaz y proporcionar el método run)
Java permite la creación dinámica de tareas, permite paso

de parámetros (a través del constructor),
La creación de grupos: no hay concepto de guardián o maestro y es
responsabilidad del recolector de basura liberar los objetos inaccesibles.
El programa principal termina cuando todos sus hilos de usuario
han finalizado.
Un hilo puede esperar a que otro finalice (join).
19
El método isAlive permite determinar si un hilo ha terminado su ejecución. Si el código del hilo es
una subclase de la clase Thread,se puede definir un identificador a un hilo de la siguiente forma:
Thread hiloID;
La finalización de hilos se produce al finalizar la ejecución del método run, mediante el método stop
o mediante el método destroy.
Los hilos pueden ser de dos tipos: usuario (user) | servicios (daemon). Los hilos de tipo daemon
proporcionan servicios y normalmente no terminan nunca, finalizan cuando no quedan hilos de
usuario.
El método setDaemon debe ser invocado antes de iniciar el hilo.
Excepciones hilos en java.
llegalThreadStateException
El método start se ha invocado después de iniciar el hilo
El método setDaemon se ha invocado después de iniciar el hilo
SecurityException
NullPointerException
InterruptException
El hilo que invoco join es despertado porque ha sido interrumpido, y no por la finalización del
hilo dependiente
Ejecución concurrente en C/Real-time POSIX
Proporciona dos mecanismos: fork y pthreads. fork crea un nuevo proceso. pthreads es una extensión
a POSIX que permite crear hilos.
Los hilos se ejecutan en el mismo espacio de direcciones
P y T son activos; S es un recurso. Tenemos tres posibles arquitecturas:

20
Programa secuencial simple.
Ignora la concurrencia de T, P, S. No requiere soporte del SO.
Desventajas: Las medidas de temperatura y presión se tienen que obtener con la misma
frecuencia (al usar un bucle). Puede ser necesario dividir e intercalar los procedimientos de
conversión para tener un balance de carga adecuado. Mientras se lee la temperatura no se
presta atención a la presión, y viceversa. Un fallo en cualquier parte afecta a todo el programa
Programa secuencial simple (usando primitivas SO).
Requiere soporte del SO. Para sistemas complejos el código puede ser poco comprensible.
Programa concurrente.
No requiere soporte del SO
Necesita soporte de tiempo de ejecución
Ventajas: Las tareas se ejecutan concurrentemente. Mientras una tarea está suspendida, la otra
puede estar ejecutándose. Si las dos están suspendidas, no hay ejecución (no hay espera
activa). La lógica de la aplicación se refleja en el código. El paralelismo inherente se
representa en la ejecución de tareas.
Desventajas: Ambas tareas envían datos a la pantalla. Solo puede ser accedido por una tarea
al mismo tiempo, se requiere, entonces, una tercera entidad para controlar el acceso a la
pantalla. Debe asegurar exclusión mutua en el acceso.
Concurrencia en el lenguaje o en el S.O.
Argumentos a favor de la concurrencia en el lenguaje; Programas más legibles y mantenibles, Mas
portable, Un sistema empotrado podría no tener S.O. Optimizaciones del compilador
Argumentos en contra; Mas fácil, programas de diferentes lenguajes, Difícil implementación de un
lenguaje concurrente de forma eficiente sobre el modelo del S.O, Estandarización de S.O.
Resumen
Los dominios de aplicación son inherentemente paralelos. Inclusión de la noción de tarea incrementa
el poder expresivo y la facilidad de uso del lenguaje. Sin concurrencia, el software debe construirse
con un solo bucle de control. La estructura del bucle no puede reflejar la estructura del sistema.
Programación concurrente tiene costes asociados. Es necesario tener un sistema de soporte en tiempo
real para gestionar tareas. El comportamiento de una tarea se puede describir por sus estados (no
existente, creado, inicializado, ejecutable, esperando terminación dependiente/hijo, terminada).
Ada proporciona un modelo dinámico con soporte para tareas anidadas y diferentes opciones de
terminación. El padre de una tarea debe esperar a que la inicialización del hijo termina. El maestro de
una tarea debe esperar a que sus dependientes finalicen. El maestro puede ser una tarea o un bloque.
Java proporciona un modelo dinámico con soporte para tareas anidadas
POSIX permite crear dinámicamente, con una estructura plana.
21
La inclusión de tareas en un lenguaje de tiempo real incrementa el poder expresivo y facilidad de uso
del lenguaje. Sin concurrencia, el software debe construirse como un único bucle de control. La
estructura del bucle no puede reflejar la distinción lógica entre componentes del sistema
Tema 5, Comunicación y sincronización basada en variables

compartidas.
Las mayores dificultades asociadas con la programación concurrente surgen de la interacción de
procesos. Casi nunca los procesos son independientes entre sí. El comportamiento correcto de un
programa concurrente depende estrechamente de la sincronización y la comunicación entre procesos.
La comunicación (paso de información entre tareas) requiere sincronización , mientras que la
sincronización (satisfacción de requisitos en el tiempo de ejecución) puede considerarse
comunicación sin contenido.
La comunicación entre procesos se basa normalmente o en el uso de:
variables compartidas. objetos a los que puede acceder más de un proceso, son fáciles de
implementar si hay memoria compartida y son ideales para sistemas multiprocesador con
memoria compartida. Son inseguras si no hay procedimientos de exclusión mutua.
Paso de mensajes. intercambio explícito de datos entre dos procesos mediante un mensaje
que pasa de un proceso a otro. Son adecuados para Sistemas Distribuidos.
La sincronización condicionada, o de condición, es otro requisito significativo, y es necesaria
cuando un proceso desea realizar una operación que sólo puede ser realizada adecuadamente si otro
proceso ha realizado alguna acción o está en algún estado definido (buffers, productor-consumidor).
Una forma de implementar la sincronización es comprobar las variables compartidas que actúan como
indicadores en un conjunto de procesos (Esto se conoce como espera activa o spinning, y a los
indicadores como spinlocks). Esta aproximación sirve razonablemente bien para implementar
sincronización de condición, pero no hay un método simple para la exclusión mutua.
Dificultades en la espera activa; Los protocolos son difíciles de entender, programar y demostrar su
corrección, Las pruebas no examinan todas las posibles secuencias de ejecución, es posible que
existan secuencias que lleven a una violación de la exclusión mutua o bien a un bloqueo activo
(livelock – condición de error donde una o más tareas no puede progresar, pero hacen uso del
procesador. Por el contrario, un deadlock las tareas no puede progresar, pero están suspendidas y no
hacen uso del procesador), los bucles de espera activa son ineficientes y por último, una tarea que
hace un mal uso de las variables compartidas puede corromper todo el sistema.
22
8.3 Suspender y reanudar.
Para evitar ineficiencia de la espera activa se puede Suspender la tarea cuando la condición no se
cumple. Esto evita la ineficiencia de los bucles de espera, pero pueden encontrase problemas por
condiciones de carrera. Hay varias soluciones para resolver este problema de condición de carrera,
todas ellas ofrecen cierta forma de operación de suspensión en dos etapas. Esencialmente, P1 debe
anunciar que planea suspenderse próximamente. Cualquier operación de reanudación que encuentre
con que P1 no está suspendido verá aplazado su efecto, y cuando Pl se suspenda, será reiniciado
inmediatamente.
Java proporciona suspend y resume y Ada proporciona el concepto de objeto de suspensión.
8.4 Semáforos.
Mecanismo simple para programar la exclusión mutua y sincronización de condición. Simplifican los
protocolos de sincronización y eliminan necesidad de espera activa.
Se basan en el uso de una variable entera no negativa, solo modificada en la inicialización mediante
wait(S) o signal(S).
wait(S): si S>0, decrementa S. Si no, pospone la tarea.
signal(S): incrementa S.
Si wait(s) pospone la tarea, el RTSS eliminará la tarea de la cola de ejecución y la insertará en una
cola de espera, Cuando se señalice el semáforo signal(s), una de las tareas en espera se hace ejecutable
(FIFO).
El semáforo es una primitiva de sincronización de bajo nivel simple y elegante, No obstante, un
programa construido solo con semáforos es propenso a errores.
8.5 Regiones criticas condicionales.

Las regiones condicionales crıticas intentan resolver los problemas asociados con los semáforos. Una
región critica (secuencia de instrucciones que deben ejecutarse de forma indivisible) es una sección
de código que tiene garantizada la ejecución en exclusión mutua.
Las variables que deben ser protegidas se agrupan en regiones a las que se asigna un nombre. La
sincronización de condición se proporciona mediante guardas.
23
8.6 Monitores.
El problema principal con las regiones condicionales es que pueden estar dispersas a lo largo de todo
el programa. Los monitores están pensados para atenuar este problema proporcionando regiones de
control más estructuradas. Las regiones críticas consideradas se escriben como procedimientos, y
están encapsuladas en un único módulo, llamado monitor. Como módulo, se ocultan todas las
variables que deben ser accedidas bajo la exclusión mutua. Adicionalmente, todas las llamadas a
procedimientos del módulo tienen garantizada su ejecución con exclusión mutua.
Con la definición dada, wait y signal son incompletas ya que permiten dos tareas en ejecución dentro
del monitor. Esto ocurre cuando una tarea señaliza a otra que estaba bloqueada. Soluciones:
Signal se permite solo como la última acción.
Una operacion signal provoca la ejecución de una sentencia return.
Una señal que libera a otra tarea se bloquea a si misma.
La tarea liberada debe competir por el acceso al monitor cuando la que ha señalizado
termina.
Las críticas a los monitores se centran en el uso de las variables de condición. Sustituyendo esta
aproximación a la sincronización por el uso de guardas. se obtiene una abstracción más estructurada.
Esta forma de monitor se denominará objeto protegido (Ada).
Métodos sincronizados en Java.
En muchos aspectos, los objetos protegidos de Ada son como objetos en un lenguaje de programación
orientado a objetos basado en clases. Java, que tiene la concurrencia totalmente integrada,
proporciona un mecanismo en el que los monitores pueden ser implementados en el contexto de clases
y objetos.
El modificador del método synchronized y la sincronización de bloque.
Cuando un método se etiqueta con el modificador synchronized, el acceso al método sólo se puede
realizar una vez que se ha obtenido el bloqueo asociado con el objeto. Así pues, para obtener
exclusión mutua total, cada método tiene que ser etiquetado como synchronized.
24
Un bloque puede marcarse como synchronized. Recibe como parámetro el objeto sobre el que se
obtiene el bloqueo. Esta práctica puede reducir la ventajas de la encapsulación.
Aunque los métodos o bloqueos sincronizados permiten el acceso mutuamente excluyente a los datos
en un objeto, esto no es adecuado si el dato es estático. Los datos estáticos son datos compartidos
entre todos los objetos creados a partir de una clase. Para obtener acceso mutuamente excluyente,
estos datos requieren que todos los objetos estén bloqueados.
La sincronización condicional requiere soporte adicional. Tenemos los métodos de la clase Object.
wait provoca la suspensión de la tarea y libera bloqueos asociados al objeto.
notify despierta un hilo en espera.
notifyAll despierta todos los hilos en espera.
Si se invoca un método sin bloqueo, se genera una excepción de tipo IllegalMonitorStateException.
Tanto notify como notifyAll no liberan el bloqueo, por lo que los hilos que se despiertan deben
competir por el acceso. Una diferencia importante con otros lenguajes es que no hay variables de
condición explicitas.
A modo de resumen, las diferentes primitivas de sincronizacion son:
Los semáforos.
Regiones criticas condicionales.
Monitores.
25
Mutex (Semáforos binarios).
Objetos protegidos.
Métodos sincronizados.
Concurrencia en Java la proporciona una abstracción de monitor mediante los métodos y sentencias
synchronized. Concurrencia en Ada objetos protegidos proporcionan exclusión mutua y
sincronización de alto nivel con barreras (expresiones booleanas).
Tema 6, Comunicación y sincronización basada en mensajes.

Las variaciones en el modelo de sincronización dependen de la semántica asociada al envío.
El emisor continua inmediatamente, se reciba o no el mensaje.
El emisor continua cuando se ha recibido el mensaje.
El emisor continua cuando ha recibido una respuesta del receptor.

Se pueden usar semánticas asíncronas para obtener comunicaciones síncronas/invocación remota
pero tienen los siguientes inconvenientes: Se necesitan potencialmente infinitos búferes , la
26
comunicación asíncrona está anticuada, los envíos se programan para recibir un ack, el modelo
asíncrono necesita más comunicaciones, Programas más complejos.
9.2 Nombrado de procesos y estructura de mensajes.

El nombrado de procesos implica dos subtemas: dirección frente a indirección, y simetría.
En un esquema de nombrado directo, el emisor de un mensaje nombra explícitamente al receptor.
envía <mensaje> a <nombre-proceso>
Con un esquema de nombrado indirecto, el emisor nombra a alguna entidad intermedia (conocida
como canal, buzón, enlace o tubería).
envía <mensaje> a <buzón>
Un sistema es simétrico si tanto el emisor como el receptor se pueden nombrar entre si.
envía <mensaje> a <nombre-proceso>
espera <mensaje> de <nombre-proceso>
envía <mensaje> a <buzón>
espera <mensaje> de <buzón>
Y es asimétrico si el receptor acepta mensajes de cualquier proceso. El nombrado asimétrico se adapta
al paradigma cliente-servidor, donde los procesos servidor proporcionan servicios como respuesta a
los mensajes de cualquier número de procesos
espera <mensaje>
Si el nombrado es asimétrico, la entidad intermedia debe disponer de una estructura que pueda
permitir el nombrado indirecto:
muchos-a-uno (varios escribe-uno lee, paradigma cliente servidor) .
muchos-a-muchos.
uno-a-uno (une escribe-uno lee).
uno-a-muchos (útil cuando un proceso desea enviar una solicitud a un grupo de procesos
trabajadores y no le importa qué proceso responde a la solicitud).
27
Estructura del mensaje.
De forma ideal, un lenguaje debiera permitir que cualquier objeto de datos de cualquier tipo definido
(predefinido o del usuario) sea transmitido en un mensaje.
ADA utiliza Invocación remota asimétrica directa basada en el modelo de interacción cliente/servidor.
Permite una estructura flexible de los mensajes y una definición de mensajes de forma compatible
con la definición de procedimientos. Requiere la definición de entries y la aceptación de llamadas
desde otras tareas. Una cita ocurre cuando una tarea invoca una entrada (entry) de otra tarea. La espera
selectiva permite a una tarea esperar a recibir más de un mensaje.
Ambas tareas deben estar preparadas para la comunicación. Si una está preparada y la otra no, la que
está preparada esperará a la otra. Cuando estén las dos listas, los parámetros de la tarea cliente serán
pasados a la tarea servidor. El servidor ejecuta el código de dentro del accept. Al final del accept, los
resultados son devueltos al cliente y ambas tareas continúan independientemente.
Sistemas distribuidos
Son necesarios procesos de comunicación entre procesadores heterogéneos cuyos mecanismos
permitan que la traducción de datos y partición en paquetes sea transparente a los procesos, los
mensajes recibidos se encuentren en buenas condiciones y sean del tipo esperado y que no haya
restricciones para la comunicación en relación a los tipos de datos.
28
Estándares de comunicación en SiDi: Application programming interface, remote procedure call y,
finalmente, Objetos distribuidos.
Las llamadas a procedimientos remotos son una extensión que permite a un proceso ejecutar código
que reside en más de una máquina.
En el modelo de objetos distribuidos, se busca extender el concepto RPC para su uso en un modelo
de computación distribuida orientado a objetos.
Ada permite la reserva estática de objetos, la identificación de objetos remotos Ada y la ejecución
distribuida de métodos remotos (Remote_Call_Interface).
Java permite enviar el código de un objeto y la creación remota de instancias, así como la invocación
remota y distribuida (Java.rmi).
Tema 7, acciones atómicas, procesos concurrentes y fiabilidad.

Chapter 2 considered how reliable software could be produced in the presence of a variety of errors.
Modular decomposition and atomic actions were identified as two techniques essential for damage
confinement and assessment. Also, the notions of forward and backward error recovery were
introduced as approaches to dynamic error recovery. it was shown that where tasks communicate and
synchronize their activities, backward error recovery may lead to the domino effect. In Chapter 3,
exception handling was discussed as a mechanism for providing both forward and backward error
recovery in sequential tasks. Chapters 4, 5 and 6 then considered the facilities provided by operating
systems and real-time languages for concurrent programming. This chapter brings together exception
handling and concurrency in order to show how tasks can interact reliably in the presence of other
tasks and in the presence of faults. The notion of an atomic action is explored in more detail and the
concept of asynchronous notification is introduced.
In Chapter 4, the interaction of tasks was described in terms of three types of behaviour:
Independent: Sin comunicación ni sincronización, recuperación de errores aislada.
Cooperation: Comunicación y sincronización de forma regular, recuperación de errores de
forma conjunta.
Competition: Comunicación y sincronización para acceder a recursos, recuperación de
errores relacionada con el uso de recursos.
29
Independent tasks do not communicate or synchronize with each other. Consequently, if an error
occurs within one task, then recovery procedures can be initiated by that task in isolation from the
rest of the system. Recovery blocks and exception handling can be used as described in Chapters 2
and 3. Cooperating tasks, by comparison, regularly communicate and synchronize their activities in
order to perform some common operation. if any error condition occurs, it is necessary for all tasks
involved to perform error recovery. The programming of such error recovery is the topic of this
chapter. Competing tasks communicate and synchronize in order to obtain resources; they are,
however, essentially, independent. An error in one should have no effect on the others. Unfortunately,
this is not always the case, particularly if the error occurred while a task was in the act of being
allocated a resource. Reliable resource allocation is considered in Chapter 8. Where cooperating tasks
communicate and synchronize through shared resources, recovery may involve the resource itself.
This aspect of resource allocation will also be considered in Chapter 8.
La interacción entre dos tareas no siempre implica una sola comunicación, en ocasiones será necesaria
la interacción de dos o más tareas, por lo tanto, las tareas involucradas deben ver un estado del sistema
coherente. La actividad conjunta de un grupo de tareas debe ser vista como una acción atómica o
indivisible.
10.1 Acciones atómicas.

Una acción es atómica si los procesos que la realizan no saben de la existencia de ningún otro proceso
activo, y ningún otro proceso activo tiene constancia de las actividades de los procesos durante el
tiempo que se esté realizando la acción, por lo tanto; No se comunican con otros procesos no pueden
detectar ningún cambio de estado externo y los cambios internos se comunican solo al finalizar.
Las acciones son atómicas si, en lo que respecta a otros procesos, pueden ser consideradas indivisibles
e instantáneas, de forma que los efectos sobre el sistema sean como si estuvieran entrelazadas y no
en concurrencia. Se pueden anidar unas dentro de otras.
Acciones atómicas de dos fases.
Se permite la comunicación hacia el exterior con los gestores de recursos
Fase creciente: Peticiones de recursos
Fase decreciente: Liberación de recursos
Una liberación temprana de recursos hace más difícil la recuperación de errores
Transacciones atómicas.
Una transacción atómica tiene todas las propiedades de una acción atómica, más la característica
adicional de que su ejecución puede tener éxito o fallar (no éxito). Por fallo se entiende la ocurrencia
de un error del que la transacción no puede recuperarse. Por lo tanto y para evitar estados
inconsistentes se usará la recuperación de errores hacia atrás lo que implica que los componentes
serán devueltos a su estado original. Esto último implica que no existe una ejecución parcial de una
transacción atómica.
Los requisitos para poder expresar acciones atómicas son:
Límites bien definidos.
30
Indivisibilidad (aislamiento).
Anidamiento. Evitando solapamiento entre ellas, anidamiento explícito.
Concurrencia.
Las acciones atómicas deben permitir la programación de procedimientos de recuperación
10.2 Acciones atómicas en los lenguajes concurrentes

Ninguno de los principales lenguajes de tiempo real lo proporciona directamente. Se pueden usar la
primitivas de sincronización (semáforos, monitores) para la programación de acciones atómica.
Cuando una acción atómica implica a un solo proceso, puede implementarse por exclusión mutua
mediante un semáforo binario pero la cosa se complica con varios procesos. En esos casos se pueden
usar monitores sin embargo esta solución también es problemática por que solo puede existir un
proceso activo dentro de un monitor y esto es muy restrictivo. Pueden eliminarse muchas de las
limitaciones de la solución anterior si se utiliza el monitor como un «controlador de acción» y se
realizan las propias acciones fuera del monitor.
Acciones atómicas en ADA
La acción es encapsulada en un paquete.
El cuerpo del paquete contiene el controlador de la acción, implementado de forma protegida.
31
Acciones atómicas en JAVA
Usamos interfaces para declarar las acciones atómicas
32
10.3 Acciones atómicas y recuperación de errores hacia atrás.
In Chapter 2, it was shown that when backward error recovery is applied to groups of communicating
tasks, it is possible for all the tasks to be rolled back to the start of their execution. This was the so-
called domino effect. The problem occurred because there was no consistent set of recovery points or
a recovery line. An atomic action provides that recovery line automatically. If an error occurs inside
an atomic action then the tasks involved can be rolled back to the start of the action and alternative
algorithms executed; the atomic action ensures that tasks have not passed any erroneous values
through communication with tasks outside the action. When atomic actions are used in this way they
are called conversations.
La semántica de una conversación se puede resumir de la siguiente forma:
Al entrar en la conversación se guarda el estado del proceso.
Sólo se permite comunicación con otros procesos activos en la conversación y gestores de
recursos.
Para abandonar la conversación todos los procesos deben pasar el test de aceptación. Si
algún test falla todos los procesos son restaurados.
Como alternativa se puede usar la instrucción dialog y discuss
10.4 Acciones atómicas y recuperación de errores hacia adelante.

Si ocurre una excepción en alguno de los procesos activos de una acción atómica, ésta se genera para
todos los procesos activos.
Con el modelo de terminación del manejo de excepciones, si todos los procesos activos en la acción
tienen un manejador y todos manejan la excepción sin generar ninguna otra, entonces la acción
atómica se completa normalmente. Si se utiliza un modelo de reanudación, cuando excepción ha sido
tratada, el proceso activo retoma su ejecución en el punto en el que la excepción fue generada.
Con cualquiera de los modelos, si no existe un manejador de excepciones en ninguno de procesos
activos en la acción, o falla uno de los manejadores, entonces la acción atómica falla con la excepción
estándar atomic_action_failure. esta excepción se genera para todos los procesos involucrados.
33
Manejo de excepciones en acciones atómicas
Excepciones concurrentes; Más de una tarea pueden generar excepciones al mismo tiempo.
Puede haber manejadores distintos en cada proceso. Difícil elegir manejador, existencia de
una tercera excepción: conjunción de las dos  Uso de árbol de excepciones; se elige la
excepción raíz del subárbol más pequeño que las contenga a todas, cada proceso puede tener
un árbol distinto de excepciones.
Excepciones en acciones anidadas; Todas las tareas deben participar en la recuperación.
10.5 Notificación asíncrona.

A pesar de haber abordado por separado la recuperación de errores hacia adelante y hacia atrás en
realidad puede que haya que combinarlas en muchos sistemas de tiempo real. La recuperación de
errores hacia atrás es necesaria para recuperarse de errores imprevistos, y la recuperación hacia
adelante es necesaria para deshacer o corregir cualquier interacción con el entorno.
Las notificaciones asíncronas permiten que una tarea llame la atención de otra sin esperas (se
comporta como una interrupción software).
Reanudación (manejo de eventos).
Cada proceso indica las interrupciones que manejará.
El flujo de control del proceso cambiará sólo temporalmente.
Es posible asociar un hilo distinto con el evento.
Terminación (transferencia asíncrona de control).
Cada proceso especifica un dominio de ejecución en el que podrá recibir notificaciones
asíncronas que lo finalizarán.
El requisito fundamental de un mecanismo de notificación asíncrona es permitir que un proceso
responda rápidamente a una condición que ha sido detectada por otro proceso por ello existen
ocasiones donde no es adecuada: Recuperación de errores, cambios de modo de operación,
planificación utilizando computaciones parciales/imprecisas, Interrupciones de usuario.
Notificaciones asíncronas en Ada

Permite a la aplicación responder a:
Eventos asíncronos externos.
Eventos activados por el paso del tiempo.
Transferencia asíncrona de control (ATC).
Modelo de terminación: Aborto de procesos
34
Ada y acciones atómicas
Se implementan mediante paquetes: Cada rol representa un proceso en el paquete.
Recuperación de errores hacia atrás (Conversaciones).
Cada proceso contiene un bloque de recuperación.
Uso de ATC para informar a cada tarea si se ha producido un fallo en alguna de las
restantes.
El objeto protegido Controlador se encarga de esta comunicación.
Recuperación de errores hacia delante.
Cada proceso tiene un bloque de manejo de excepciones.
Uso de ATC para informar a cada tarea si se ha producido un fallo en alguna de las
restantes.
El objeto Controlador señaliza el disparo si se ha generado alguna excepción que no
haya sido manejada en alguno de los componentes
Cada tarea indica si ha manejado la excepción con éxito y si alguna tarea indica que
la acción debe ser abortada, todas las tareas generarán Fallo_Accion_Atomica.
Recuperación hacia atrás Recuperación hacia adelante

Notificaciones asíncronas en JAVA
Java Real-Time Specification, soporta ambos modelos:
Reanudación; Manejo de eventos asíncronos (AE) donde los manejadores son entidades
programadas, no interrupciones, Un manejador puede ser asociado a uno o más eventos, y
un evento puede tener más de un manejador asociado. Cada manejador tiene un contador
del número de disparos pendientes.
Terminación; Transferencia asíncrona de control (ATC) y manejo de excepciones asíncronas
para tiempo real. ATC permite la interrupción inmediata, está integrado en el mecanismo de
manejo de excepciones de Java. Añade una extensión de interrupción de hilos. Cada método
debe indicar si está preparado para permitir una ATC.
35
AsyncEvent en RT-Java
ATC en RT-Java
Para facilita el uso estructurado java proporciona la interfaz Interruptible. La implementarán los
objetos que quieran proporcionar un método interruptible. El método run de la interfaz es
interruptible y si se interrumpe se llama al método interruptAction.
36
RT java y acciones atómicas.
ATC Ada vs RT-Java

Similitudes: Es necesario indicar las regiones de código susceptibles de recibir una ATC. ATC son
diferidas durante la interacción y finalización de hilos o tareas.
Diferencias: El modelo de RT-Java está integrado con el uso de excepciones. El modelo Ada está
integrado en la sentencia select y el uso de entries. Java requiere que los métodos indiquen si pueden
recibir ATC, en otro caso quedan pendientes. Respuestas diferidas a ATC en Ada deben hacerse
explícitas.
Resumen
Necesidad de uso de acciones atómicas. Sincronizar y comunicación en acciones atómicas.
Recuperación de errores hacia atrás: Conversaciones.
Recuperación de errores hacia adelante: Basada en excepciones, modelos de reanudación y
terminación.
Notificación asíncrona para la recuperación de errores en Ada y RT-Java: Manejo de eventos
y transferencia asíncrona de control (ATC).
Tema 8, Control de recursos.

El Capítulo 10 consideraba el problema de conseguir cooperación entre procesos fiables. Se ha
señalado que se precisa también la coordinación entre los procesos si se pretende compartir el acceso
a recursos escasos, como dispositivos externos, archivos, campos de datos compartidos, búferes.
Estos procesos se han denominado procesos competitivos. Aunque los procesos no se comuniquen
37
directamente entre ellos para pasarse información sobre sus propias actividades, pueden comunicarse
para coordinar el acceso a los recursos compartidos, esta comunicación no necesita ser atómica. La
implementación de entidades de recursos requiere alguna forma de agente de control. Si el agente de
control es pasivo, entonces se dice que el recurso es protegido (o sincronizado). Alternativamente,
si se requiere un agente activo para programar el nivel correcto de control. el controlador de recursos
es llamado servidor.
El acto de asignación de recursos tiene implicaciones en la fiabilidad; Un fallo en un proceso puede
provocar que un recurso no esté disponible para los demás, Inanición de recursos si se permite que
otros lo monopolicen. Los procesos pueden llegar a una situación de interbloqueo.
11.2 Gestión de recursos.

Las características de modularidad (en particular la ocultación de información) dictan que recursos
deben encapsularse, y que sólo puede accederse a ellos a través de una interfaz de alto nivel.
En la sincronización basada en monitor, los recursos protegidos estarían encapsulados en el monitor.

La espera ocupada y los semáforos no proporcionan el nivel apropiado de encapsulación. Las regiones
criticas condicionales (CCR) tampoco se evalúan explícitamente; los objetos protegidos son en
esencia una forma moderna de CCR.
11.3 Potencia expresiva y facilidad de uso.

En el contexto de la gestión de recursos, analizamos:
La potencia expresiva, capacidad de un lenguaje para expresar las restricciones de
sincronización requeridas.
La facilidad de uso de las primitivas de sincronización: monitores/métodos sincronizados
(sincronización de condición), servidores (con una interfaz de paso de mensajes), recursos
protegidos (implementados como objetos protegidos).
38
En el contexto del control de recursos, la información necesaria para expresar estas restricciones se
puede clasificar:
Tipo de petición de servicio: p.ej. lectura sobre escritura.
Orden en el que llegan las solicitudes: asegurar un reparto igualitario, impedir inanición.
Estado del servidor y de todos los objetos que gestiona: p.ej. un recurso solo se puede
asignar si está libre.
Parámetros de una solicitud: El orden de las operaciones en un servidor puede estar
restringido por la información contenida en los parámetros de las peticiones. Si la expresividad
es insuficiente: Se requiere doble interacción con el gestor de recursos y esta debe hacerse de
forma atómica
La prioridad del cliente: El dispach puede ordenar la prioridad
En general hay dos aproximaciones a la restricción del acceso para un servicio:
Espera condicional: se aceptan todas las solicitudes, pero cualquier proceso cuya solicitud
no se pueda atender se suspende en una cola (monitor).
Evitación: las solicitudes no se aceptan a menos que puedan ser satisfechas. Las condiciones
bajo las que se puede aceptar una solicitud se expresan como una guarda en una acción de
aceptación. Posee una forma más estructurada de programación de gestores de recursos, pero
carece de potencia expresiva.
El problema de la potencia expresiva se puede mejorar con la funcionalidad de reencolado.
11.4 La funcionalidad del reencolado. Semántica del reencolado

El reencolado no es una simple llamada. La entrada que se nombra en una sentencia de reencolado
(entrada objetivo) debe tener un perfil de parámetros equivalente a la de la entrada que la reencola, o
no tener parámetros.
Si un procedimiento P llama al procedimiento Q, cuando finaliza Q el control se devuelve a P
Si una entrada X reencola la entrada Y, el control no se devuelve a X.
Cuando finaliza Y, el control pasa de vuelta al objeto que llamo a X.
Cuando el cuerpo de una entrada o un accept ejecuta un reencolado, se da por finalizado.
39
11.5 Nombrado asimétrico y seguridad.
En lenguajes que tienen nombrado simétrico directo, un proceso servidor (o un recurso protegido)
conoce siempre la identidad del proceso cliente con el que está tratando. Éste es también el caso con
esquemas de nombrado indirecto basados en un intermediario uno a uno. El Nombrado asimétrico
hace, sin embargo, que el servidor no sea consciente de la identidad del cliente. Ya se ha apuntado
antes que esto tiene la ventaja de que se pueden escribir servidores de propósito general, pero puede
conducir a una seguridad deficiente en la utilización de los recursos.
Un recurso se solicita normalmente en dos modos de acceso: Acceso compartido o exclusivo.
11.7 Interbloqueos.
Los accesos compartidos pueden generar: interbloqueos (T1 tiene acceso exclusivo a R1 y solicita el
acceso a R2 y T2 tiene acceso exclusivo a R2 y solicita el acceso a R1), livelock (un conjunto de
procesos interaccionando colocados en bucles de los que no pueden salir, pero en los que no están
haciendo ningún trabajo) o inanición.
Condiciones necesarias para que ocurra el interbloqueo.
Exclusión mutua: sólo un proceso puede utilizar un recurso al mismo tiempo (es decir, el recurso no
se puede compartir o está limitado su acceso concurrente).
Mantenimiento y espera: debe haber procesos que mantengan recursos mientras esperan por otros.
No desalojo (no apropiación): un recurso sólo puede ser liberado por un proceso voluntariamente.
Espera circular: debe existir una cadena circular de procesos, de forma que cada proceso mantenga
recursos que son solicitados por el siguiente proceso en la cadena.
Para manejar los interbloqueos, y obtener así un STR fiable, tenemos 3 aproximaciones posibles:
Prevención de interbloqueo; garantizando que nunca ocurra al menos una de las 4 condiciones
Evitación de interbloqueo; Si se tiene más información sobre el uso de los recursos, entonces
es posible diseñar un algoritmo que permita que ocurran las cuatro condiciones pero que aun
así el sistema no entre en un estado de interbloqueo.
40
Detección y recuperación; como conocer información sobre el uso de recursos es difícil se
puede permitir que ocurra el interbloqueo y luego tomar acciones correctivas (grafos de
asignación de recursos)
Tema 9, Capacidades de tiempo (lineal, transitivo, irreflexivo y denso) real.

In Chapter 1, it was noted that a language for programming embedded systems requires facilities for
real-time control.
The introduction of the notion of time into a programming language can best be described in terms
of three largely independent topics.
(1) Interfacing with ‘Time’; for example, accessing clocks so that the passage of time can be
measured, delaying tasks until some future time, and programming timeouts so that the non-
occurrence of some event can be recognized and dealt with.
(2) Representing timing requirements; for example, specifying rates of execution and deadlines.
(3) Satisfying timing requirements.
El tiempo es lineal, transitivo, irreflexivo y denso.
If a program is going to interact in any meaningful way with the time frame of its environment, then
it must have access to some method of ‘telling the time:
Accediendo al marco temporal del entorno.
Mediante un reloj hardware interno.
Paquete reloj en ADA
El paquete Real_Time proporciona otro reloj en el

lenguaje Ada, similar a Calendar pero con
mayor granularidad y Monotónico: sin saltos
de año, segundos u otros ajustes.
Reloj en JAVA
Standard Java (java.lang), System.currentTimeMillis Devuelve los milisegundos transcurridos desde
el 1 de enero de 1970 GTM.
41
Las Clases Date y Calendar (java.util) hacen uso de currentTimeMillis para crear objetos.
Real-Time Java, añade relojes de tiempo real con alta resolución.
12.3 Retraso de un proceso.

Durante un período de tiempo relativo, Retardo relativo.
Hasta un instante absoluto de tiempo en el futuro, Retardo absoluto.
In Real~Time Java, the sleep method (defined in the RealtimeThread class) can be used for both
relative and absolute delays.
En ADA para calcular un retardo relativo. En ADA para calcular un retardo absoluto.
Start := Clock; -- from calendar START := Clock;
loop FIRST_ACTION;
exit when (Clock - Start) > 10.0; delay until START + 10.0;
end loop; SECOND_ACTION;
42
12.4 Programming timeouts (tiempo limite de espera).
Perhaps the simplest time constraint that an embedded system can have is the requirement to
recognize, and act upon, the non-occurence of some external event. For example, a temperature sensor
may be required to log a new reading every second, the failure to give a reading within 10 seconds
being defined as a fault. In general, a timeout is a restriction on the time a task is prepared to wait for
a communication.
También se usan timeouts para programar tiempos límite de ejecución de las tareas. Se puede hacer
uso de timeouts en cualquiera de las posibilidades de sincronización:
Semáforos.
Regiones críticas condicionales (CCR).
Variables de condición en monitores.
Entradas en objetos protegidos.
Timeouts en acciones.
Un timeout puede considerarse una notificación asíncrona. Útil para capturar errores de código
(bucles infinitos) y también para definir tareas con partes obligatorias y opcionales (La parte opcional
solamente se ejecutará si hay tiempo disponible).
Timeouts son implementados mediante una subclase de AsynchronouslyInterruptedException
denominada Timed.
12.5 Especificación de requisitos de temporización.

For many real—time systems, it is not sufficient for the software to be logically correct; the programs
must also satisfy timing constraints determined by the underlying physical system.
The verification of a real—time system can usefully be interpreted as requiring a two—stage process.
(1) Verifying requirements/designs — given an infinitely fast reliable computer, are the
temporal requirements coherent and consistent; that is, have they the potential to be
satisfied?
(2) Verifying the implementation — with a finite set of (possible unreliable) hardware
resources, can the temporal requirements be satisfied?
As indicated above, (l) may require formal reasoning (and/or model checking). For example, if event
A must be completed before event B, but is dependent on some event C that occurs after B, then no
matter how fast the processor it will never be possible to satisfy these requirements.
43
12.6 Temporal scopes (ámbitos temporales).
Facilitan la representación de requisitos temporales, Identifican a un conjunto de sentencias asociadas
con una restricción temporal: límite temporal (deadline), Retardo mínimo (min. Delay), retardo
máximo (max. Delay), Tiempo máximo de ejecución (max. execution time), Lapso de tiempo
máximo (max. elapsed time).
Periódicos: Acciones repetitivas, Asociados a tiempos límites que deben cumplir.

Aperiódicos o esporádicos: Consecuencias de eventos asíncronos, Tienen asociados tiempos de
respuesta.
Según la importancia del tiempo: Estricto (hard), Flexible (soft), Interactivo (interactive), Firme.
Tema 10, Planificacion.

In a concurrent program, it is not necessary to specify the exact order in which tasks execute.
Synchronization primitives are used to enforce the local ordering constraints, such as mutual
exclusion, but the general behaviour of the program exhibits significant non-determinism. If the
program is correct, then its functional outputs will be the same regardless of internal behaviour or
implementation details.
Un STR usará esquemas de planificación para obtener sus objetivos:
Algoritmo de ordenación del uso de los recursos (CPU).
Predecir el comportamiento del sistema en el caso peor. Se cumplen en todos casos.
Estáticos (antes ejecución) / Dinámicos (toma decisiones en tiempo ejecución).
13.1 Modelo de proceso simple (teórico).

Modelo que permite describir algunos esquemas de planificación estándar; La aplicación está
compuesta por un conjunto fijo de procesos, Los procesos son periódicos, con periodos conocidos,
los procesos son independientes entre sí (Instante crítico: todos los procesos son ejecutados a la vez
lo que implicara la carga máxima de trabajo para la CPU), las sobrecargas del sistema, tiempos de
cambio de contexto y demás se suponen con coste cero, Los tiempos límite de los procesos son
iguales a sus periodos y los procesos tienen tiempo de ejecución constante en el peor caso.
44
13.2 Ejecutivo cíclico.
With a fixed set of purely periodic tasks, it is possible to lay out a complete schedule such that the
repeated execution of this schedule will cause all tasks to run at their correct rate.
Los procesos no existen en tiempo de ejecución. Los procedimientos comparten un espacio de

direcciones. Los periodos deben ser múltiplos del tiempo de ciclo secundario
Dificultad para incorporar procesos esporádicos. Dificultad para incorporar procesos con periodos
grandes. Dificultad para construir el ejecutivo cíclico. Procesos con tiempo notable tendrán que ser
divididos en procedimientos de tamaño fijo.
13.3 Planificación basada en procesos.

With the cyclic executive approach, at run—time, only a sequence of procedure calls is executed. The
notion of task (thread) is not preserved during execution. An alternative approach is to support task
execution directly and to determine which task should execute at any one time by the use of one or
more scheduling attributes.
45
Soportan la ejecución de procesos de forma directa. En cada instante se determinará cuál es el proceso
que deba ejecutarse.
Alternativas de planificación:
Planificación de prioridad estática o fija: FPS Cada proceso tiene una propiedad estática
fija calculada antes de la ejecución. Esquemas apropiativo/no apropiativo/apropiación
diferida. Esquema asignación monotonico: (A cada proceso se le asigna una prioridad en
función de su periodo, prioridad 1 la menor).
Test Planificabilidad basada en la utilización: Esquema apropiativo basado en
prioridades usando el Algoritmo de tasa monotónica. Si se cumple U los N procesos
cumplirán sus tiempos limite. Mayor periodo menor prioridad.
U = 0,24 + 0,25 + 0,33 = 0,82 y 0,82 no es <= 0.78 por lo tanto no pasa el test.
Se empieza a ejecutar C por se el más prioritario, termina en 10 y se empieza a

ejecutar B. Termina en 20. se ejecuta A durante 10 ticks pero es expropiado y pierde
el uso del procesador al tener que ejecutarse C cada 30 ticks. Vuelve a ejecutarse
C y B. En el tick 50 A no ha terminado por lo que no ha cumplido su periodo.
Si un conjunto de procesos pasa el test de planificabilidad, entonces cumplirá todos

los tiempos límite; si lo falla, puede o no fallar en tiempo de ejecución. Condición
suficiente pero no necesaria.
46
test de utilización para FPS no es exacto y no es aplicable a modelos más generales.
Para el proceso de mayor prioridad el tiempo de respuesta en su peor caso = a su
tiempo de ejecución ( R = C), pero para el resto existen interferencias Ri = Ci + Ii
para resolver esta ecuación usamos ->
Si el valor Wi > Ti (periodo) el proceso no cumplirá su tiempo límite.

El análisis del tiempo de respuesta es suficiente y necesario.
Primero el tiempo límite más temprano: EDF. Los procesos se ejecutan según su tiempo
limite más próximo. Se dice que este esquema es dinámico. Test de utilización para EDF es
más simple pero más difícil de implementar y FPS es más predecible en situaciones de
sobrecarga. Estrategia dinámica.
Planificación basada en el valor: VBS. Si el sistema puede llegar a sobrecargarse se

necesita un esquema más adaptable que FPS|EDF empleando un algoritmo de planificación
en línea.
13.7 Tiempo de ejecución en el peor caso.

C = Tiempo de ejecución del proceso en el peor caso (WCET). C se puede obtener por análisis o
medición: Medición: observación experimental de los casos, Análisis: modelo efectivo del
procesador.
13.8 Procesos esporádicos / aperiódicos.

Inclusión de procesos esporádicos en el modelo simple. T = tiempo mínimo entre ejecuciones, Ej:
T=20 indica que el proceso no será activado más de una vez cada 20 ms.
Tiempo límite del proceso (D):
D = T en el modelo simple.
D<T para procesos esporádicos (Ej. procesos encargados resolución errores).
47
La tasa de llegada de procesos esporádicos en el caso peor es considerablemente mayor que la media.
Procesos estrictos y flexibles.
Reglas para encontrar los requisitos mínimos que no lleven a utilizaciones muy bajas del procesador
(ya que en el peor caso la tasa procesos esporádicos es mayor que la media):
1. Todos los procesos deben ser planificables utilizando los tiempos medios y las tasas
medias de llegadas (pueden existir situaciones en las que no sea posible cumplir los tiempos
límite sobrecarga transitoria).
2. Todos los procesos estrictos deben ser planificables utilizando los peores casos del tiempo
de ejecución y de la tasa de llegada de todos los procesos, incluyendo los flexibles (asegura
que ningún proceso estricto incumplirá su límite).
One simple way of scheduling aperiodic tasks, within a priority—based scheme, is to run such tasks
at a priority below the priorities assigned to hard tasks. In effect, the aperiodic tasks run as background
activities, and therefore cannot steal, in a preemptive system, resources from the hard tasks. Although
a safe scheme, this does not provide adequate support to soft tasks which will often miss their
deadlines if they only run as background activities. To improve the situation for soft tasks, a server
(or execution-time server) can be employed. Servers protect the tasking resources needed by hard
tasks, but otherwise allow soft tasks to run as soon as possible.
Vamos a considerar varios enfoques: asignar a los procesos esporádicos una prioridad < procesos
estrictos → los procesos esporádicos incumplirán frecuentemente su tiempo limite | uso servidores
(permiten que los procesos esporádicos se ejecuten lo antes posible).
Servidor diferible (DS)
Servidor esporádico (SS)
Planificación de prioridad dual | EDL versión para EDF
Para D=T la ordenación de prioridad de tasa monotónica resulta óptima
Para D<T es posible definir una formulación similar: La prioridad fija de un proceso es inversamente
proporcional a su tiempo limite. DMPO: deadline monotonic priority ordering
(Di, < Dj, => Pi, > Pj,)
La ordenación monotonica de prioridades de tiempo límite (DMPO) es óptima si cualquier conjunto
de procesos, Q, planificable por el esquema de prioridades, W, también lo es mediante DMPO.
48
13.10 Interacciones y bloqueos entre procesos.
Inversión de prioridad, Un proceso es suspendido a la espera de que
otro proceso de menor prioridad realice algún cálculo (Se dice
que el proceso de mayor prioridad está
bloqueado).
Un esquema puro de prioridades puede llevar

fácilmente a inversión de prioridad(ver proceso d). Una forma de limitar este efecto es utilizar la
herencia de prioridad. La prioridad de un proceso será el máximo entre su prioridad y las prioridades
de los procesos que dependan de él.
Si un proceso tiene m secciones críticas que pueden provocar su bloqueo, el máximo número de veces
que puede ser bloqueado será m.
Si B es el máximo tiempo de bloqueo y k el número de secciones críticas, el proceso i tiene un límite
superior de bloqueo dado por:
Tiempo de respuesta con bloqueo.
El tiempo de respuesta teniendo en cuenta el factor de bloqueo se puede calcular como:
49
Y con la ecuación de recurrencia:
13.11 Protocolos de acotación de la prioridad.

Aunque el protocolo estándar de herencia da un límite superior para el número de bloqueos con los
que se puede encontrar un proceso de prioridad alta, este límite puede todavía conducir a un cálculo
del peor caso inaceptablemente pesimista. Esto se debe a la posibilidad de desarrollar cadenas de
bloqueos (bloqueos transitivos), es decir, situaciones en las que el proceso c es bloqueado por el
proceso b, el cual está bloqueado por el proceso a, y así sucesivamente (interbloqueos). Los
protocolos de acotación de la prioridad abordan estas cuestiones. En sistema monoprocesador, Un
proceso de alta prioridad puede ser bloqueado por procesos de prioridad baja en una sola ocasión
como máximo. El protocolo asegura que, si un recurso está bloqueado por cierto proceso a, y esto
conduce a que se bloquee un proceso de mayor prioridad, b, entonces no se permite que ningún otro
recurso que pueda bloquear a b sea bloqueado más que por a.
Protocolo original de acotación de la prioridad: OCPP.
Cada proceso tiene asignada una prioridad estática por defecto.
Cada recurso tiene definido un valor cota estático, que es la prioridad máxima de los
procesos que lo están utilizando.
Un proceso tiene una prioridad dinámica que es el máximo de su prioridad estática y
de cualquiera de las que herede debido a bloqueos.
Un proceso sólo puede bloquear un recurso si su prioridad dinámica es mayor que la
cota máxima de cualquier recurso actualmente bloqueado (excluyendo los
bloqueados por él)
Tiempo máximo que un proceso puede estar bloqueado:
50
Protocolo inmediato de acotación de la prioridad: ICPP (fija la prioridad de un
proceso tan pronto como bloquea un recurso).
Cada proceso tiene asignada una prioridad por defecto.
Cada recurso tiene definido un valor cota estático (Prioridad máxima de los procesos
que lo utilizan).
Un proceso tiene una prioridad dinámica, que es el máximo entre su prioridad y los
valores techo de cualquier recurso que tenga bloqueado.
Un proceso solamente podrá ser bloqueado al principio de su ejecución.
Cuando el proceso comience, todos los recursos deben estar libres. Si no es así, algún
proceso tendrá una prioridad mayor o igual, y la ejecución del proceso será pospuesta
OCCP Versus ICCP: El comportamiento en el peor caso es idéntico. ICPP es más sencillo de
implementar (No hay que monitorizar las relaciones de bloqueo). ICPP produce menos cambios de
contexto (El bloqueo es previo a la ejecución), ICPP requiere más cambios de prioridad.
13.12 Modelo de proceso extensible para FPS.

Los tiempos límite pueden ser menores que el periodo D<T, y pueden soportar procesos esporádicos
y aperiódicos, Se contemplan interacciones entre procesos (Los bloqueos se tienen en cuenta en los
tiempos de respuesta).
Todos los modelos descritos anteriormente necesitan un distribuidor realmente apropiativo. En esta
sección, se va a describir un esquema alternativo, la Planificación cooperativa, que usa un
distribuidor con apropiación diferida.
‘Planificación cooperativa’ Permite que se ejecuten procesos de menor prioridad, ICPP permite
bloqueos no acumulativos, Divide el código en bloques no desalojables. Incrementa la planificación
del sistema. Sin interferencias en el último bloque no desalojable. Mayor precisión en la predicción
de los tiempos de ejecución de los bloques no desalojables.
51
Fluctuaciones en la activación(jitter) y tiempos limites arbitrarios.
In the Simple model, all tasks are assumed to be periodic and to be released with perfect periodicity;
that is, if task l has period T, then it is released with exactly that frequency. Sporadic tasks are
incorporated into the model by assuming that their minimum interarrival interval is T. This is not,
however, always a realistic assumption.
Por tanto, los tiempos limite puede ser arbitrarios, Es posible que D (y potencialmente) R > T.
Adicionalmente, La tolerancia a fallos (hacia adelante o atrás) implica cálculos extra pero los tiempos
límite (deadlines) deben seguir cumpliéndose.
Instante critico y desplazamientos.
En el análisis de planificabilidad presentado al principio del este capítulo, se supone que todos los
procesos comparten un tiempo de activación común. El instante crítico es aquel en el activan todos
los procesos a la vez (esto suele ocurrir en el instante 0). Para la planificación de prioridades estáticas,
esta suposición resulta segura; si todos los procesos cumplen sus requisitos de temporización cuando
son activados conjuntamente, siempre serán panificables. Existen, sin embargo, conjuntos de
procesos que se pueden beneficiar de la elección explícita de sus tiempos de activación de forma que
no compartan un instante crítico. Se podría decir que un proceso tiene un desplazamiento con
respecto a otros.
13.13 Sistemas dinámicos y análisis en línea.

Para los sistemas de tiempo real estrictos, es de desear un análisis fuera de línea (offline); de hecho,
a menudo resulta obligatorio.
El análisis offline para sistemas estrictos requiere: Patrones de llegada del trabajo entrante conocidos
y limitados, Tiempos de computación limitados, Esquema de planificación con ejecución predecible.
En estas situaciones la planificación de prioridad estática puede ser aceptable pero hay sistemas que
requieren una planificación en linea (aplicaciones flexibles donde no se conocen los tiempos de
llegada ni de computación).
La principal tarea de un sistema planificación en linea es la gestión de sobrecargas:
Módulo de control de admisión (Limita el número de procesos que compiten por los
procesadores).
Rutina de distribución EDF (dinámica) para procesos admitidos.
52
Si hay que admitir ciertos procesos y rechazar otros, es preciso conocer la importancia relativa de
cada uno. Asignación de valores para admisión/rechazo:
Estático: El proceso siempre tiene el mismo valor, requiere especialistas en el dominio de
aplicación.
Dinámico: El valor del proceso se calcula cuando se activa.
Adaptativo: El valor del proceso cambia durante su ejecución.
la programación basada en prioridad es más propia de los SO que de los lenguajes pero el enfoque de
los SO no resulta adecuada para sistemas de tiempo real estricto.
RESUMEN
Esquema de planificación;
Define un algoritmo para la compartición de recursos
Permite la predicción del comportamiento en el peor caso
Implementación mediante ejecutivo cíclico: un ciclo principal / varios ciclos secundarios
Uso de un sistema basado en prioridades para solventar los inconvenientes del ejecutivo cíclico
Procesos esporádicos
Secciones no expropiables
Fluctuaciones en la activación
Test de utilización: No es exacto
Análisis del tiempo de respuesta: Más flexible y Adaptable (Procesos periódicos y aperiódicos,
Bloqueos , Planificación cooperativa, Tolerancia a fallos, Desplazamientos).
Ada y RT-Java para planificación: Ambas soportan la planificación basada en prioridades. Java
permite la implementación de sistemas más dinámicos
Tema 11, Programación de bajo nivel.

Entre las principales características de un sistema embebido se encuentra la necesidad de interacción
con dispositivos de entrada y salida (E/S) de propósito específico.
La programación de controladores de dispositivos requiere: Posibilidad de pasar datos e información
de control y la posibilidad de manejar interrupciones.
En lo concerniente a la entrada y salida de dispositivos, hay dos clases generales de arquitecturas: la
primera dispone de buses lógicos diferentes para la memoria y para E/S: en la segunda, la memoria y
los dispositivos de E/S se asientan sobre el mismo bus lógico (memory mapped I/O).
53
La interfaz física de un dispositivo suele efectuarse mediante un conjunto de registros. Con buses
para memoria (intel) y para dispositivos de E/S separados lógicamente, el computador precisa de dos
tipos de instrucciones de ensamblado:
Acceso al dispositivo. Ejemplo: IN AC, PORT OUT AC, PORT
Mientras que en la arquitectura E/S sobre memoria. (Ej. M68000). Según las direcciones se accederá
al dispositivo o a la memoria.
Hay que destacar dos tipos de mecanismos generales para efectuar y controlar la E/S: mecanismos de
control dirigido por estatus, y mecanismos de control dirigidos por interrupción.
Dirigido por estatus: Cada programa realiza las comprobaciones para determinar el estatus
del dispositivo. Clases de instrucciones hardware para este mecanismo:
Operaciones de test.
Operaciones de control.
Operaciones de E/S
Dirigido por interrupción: Permiten que la E/S se efectúa asíncronamente. Las
interrupciones aumentan grado de no determinismo, pueden no estar permitidas en los STR.
Controlado por programa.
Iniciado por programa, acceso Directo a Memoria (DMA).
Controlado por programa de canal.
Los dos últimos tipos pueden provocar robos de ciclo de acceso a memoria al procesador y
producir situaciones no deterministas.
Elementos necesarios para los dispositivos dirigidos por interrupción:
Mecanismos de cambio de contexto.
Cambio de contexto: Preservación del estado del procesador. Establecimiento del
estado adecuado del procesador. Restauración del estado del proceso suspendido.
Estado de un proceso: PC. Estatus del programa. Registros.
Niveles de cambios de contexto: Básico(PC), Parcial (PC. Estatus del programa), Completo.
Identificación del dispositivo de la interrupción.
54
Vectorizados: consulta del vector de interrupción y su correspondencia con las
direcciones de los dispositivos HW.
Por estatus. Existen varios dispositivos conectados al mismo controlador. Cada
interrupción tiene una palabra de estatus asociada que especifica el dispositivo.
Por sondeo. Se pregunta por el estatus de cada dispositivo.
Algunas arquitecturas modernas asocian una primitiva de alto nivel al servicio de la
interrupción.
Identificación de la interrupción. Comprobar la información de estatus del dispositivo, la
misma interrupción señala su causa.
Control de interrupciones. Control de interrupciones mediante la habilitación / inhabilitación
de las mismas. Mecanismos:
Control por estatus por interrupción.
Control por máscara de interrupción.
Control por nivel de interrupción.
Control de prioridad. Prioridad para atender las interrupciones. Mecanismos estáticos o
dinámicos relacionados con los mecanismos de control y niveles de prioridad del
procesador.
Ejemplo Motorola 68000 (Arquitectura sobre Memoria, interrupciones vectorizadas). Cuando
ocurre una interrupción: Almacena PC y estatus del procesador (PSW). Se cargan el nuevo PC y PSW
del vector de interrupción. La primera palabra contiene la dirección de la rutina de servicio, la
segunda contiene el PSW y la prioridad.
15.2 Requisitos del Lenguaje.

El requisito principal de un lenguaje de alto nivel es que proporciona un modelo abstracto de
manejo de dispositivos. Lenguajes ensambladores. Lenguajes de medio y alto nivel (C, Módula-2,
Java, occam2, ADA).
Mecanismos de Encapsulamiento y Modularidad.
Los interfaces de bajo nivel no suelen ser portables (dependen de la maquina). Es importante separar
las secciones de código portables de las que no lo son.
Modelos Abstractos de Manejo de Dispositivos.
Un dispositivo puede verse como un procesador que efectúa cierta tarea. El sistema informático
aparece compuesto por varios elementos de Proceso ejecutando procesos paralelos. La sincronización
vendrá dada por las interrupciones. Existen modelos para comunicarse y sincronizarse con los
dispositivos.
Esos modelos deben cubrir los siguientes aspectos:
Mecanismos para la representación, direccionamiento y manipulación de los registros de los
dispositivos (Cada registro puede representarse como una variable u objeto)
55
Representación adecuada de las interrupciones: Procedimiento (más común), Ejecución
esporádica de un proceso. Notificación asíncrona. Sincronización por variable de condición
compartida. Sincronización basada en mensajes.
El uso e implementación de estas opciones depende del lenguaje de programación.
15.8 Planificación de controladores de dispositivos.

Consideración de controladores dirigidos por programa ya que DMA y el programa de control de
canal pueden provocar no determinismo. El manejador suele tener mayor prioridad que la ejecución
de un proceso ordinario.
El protocolo para emplear un dispositivo dirigido por estatus es el siguiente:
Petición de lectura.
Espera hasta que el HW efectúa la lectura.
Espera ocupada.
Replanificación del proceso para un instante posterior.
Para procesos periódicos, separación de la acción entre periodos. Desplazamiento del
periodo.
Acceso al registro para realzar la lectura desde el programa.
15.9 Gestión de la memoria.

Los STR suelen tener limitada la cantidad de memoria disponible. • Es necesario garantizar una
utilización eficiente. Aspectos:
Gestión del montículo (heap). Región de memoria disponible para las solicitudes de
memoria dinámica del sistema operativo. Es necesario gestionar las reservas y liberaciones
de memoria heap. Para las liberaciones de memoria:
El programador lo devuelve de forma explícita (ej. C).
Monitorizando por parte del sistema la memoria y determinando cuándo no se va a
acceder a ella.
Monitorizando por parte del sistema la memoria y determinando cuándo no va a ser
usada. Recolector de basura.
El recolector de basura puede tener un impacto sobre la predecibilidad en la ejecución de los
procesos.
Gestión de la pila. El tamaño de la pila es un aspecto a considerar. Es necesario conocer el
comportamiento de ejecución de cada tarea para predecir sus necesidades de memoria de
pila. Es útil utilizar herramientas para el análisis del flujo de control a partir del código de la
tarea.
56

Strap Un Tes

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Strap Un Tes

Загружено:

Авторское право:

Доступные форматы

SISTEMAS TIEMPO REAL

Grande y complejo. Pero no es obligatorio.

CICLOS DE DESARROLLO DE SISTEMAS DE TIEMPO REAL

Tema 2, Prevención de fallos y Tolerancia a fallos.

Four sources of faults which can result in system failure:

• Inadequate specification (durante la especificación de requisitos).

5.1 Fiabilidad, fallo y defectos.

5.4 Software fault tolerance (N-Versiones).

5.6 La estrategia de los bloques de recuperación en la tolerancia fallos software.

5.7 N-Version vs recovery blocks.

5.8 Redundancia dinámica y excepciones.

5.10 Seguridad, fiabilidad y confiabilidad (SAFETY AND RELIABILITY)

Tema 3, Excepciones y manejo de expceciones.

6.2 Manejo de excepciones moderno. Dominio y propagación de una Excepción.

subtype Temperature is Integer range 0 . . 100;

−− read temperature sensor and calculate its value

−− handler for Constraint Error

// statements which may raise exceptions

¿Qué ocurre con el flujo de programa?, continuar o no con la ejecución

Si no hay manejador en el bloque, la excepción se propaga; para un bloque, se genera en el

Un manejador con un parámetro de tipo T, atrapara una excepción que es de tipo E, si T y E

Tema 4, Programación concurrente.

Cobegin. es una forma estructurada de denotar la ejecución concurrente de un conjunto de

Java permite la creación dinámica de tareas, permite paso

P y T son activos; S es un recurso. Tenemos tres posibles arquitecturas:

Tema 5, Comunicación y sincronización basada en variables

8.5 Regiones criticas condicionales.

Tema 6, Comunicación y sincronización basada en mensajes.

El emisor continua inmediatamente, se reciba o no el mensaje.

El emisor continua cuando se ha recibido el mensaje.

El emisor continua cuando ha recibido una respuesta del receptor.

9.2 Nombrado de procesos y estructura de mensajes.

Tema 7, acciones atómicas, procesos concurrentes y fiabilidad.

10.1 Acciones atómicas.

10.2 Acciones atómicas en los lenguajes concurrentes

El cuerpo del paquete contiene el controlador de la acción, implementado de forma protegida.

10.4 Acciones atómicas y recuperación de errores hacia adelante.

10.5 Notificación asíncrona.

Notificaciones asíncronas en Ada

Recuperación hacia atrás Recuperación hacia adelante

ATC Ada vs RT-Java

Tema 8, Control de recursos.

11.2 Gestión de recursos.

En la sincronización basada en monitor, los recursos protegidos estarían encapsulados en el monitor.

11.3 Potencia expresiva y facilidad de uso.

11.4 La funcionalidad del reencolado. Semántica del reencolado

Tema 9, Capacidades de tiempo (lineal, transitivo, irreflexivo y denso) real.

El paquete Real_Time proporciona otro reloj en el

12.3 Retraso de un proceso.

12.5 Especificación de requisitos de temporización.

Periódicos: Acciones repetitivas, Asociados a tiempos límites que deben cumplir.

Tema 10, Planificacion.

13.1 Modelo de proceso simple (teórico).

Los procesos no existen en tiempo de ejecución. Los procedimientos comparten un espacio de

13.3 Planificación basada en procesos.

Se empieza a ejecutar C por se el más prioritario, termina en 10 y se empieza a

Si un conjunto de procesos pasa el test de planificabilidad, entonces cumplirá todos

para resolver esta ecuación usamos ->

Si el valor Wi > Ti (periodo) el proceso no cumplirá su tiempo límite.

Planificación basada en el valor: VBS. Si el sistema puede llegar a sobrecargarse se

13.7 Tiempo de ejecución en el peor caso.

13.8 Procesos esporádicos / aperiódicos.

Un esquema puro de prioridades puede llevar

13.11 Protocolos de acotación de la prioridad.