Ejercicio 1 (1 - webdiis.unizar.eswebdiis.unizar.es/asignaturas/pscd/lib/exe/fetch.php?media=... ·...

Programación Concurrente 1ª Convocatoria 00/01 (07/06/01) Ing. Informática. C.P.S. Universidad de Zaragoza

Tiempo total para el examen: 2:00 horas

PRIMERA PARTE Ejercicio 1 (2.0 ptos.): Responder de manera concisa y razonada a las siguientes cuestiones:

1. La composición concurrente de acciones implica la ejecución paralela de las acciones compuestas.

2. La equidad de un programa concurrente siempre requiere un scheduler equitativo.

3. Un semáforo es un dato de tipo entero cuyo valor se incrementa o decrementa en una unidad mediante sus operaciones “send” and “wait”, respectivamente.

4. Una operación “wait” sobre un semáforo provoca la suspensión temporal del proceso que la invoca.

5. Siendo “s” un semáforo, la ejecución de la instrucción “send(s)” provoca la reanudación de todos los procesos que estaban ejecutando un “wait(s)”.

6. Los monitores permiten la comunicación y la sincronización de los procesos de un programa concurrente.

7. Cuando ningún proceso está ejecutando una acción de un monitor, los valores de las variables permanentes del monitor están indefinidos.

8. Para demostrar la corrección de un monitor, hay que probar que el invariante del monitor se verifica en . . . . . . .

9. A partir del momento en que se inicia la ejecución de alguna operación sobre un monitor, ningún otro proceso puede usar dicho monitor hasta que el único que lo usa termine de realizar la operación en cuestión.

10. Para que dos procesos puedan comunicar mediante paso asíncrono de mensajes, es necesario que cada uno conozca la identidad del otro.

La segunda parte del examen será entregada cuando se deposite la primera


Tiempo total para el examen: 2:00 horas

SEGUNDA PARTE

Ejercicio 2 (2.0 ptos.): Supongamos que disponemos de un procesador con una acción “swap(v1,v2)” que, de manera atómica, intercambia los valores de las variables escalares que se pasan como parámetros. El ejercicio pide desarrollar una solución al problema de la sección crítica para n procesos. Además, hay que dar un invariante global para dicho programa y razonar sobre el cumplimiento de las propiedades exigidas a las soluciones a dicho problema.

La segunda parte del examen será entregada cuando se deposite la primera


Ejercicio 1 (2.0 ptos.): Considerar el siguiente programa concurrente: Vars turno: Ent := 1 P1:: P2:: Mq TRUE Mq TRUE Mq turno = 2 Mq turno = 1 seguir seguir FMq FMq secciónCrítica1 secciónCrítica2 turno := 2 turno := 1 secciónNoCrítica1 secciónNoCrítica2 FMq FMq • Probar formalmente que el programa asegura la exclusión mutua en

la ejecución de las secciones críticas • Comentar razonadamente si el programa cumple o no las demás

propiedades deseables en los algoritmos de exclusión mutua • Escribir el código correspondiente a una adaptación del algoritmo

para el caso de n procesos

Tiempo total para la realización del examen: 1:45 horas


Ejercicio 2 (2.0 ptos.): Un grafo de precedencias de tareas es un grafo dirigido acíclico que establece un orden de ejecución de tareas de un programa concurrente, de manera que una tarea no puede empezar a ejecutarse hasta que las que sean anteriores en el grafo hayan terminado. Por ejemplo, si consideramos el grafo de la figura 1, la tarea P4 no puede empezar a ejecutarse hasta que P2 y P1 terminen, mientras que P5 no puede empezar hasta que P1, P2, P3 y P4 hayan terminado. Asumamos que cada tarea ejecuta el siguiente código: espera a que las tareas anteriores terminen ejecuta el cuerpo de la tarea avisa de su terminación a quien corresponda 1. Usando semáforos, escribir el programa concurrente correspondiente

al diagrama de la figura 1 2. Esquematizar un método general de sincronización para un grafo de

precedencias general. Calcular el número de semáforos que el método utilizaría. Este número se puede poner, por ejemplo, como función del número de tareas, de arcos, etc.

P1

P2

P5P3

P4

Figura 1. Un grafo de precedencias



Ejercicio 1: Considerar el programa concurrente (parcial) que se muestra a continuación. Vars x,v:Ent; p: booleano P1:: P2:: . . . . . . --Q1 --Q2 x --R1 --R2 x := x + v p := >0

. . . . . . El ejercicio requiere anotar el programa y probar bajo qué condiciones (si las hay) se puede asegurar la ausencia de interferencias y bajo qué condiciones (si las hay) puede haber interferencias. Ejercicio 2: Considérese el problema de implementar una barrera para n procesos, con el esquema de código que se muestra a continuación. P(i: 1..n):: Mq TRUE código propio -- lo relativo a la barrera FMq Monitor barreraDeN ... Fin monitor Se pide implementar el código del monitor barreraDeN, así como completar el código de los procesos. Razonar sobre la corrección de la solución propuesta. Ejercicio 3: Considerando el esquema del ejercicio anterior, dar una implementación en Ada de un programa en el que 4 procesos deben sincronizar por barrera. Se valorará que la solución sea fácilmente generalizable a casos con más generales. Ejercicio 4: Considerar el código Ada en el Anexo-I, en el que dos tareas se ejecutan concurrentemente compartiendo varias variables enteras. Dicha ejecución presenta un problema: nada impide que se use una



variable en una expresión con un valor todavía indefinido. Se pide lo siguiente:

• Modificar el programa de manera que ninguna variable se use antes de ser inicializada.

• ¿Podría un programa escrito de acuerdo a la propuesta anterior llegar a bloquearse? Si es así, escribir un ejemplo sencillo de bloqueo. Si no es posible, justificar "de manera convincente" por qué es así.

Anexo-I ------------------------------------------------ with Ada.text_io; use Ada.text_io; with Ada.integer_text_io; use Ada.integer_text_io; procedure ejercicio is a,b,c,d,e: integer; ------------------------------------------------ task t1; task t2; ------------------------------------------------ task body t1 is begin get(a); get(b); c := a+b; b := 2*d*e; end t1; ------------------------------------------------ task body t2 is begin get(c); get(d); b := a+d+c; get(e); e := e*e; end t2; ------------------------------------------------ begin null; end ejercicio;



Ejercicio 1 (2.5 ptos.): Considerar el siguiente programa concurrente: Vars s: Ent := 1 P1:: P2:: --Q_1 --Q_2 Mq TRUE Mq TRUE <await s>0 <await s>0 s := s-1 s := s-1 > > S_1 S_2 <s := s+1> <s := s+1> --R_1 --R_2 FMq FMq donde ni S_1 ni S_2 modifican la variable s y los predicados de la especificación no dependen de s. Se pide lo siguiente:

• Anotar completamente ambos procesos, y probar la corrección de cada uno de ellos.

• Probar que las verificaciones son libres de interferencias. • Probar que S_1 y S_2 se ejecutan en exclusión mutua.



Ejercicio 2 (2.5 ptos.): Considerar el código Ada en el Anexo-I, en el que dos tareas se ejecutan concurrentemente compartiendo varias variables enteras. Dicha ejecución presenta un problema: nada impide que se use una variable en una expresión con un valor todavía indefinido. Se pide lo siguiente:

• Utilizando el paquete de semáforos, completar el código de dicho programa de manera que nunca una variable sea usada en una expresión antes de que se le haya asignado un valor, ya sea mediante una instrucción get o una asignación.

• Explicar cómo se generalizaría dicha solución para cualquier programa.

• ¿Podría un programa escrito de acuerdo a la propuesta anterior llegar a bloquearse? Si es así, escribir un ejemplo sencillo de bloqueo. Si no es posible, justificar "de manera convincente" por qué es así.

• Para el ejemplo concreto en el Anexo-I plantear una solución alternativa en Ada que no requiera el uso de semáforos y, análogamente al caso anterior, explicar cómo puede generalizarse para cualquier programa.

Ejercicio 3 (3.0 ptos.) La gerencia de una empresa está compuesta por el director y cuatro subdirectores. Además, el director dispone de un secretario. Para el día de hoy hay convocada una reunión de los 5 miembros de la gerencia en la sala de reuniones de la sede principal de la empresa. Dado que los subdirectores tienen que venir de distintos sitios, el director se encuentra trabajando en su despacho. Cuando todos los subdirectores se encuentran en la sala de reuniones, el secretario avisará al director, y la reunión podrá empezar. Cuando el director se retire, la reunión se dará por concluida, pudiendo volver cada subdirector a su origen. El ejercicio pide diseñar un programa concurrente y dar una implementación en ADA que simule el sistema desde el momento en que el director cursa la orden al secretario para que convoque una reunión y hasta que cada subdirector vuelve a su destino una vez finalizada la misma. Pare ello hay que tener en cuenta que: • cada persona que aparece en el enunciado se representará mediante

una tarea ADA.



• las duraciones que aparezcan en el diseño (tiempo de viaje de un

subdirector desde/hasta la sede central, tiempo de duración de la reunión, etc.) se establecen arbitrariamente.

Responder también a las siguientes cuestiones: • ¿Se puede bloquear el programa? • ¿Se trata de un programa equitativo? • Asumiendo que cada subdirector atiende la llamada a reunión en

cuanto la recibe (pero que, aunque a todos se les envía la convocatoria en el mismo instante, por cuestiones de saturación de tráfico de redes no necesariamente todos la reciben a la vez), estimar el tiempo máximo y mínimo transcurrido desde el momento en que se lanza la convocatoria de reunión hasta que ésta puede empezar a celebrarse.

• ¿Cómo habría que modificar el programa para tener en cuenta que los dos primeros subdirectores viven en la misma ciudad, y que, por lo tanto, en cuanto reciben la convocatoria quedan de acuerdo para realizar el viaje juntos?



Anexo-I package semaforos is subtype numBin is integer range 0..1; protected type semaforo(valInicial: integer := 1) is entry wait; procedure send; private valor: natural := valInicial; end semaforo; protected type semaforoBinario(valInicial: numBin := 1) is entry wait; entry send; private valor: numBin := valInicial; end semaforoBinario; end semaforos; ------------------------------------------------ with Ada.text_io; use Ada.text_io; with Ada.integer_text_io; use Ada.integer_text_io; procedure ejercicio2 is a,b,c,d: integer; ------------------------------------------------ task t1; task t2; ------------------------------------------------ task body t1 is begin get(a); c := a+b; b := 2*d; end t1; ------------------------------------------------ task body t2 is begin get(c); get(d); b := a+d+c; end t2; ------------------------------------------------ begin null; end ejercicio2;



Ejercicio 1 (2.5 ptos.): Considerar el código Ada en el Anexo-I. El ejercicio pide completar el código de manera que se cumplan los siguientes requisitos: • el programa termine apropiadamente, habiendo procesado todos los

datos en el fichero de entrada. • hay que asegurar que los índices i1 e i2 leídos por un proceso sean

dos datos consecutivos del fichero "datosEntrada". • durante la ejecución de la invocación a modifica por parte de un

proceso, ningún otro proceso puede acceder a los datos vD(i1) y vD(i2).

• como mecanismo de sincronización se debe utilizar el paquete de semáforos binarios especificado en el Anexo-I. No se permiten utilizar ni más tareas ni objetos protegidos.

• es muy importante que haya tanta concurrencia como sea posible; es decir, que el número de entrelazados que se prohíban por las sincronizaciones impuestas sea tan pequeño como sea posible. No es aceptable, por ejemplo, encapsular en una exclusión mutua el acceso al vector completo de datos, ya que dos procesos accediendo a dos pares de datos distintos deberían poder hacerlo simultáneamente.

• razonar sobre el cumplimiento de todas los requerimientos por parte del programa desarrollado.



Ejercicio 2 (1.5 ptos.): Un sistema dispone de tres tipos de recursos, que vamos a denominar t1, t2 y t3. Para cada uno de los tres tipos el sistema dispone de 10, 5 y 8 unidades, respectivamente. Una tarea cliente ejecuta el siguiente bucle Mq TRUE obtener(n1,n2,n3) --0<=n1<=10, 0<=n2<=5, 0<=n3<=8 pedir al servidor los (n1,n2,n3) recursos trabajar con los recursos pedidos liberar los recursos FMq Asumamos que hay n procesos clientes con el esquema anterior. El programa se va a implementar en un entorno con comunicación asíncrona usando la notación algorítmica empleada en clase. Se pide: • escribir el código del proceso servidor. • escribir el código de los procesos cliente. • el programa ha de ser equitativo, en el sentido de que toda petición ha

de ser atendida tarde o temprano. • se valorará, además, que los procesos cliente sean atendidos en el

orden en que realizan las peticiones (evidentemente, cuando los recursos requeridos estén disponibles).

Nota: si se requieren estructuras de datos "complejas", como colas,

pilas, árboles, etc., no es necesario implementarlas; basta con especificarlas.



Anexo-I package semaforos is subtype numBin is integer range 0..1; protected type semaforoBinario(valInicial: numBin:= 1) is entry wait; entry send; private valor: numBin := valInicial; end semaforoBinario; end semaforos; ... with semaforos; use semaforos; procedure ejercicio1 is numProc: constant integer := 150; --num. de procesos maxDato: contstant integer := 10000; --datos en rango 1..10000 subtype rangoProc is integer range 1..numProc; subtype rangoDatos is integer range 1..maxDato; type vecDatos is array(rangoDatos) of integer; vD: vecDatos := (others => 0); fichEnt: Ada.Text_Io.File_Type; . . . ---------------------------------------------------------- procedure modifica(i1,i2: in rangoDatos; vD: in out vecDatos) is --Pre: TRUE --Post: trabaja modificando los datos vD(i1) y vD(i2) -- No importa cómo es esta modificación ---------------------------------------------------------- task type proceso(id: rangoProc); type ptProceso is access proceso; task body proceso is i1,i2: rangoDatos; . . .



begin . . . while . . . loop . . . get(fichEnt,i1); . . . get(fichEnt,i2); . . . modifica(i1,i2,vD); . . . end loop; . . . end; ---------------------------------------------------------- losProcesos: . . .; begin open(fichEnt,In_File,"datosEntrada"); --"datosEntrada" contiene un número par de datos, --correctos para el rango "rangoDatos" . . . --todos los procesos ya han terminado close(fichEnt); end ejercicio1;



Ejercicio 1 (2.0 ptos.): Considerar un sistema compuesto por 3 procesos como el que se detalla a continuación, que requieren el uso de un recurso compartido, pero que sólo puede ser usado simultáneamente por dos procesos. Vars ...... --sólo son necesarios enteros --I:...... (invariante global) P(i:1..3):: Mq TRUE <await C1 toma el recurso > usa el recurso <await C2 libera el recurso > FMq El ejercicio requiere: • Completar el código anterior de manera que se cumpla la propiedad

de seguridad: no más de dos procesos están usando simultáneamente el recurso.

• Definir un invariante global I que ayude a deducir la propiedad de uso correcto del recurso de acuerdo a las especificaciones.

• Deducir las guardas C1 y C2 que aseguren que el predicado I es efectivamente un invariante global.

• Probar que el programa cumple la propiedad de seguridad anteriormente citada.

• Definiendo que el programa es equitativo si en toda historia infinita todo proceso se ejecuta un número infinito de veces, ¿es el programa equitativo?

• Modificar el programa de manera que no sea posible que ningún proceso ejecute dos iteraciones consecutivas sin que entre ellas al menos un proceso diferente ejecute una iteración.



Ejercicio 2 (2.0 ptos.): Considerar el programa Ada que se muestra en el apéndice. Responder a las siguientes cuestiones: • ¿Se trata de un programa equitativo? Si la respuesta es no, escribir

una traza de ejecución infinita que no sea equitativa. • Entendiendo por bloqueo total un estado en que todos los procesos

están bloqueados, ¿existe un bloqueo total? Si es así, escribir una traza que lleve a un bloqueo total. Si no existe bloqueo total, razonar la respuesta.

• Se dice que el programa tiene un bloqueo parcial si existe alguna historia infinita en que algún proceso sólo aparece un número finito de veces. ¿Tiene el programa algún bloqueo parcial? Si la respuesta es afirmativa, escribir una traza de ejecución que corresponda a un bloqueo parcial.

• Si por razones de implementación el tipo buffer tuviera que ser de capacidad finita, ¿podría llegar a “desbordarse” o, equivalentemente, la ejecución de la primitiva “send” pudiera llegar a ser bloqueante?



APÉNDICE

generic type dato is private; package canalesAsinc is . . . protected type canalAsinc is procedure send(d: in dato); entry receive(d: out dato); -- implementa las primitivas de comunicación -- asíncrona usadas en clase private . . . end canalAsinc; private . . . end canalesAsinc; . . . procedure ejercicio2 is package paqCanales is new canalesAsinc(integer); c1,c2,c3,c4,c5: paqCanales.canalAsinc; ----------------------------------------------------------- task tarea1; task body tarea1 is semilla: Generator; v: integer; begin Ada.Numerics.Float_Random.reset(semilla); loop put_line("1_1"); if Ada.Numerics.Float_Random.random(semilla)<0.4 then c1.receive(v); put_line("1_2"); c4.send(1); put_line("1_3"); else c2.send(1); put_line("1_4"); c3.receive(v); put_line("1_5"); end if; end loop; end tarea1; -----------------------------------------------------------



task tarea2; task body tarea2 is sem enerator; illa: G v: integer; begin Ada.Numerics.Float_Random.reset(semilla); loop put_line(" 2_1"); if Ada.Numerics.Float_Random.random(semilla)<0.5 then c2.receive(v); c5.send(2); put_line(" 2_2"); c3.send(2); _line(" 2_3"); put else c4.receive(v); put_line(" 2_4"); c1.send(2); line(" 2_5"); put_ end if; end loop; end tarea2; ----------------------------------------------------------- task tarea3; task body tarea3 is priVez: boolean := true; v: integer; begin loop put_line(" 3_1"); if priVez then c5.receive(v); priVez := false; _line(" 3_2"); put else put_line(" 3_3"); end if; end loop; end tarea3; ----------------------------------------------------------- begin null; end ejercicio2;



Ejercicio 1 (4.0 ptos.) La gerencia de una empresa está compuesta por el director y cuatro subdirectores. Además, el director dispone de un secretario. Para el día de hoy hay convocada una reunión de los 5 miembros de la gerencia en la sala de reuniones de la sede principal de la empresa. Dado que los subdirectores tienen que venir de distintos sitios, el director se encuentra trabajando en su despacho. Cuando todos los subdirectores se encuentran en la sala de reuniones, el secretario avisará al director, y la reunión podrá empezar. Cuando el director se retire, la reunión se dará por concluida, pudiendo volver cada subdirector a su origen. El ejercicio pide diseñar un programa concurrente y dar una implementación en ADA que simule el sistema desde el momento en que el director cursa la orden al secretario para que convoque una reunión y hasta que cada subdirector vuelve a su destino una vez finalizada la misma. Pare ello hay que tener en cuenta que: • cada persona que aparece en el enunciado se representará mediante

una tarea ADA. • las duraciones que aparezcan en el diseño (tiempo de viaje de un

subdirector desde/hasta la sede central, tiempo de duración de la reunión, etc.) se establecen arbitrariamente.

Responder también a las siguientes cuestiones: • ¿Se puede bloquear el programa? • ¿Se trata de un programa equitativo? • Asumiendo que cada subdirector atiende la llamada a reunión en

cuanto la recibe (pero que, aunque a todos se les envía la convocatoria en el mismo instante, por cuestiones de saturación de tráfico de redes no necesariamente todos la reciben a la vez), estimar el tiempo máximo y mínimo transcurrido desde el momento en que se lanza la convocatoria de reunión hasta que ésta puede empezar a celebrarse.

• ¿Cómo habría que modificar el programa para tener en cuenta que los dos primeros subdirectores viven en la misma ciudad, y que, por lo tanto, en cuanto reciben la convocatoria quedan de acuerdo para realizar el viaje juntos?



Ejercicio 1 (2.0 ptos.): Considerar el fuente Ada que se muestra en el Anexo I. Vamos a definir una secuencia de ejecución como una secuencia de mensajes de salida P1 en casa P1 en r1 P2 en casa P2 en r3 P1 en casa P1 en r1 P2 en r2 P1 en casa P1 en r1 P2 en casa P2 en r3 P1 en casa P1 en r1 P2 en r2 ... resultado de una posible ejecución del programa. Una secuencia de ejecución infinita se dice equitativa si no es cierto que a partir de un momento dado sólo aparezcan mensajes de un mismo proceso. Se pide responder a las siguientes cuestiones: 1. ¿Existe alguna secuencia de ejecución infinita? Si es así, describirla. 2. En el caso de existir secuencias infinitas, ¿son éstas equitativas? 3. ¿Existe alguna secuencia que lleve a bloqueo? Si es así, describirla. 4. En el caso de que existan secuencias que lleven a bloqueo, añadir al

programa los elementos que se consideren necesarios de forma que en el programa modificado no hay bloqueos y las secuencias de ejecución sean un subconjunto de las secuencias de ejecución del programa original.

5. Sobre el programa resultado de 4, añadir los elementos necesarios para que además de ser libre de bloqueos sea equitativo (con la definición de equidad que hemos presentado arriba) manteniendo que las secuencias de ejecución de este último programa sea un subconjunto de las secuencias del programa del punto 4.

Nota: No se puede hacer ninguna suposición acerca del

funcionamiento del planificador de Ada, ni tampoco acerca de su comportamiento ante una instrucción “delay”.



Ejercicio 2 (2.0 ptos.): Varios procesos de dos tipos distintos, A y B, entran y salen de una habitación común. Una vez que un proceso de tipo A entra, sólo puede salir cuando se encuentre simultáneamente dentro de la habitación con dos procesos de tipo B; uno de tipo B que entra, sólo puede salir cuando se encuentre con uno de tipo A. Pero ojo: dado que por la puerta los procesos sólo pueden salir de uno en uno, si uno “pierde” la oportunidad de salir cuando había cumplido la condición de salida deberá esperar que ésta se vuelva a cumplir. Por ejemplo, supongamos el caso en que en un momento determinado se encuentran dentro un proceso tipo A (A1) y dos de tipo B (B1,B2). En un principio, cualquier de los tres puede salir. Supongamos que sale B1, con lo que en la habitación quedan A1 y B2. En este estado B2 podría salir, pero no A1, que ha perdido su oportunidad y debería esperar a que llegue otro de tipo B antes de poder salir. El ejercicio pide escribir un programa en Ada que simule el funcionamiento del sistema descrito. Para ello, hay que definir dos tipos de tarea, A y B, y lanzar 5 tareas de cada tipo. La habitación se modelará mediante un objeto protegido. Un ejemplo de resultado de una ejecución del simulador puede ser el siguiente: Proceso Accion Estado hab. A_1 entra (1,0) B_1 entra (1,1) B_1 sale (1,0) B_2 entra (1,1) B_1 entra (1,2) --A_1 podría salir B_2 sale (1,1) --A_1 ya no podría salir B_3 entra (1,2) --A_1 podría salir .....



Anexo I package semaforos is protected type semaforo(valInicial: integer := 1) is entry wait; procedure send; private valor: natural := valInicial; end semaforo; protected type semaforoBinario(valInicial: integer := 1) is entry wait; entry send; private valor: integer range 0..1 := valInicial; end semaforoBinario; end semaforos; with ada.text_io; use ada.text_io; with semaforos; use semaforos; with Ada.Numerics.Float_Random; use Ada.Numerics.Float_Random; procedure ejercicio1 is r1: semaforo(1); r2: semaforo(1); r3: semaforo(1); ---------------------------------------- task t1; task t2; ---------------------------------------- task body t1 is semilla: Generator; begin Ada.Numerics.Float_Random.reset(semilla); loop put_line("P1 en casa"); r1.wait; put_line("P1 en r1"); if Ada.Numerics.Float_Random.random(semilla)<0.7 then r1.send; else r2.wait; r1.send; put_line("P1 en r2"); r3.wait; r2.send;



put_line("P1 en r3"); r3.send; end if; end loop; end t1; ---------------------------------------- task body t2 is begin loop put_line(" P2 en casa"); r3.wait; put_line(" P2 en r3"); r2.wait; r3.send; put_line(" P2 en r2"); r2.send; end loop; end t2; ---------------------------------------- begin null; end ejercicio1;



Ejercicio 1 (4.0 ptos.): Escribir un programa completo en ADA de acuerdo con las siguientes especificaciones:

1. Lanza una tarea servidora para el acceso a una matriz de reales de dimensión 7x7.

2. Lanza 10 tareas cliente, de manera que cada una de ellas ejecuta durante 10 minutos el bucle que se esquematiza a continuación.

get(i);get(j);get(val); . . . asignar a la componente “(i,j)” de la matriz el valor “f(val)” . . .

Es preciso tener en cuenta que “f” es una función de tipo real, de la

que no sabemos nada. 3. Cuando todas las tareas cliente han terminado, lanza una tarea que

escribe por la salida estándar el contenido de la matriz. 4. Es preciso que la matriz sea inicializada con todas sus componentes

igual a 0.0 antes de que ninguna tarea cliente pueda acceder a la matriz.

El programa debe asegurar que el acceso a una componente de la matriz se haga en exclusión mutua para evitar interferencias entre los distintos procesos que la utilizan. Razonar sobre “la concurrencia permitida” por la solución presentada, y sobre cómo podría aumentarse.



Ejercicio 2 (2.0 ptos.): Considerar el siguiente programa concurrente:

Vars x: Ent := ???? --P P1:: P2:: <await x >= 3 <await x >= 2 x := x-3 x := x-1 > >

Establecer el predicado P más débil que haga que el programa anterior sea libre de bloqueos, asumiendo que el scheduler es débilmente equitatito. Ejercicio 3 (2.0 ptos.): El siguiente programa implementa una solución al problema de la sección crítica mediante el uso de una instrucción del tipo test-and-set, cuya semántica es la siguiente:

TS(cer,val): <val:=cer;cer:=TRUE>

Vars ocup:Bool := FALSE P1:: P2:: Vars val:Bool Vars val:Bool Mq TRUE Mq TRUE TS(ocup,val) TS(ocup,val) Mq val Mq val TS(ocup,val) TS(ocup,val) FMq FMq secCrit1 secCrit2 ocup:=FALSE ocup:=FALSE secNoCrit1 secNoCrit2 FMq FMq

Anotar el programa, y probar que, efectivamente, las secciones críticas de ambos procesos se ejecutan en exclusión mutua.



Ejercicio 1: Escribir un programa concurrente (en el lenguaje algorítmico utilizado en clase) para encontrar el máximo de un vector de n componentes enteras, de manera que un proceso busca en los índices pares y el otro en los impares. Anotar completamente el programa, y demostrar que los procesos son libres de interferencias. Ejercicio 2: Supongamos que disponemos de una montaña rusa que debemos controlar. Se trata de una atracción pequeña (sólo un vagón con capacidad para k pasajeros) y rácana (no se pone en marcha hasta que la vagoneta está llena, aunque haya que esperar una eternidad). Supongamos que hay hasta c posibles clientes (k < c). Se trata de, usando semáforos como método de sincronización, escribir el código (en el lenguaje algorítmico utilizado en clase) de los procesos "cliente" y el proceso "vagoneta". Definir el invariante (o invariantes) que sean útiles para asegurarnos de que el programa efectivamente implementa las especificaciones dadas. Ejercicio 3: Varios procesos de tres tipos distintos, A, B y C, entran y salen de una habitación común (que tiene un capacidad infinita). Una vez que un proceso de tipo A entra, sólo puede salir cuando se encuentre simultáneamente dentro de la habitación con dos procesos de tipo B y uno de tipo C; uno de tipo B que entra, sólo puede salir cuando se encuentre con uno de tipo A y uno de tipo C; un proceso de tipo C que entra en la habitación puede salir cuando le plazca. Pero ojo: dado que por la puerta los procesos sólo pueden salir de uno en uno, si uno “pierde” la oportunidad de salir cuando había cumplido la condición de salida deberá esperar a que ésta se vuelva a cumplir. Por ejemplo, supongamos el caso en que en un momento determinado se encuentran dentro un proceso tipo A (A1), un proceso de tipo C (C1) y dos de tipo B (B1,B2). En un principio, cualquiera de los tres puede salir. Supongamos que sale B1, con lo que en la habitación quedan A1, B2 y C1. En este estado B2 podría salir, pero no así A1, que ha perdido su oportunidad y debería esperar a que se den las condiciones adecuadas antes de poder salir. El ejercicio pide escribir un programa en Ada que simule el funcionamiento del sistema descrito. Para ello, hay que definir tres tipos de tarea, A, B y C, y lanzar 5 tareas de cada tipo. La habitación se modelará mediante un objeto protegido.



Un ejemplo de resultado de una ejecución del simulador puede ser el siguiente: ... A_2 ENTRA: (2 1 1) B_2 ENTRA: (2 2 1) A_1 SALE: (1 2 1) A_1 ENTRA: (2 2 1) A_ 2 SALE: (1 2 1) A_2 ENTRA: (2 2 1) C_2 ENTRA: (2 2 2) A_1 SALE: (1 2 2) A_1 ENTRA: (2 2 2) A_2 SALE: (1 2 2) ...




Ejercicio 1: Considerar el programa que se muestra a continuación. Probar que es correcto. Vars x,y:Ent --Q: x=y P1:: P2:: x := x-1 y := y+1 x := x+1 y := y-1 --R: x=y Ejercicio 2: Considérese la siguiente solución al problema de la sección crítica, basada en el uso de semáforos. Consts n: Ent := … --lo que sea Vars mutex: semaforo := 1 P(i: 1..n):: Mq TRUE wait(mutex) Sección Crítica send(mutex) Sección No Crítica FMq Responder a las siguientes cuestiones:

• Si el scheduler es fuertemente equitativo, ¿es el programa equitativo? (es decir, todo proceso que desee entrar a la sección crítica entrará). Si la respuesta es negativa, modificar el programa de manera que, asumiendo un scheduler fuertemente equitativo, se pueda asegurar un comportamiento equitativo (añadir el código que se considere necesario).

• Si el scheduler es débilmente equitativo, ¿es el programa equitativo? Si la respuesta es negativa, modificar el programa de manera que, asumiendo un scheduler débilmente equitativo, se pueda asegurar un comportamiento equitativo.

En ambos casos, razonar sobre la corrección de la solución propuesta, así como sobre el cumplimiento de las propiedades que habitualmente se buscan en algoritmos de exlusión mutua.



Ejercicio 3: Considerar un sistema compuesto por 3 procesos como el que se detalla a continuación, que requieren el uso de un recurso compartido, pero que sólo puede ser usado simultáneamente por dos procesos. Vars ...... --sólo son necesarios enteros --I:...... (invariante global) P(i:1..3):: Mq TRUE <await C1 toma el recurso > usa el recurso <await C2 libera el recurso > FMq El ejercicio requiere: • Completar el código anterior de manera que se cumpla la propiedad

de seguridad: no más de dos procesos están usando simultáneamente el recurso.

• Definir un invariante global I que ayude a deducir la propiedad de uso correcto del recurso de acuerdo a las especificaciones.

• Deducir las guardas C1 y C2 que aseguren que el predicado I es efectivamente un invariante global.

• Probar que el programa cumple la propiedad de seguridad anteriormente citada.

• Definiendo que el programa es equitativo si en toda historia infinita todo proceso se ejecuta un número infinito de veces, ¿es el programa equitativo?

Ejercicio 4: El ejercicio pide completar el código en el Anexo-I de manera que se cumplan los siguientes requisitos: • El programa termine apropiadamente, habiendo procesado todos los

datos en el fichero de entrada. • Se asegure que los índices i1 e i2 leídos por un proceso sean dos

datos consecutivos del fichero "datosEntrada".



• Durante la ejecución de la invocación a modifica por parte de un proceso, ningún otro proceso puede acceder a los datos vD(i1) y vD(i2).

• Se use como único mecanismo de sincronización el paquete de canales asíncronos especificado en el Anexo-I.

• Es importante que haya tanta concurrencia como sea posible; es decir, que el número de entrelazados que se prohíban por las sincronizaciones impuestas sea tan pequeño como sea posible. No es aceptable, por ejemplo, encapsular en una exclusión mutua el acceso al vector completo de datos, ya que dos procesos accediendo a dos pares de datos distintos deberían poder hacerlo simultáneamente.

• Razonar sobre el cumplimiento de todas los requerimientos por parte del programa desarrollado.



Anexo-I generic type dato is private; package canalesAsinc is . . . protected type canalAsinc is procedure send(d: in dato); --no bloqueante entry receive(d: out dato); private . . . end canalAsinc; private . . . end canalesAsinc;

. . . procedure modificaDatos is numProc: constant integer := 150; --num. de procesos maxDato: contstant integer := 10000; --datos en rango 1..10000 subtype rangoProc is integer range 1..numProc; subtype rangoDatos is integer range 1..maxDato; type vecDatos is array(rangoDatos) of integer; vD: vecDatos := (others => 0); fichEnt: Ada.Text_Io.File_Type; . . . ---------------------------------------------------------- procedure modifica(i1,i2: in rangoDatos; vD: in out vecDatos) is --Pre: TRUE --Post: trabaja modificando los datos vD(i1) y vD(i2) -- No importa cómo es esta modificación ---------------------------------------------------------- task type proceso(id: rangoProc); type ptProceso is access proceso; task body proceso is i1,i2: rangoDatos; . . . begin . . . while . . . loop . . . get(fichEnt,i1); . . . get(fichEnt,i2);



. . . modifica(i1,i2,vD); --en la modificación no itervienen más --componentes de vD que vD(i1) y vD(i2) . . . end loop; . . . end; ---------------------------------------------------------- losProcesos: . . .; . . . begin open(fichEnt,In_File,"datosEntrada"); --"datosEntrada" contiene un número par de datos, --correctos para el rango "rangoDatos" . . . --todos los procesos ya han terminado close(fichEnt); end modificaDatos;



Ejercicio 1: Considérese el caso de un sistema compuesto por un conjunto de procesos que utilizan Linda como mecanismo de coordinación. Cada proceso tiene que reunirse con su pareja correspondiente (un proceso iniciador se encarga de generar adecuadamente las parejas); una vez que se han reunido, se escribe un único mensaje indicando que la pareja ya se ha reunido, y a partir de ese momento ambos procesos pueden terminar. Completar el código que sigue de acuerdo con las especificaciones, teniendo en cuenta que es importante que el sistema tenga "tanta concurrencia" como sea posible. Consts n=2*50 Vars c: canalLinda P(i: 1..n):: --num. total de procesos ... Principio ... --espero a encontrarme con mi pareja --uno de los dos escribe el mensaje --me voy ... Fin ... Inicializador:: Principio --se ejecuta n/2 veces -- genera una pareja de procesos (p1,p2) -- c.write(["pareja",p1,p2]) --de manera que las n/2 posibles parejas están --bien formadas NO HAY QUE HACER NADA DE ESTA PARTE ... Fin

Ejercicio 2: Considerar un sistema compuesto por 2 procesos que iteran indefenidamente. Vars ...... --las que se consideren oportunas A(i:1..2):: Mq TRUE .... <await C .... > --tareas propias ....



FMq El ejercicio requiere: • Completar el código anterior de manera que se cumpla la propiedad

de equidad: nunca un proceso se ha de ejecutar más de 30 veces consecutivas sin una ejecución del otro proceso.

• Anotar adecuadamente el programa y probar que cumple la propiedad de equidad anteriormente citada.

Ejercicio 3: Considérese le esqueleto de programa Ada mostrado en el Anexo-I. Cada tarea está parametrizada por un vector de enteros que corresponde a los días, contados desde el 1 de enero de 2006 y ordenados cronológicamente, en que el correspondiente proceso visitará Zaragoza,. Así, si "a1(1)" y "a2(1)" son 32 y 16, respectivamente, quiere decir que el 1 de febrero es el primer día en que el primer proceso vendrá a nuestra ciudad, mientras que el segundo vendrá por primera vez el 16 de enero. El ejercicio pide completar el código del esqueleto de manera que se encuentre, para cada proceso, la primera posición de la agenda correspondiente en que los tres procesos coincidirán en Zaragoza en una fecha igual o posterior al valor "t" obtenido mediante "get(t)", asumiendo que dicha coincidencia existe.



Anexo-I ---------------------------------------------------------- -- Fich.: ejercicio3.ads -- Tema: Para el tercer ejercicio del examen de junio-06 -- Fecha: junio-06 -- Fuente: J. Ezpeleta -- Com.: Para examen junio-06 ---------------------------------------------------------- procedure ejercicio3 is n: constant integer := 100; type agenda is aliased array(1..n) of integer type ptAgenda is access agenda; task type proceso(p: ptAgenda) is . . . . end; task body proceso is . . . . end; a1,a2,a3: ptAgenda; t: integer; . . . . begin get(t); --se asume correcto . . . . for i in 1..n loop --lee de algún sitio a1.all(i), a2.all(i) y a3.all(i) --se asume hecho end loop; . . . . end ejercicio3;



Ejercicio 1: Considérese el siguiente trozo de código, correspondiente a la ejecución concurrente de tres procesos: Vars r1: Sem := 1 r2: Sem := K --un natural > 0 P1:: P2(i : 1..2):: Mq TRUE Mq TRUE wait(r1) wait(r2) --A --A(i) wait(r2) wait(r1) --B --B(i) send(r1) send(r2) --C --C(i) send(r2) send(r1) FMq FMq Responder a las siguientes cuestiones respecto al programa:

1. Razonar sobre si el programa tiene problemas de falta de equidad,

dependiendo del valor inicial K 2. Razonar sobre si el programa tiene problemas de bloqueos,

dependiendo del valor inicial K En función al valor de K, ¿se puede afirmar que el estado “C” de P1,

el estado “C(1)” de P(1) y el estado “C(2)” de P(2) están es exclusión mutua?

Sabemos que cuando K=2 el programa sí que tiene problemas de bloqueo. Plantear posibles soluciones e implementaciones para evitar que dichas situaciones de bloqueo puedan darse.



Ejercicio 2: Considérese un sistema de producción compuesto por los siguientes elementos:

• un proceso pBloques que constantemente produce bloques de metal en forma de cubo. Cuando un bloque es producido, lo introduce en el almacén AB con capacidad para kB (>0) bloques, si es que queda algún hueco. Si no lo hay, se queda esperando a que haya algún hueco antes de producir otro bloque

• un proceso pTuercas que constantemente produce tuercas y las deposita en el almacén AtyT para guardar tanto tuercas como tornillos (el almacén tiene capacidad para kTyT elementos, entre tuercas y tornillos)

• un proceso pTornillos que constantemente produce tornillos y los deposita en el mismo almacén usado para guardar las tuercas

• un proceso pEnsambla que toma un bloque, una tuerca y un tonillo, taladra el bloque e inserta y enrosca la tuerca y el tornillo

Diseñar y escribir el código del proceso pControlador, que controla el acceso a los dos almacenes, de manera que se asegure un buen comportamiento del sistema. Cualquiera de los proceso involucrados debe acceder a los almacenes a través del proceso controlador. Debe usarse paso síncrono de mensajes como mecanismo para la sincronización de los procesos involucrados, pBloques, pTornillos, pTuercas y pEnsambla, con el controlador.



Ejercicio 3: Considérese el siguiente entorno de datos Consts K= … --lo que sea, natural >=1 N=4*K Tipos vect= vector(1..N) de Ent Vars v: vect := . . . --asúmase que está inicializado suma: Ent := 0 --Q: v=V P(i:: 1..4): . . . --R : suma=V(1)+V(2)+ . . . +V(N)

en el que cuatro procesos pueden acceder concurrentemente a los datos del vector. Se pide:

• escribir el código de dichos procesos de manera que cada proceso sume no más de K componentes del vector, y, al terminar todos su ejecución, la variable “sum” contenga la suma de todas las componentes del vector. No podemos asumir que existan mecanimos para la sincronización de procesos, pero sí que el “scheduler” es incondicionalmente equitativo

• anotar el programa, y razonar sobre la corrección del mismo respecto a la especificación dada



Ejercicio 1: Considérese el siguiente programa concurrente: Const n= ... -- >0, lo que sea Vars turno: Ent := . . . -- 1<=turno<=n P(i: 1..n):: Mq TRUE Mq turno <> i seguir FMq secciónCrítica Si i=n Ent turno := 1 SiNo turno := i+1 FSi secciónNoCrítica FMq El ejercicio pide: • En caso de que fuera necesario, modificar el programa para asegurar

el acceso a la sección crítica en exclusión mutua. • Anotar y probar formalmente que el programa asegura la exclusión

mutua en la ejecución de las secciones críticas. • Comentar razonadamente si el programa cumple o no las demás

propiedades deseables en los algoritmos de exclusión mutua.



Ejercicio 2: Considérese el siguiente programa concurrente Consts nV1: Nat := NV1 -- >0 nV2: Nat := NV2 -- >0 nP1: Nat := NP1 -- >0 nP2: Nat := NP2 -- >0 . . . P1(i:1..nP1):: P2(i:1..nP2):: Mq TRUE Mq TRUE . . . . . . escribe(1) escribe(2) . . . . . . FMq FMq Se pide completar el código del programa anterior de manera que se cumpla la propiedad siguiente: “Nunca se escriben más de nV1 unos seguidos, ni más de nV2 doses seguidos”. Para la sincronización se deberá utilizar el modelo de coordinación Linda. Es necesario que se explique el diseño y que se razone sobre la corrección respecto a la propiedad especificada.



Ejercicio 3: Considérese el siguiente programa concurrente Consts n: Nat := N -- >0 Vars x,y,z: Ent Principio leer(x,y,z) PCo i:=1..n Vars miX: Ent leer(miX) <await x+y>0 z := 2*x y := y+1 > <z := z+3+miX> <await x>0 y := 2*x+y > Fco Fin Se pide escribir un programa Ada equivalente al mostrado.



Ejercicio 1: Comentar razonadamente las siguientes afirmaciones:

La equidad de un programa concurrente requiere, necesariamente, un “scheduler” equitativo.

En general, es más fácil probar propiedades de seguridad que de vivacidad

Considérese una instrucción “<await B S>”. ¿Qué se puede decir del comportamiento del programa concurrente que la contenga en uno de sus procesos P en relación a las variables involucradas en la guarda “B”.

En la programación con objetos protegidos en Ada, se considera “de muy mala educación” invocar desde el monitor a un procedimiento externo que a su vez pueda invocar al monitor.

Ejercicio 2: Considérese el esqueleto de código Ada en el Anexo-I, en el que se ponen en marcha 150 procesos, cada uno con su identificador correspondiente, que modifican los valores de una matriz común de datos. Se pide completarlo de manera que se asegure que no haya interferencias en el acceso a los datos compartidos. Hay que evitar soluciones que secuencialicen el programa innecesariamente. Por otro lado, para gestionar la concurrencia únicamente se puede utilizar el vector “vectSem”. Ejercicio 3: Probar por debilitamiento de aserciones que el siguiente programa es correcto Vars x: Entero := 0 --x = 0 PCo <x := x + 24> || <x := x + 2> || <x := x + 4> FCo --x = 30



Ejercicio 4: Una forma de obtener un valor aproximado de la integral de una función de una curva en un intervalo dado consiste en acumular la suma de las áreas de rectángulos que se aproximen a la curva tanto como sea posible. Véase un esquema en la figura 1. Es claro que cuanto más estrechos sean los rectángulos, mejor será la aproximación (y más cálculos habrá que hacer).

Figura 1. Cálculo aproximado de la integral

Por otro lado, el patrón de diseño “supervisor-worker” (figura 2) propone una organización sencilla en la que un proceso patrón suministra tareas a cada uno de los trabajodores a través de un medio común para el intercambio de información. Cada trabajador toma la solicitud, obtiene los resultados y los deposita en el medio común, quedando a la espera de nuevas tareas encargadas por el proceso patrón, o hasta que éste le indique que puede terminar. El patrón toma los resultados y actúa en función a cuál sea su objetivo.

Figura 2. Esquema del patrón-trabajador El ejercicio pide implementar, usando ese patrón, una solución al problema del cálculo del area bajo la curva “ f(x)=2x2 ”. Para ello hay que tener en cuenta las siguientes especificaciones:



el proceso patrón tiene como datos iniciales los valores de “a” y “b” (asumimos a<b) así como del valor “deltaX”, ancho de los rectángulos a considerar (deltaX<=(b-a)). Todos ellos son datos de tipo real

hay 20 procesos trabajador, todos ellos idéndicos (aunque puede que se ejecuten con velocidades distintas)

para cada rectángulo tomaremos como altura el valor de la función en el punto izquierdo de la base



Anexo-I package semaforos is subtype numBin is integer range 0..1; protected type semaforoBinario(valInicial: numBin:= 1) is entry wait; entry send; private valor: numBin := valInicial; end semaforoBinario; end semaforos; --no hay que implementar el paquete de semáforos with semaforos; use semaforos; procedure junio09 is numProc: constant integer := 150; --num. de procesos n: constant integer := 10; --num. de filas m: constant integer := 20; --num. de columnas maxSem: constant integer := 50; --num. máx de semáforos numVeces: constant integer := 100000; subtype rangoFil is integer range 1..n; subtype rangoCol is integer range 1..m; subtype rangoProc is integer range 1..numProc; dat: array(rangoFil,rangoCol) of integer; --matriz de datos vectSem: array(0..maxSem) of semaforoBinario; --los sem. nV: integer := 0; ... ---------------------------------------------------------- task type proceso(id: rangoProc); type ptProceso is access proceso; task body proceso is i1: rangoFil; i2: rangoCol; unDato: rangoCol; . . .



begin . . . nV := nV+1; while nV<=numVeces loop . . . get(i1); get(i2); get(unDato); . . . dat(i1,i2) := id*unDato; . . . nV := nV+1; . . . end loop; . . . end; ---------------------------------------------------------- losProcesos: . . .; begin . . . end junio09;



Ejercicio 1: Considérese la siguiente solución para el problema de los filósofos:

Consts n=N –-N>0 Vars s: Ent := 1 libre: vector(1..n) de Ent := (1..n,1) --P P(i=1..n):: Vars exito: booleano:=FALSE Mq TRUE Mq not exito <await s>0 s := s-1 > Si libre(i)=1 AND libre(i@1)=1 --@: suma módulo n Ent libre(i):=0 libre(i@1):=0 exito:=TRUE SiNo <s:=s+1> FSi FMq --comiendo exito:=FALSE libre(i):=1 libre(i@1)=1 <s:=s+1> FMq

Se pide lo siguiente:

Anotar el programa de manera que se pueda probar la siguiente afirmación: “cuando un filósofo está comiendo, éste ha cogido sus tenedores a izquierda y derecha”

Probar que dicha propiedad se cumple Probar que el programa es libre de bloqueos Comentar el comportamiento del programa en lo referente a

propiedades de equidad



Ejercicio 2: Considérense las siguientes instrucciones en un entorno de de procesos que se comunican mediante paso síncrono de mensajes, con la semántica estudiada en clase:

Sel Sel B1: C1;S1 B1;C1: S1 . . . . . . Bn: Cn;Sn Bn;Cn: Sn Fsel FSel

Justificar la afirmación: “En un caso general, ambas instrucciones tienen comportamientos diferentes”.

Estudiar si existen casos en que ambas instrucciones sean comportamentalmente equivalentes.

Ejercicio 3: Considérese el siguiente programa concurrente:

Consts n: Nat := N --N >0 Vars x,y,z: Ent Principio leer(x,y,z) PCo i:=1..n Vars miX: Ent leer(miX) <await x > y z := 2*x y := y+1 > <z := z+3+miX> <await x > 0 y := 2*x+y > Fco Fin

Se pide escribir un programa en Ada o Java que sea comporta-mentalmente equivalente al mostrado.



Ejercicio 4: Escribir un algoritmo para resolver el siguiente problema, asumiendo que los procesos utilizan comunicación asíncrona: “hay que escribir la secuencia ordenada de los 1000 primeros múltiplos de 2, los 1000 primeros múltiplos de 3 y los 1000 primeros múltiplos de 5 “. En la solución intervienen cuatro procesos: uno por cada secuencia de múltiplos y otro para ir escribiéndo la secuencia ordenada.

Programación Concurrente1a Convocatoria 10/11

13/06/11Depto. de Informática e Ingeniería de Sistemas

Universidad de Zaragoza

Ejercicio 1 (1.25 ptos.)

Considérese el esqueleto de código Ada que se muestra en el Anexo-I. El ejerciciopide completarlo, en Ada, con lo que sea necesario para que se cumpla la siguientepropiedad: En la secuencia de números de salida, nunca aparecen más de nV1datos seguidos escritos por tareas de tipo P1, ni más de nV2 datos seguidosescritos por tareas de tipo P2.

Razonar sobre el cumplimiento de la propiedad en la solución propuesta.


El Anexo-II muestra un algoritmo de sección crítica propuesto por Manna y Pnuelli

Suponiendo que la instrucción Si ...Fsi de los dos procesos no fuera atómica,encontrar una secuencia de ejecución que demuestre que en este caso no se cumplela propiedad de exclusión mutua.

Suponiendo ahora que la instrucción Si ...Fsi es atómica, probar la correccióndel algoritmo, entendiendo que se busca que los dos procesos no puedan estarsimultáneamente en las secciones críticas.

Comentar razonadamente si este último algoritmo cumple o no las demás propiedadesdeseables en los algoritmos de exclusión mutua.

1

Programación Concurrente. Curso 2010-11 1a Convocatoria 10/11 (13/06/11)


Considérese el esquema de programa que se muestra a continuación. Se pide escribirel código del proceso Productor y de los procesos de tipo Consumidor usando el canaltipo Linda y sus operadores de acceso de manera que el comportamiento sea el mismoque el mostrado (es decir, usar Linda para reemplazar las instrucciones 〈 . . . 〉).

No se admite una solución secuencial, valorándose el grado de paralelismo permitido.

Vars c: canalLinda

Productor ::Vars x: Ent := . . . --lo que sea

y: Ent := . . . --lo que seaz: Ent := . . . --lo que seaw: Ent := . . . --lo que sea

Principio. . .--almacena en Linda los valores de x, y, z, w. . .

Fin

Consumidor(i:1..300)::Vars miX: Ent

PrincipiomiX := . . . –-cualquier valor aleatorio

<await x+y>0y := y+1x := miX

><z := z+3+miX -w><await x>0

y := 2*x+y>

Fin

2


Anexo-I

with Ada.text_io; use Ada.text_io;

procedure ejercicio issubtype rangoProc1 is integer range 1..100;subtype rangoProc2 is integer range 101..200;nV1: constant integer := 33;nV2: constant integer := 17;...--------------------------------------task type P1(id: rangoProc1 );type ptP1 is access P1;

task body P1 is...

beginloop

...put_line(Integer ’Image(id));...

end loop;end;--------------------------------------task type P2(id: rangoProc2 );type ptP2 is access P2;

task body P2 is...

beginloop

...put_line(Integer ’Image(id));...

end loop;end;

procs_1: ...;procs_2: ...;...

begin...

end ejercicio;

3


Anexo-II

Vars wantP ,wantQ: Ent := 0

P:: Q::Mq TRUE Mq TRUE

secciónNoCrítica secciónNoCrítica

<Si wantQ = -1 Ent <Si wantP = -1 EntwantP := -1 wantQ := 1

SiNo SiNowantP := 1 wantQ := -1

Fsi > Fsi >

<await wantP /= wantQ > <await wantP /= -wantQ >

secciónCrítica secciónCríticawantP := 0 wantQ := 0

FMq FMq

4

Ejercicio 1 (1 - webdiis.unizar.eswebdiis.unizar.es/asignaturas/pscd/lib/exe/fetch.php?media=... ·...

Documents

Transcript of Ejercicio 1 (1 - webdiis.unizar.eswebdiis.unizar.es/asignaturas/pscd/lib/exe/fetch.php?media=... ·...