Tema 5. Programación Concurrente

TEMA 5.
PROGRAMACIÓN
CONCURRENTE.
5.1. Ejecución concurrente.

5.2. Representación de procesos.
5.3. Tareas en Ada.
5.4. Ejemplo.
5.5. Comunicación y sincronización con variables comunes.
5.6. Comunicación y sincronización mediante mensajes.
1
• Un programa concurrente está formado por una colección de procesos
secuenciales autónomos que se ejecutan (aparentemente) en paralelo.
• Podemos distinguir tres formas de ejecutar una colección de procesos
concurrentes:
1. Los procesos multiplexan sus ejecuciones sobre un único procesador
(multiprogramación).
2. Los procesos multiplexan sus ejecuciones sobre un sistema
multiprocesador de memoria compartida (multiproceso).
3. Los procesos multiplexan sus ejecuciones en varios procesadores que no
comparten memoria (procesamiento distribuido).
• El término concurrencia indica paralelismo potencial.
• Vida de un proceso:
terminado
inexistente creado iniciándose ejecutable
Tema 5. Programación concurrente. 2

• Los procesos concurrentes se ejecutan con ayuda de un núcleo de ejecución
(Run-Time Kernel) que posee muchas de las propiedades del planificador en
un sistema operativo y que lógicamente está situado entre el hardware y el
software de la aplicación.
• El núcleo se encarga de la creación, terminación y el multiplexado de los
procesos.
• El núcleo puede tomar varias formas:
– Núcleo desarrollado como parte de la aplicación.
– Núcleo incluido en el entorno de ejecución del lenguaje.
– Núcleo de un sistema operativo tiempo real.
– Núcleo microprogramado dentro del procesador para mayor eficiencia.
• El algoritmo de planificación utilizado por el núcleo de ejecución afectará al
comportamiento temporal del programa.
• Desde el punto de vista del programador, el núcleo de ejecución planifica los
procesos de una forma no determinista.

• Cuando hablamos de procesos debemos distinguir:
– Procesos pesados: cada uno se ejecuta en su máquina virtual. Cada
proceso puede ser visto como un programa independiente.
– Procesos ligeros (threads): todos los threads de un mismo proceso
comparten la misma máquina virtual. Tienen acceso al mismo espacio de
memoria.
• La concurrencia puede estar soportada por el lenguaje de programación o sólo
por el sistema operativo. El soportar la concurrencia en los lenguajes de
programación tiene una serie de argumentos a favor, como por ejemplo
– Conduce a programas más legibles y fáciles de mantener.
– Un STR podría no disponer de un sistema operativo.
Pero también algunos en contra:
– Dificultad al implementar de forma eficiente el modelo de concurrencia
del lenguaje sobre el modelo de concurrencia del sistema operativo.
• Estamos interesados en el estudio de la concurrencia soportada por el lenguaje
de programación.
Lenguajes concurrentes
• Los lenguajes de programación concurrentes proporcionan elementos para:
– La expresión de la ejecución concurrente a través de la noción de proceso.
– La sincronización de procesos.
– La comunicación entre procesos.
• Teniendo en cuenta la relación entre los procesos, estos pueden:
– Ser independientes: no se comunican ni sincronizan.
– Cooperar para un fin común: regularmente se comunican y sincronizan sus
actividades para realizar alguna operación común.
– Competir por el uso de recursos: se comunican y sincronizan con el fin de
obtener los recursos compartidos.
• Los modelos de concurrencia de los distintos lenguajes de programación
difieren respecto a:
Estructura Granularidad Terminación
Nivel Inicialización Representación

Características de los lenguajes concurrentes
• Estructura
– Estática: número de procesos fijo y conocido en tiempo de compilación.
– Dinámica: número de procesos conocido sólo en tiempo de ejecución.
• Nivel de paralelismo
– Anidado (nested): procesos definidos a cualquier nivel del programa.
– Plano (flat): procesos definidos sólo al nivel externo del programa.
• Granularidad del paralelismo
– Grano grueso (coarse grain): pocos procesos pero de larga vida.
– Grano fino (fine grain): gran número de procesos simples.
• Inicialización
Paso de parámetros o comunicación explícita.
• Terminación
al completar la ejecución aborto nunca
suicidio excepción sin manejar cuando no se necesita más
Jerarquía de procesos
• Con niveles de procesos anidados se pueden crear jerarquías de procesos.
• Para cualquier proceso es útil distinguir:
– El proceso (o bloque) que es el responsable de su creación. Relación
padre/hijo.
– El proceso (o bloque) que se ve afectado por su terminación. Relación
guardián/subordinado.
• El guardián puede ser:
– el padre, otro proceso o un bloque interno de uno de los anteriores
• El guardián no puede terminar hasta que no lo hayan hecho todos sus
subordinados. esperando
terminado terminación subordinado
inexistente creado iniciándose ejecutable
esperando
inicio hijo

5.2. Representación de procesos.
• La ejecución concurrente en un lenguaje de programación puede representarse:
Corutina A Corutina B
– Corrutinas
1 2 3
Resume B Resume A
5 4
– fork/join pid = fork(); /* Se crea un proceso idéntico al original */

. . .
c = join(); /* El primero que llega espera al otro */
. . .
– Cobegin/coend cobegin
S1; S2; S3; . . . Sn
coend
– Declaración explícita de procesos

• Los procesos son unidades de programa (como los procedimientos).
• Permite una mejor estructura.
• Ejemplo: Ada.
5.3. Tareas en Ada.
• Tarea: es el nombre que reciben las actividades concurrentes en Ada.
• La tarea, como unidad de programa que es, tiene dos partes:
– Especificación: define la interfaz visible de la tarea.
– Cuerpo: define la actividad de la tarea.
• Las tareas se crean implícitamente cuando se entra en el ámbito de su
declaración, y comienzan a ejecutarse antes que el cuerpo correspondiente a la
parte declarativa donde se declaran.
Procedure Ejemplo1 is
Task A;
Task body A is
--declaraciones
begin ...
end A;
begin -- A comienza su ejecución aquí antes que la primera
... -- sentencia de Ejemplo_1
end Ejemplo_1; -- Ejemplo1 no retorna mientras no termine A
5.3. Tareas en Ada.
El tipo tarea
• En ocasiones es útil tener un grupo de tareas similares.
• La declaración de un tipo tarea permite disponer de una plantilla para crear
tareas similares.
• Las tareas que se declaran directamente (como antes) son de un tipo anónimo.
task type Tipo_A;
A, B : Tipo_A;
type Long is array (1..100) of Tipo_A;
type Mixture is record
Indice : Integer;
Accion : Tipo_A;
end record;
L : Long; M : Mixture;
task body Tipo_A is
...
end Tipo_A;
5.3. Tareas en Ada.
El tipo tarea
• Ejemplo
procedure Robot is
type Dimension is (Plano_X, Plano_Y, Plano_Z);
task type Control (Dim : Dimension);
C1 : Control(Plano_X); C2 : Control(Plano_Y); C3 : Control(Plano_Z);
task body Control is
Posicion, Setting : Integer; -- Posición absoluta y movimiento relativo
begin
Position:= 0; -- Posición de reposo
loop
Calcula_Movimiento(Dim, Setting);
Posicion:= Posicion + Setting;
Mueve_Brazo(Dim, Posicion);
end loop;
end Control;
begin
null;
end Robot;
5.3. Tareas en Ada.
Tareas dinámicas
• La creación dinámica de tareas puede ser efectuada explícitamente utilizando
el operador new sobre un tipo acceso (acceso a un tipo tarea):
procedure Ejemplo2 is
task type T;
type A is access T;
P : A;
Q : A:= new T;
begin
...
P:= new T;
Q:= new T;
...
end Ejemplo2;
• Existen tres tareas activas: P.all, Q.all y la primera tarea que fue creada.
• Esta tarea se convierte en anónima al reasignar su puntero.

5.3. Tareas en Ada.
Tareas dinámicas
• Para las tareas creadas con new el bloque que actúa como guardián (o maestro,
que es como se denomina en Ada) es aquel que contiene la declaración del tipo
acceso.
declare
task type T;
type A is access T;
begin
...
declare -- bloque interno
X : T;
Y : A:= new T;
begin
-- secuencia de instrucciones
end; -- Tiene que esperar a que termine X pero no Y.all
... -- Y.all podría estar activa todavía, aunque el nombre Y está fuera de ámbito
end; -- Tiene que esperar a que termine Y.all

5.3. Tareas en Ada.
Tareas y excepciones
• Si una tarea falla mientras está siendo inicializada el padre de la tarea recibe la
excepción Tasking_Error.
• Cuando la tarea comienza su ejecución recibe cualquier excepción que eleve.
Identificación de tareas
• El tipo task es limited private:
Robot_Arm.all:= New_Arm.all; Robot_Arm:= New_Arm;
• El anexo de programación de sistemas de Ada proporciona un mecanismo por
el que cada tarea puede obtener su propia identificación y ésta puede ser
pasada a otras tareas.
package Ada.Task_Identification is
type Task_Id is private;
Null_Task_Id : constant Task_Id;
function Current_Task return Task_Id; --Devuelve un identificador único
... private ...
end Ada.Task_Identification;
• El paquete soporta los atributos T’Identity y E’Caller.
5.3. Tareas en Ada.
Terminación de tareas
• Una tarea termina cuando:
– Completa la ejecución de su cuerpo (o bien normalmente o bien como
resultado de una excepción no manejada).
– Ejecuta una alternativa terminate en una instrucción select (se verá después).
– Es abortada.
• Una tarea puede comprobar si otra ha terminado:
if T’Terminated then -- para alguna tarea T
...
end if;
• Pero no puede saber si terminó normalmente o como consecuencia de un error.
• Una tarea puede abortar otra cuyo nombre es visible: abort T;
• Cuando se aborta una tarea, se abortan también todos sus subordinados.
• Las tareas anónimas no se pueden abortar.
• Se puede abortar una tarea identificada mediante
Ada.Task_Identification.Abort_Task.

5.4. Ejemplo.
Sistema empotrado sencillo
Termopares
ADC
Transductor
Calentador Switch T
P ADC
Pantalla DAC Válvula
• El objetivo global del sistema es el de mantener la temperatura y presión de

algún proceso químico dentro de unos límites preestablecidos.

5.4. Ejemplo.
• Solución 1: Se utiliza un único programa que ignora la concurrencia lógica de
T, P y S => No es necesario sistema operativo.
procedure Controlador is if Lista_Presion then
TR : Temp_Leida; Leer(PR);
PR : Presion_Leida; Convertir_Presion(PR, PS);
HS : Valor_Calentador; Escribir(PR);
PS : Valor_Presion; Escribir(PS);
Lista_Temp, Lista_Presion : Boolean; end if;
begin end loop;
loop end Controlador;
...
if Lista_Temp then
Leer(TR);
Convertir_Temp(TR, HS);
Escribir(TR);
Escribir(HS);
end if;
• Problema: Se basa en una espera ocupada. Además ambas actividades deberían

estar desacopladas.
5.4. Ejemplo.
• Solución 2: Tres procedimientos secuenciales ejecutados como procesos de un
sistema operativo.
procedure Controlador is procedure Controlador_Presion is
Controlador_Temp : Thread_ID; PR : Presion_Leida; PS : Valor_Presion;
Controlador_Pres : Thread_ID; begin
procedure Controlador_Temperatura is loop
TR : Temp_Leida; HS : Valor_Calentador; Leer(PR);
begin Convertir_Temp(PR, PS);
loop Escribir(PR);
Leer(TR); Escribir(PS);
Convertir_Temp(TR, HS); end loop;
Escribir(TR); end Controlador_Presion;
Escribir(HS); begin
end loop; -- Crear los dos procesos
end Controlador_Temperatura; end Controlador;
• Problema: No hay diferencia entre procedimientos y procesos concurrentes =>

dificulta la creación y mantenimiento de sistemas grandes.
5.4. Ejemplo.
• Solución 3: Con un único programa en un lenguaje concurrente => no hace
falta sistema operativo pero sí un núcleo de ejecución.
procedure Controlador is task body Controlador_Pres is
task Controlador_Temp; PR : Presion_Leida; PS : Valor_Presion;
task Controlador_Pres; begin
task body Controlador_Temp is loop
TR : Temp_Leida; HS : Valor_Calentador; Leer(PR);
begin Convertir_Temp(PR, PS);
loop Escribir(PR);
Leer(TR); Escribir(PS);
Convertir_Temp(TR, HS); end loop;
Escribir(TR); end Controlador_Pres;
Escribir(HS); begin
end loop; null;
end Controlador_Temp; end Controlador;
• Problema: Ambas tareas hacen uso de la pantalla => hace falta gestionar el
acceso a este recurso compartido.
5.5. Comunicación y sincronización con
variables comunes.
• Hay veces en las que los procesos cooperan para un fin común o compiten
por la utilización de recursos.
• Para ello es necesario realizar operaciones de comunicación y sincronización
entre procesos:
– Dos procesos se comunican cuando hay una transferencia de información
de uno a otro.
– Dos procesos están sincronizados cuando hay restricciones en el orden en
que ejecutan algunas de sus acciones.
• La forma más sencilla de comunicación entre dos procesos o más procesos
consiste en la compartición de variables comunes.
• El acceso incontrolado a variables comunes
– Hace que el resultado de la ejecución dependa del orden en que se
intercalan las instrucciones de dos o más procesos: condición de carrera
(race condition).
– Es una situación anómala que hay que evitar
variables comunes.
Mecanismos de sincronización
• Sección crítica: secuencia de instrucciones que debe ejecutarse de forma
indivisible.
• Exclusión mutua: forma de sincronización que se usa para proteger una
sección crítica.
• Espera ocupada
while Test_and_Set(Flag) loop
null;
end loop;
-- Sección Crítica
Flag:= False;
– La operación Test_and_Set es atómica.
– Ineficiente.
– Los protocolos que usan esperas ocupadas son difíciles de diseñar,
entender y demostrar su correctitud.
variables comunes.
• Semáforos
– Un semáforo es una variable que toma valores enteros no negativos.
– Además de asignarle un valor inicial, sólo se pueden hacer dos
operaciones (indivisibles) sobre un semáforo: wait y signal.
– Ejemplo: Mutex : Semaforo; -- Inicializado a 1 por defecto
task t1; task t2;
task body t1 is begin task body t2 is begin
loop loop
... ...
Wait(Mutex); Wait(Mutex);
-- Sección Crítica 1 -- Sección Crítica 2
Signal(Mutex); Signal(Mutex);
... ...
end loop; end loop;
end t1; end t2;

variables comunes.
• Regiones críticas condicionales
– Una región crítica es una secuencia de instrucciones que se ejecuta en
exclusión mutua.
– La sincronización condicional se consigue por medio de guardas en las
regiones críticas: sólo se puede entrar en la región crítica cuando la guarda
es verdadera.
– Ejemplo (no Ada)
V : Shared T;
region V when condición is

...
end region;

variables comunes.
• Monitores
– Un monitor es un módulo cuyas operaciones se ejecutan en exclusión
mutua.
– La sincronización condicional se consigue por medio de variables de
condición y las operaciones wait y signal.
– Ejemplo (no Ada)
monitor buffer;
export append, take;
var . . .
procedure append (i : integer);
begin
if Buffer_Lleno then wait(hay_espacio);
. . . signal(hay_item);
end append;
procedure take (var i : integer); . . . end take;
begin -- incicialización de las variables del monitor
end buffer;
variables comunes.
Objetos protegidos (Ada)
• Un objeto protegido encapsula datos que sólo podrán ser accedidos a través de
subprogramas protegidos o entradas protegidas en exclusión mutua.
• La condición de sincronización se alcanza mediante expresiones booleanas en
las entradas (son guardas, pero en Ada se llaman barreras), que deben
evaluarse antes de la ejecución de la entrada.
• Una unidad protegida podría ser declarada como un tipo o como una única
instancia y, como toda unidad de programa, consta de una especificación y un
cuerpo.
• Ejemplo: protected type Shared_Integer(Initial_Value : Integer) is
function Read return Integer;
procedure Write(New_Value : Integer);
procedure Increment(By : Integer);
private
The_Data : Integer:= Initial_Value;
end Shared_Integer;
My_Data : Shared_Integer(42);
variables comunes.
• Un procedimiento protegido proporciona acceso exclusivo a los datos
encapsulados tanto para escritura como para lectura.
• Una función protegida proporciona acceso concurrente de lectura a los datos
encapsulados.
• Una entrada protegida es un procedimiento protegido guardado por una
expresión booleana (barrera). Si esta barrera es false al llamar a la entrada, se
suspende la tarea llamadora hasta que la barrera valga true y no exista ninguna
otra tarea activa dentro del objeto protegido.
protected body Shared_Integer(Initial_Value : Integer) is
function Read return Integer is begin
return The_Data;
end Read;
procedure Write(New_Value : Integer) is begin
The_Data:= New_Value;
end Write;
procedure Increment(By : Integer) is begin
The_Data:= The_Data + By;
end Increment;
end Shared_Integer;
variables comunes.
• Ejemplo: Buffer compartido.
Buffer_Size : constant Integer:= 10; protected body Bounded_Buffer is
type Index is mod Buffer_Size; entry Get(Item : out Data_Item)
subtype Count is Natural range 0..Buffer_Size; when Number_In_Buffer > 0 is
type Buffer is array (Index) of Data_Item; begin
Item:= Buf(First);
protected type Bounded_Buffer is First:= First + 1;
entry Get(Item : out Data_Item); Number_In_Buffer:= Number_In_Buffer - 1;
entry Put(Item : in Data_Item); end Get;
entry Put(Item : in Data_Item)
private when Number_In_Buffer < Buffer_Size is
First, : Index:= Index’First; begin
Last : Index:= Index’Last; Last:= Last + 1;
Number_In_Buffer : Count := 0; Buf(Last):= Item;
Buf : Buffer; Number_In_Buffer:= Number_In_Buffer + 1;
end Bounded_Buffer; end Put;
end Bounded_Buffer;

5.6. Comunicación y sincronización mediante
mensajes.
• La alternativa al paradigma de memoria compartida lo constituye el paradigma
de paso de mensajes.
• Las variaciones en el modelo de sincronización de procesos surgen a partir de
la semántica de la operación send:
– Asíncrono: el emisor no espera a que el mensaje se reciba.
– Síncrono: el emisor continúa después de que el mensaje se reciba.
– Invocación Remota: el emisor continúa sólo cuando el receptor manda
una respuesta. Modela el paradigma de comunicación petición-respuesta.
Es el que incluye Ada.
Modelo de Ada
• Para que una tarea pueda recibir un mensaje debe definir una entrada (entry).
• Ésta entrada es invocada por otra tarea para enviar un mensaje.
task Tarea_Calculadora is
entry Suma(S1, S2 : Integer; Resultado : out Integer);
entry Resta(M, S : Integer; Resultado : out Integer);
end Tarea_Calculadora;
En otra tarea: Tarea_Calculadora.Suma(10, 15, c);
mensajes.
Modelo de Ada
• Se pueden definir entradas privadas: sólo pueden ser llamadas por tareas
locales al cuerpo de la tarea en la que se definen.
• También pueden haber entradas con igual nombre pero distintos parámetros.
task type Telephone_Operator is
entry Directory_Enquiry(Person : in Name; Addr : in Address; Num : out Number);
entry Directory_Enquiry(Person : in Name; Zip : in Postal_Code; Num : out Number);
entry Report_Fault(Num : Number);
private
entry Allocate_Repair_Worker(Num : out Number);
end Telephone_Operator;
• Se pueden definir conjuntos de entradas con un discriminante discreto.
type Channel_Number is new Integer range 1..7;
task Multiplexor is
entry Channels(Channel_Number) (Data : Input_Data);
end Multiplexor;
Se podría usar : Multiplexor.Channels(3)(Dato);
mensajes.
Modelo de Ada
• En Ada, entradas protegidas y entradas de tareas son idénticas desde la
perspectiva del llamador.
• Si se llama a la entrada de una tara inactiva, se eleva la excepción
Tasking_Error en el punto de llamada.
• Para poder recibir un mensaje, la tarea receptora tendrá que aceptar la llamada
a la entrada correspondiente.
accept Suma(S1, S2 : Integer; Resultado : out Integer) do
Resultado:= S1 + S2;
end Suma;
accept Channels(3)(Data : Input_Data) do
-- Almacena el dato para el tercer canal
end Channels;
• Todas las entradas deben tener accept’s asociados con ellas.
• La cláusula accept se puede poner en cualquier lugar del cuerpo de una tarea.
En particular, podría ponerse dentro de otro accept (siempre que sea de una
entrada diferente). No se puede poner en un procedimiento.

mensajes.
Modelo de Ada
• Existe la posibilidad de que se eleve una excepción dentro de una instrucción
accept:
– Si hay un manejador válido dentro de accept, éste termina normalmente.
– Caso contrario, el accept es terminado y se re-eleva la excepción en las
tareas llamadora (después de la llamada a la entrada) y llamada (después
del accept).
• Hasta ahora hemos visto como las dos tareas tienen que estar listas para
realizar la comunicación, la que llega primero a la cita se suspende hasta que la
otra ejecuta la acción complementaria (llamada ó aceptación).
• Hay ocasiones en las que no es posible prever el orden en que se van a invocar
las distintas entradas de un tarea. En estos caso se usa espera selectiva.
• Esto ocurre cuando una tarea servidora acepta llamadas de varios clientes, pero
no sabe el orden en que los clientes van a realizar las llamadas.
• Es necesario que una tarea pueda esperar simultáneamente llamadas en varias
entradas.
mensajes.
Modelo de Ada
• Para ello, Ada dispone de la cláusula select.
task body Tarea_Calculadora is ... select
begin when <Expresión_Booleana> =>
-- Inicialización del servicio accept <entrada> do . . . end <entrada>;
loop -- cualquier secuencia de instrucciones
select or
accept Suma (S1, S2: integer; S : out integer) do -- similar
... ...
end Suma; end select;
or
accept Resta (M, S: integer; R : out integer) do
...
end Resta;
end select;
end loop;
end Tarea_Calculadora;
• Además de las alternativas accept, pueden existir otras: una cláusula else, una
cláusula terminate o una cláusula delay.
mensajes.
Modelo de Ada
• Else se ejecuta si no hay otra alternativa inmediatamente ejecutable.
• Delay será estudiada en el tema siguiente.
• Terminate: sólo se puede elegir si no hay tareas que puedan invocar al select,
y la tarea que lo ejecuta será terminada.
procedure P is begin
task server is server.E1;
entry E1; -- Sin terminate, P nunca terminaría
end server; -- debido al bucle de la tarea server
task body server is begin end P;
loop
select
accept E1 do ... end E1;
or
terminate;
end select;
end loop;
end server;

Tema 5. Programación Concurrente

Cargado por

Copyright:

Formatos disponibles

Tema 5. Programación Concurrente

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 5. Programación Concurrente

Cargado por

Copyright:

Formatos disponibles

TEMA 5.

5.1. Ejecución concurrente.

inexistente creado iniciándose ejecutable

Tema 5. Programación concurrente. 2

Tema 5. Programación concurrente. 3

Tema 5. Programación concurrente. 5

inexistente creado iniciándose ejecutable

Tema 5. Programación concurrente. 7

– fork/join pid = fork(); /* Se crea un proceso idéntico al original */

– Declaración explícita de procesos

Tema 5. Programación concurrente. 12

Tema 5. Programación concurrente. 13

Tema 5. Programación concurrente. 15

Pantalla DAC Válvula

• El objetivo global del sistema es el de mantener la temperatura y presión de

Tema 5. Programación concurrente. 16

• Problema: Se basa en una espera ocupada. Además ambas actividades deberían

• Problema: No hay diferencia entre procedimientos y procesos concurrentes =>

Tema 5. Programación concurrente. 22

region V when condición is

Tema 5. Programación concurrente. 23

Tema 5. Programación concurrente. 27

Tema 5. Programación concurrente. 30

También podría gustarte