Programación Concurrente Prácticas 1, 2 y 3

Transcripción

1 Programación Concurrente Prácticas 1, 2 y 3 Dpto. LSIIS Unidad de Programación Convocatoria de Febrero curso 2006/2007 Normas La fecha límite de entrega de la práctica 1 es el 11 de diciembre de 2006 a las 21:00. La fecha límite de entrega de la práctica 2 es el 8 de enero de 2007 a las 21:00. La fecha límite de entrega de la práctica 3 es el 22 de enero de 2007 a las 21:00. Deberá mencionarse explícitamente el uso de recursos (código, algoritmos específicos, esquemas de implementación, etc.) que no hayan sido desarrollados por el alumno o proporcionados como parte de asignaturas de la carrera. La falta de esta mención podrá impedir aprobar las prácticas. Os recordamos que todas las prácticas entregadas pasan por un proceso automático de detección de copias. Los involucrados en la copia de una práctica corren el riesgo de suspenderlas suspenderlas para el año académico en curso, independientemente de la calidad o adecuación del código. 1. Pastas de té Una fábrica de pastas de té tiene tres hornos que producen pastas de diferentes pesos. Procedentes de los hornos, las pastas se van situando en una cinta transportadora común. Las pastas tienen que ser empaquetadas en cajas. Para ello, uno o varios robots empaquetadores toman pastas de la cinta y las introducen en la caja tal y como muestra la siguiente figura: Cada caja puede contener un número diferente de pastas siempre y cuando no se sobrepase un peso límite. Por este motivo, antes de incluir una pasta en la caja, cada empaquetador debe asegurarse de que con su inclusión no se sobrepasa el peso máximo. Si no se sobrepasa el peso se

2 2 Programación Concurrente incluye la pasta en la caja; en otro caso, un operario debe retirar la caja que se estaba llenando y sustituirla por otra vacía. El objetivo consiste en llenar cada caja lo más posible. Esto puede ser conseguido por cualquiera de los robots empaquetadores que intentan depositar simultáneamente alguna pasta. Se nos asegura que no puede haber interferencias físicas entre brazos robot que intentan soltar pastas al mismo tiempo en la caja. Se pretende que haya la máxima concurrencia posible entre los brazos robot, es decir, que varios de ellos puedan retirar simultáneamente pastas de la cinta transportadora y, también simultáneamente, dejarlas en la caja. Hay que evitar, por otro lado, que se sobrepase el peso máximo admitido por la caja y que se intenten dejar pastas cuando no hay caja o cuando se está reponiendo. Para desarrollar el software de control se dispone de un paquete en Ada ya programado que proporciona, entre otros, los siguientes procedimientos de acceso a los robots y dispositivos mecánicos (se ignoran los hornos y la cinta; no es asunto del software de control): with Basicos; use Basicos; package Cadena is N_EMPAQUETADORES : constant Positive := 10; type Id_Empaquetador is range 1.. N_EMPAQUETADORES; -- Retirar_Caja provoca que el brazo retire la caja que estaba -- siendo llenada, tiempo durante el cual el proceso que lo invoca -- queda bloqueado. Para poder invocarlo es necesario que haya una -- caja en la zona de llenado. procedure Retirar_Caja; -- Reponer_Caja provoca que el brazo auxiliar obtenga una nueva -- caja y la coloque en la zona de llenado, tiempo durante el cual -- el proceso que lo invoca queda bloqueado. Para poder invocarlo -- no debe haber ninguna caja en la zona de llenado. procedure Reponer_Caja; -- Tomar_Pasta provoca que el proceso que lo invoca quede -- bloqueado hasta que el el empaquetador con identificador E -- toma una pasta del mostrador y registra el peso de la misma en P. procedure Tomar_Pasta (E : in Id_Empaquetador; P : out Tipo_Peso_Pasta); -- Soltar_Pasta provoca que el proceso que lo invoca quede -- bloqueado hasta que el empaquetador con identificador E suelta -- la pasta. Es necesario que haya una caja en la zona de llenado -- y que el robot empaquetador en cuestión tenga una pasta. -- Físicamente, no hay interferencia entre dos robots que intentan -- depositar pastas simultáneamente en una misma caja. procedure Soltar_Pasta (E : in Id_Empaquetador); end Cadena;

3 Curso 2006/2007 Convocatoria de Febrero 3 2. Diseño Tras el análisis del problema, se incluye un diseño propuesto: grafo de recursos y procesos, código de los procesos y especificación del recurso. Asumimos que el recurso está contenido en una variable Cont_Caja accesible por los procesos cuyo tipo es Control_Caja Tomar_Pasta (E,P) Reponer_Caja Caja Empaquetadores (E) Comunicar_Peso (Caja, P) Incrementar_Peso (Caja, P) Notificar_Reposicion Brazo Notificar_Pasta_En_Caja (Caja) Preparar_Reposicion Soltar_Pasta (E) Retirar_Caja Declaración de recurso: Cont_Caja : Control_Caja; Controlador de empaquetador: loop Tomar_Pasta (E, Peso_Pasta); Put_Line ("Emp." & Id_Empaquetador Image (E) & " tomó pasta " & Tipo_Peso Image (Peso_Pasta)); Comunicar_Peso (Cont_Caja, Peso_Pasta); Incrementar_Peso (Cont_Caja, Peso_Pasta); Soltar_Pasta (E); Put_Line ("Emp." & Id_Empaquetador Image (E) & " soltó pasta " & Tipo_Peso Image (Peso_Pasta)); Notificar_Pasta_En_Caja (Cont_Caja); end loop; Controlador de reponedor: loop Preparar_Reposicion (Cont_Caja); Put_Line ("+++ Retiramos caja"); Retirar_Caja; Put_Line ("+++ Reponemos caja"); Reponer_Caja; Notificar_Reposicion (Cont_Caja); end loop; Especificación del recurso: C-TADSOL Control Caja OPERACIONES ACCIÓN Preparar Reposicion: Control Caja[io] ACCIÓN Notificar Reposicion: Control Caja[io] ACCIÓN Comunicar Peso: Control Caja[io] Peso[i] ACCIÓN Incrementar Peso: Control Caja[io] Peso[i] ACCIÓN Notificar Pasta En Caja: Control Caja[io] SEMÁNTICA DOMINIO:

4 4 Programación Concurrente TIPO: Control Caja= (peso: Peso estado: Estado accediendo: N) Estado = preparada a reponer reponiendo INICIAL(c): c = (0, preparada, 0) CPRE: c = (, a reponer, 0) Preparar Reposicion(c) POST: c sal = (c ent.peso, reponiendo, 0) CPRE: verdad Notificar Reposicion(c) POST: c sal = (0, preparada, 0) CPRE: c.estado reponiendo Comunicar Peso(c, p) POST: c ent = (pin,, a) (pin + p > P ESO MAXIMO c sal = (pin, a reponer, a)) (pin + p P ESO MAXIMO c sal = (pin, preparada, a)) CPRE: c.peso + p P ESO MAXIMO c.estado reponiendo Incrementar Peso(c, p) POST: c ent = (pin, e, a) c sal = (pin + p, e, a + 1) CPRE: verdad Notificar Pasta En Caja(c) POST: c ent = (pin, e, a) c sal = (pin, e, a 1) Notas informales sobre el funcionamiento del recurso La reposición pasa por tres fases: preparada (se pueden dejar pastas), a reponer (se debe reponer una caja, porque hay un robot que puede sobrepasar su capacidad) y reponiendo (se ha iniciado la secuencia de reposición). El estado a reponer no es irreversible, pues sólo señala que un brazo robot necesita una caja nueva, pero puede haber otro brazo que lleve una pasta de peso inferior al necesario para exceder el peso máximo de la caja. Si la señal de este segundo brazo llega a tiempo puede eliminar la petición de recambio y dejar una pasta que aún cabe en la caja. El estado reponiendo sí es irreversible, pues indica que el brazo reponedor ha recibido la necesidad de reposición e iniciará el proceso de cambio de caja. Para que haya un buen comportamiento en caso de varios robots, el peso de caja se guarda en el recurso, lo que garantiza su acceso atómico. La CPRE de Incrementar Peso asegura que: Ningún robot puede exceder el peso máximo (c.peso + p P ESO MAXIMO), pues se comprueba justo antes de intentar dejar la pasta y su POST incrementa (atómicamente) dicho peso antes de que este sea efectivo en la caja, con lo que el recurso contiene un avance del futuro de la caja y las decisiones tomadas según este valor son seguras. Ningún robot dejará una pasta mientras se está reponiendo la caja (c.estado reponiendo). Pero un robot cuya pasta no causa exceso de peso puede dejar la mercancía aunque haya otro robot bloqueado por su pasta mientras no se haya iniciado la secuencia de reposición. En este último caso, el robot que ha adelantado a los demás elimina la señal de reposición. Será este mismo (u otro, si hay más no bloqueados) el que la reactive, si es necesario, en el momento en que, tras dejar su pasta, adquiera otra del horno e intente depositarla en la caja. Esto intenta maximizar el peso final de la caja. De no hacerlo así, una solución extrema, correcta, pero evidentemente indeseable, es poner siempre una sola pasta y reponer la caja.

5 Curso 2006/2007 Convocatoria de Febrero 5 Una solucion que maximiza el peso en lo posible es esperar a todos los robots en una barrera, calcular qué combinación de pastas de entre las disponibles daría un mejor resultado, elegir la mejor de las pastas, depositar sólo esa pasta repetir el ciclo. Sin embargo esta solución tiene una concurrencia muy baja, ya que tiende a que en cada momento sólo un robot acceda a la caja y al mostrador. El conteo de número de brazos robot accediendo a la caja es necesario para implementar una exclusión parcial (como en los problemas de Lectores y Escritores) que impida que se inicie una reposición de la caja mientras un brazo robot accede a la misma. Ello podría suceder si mientras se deposita (físicamente) una pasta, otro robot excede el peso máximo y pide un cambio de caja que se inicia mientras el anterior está aún dejando la pasta. Por otra parte, se permite que varios brazos robots dejen simultáneamente pastas en la caja. 3. Prácticas 3.1. Primera práctica La entrega de la primera práctica constará de una implementación del recurso en Ada 95 usando objetos protegidos, basada en la especificación dada en el enunciado. La implementación a realizar debe estar contenida en un fichero llamado cajas de pastas.adb (ver el apartado 4) Segunda práctica La entrega de la segunda práctica constará de una implementación del recurso compartido en Ada 95 mediante rendez-vous y/o paso de mensajes y basada en la especificación entregada en el enunciado. La implementación deberá estar contenida en un fichero llamado cajas de pastas.adb (ver el apartado 4) Tercera práctica Supongamos una variación del problema original en la que los robots empaquetadores no registran el peso de las pastas, sino que la plataforma en que está la caja tiene una balanza y en el paquete Cadena se dispone de una operación Peso_Balanza(P: out Peso) que es no bloqueante y de ejecución prácticamente inmediata. La entrega de la tercera práctica constará de una memoria en papel con un nuevo diseño que debe cumplir en lo posible los mismos requisitos que se tenían para el problema inicial. Puede modificarse todo lo que sea necesario, tanto en el diseño del recurso como en el código de las tareas. Debe entregarse el grafo de procesos y recursos (si ha variado), la especificación formal del recurso necesario para la sincronización de los procesos y el código de los procesos en función de la interfaz del recurso especificado.

6 6 Programación Concurrente 4. Información general El texto de estas prácticas se encuentra en La entrega del código se realizará vía WWW en la dirección Las memorias pedidas (en la práctica 3) se entregarán en papel al profesor del grupo en el que se esté matriculado (se habilitará un buzón a la entrada de la unidad para ello). El código que entreguéis (para objetos protegidos o para paso de mensajes) no debe realizar ninguna operación de entrada / salida. Para facilitar la realización de la práctica se suministran varias unidades completas de compilación, de las que destacamos: fabrica: programa principal que arranca todas las demás tareas junto con el recurso compartido. cadena: simulación de las operaciones de una cadena como la descrita en el enunciado. Estas unidades están disponibles en En la misma dirección se puede encontrar el interfaz (cajas_de_pastas.ads) del paquete con el tipo que representa el recurso compartido y un esqueleto de código (cajas_de_pastas.adb) que debéis completar (y posteriormente entregar) con la implementación del recurso compartido mediante objetos protegidos y mediante paso de mensajes. El código que entreguéis debe poder compilarse y ejecutar sin errores junto con el resto de los paquetes entregados sin modificar estos últimos, aunque los cambiéis y ajustéis para hacer pruebas durante el desarrollo. Podéis utilizar las librerías auxiliares que están disponibles en Si os veis en la necesidad de usar algún otro paquete adicional que no venga con GNAT y que no os estemos proporcionando, hacédnoslo saber con antelación suficiente para evaluar la petición. El programa de recepción de prácticas podrá rechazar entregas que: Tengan errores de compilación. Utilicen otras librerías o paquetes aparte de los estándar de Ada y los que se han mencionado anteriormente. No estén suficientemente comentadas. Alrededor de un tercio de las líneas deben ser comentarios significativos. No se tomarán en consideración para su evaluación prácticas que tengan comentarios ficticios con el único propósito de rellenar espacio. Estén escritas con un estilo incorrecto: los programas se compilarán con el compilador GNAT y las opciones -gnaty -gnata. Recomendamos, por tanto, usar estas opciones para desarrollar las prácticas. No superen unas pruebas mínimas de ejecución.