Professional Documents
Culture Documents
Ada es un lenguaje que esta orientado para muchos aspectos importantes de sistemas
prácticos en el mundo real. Algunas de las características del lenguaje son:
Página 1 de 27
SISTEMAS EN TIEMPO REAL
Los problemas internos del sistema son los que dan lugar a las fallas, a estos
problemas los llamaremos errores. Un componente fallido del sistema será aquel que en algún
momento de su vista caerá en un error.
Modos de fallas:
Un sistema provee servicios, de donde es posible clasificar los modelos de falla de un sistema
según el impacto que tiene sobre los servicios que presta.
Puede identificarse dos dominios de fallas:
Fallas por valor: el valor retornado es un error ya sea porque es incorrecto o porque está
fuera del rango esperado
Falla por tiempo: el servicio es entregado fuera de tiempo. Puede ser: demasiado temprano,
demasiado tarde o infinitamente tarde (nunca)
Página 2 de 27
SISTEMAS EN TIEMPO REAL
Falla silenciosa: los valores dados por el sistema son correctos pero a veces aparece una
falla por omisión
Falla de detención igual que el anterior en el sentido que entra en “silencio” pero permite
que los demás sistemas lo detecten.
Nunca falla: un sistema que produce resultados correctos en valor y en tiempo.
1. Prevención de fallas:
Hay dos estados posibles:
a) Evitar la falla: intenta evitar la introducción de fallas potenciales durante la construcción del
sistema.
Desde el punto de vista del hardware esto puede conseguirse mediante
el uso de componentes más confiables, dentro de las restricciones de costo y
performance dadas.
Uso de técnica adecuadas para la interconexión de componentes
Aislar los componentes de la interferencias externas
Desde el punto de vista del software no se produce deterioro físico, de donde la prevención
tiene más que ver con las etapas de diseño. Con este fin deben utilizarse:
Especificación de requerimientos rigurosa (lo más formal posible)
Uso de metodologías de diseño probadas
Uso de lenguajes con facilidades de abstracción y modularización
Uso de ambientes de ingeniería de software que ayuden a manejar los componentes y
la complejidad del sistema
Pese a todos los testeos, es factible que el sistema no permita su detención hasta que la falla
sea reparada. Es necesario entonces pensar en otras alternativas.
2. Tolerancia a fallas
Pueden proveerse varios niveles de tolerancia a fallas:
Tolerancia a fallas completa: el sistema sigue operando en presencia del error sin una
pérdida significativa de su funcionalidad.
Degradación leve (graciosa): el sistema sigue funcionando degradado hasta su reparación
Falla segura: el sistema mantiene su integridad y aborta su funcionamiento en forma
temporaria.
El nivel de tolerancia a falla requerido dependerá de la aplicación
3. Redundancia
Las técnicas para lograr tolerancia a fallas se basan en elementos extra introducidos al sistema
para detectar y recuperar errores.
Página 3 de 27
SISTEMAS EN TIEMPO REAL
Son redundantes en el sentido de que no son necesarios para el funcionamiento del sistema.
Esto se denomina redundancia proteccionista. Se busca minimizar la redundancia y maximizar
la confiabilidad sujeto a las restricciones de costo y tamaño del sistema. Es importante ver que
la redundancia incrementa la complejidad del sistema.
En hardware
Redundancia estática (masking): se replica el mismo componente y se toma por ejemplo el
dato de la mayoría. El que es distinto es enmascarado.
Redundancia dinámica: La redundancia está dentro del componente el cual indica explícita
o implícitamente que se trata de un error, de donde la recuperación debe ser provista por
otro componente. Ej: chequeo de errores en la comunicación
En software:
N-versión Programming: Se basa en el éxito de la redundancia por hardware. Dado que el
software no se deteriora apunta a la detección de falla de diseño. N-version programming es la
generación de N versiones de programas funcionalmente equivalentes, independientes entre sí,
con N >= 2, para la misma especificación inicial.
Los programas se ejecutan concurrentemente y sus resultados son comparados por un
manejador de procesos. Si hay diferencias en el resultado se toma uno consensuado
(suponiendo que hay mas de 1).
Se supone que los programas podrían fallar independientemente (esto puede no cumplirse si
las versiones están escritas en un mismo lenguaje y la falla está asociada con él). Una manera
de asegurar la independencia de los errores es el uso de diferentes lenguajes y si se usa el
mismo se sugiere el uso de diferentes compiladores (compiladores del mismo lenguaje de
diferentes fabricantes). Las N versiones deberían estar en máquinas separadas comunicadas
mediante líneas tolerantes a fallas.
Cada proceso debe poder comunicarse con el manejador durante su ejecución de manera de
poder comunicar problemas. Ej: no va a terminar.
La comunicación entre el proceso y el manejador está dada por el lenguaje usado y su forma
de concurrencia
Página 4 de 27
SISTEMAS EN TIEMPO REAL
4) Tratamiento del error: aunque el daño haya sido reparado, el error aún podría existir, de
donde, debe tomarse alguna acción.
Detección por la aplicación: son detectados por la aplicación en sí misma. Ej: Chequeo
de tiempo: ver que la respuesta es obtenida en un plazo determinado. Es importante ver
que esto no garantiza que la respuesta sea correcta. Otro Ej: códigos de detección de
errores
En cuanto a las acciones atómicas, permiten realizar una acción sin interacción con el sistema.
Es decir desde afuera se la ve como una acción indivisible. Esto permite proteger recursos, de
manera que cada vez que un proceso quiera acceder aun recurso debe perdir permiso.
Backware: estas técnicas buscan llevar al sistema a un estado seguro previo. Esto implica la
ejecución de otra parte del código, es similar al N-version programming, con la idea que esta
nueva versión no provoque errores. El punto al cual es recuperado el proceso se llama punto
de recuperación y el acto de establecer esto es llamado punto de chequeo. Para establecer
el punto de recuperación es necesario salvar el estado del sistema en ejecución. Es importante
notar que si bien el sistema retorna aun estado consistente, no es posible cambiar las acciones
que la falla haya podido tener sobre el entorno.
Si los procesos son concurrentes puede ocurrir un efecto dominó donde el roll back de uno
lleve a que el otro también se tenga que recuperar. En la figura, si P2 tiene un error después de
R22 y de que la comunicación IPC4 se realice, llevará a que P1 retorne a R12 y eso comienza
a desandar todas las comunicaciones llevando a ambos procesos al comienzo. Esto se conoce
como efecto dominó.
Página 5 de 27
SISTEMAS EN TIEMPO REAL
de recuperación deben ser seleccionado de forma que no resulte en un roll back de todos los
procesos en lugar de llevar al sistema a un estado consistente.
5. Redundancia dinámica y excepciones
Una excepción se define como la ocurrencia de un error. El traer la excepción para que se
trate es lo que se conoce como raising. La respuesta del invocador es llamada catching. El
manejo de excepciones puede ser considerado una recuperación de error hacia delante, ya que
cuando una excepción se activa, el sistema no vuelve a un estado anterior sino que el control
se pasa al manejador. Sin embargo, puede usarse un manejador de excepciones para proveer
recuperación hacia atrás como veremos más adelante.
Ada define a las excepciones como una forma de solucionar de manera consistente las
condiciones de error. Es decir que las excepciones solo se utilizan para manejar situaciones de
anormalidad. Este lenguaje define cinco excepciones predefinidas que son las que tratan los
errores relacionados con el lenguaje y que son útiles sobre todo en la etapa del debugging:
a. Numeric_error: es la que ocurre al intentar realizar una operación numérica invalida,
como puede ser una división por cero o un overflow. El compilador es el encargado de
levantar la excepciona.
b. Constraint_error: se activa cuando se viola alguna restricción, como por ej. rangos,
índice de un arreglo o condiciones discriminantes.
c. Program_error: atrapa todos los errores semánticos, como por ej. ninguna de las
alternativas del select está habilitada o hay variables no inicializadas.
d. Storage_error: se levanta si no hay espacio suficiente para satisfacer las necesidades
del programa en ejecución.
e. Tasking_error: se levanta si se presenta un problema en la comunicación entre dos
tareas; por ej. una tarea llama a otra que no la va a atender.
La propagación de una excepción se efectúa en el caso que, si ocurre que la unidad que
levanta la excepción no contiene un manejador de excepciones, dicha excepción se propaga al
modulo que la llamó. Por ej.:
Página 6 de 27
SISTEMAS EN TIEMPO REAL
With Gnat.IO;
Use Gnat.IO;
Procedure Propagacion is
Procedure raise_exc is
Begin
Put (“ raise_exc”);
Raise Constraint_error;
- no hay manejador, se propaga al llamador
end raise_exc;
procedure Llamador is
begin
Put (“Llamador”);
Raise_exc;
Put (“Llamador despues de la excepcion”);
Exception
When Constraint_error =>
Put (“ Constraint_error en llamador”);
End;
Begin
Put (“ Principal llamando a llamador”);
Llamador;
Put (“ Principal retornando de llamador”);
Exception
When Constraint_error =>
Put (“ Constraint_error en el principal”);
End Propagacion;
Además es posible indicar bloques de programa, cada uno con su propio manejador de manera
que se active el que corresponde.
El alcance que tiene la excepción es el mismo que el dado para cualquier identificador. Si
analizamos el siguiente ejemplo:
With Gnat.IO;
Use Gnat.IO;
Procedure demo_alcance is
E: exception;
Procedure p is
Begin
Raise e; { levanta demo_alcance.e }
End;
Procedure q is
E : exception ;
Begin
P;
Exception
Página 7 de 27
SISTEMAS EN TIEMPO REAL
Página 8 de 27
SISTEMAS EN TIEMPO REAL
C1 : Control (planox);
C2 : Control (planoy);
C3 : Control (planoz);
Página 9 de 27
SISTEMAS EN TIEMPO REAL
Vemos que hay cuatro hilos de ejecución simultáneos. La ventaja de estas declaraciones
dinámicas es que su guardián no es el bloque donde fueron creadas sino aquel que contiene la
declaración de la tarea.
Declare
Task type T;
Type A is access T;
Begin
.....
declare {bloque interior}
x : T;
y : A := new T;
begin
...... {secuencia de sentencia}
end; {debe esperar que x termine pero no y.all}
{Y podria estar activa aunque su nombre esta
fuera de rango}
......
end; {debe esperar a que y.all termine}
No es legal en Ada el asignar una tarea a otra estructura de datos aunque sean de igual tipo.
Por ejemplo: si Brazo_robot y Nuevo_brazo son dos punteros al mismo tipo de tarea, no es
legal hacer:
Brazo_Robot.all := Nuevo_Brazo.all
Sin embargo
Brazo_Robot := Nuevo_Brazo
Página 10 de 27
SISTEMAS EN TIEMPO REAL
4. Sincronización y Comunicación
La mayor dificultad de la programación concurrente está en la interacción de los procesos. La
comunicación puede realizarse mediante:
Variables compartidas: en donde la comunicación se lleva a cabo cuando los procesos
referencian estas variables en el momento apropiado.
Pasaje de mensajes: implica un intercambio explícito de datos entre los dos procesos y
dicho cambio se lleva a cabo a través del mensaje.
1. Sincronización de Procesos
Hay una cuestión implícita en el mensaje. Un receptor no puede recibir un mensaje que no
haya sido enviado. A diferencia de la variable compartida donde es posible leer el valor de la
variable sin saber si ha sido escrita previamente. En el caso de mensajes, el pretender leer un
mensaje que aun no ha llegado producirá que el proceso que quiere leer quede suspendido
hasta que el mensaje llegue.
Existe una relación entre estas formas enviar un mensaje. Dos eventos asincrónicos se pueden
comportar como una comunicación sincrónica.
P1 P2
Página 11 de 27
SISTEMAS EN TIEMPO REAL
Send_asincrónico(mensaje) wait(mensaje)
Wait(reconocimiento) send_asincronico(reconocimiento)
Dos comunicaciones sincrónicas pueden ser usadas para construir una invocación remota.
P1 P2
Send_asincrónico(mensaje) wait(mensaje)
Wait(replay) ...
Construye el replay
...
send_asincronico(replay)
2. Nombrado de procesos
Aún en el caso b) el mensaje puede ser sincrónico, es decir, el emisor espera a que alguien lo
reciba.
Página 12 de 27
SISTEMAS EN TIEMPO REAL
Ada y Occam utilizan el pasaje de mensajes tanto para comunicación como para
sincronización. Occam sólo soporta la comunicación por canal. En cambio Ada permite además
la comunicación vía memoria compartida y objetos protegidos.
El modelo de Ada
La semántica del modelo remoto tiene mucho que ver con la llamadas a procesos, en el sentido
que el dato es pasado al receptor, este lo recibe, lo ejecuta y lo retorna.
Ej:
Task type Salida_pantalla(id:Identif_Pantalla) is
-- define un tipo de task
entry Escribir( valor: character; x_coord, y_Coord:Integer);
end Salida_Pantalla;
Display : Salida_Pantalla(Tty1);
Un entry puede tener parámetros in, out y in out. No puede tener resultado como una función,
sino que debe ser llamada como un procedimiento. El nombre de la tarea no puede aparecer
en una cláusula use de donde forzosamente debe ser nombrada en la invocación, de la forma
T.E(...) donde T es la tarea y E la entrada.
Lo anterior define siete entradas con la misma especificación para los parámetros. Para llamar
a uno de los canales es necesario poner
Multiplexor.Channels(3)(D)
Ejemplo:
with GNat.Io; Use Gnat.Io;
procedure VerLetras is
task P1 is
entry Mostrar(C : in character);
end P1;
task body P1 is
i : Integer range 1..10;
begin
for i in 1..10 loop
accept Mostrar(c : in character) do
-- lo muestra solo si es letra mayuscula
if C in 'A'..'Z' Then
Put(C);
end if;
end Mostrar;
end loop;
Página 13 de 27
SISTEMAS EN TIEMPO REAL
end P1;
task P2;
task body P2 is
letra : character;
n : Integer range 1..10;
begin
for n in 1..10 loop
Get(Letra);
P1.mostrar(Letra);
end loop;
end P2;
begin
null;
end VerLetras;
En el código anterior File_Handler llama al manejador para abrir un archivo. Este requerimiento
puede ser exitoso o terminar con el levantamiento de una de dos excepciones Device_off_Line
o File_Does_Not_Exist. La primera excepción es manejada dentro del accept. Se hace un
intento para bootear el dispositivo y luego el requerimiento de apertura es repetido. Como el
Página 14 de 27
SISTEMAS EN TIEMPO REAL
manejador está dentro del accept, el cliente no advierte esta actividad (si el dispositivo no
bootea, esto quedaría indefinidamente suspendido). La segunda excepción ocurre por una falla
del requerimiento indicado por el usuario, de donde no se maneja dentro de la excepción y se
devuelve al usuario para que actúe. La acción a tomar será del tipo:
begin
File_Handler.Open(New_File);
exception
when File_Does_Not_Exist =>
File_Handler.Create(New_File);
File_Handler.Open(New_File);
end;
Para implementar en forma segura los entry calls condicionales y timed con el modelo
de rendezvous, se necesitan dos relojes: un timer de intervalo y un reloj de time-off-day. El
tiempo asociado con el comienzo del rendezvous puede ser medido en el procesador llamado.
El procesador que llama envía un mensaje al procesador remoto y espera un mensaje de
respuesta observando el estado del rendezvous. En el caso de un entry call timed, el proceso
llamador incluye el delay de tiempo en el mensaje.
Página 15 de 27
SISTEMAS EN TIEMPO REAL
Espera selectiva
Los ejemplos anteriores son estáticos en cuanto al orden de ejecución de las entradas a las
tareas. Esto en realidad no es así, es necesario contar con la posibilidad de seleccionar de un
conjunto de entradas aquella que se presenta a fin de dar un servicio un poco más general.
Esto funciona como la Chance de CSP
Ejemplo:
with Gnat.Io; use Gnat.Io;
procedure mensaje is
subtype Line is String(1..100);
task Char_To_Line is
entry Agregar(C: in Character);
entry Sacar( L : out Line; N : out Natural );
end;
task body Char_To_Line is
MiLinea : Line;
Longitud : Natural := 0;
begin
loop
select
accept Agregar(C : in Character) do
Longitud := Longitud +1;
MiLinea(Longitud) := C;
end Agregar;
or
accept Sacar(L : out Line; N : out Natural) do
L := MiLinea;
N := Longitud;
end Sacar;
or
terminate;
end select;
end loop;
end Char_To_Line;
dato : Character;
Texto : Line;
cuantos : Natural;
begin
Get(dato);
while dato /= '.' loop
Char_To_line.Agregar(dato);
Get(Dato);
end loop;
Char_To_Line.Sacar(Texto, cuantos);
Put_Line(Texto(1..cuantos));
Página 16 de 27
SISTEMAS EN TIEMPO REAL
Note la opción de terminate para evitar que el proceso principal nunca termine. Este evento se
activa cuando el proceso llamador terminó y es un forma de que la tarea hija se entere de esta
situación.
5. Acciones atómicas
La programación concurrente permite representar de una forma más natural el funcionamiento
y la interacción de los distintos objetos del mundo real. Desafortunadamente, la concurrencia
trae nuevos problemas que no existían en la programación secuencial.
La más fuerte de todas es la segunda ya que la interacción entre la acción atómica y su entorno
sólo se realiza si no interfiere con la operación indivisible.
Sin embargo, esto sólo se verifica en una situación ideal y se necesita una visión más práctica.
En primer lugar debería permitírsele a la acción atómica comenzar aunque no tenga todos sus
recursos, esto la puede llevar a pedir recursos durante su ejecución, es decir, debería
comunicarse con el administrador de recursos.
El administrador es sólo el encargado de verificar que el recurso sea utilizado adecuadamente
y no hace ninguna gestión sobre él. Sería deseable, además, que en cuanto los recursos ya no
sean necesarios puedan ser liberados en forma prematura por las acciones atómicas a fin de
agilizar el sistema completo.
Página 17 de 27
SISTEMAS EN TIEMPO REAL
Con esta idea y para proteger a la acción atómica, su alocación de recursos se divide en dos
fases, una primera fase de crecimiento donde sólo puede pedir recursos y luego un fase de
achicado donde sólo se le permite liberar recursos.
Es importante ver que la liberación temprana de recursos complica la recuperación de errores
en la acción atómica (el recurso puede haber sido modificado y liberado y luego se presenta el
error).
Asumiremos acciones atómicas de dos fases donde los recursos no se liberan hasta que la
acción no se haya completado.
Transacciones atómicas.
Una transacción atómica es una acción atómica a la que se le ha agregado una propiedad de
éxito o fracaso. Si fracasa se supone que el sistema debe retornar a un estado consistente. Es
decir al momento previo al comienzo de la transacción.
Este tema será analizado más adelante cuando se vean Bases de Datos Distribuidas.
Semáforos:
Un acción atómica realizada por un único proceso puede implementarse por exclusión mutua
mediante un semáforo binario:
Wait(semaforo);
Accion_atómica;
Signal(semaforo);
Supongamos que dos procesos intervienen en la misma acción atómica y ambos utilizan un
recurso que no puede compartirse. Para manejar la acción atómica se utilizan 4 semáforos:
Los semáforos inicio_accion_atomica1, inicio_accion_atomica2 aseguran que
sólo dos procesos ingresen a la acción. Cualquier otro que lo intente será bloqueado.
Los semáforos termino_accion_atomica1, termino_accion_atomica2 aseguran que
no se pueden ir sin que el otro termine.
Note que se necesita otro semáforo para gestionar la exclusión mutua al recurso.
Página 18 de 27
SISTEMAS EN TIEMPO REAL
Inicio_accion_atomica1, inicio_accion_atomica2 : semaphore := 1;
Termino_accion_atomica1,termino_accion_atomica2: semaphore := 0;
procedure codigo_primer_proceso is
begin
Inicia la accion atomica
wait( inicio_accion_atomica1);
acceder al recurso en modo nocompartido
actualizar el recurso
indicar al segundo proceso que puede acceder al recurso
cualquier procesamiento final de la accion
wait( termino_accion_atomica2);
devolver el recurso
signal( termino_accion_atomica1);
signal( inicio_accion_atomica1);
end codigo_primer_proceso;
procedure codigo_segundo_proceso is
begin
Inicia la accion atomica
wait( inicio_accion_atomica2);
procesamiento inicial
esperar a aque el primer proceso avise que se puede usar
el recurso
acceder al recurso
signal( termino_accion_atomica2);
wait( termino_accion_atomica1);
signal( inicio_accion_atomica2);
end codigo_segundo_proceso;
El ejemplo anterior muestra que los semáforos permiten resolver muchos de los problemas de
sincronización, pero presentan los siguientes problemas:
Sólo dos procesos pueden entrar, pero no asegura que son los dos que deberían entrar
La estructura wait-signal ya fue criticada en capítulos anteriores
No es fácil de extender a N procesos.
Monitores:
El encapsular la acción atómica en un monitor asegura que las ejecuciones parciales sean
verificadas.
monitor accion_atomica
export codigo_primer_proceso, codigo_segundo_proceso;
Página 19 de 27
SISTEMAS EN TIEMPO REAL
primer_proceso_activo : boolean := false;
segundo_proceso_activo : boolean := false;
primer_proceso_termino : boolean := false;
segundo_proceso_termino : boolean := false;
no_primer_proceso, no_segundo_proceso : condition;
fin_accion_atomica1, fin_accion_atomica2 : condition;
procedure codigo_primer_proceso
begin
if primer_proceso_activo then wait( no_primer_proceso);
primer_proceso_activo := true;
acceder al recurso en modo no compartido
actualizar el recurso
indicar al segundo proceso que puede acceder al recurso
(enviar signal)
cualquier proceamiento final
if not segundo_proceso_termino then
wait(fin_accion_atomica2);
primer_proceso_termino := true;
liberar el recurso
signal( fin_accion_atomica1);
primer_proceso_activo := false;
signal(no_primer_proceso);
end;
procedure codigo_segundo_proceso
begin
if segundo_proceso_activo then wait( no_segundo_proceso);
segundo_proceso_activo := true;
procesamiento inicial
esperar que el primer proceso indique que el recurso está
disponible
acceder al recurso
signal( fin_accion_atomica2);
segundo_proceso_termino := true;
segundo_proceso_activo := false;
signal(no_segundo_proceso);
end;
Muchas de las limitaciones de la solución anterior podrían solucionarse usando el monitor como
un controlador de acciones y realizando las acciones de forma externa al monitor.
Página 20 de 27
SISTEMAS EN TIEMPO REAL
Una acción atómica que involucre tres tareas podría implementarse en Ada mediante
rendezvous anidados, pero esto impediría el paralelismo dentro de la acción.
package Action_X is
procedure Codigo_primer_tarea( --params );
procedure Codigo_segunda_tarea( --params );
procedure Codigo_tercer_tarea( --params );
end Action_X;
Página 21 de 27
SISTEMAS EN TIEMPO REAL
end Action_Controller;
En el ejemplo anterior, la acción se sincroniza mediante el objeto protegido. Esto asegura que
sólo tres tareas pueden entrar y que sincronicen su salida.
Por simplicidad, sólo se considerarán procesos estáticos. También se asumirá que todos los
procesos que intervienen en la acción atómica son conocidos en compilación.
Cada proceso involucrado en la acción declara una sentencia action que especifica: nombre
de la acción, nombre del otro proceso que interviene en la acción y el nombre del proceso a ser
ejecutado al entrar a la acción.
Ej: el proceso P1 desea ejecutar la acción atómica A junto con los procesos P2 y P3. Se
declara entonces lo siguiente:
action A with (P2,P3) do
adquirir los recurso
comunicación con P2 y P3
liberar los recursos
end A;
Se asume que los alocadores de recursos son conocidos y que la comunicación dentro de la
acción se limita a los tres procesos. Esto se chequea en compilación. Las acciones anidadas
serán permitidas siempre que el anidamiento sea estricto. Note que si los procesos no son
conocidos en compilación cualquier comunicación será permitida siempre que ambos procesos
se encuentren activos en la misma acción atómica.
Página 22 de 27
SISTEMAS EN TIEMPO REAL
Los procesos de la acción sólo pueden salir cuando todos desean hacerlo. Esto implica que
todos los procesos deben entrar a la acción para que los que entraron puedan salir. En algunos
casos es importante que los procesos que hayan entrado puedan salir aunque otros no hayan
llegado.
Las acciones atómicas restringen el flujo de información a un entorno bien definido y por lo
tanto pueden proveer la base tanto para aislar como para recuperar el error.
Las acciones atómicas proveen una línea de recuperación automática evitando de esta forma el
"efecto dominó" visto anteriormente. Si un error se presenta dentro de una acción atómica,
todos los procesos involucrados son llevados al momento en que comenzó la acción y luego
ejecutar un proceso alternativo; la acción atómica asegura que ningún valor erróneo ha sido
transmitido a otros procesos. Las acciones atómicas utilizadas de esta forma se denominan
conversaciones.
3.1. Conversaciones:
En las conversaciones cada acción tiene un bloque de recuperación. Una sintaxis podría ser la
siguiente:
Según Randell (1975), todos los procesos que intervienen en la conversación deben haber
entrado en ella antes de que alguno pueda salir. Sin embargo, lo aquí definido es un poco
Página 23 de 27
SISTEMAS EN TIEMPO REAL
A veces, es difícil recuperar errores hacia atrás cuando se trata de sistemas embebidos, por lo
cual debe considerarse la recuperación hacia adelante y junto con ella los manejadores de
excepciones. Veremos manejadores de excepciones entre procesos concurrentes involucrados
en acciones atómicas.
En la recuperación hacia atrás, cuando ocurre un error, todos los procesos involucrados
en la acción atómica participan en la recuperación. Lo mismo ocurre con los manejadores de
excepciones y la recuperación hacia adelante. Si una excepción ocurre en uno de los procesos,
también se levanta en todos los procesos activos en la acción. La excepción que se genera
desde otros proceso se llama asincrónica. Una posible sintaxis para Ada podría ser:
En cualquiera de los dos casos, si algún proceso falla y no dispone del manejador
correspondiente o si el manejador falla, la acción atómica falla levantando la excepción
falla_accion_atomica. Esta última será levantada en todos los procesos involucrados.
Ninguno de los principales lenguajes para tiempo real soporta acciones atómicas ni el
levantamiento asincrónico. Esta es una de las razones por la cual no disponen de un método
adecuado para especificar el dominio de la excepción. Sin embargo, Ada soporta eventos
asincrónicos: es decir una mecanismo para obtener la tensión de otro proceso sin tener
necesidad de esperar. Hay dos modelos básicos: resumption y termination.
Página 24 de 27
SISTEMAS EN TIEMPO REAL
Con el termination model cada proceso especifica un dominio de ejecución durante el cual está
preparado para recibir eventos asincrónicos. Si un evento ocurre fuera de este dominio podría
ser ignorado o encolado. Después que el evento ha sido manejado, el control es retornado al
proceso interrumpido en una posición diferente a la que tenía cuando el evento ocurrió. Ada
soporta el modelo de terminación para el manejo de eventos asincrónicos mediante un
mecanismo de transferencia de control asincrónico.
Una forma de manejar eventos asincrónicos es abortar el proceso y permitir al proceso maestro
recuperarse. Todos los sistemas operativos y la mayoría de los lenguajes de programación
concurrente proveen esta facilidad; pero se trata de una solución extrema de donde un
mecanismo de eventos asincrónicos debe ser provista.
Control de Recursos:
Las acciones atómicas tienen como objetivo lograr un proceso de cooperación entre procesos
confiable. También es necesario coordinar cuando se trata de compartir recursos. En este caso
se dice que se trata de procesos competitivos. En este caso los procesos no se comunican
para intercambiar información sino para coordinar el acceso a los recursos compartidos.
Página 25 de 27
SISTEMAS EN TIEMPO REAL
Es importante proveer de un acceso a los recursos seguro de manera que no ocurra que un
proceso tome algún recurso que nunca libere dejando a otros esperando eternamente.
Aunque los procesos necesitan comunicarse y sincronizarse para alocar los recursos, no lo
hacen en la forma de una acción atómica. Esto se debe a que sólo intercambian información
específica. Como resultado, el controlador del recurso, sea protegido o servidor, aceptará
cualquier cambio a su dato local.
Dado que el acceso al recurso se realiza vía el controlador de dicho recurso, la comunicación
entre el proceso y el controlador debería realizarse mediante una acción atómica de manera
que nadie interfiera mientras el recurso se aloca o se libera. Nótese que el administrador del
recurso y el proceso cliente podrían utilizar una recuperación de errores hacia adelante o hacia
atrás que permitan soportar errores previstos o no previstos.
Página 26 de 27
SISTEMAS EN TIEMPO REAL
Comunicación remota
Página 27 de 27