Práctica de programación concurrente ETSI Informática, UNED David Fernández-Amorós 1.

Transcripción

1 1. Enunciado Cuando un enfermo quiere a ir al médico, hace lo siguiente; primero necesita que uno de los operadores esté libre. Hay cinco operadores. El operador le indica al enfermo su número de operador y el enfermo lo apunta. El operador pregunta su número al enfermo y lo apunta también. El operador lleva la cuenta de cuantos clientes ha atendido. El enfermo tiene una conversación con el operador, que tiene que apuntar la cita con un programa informático, proceso que puede llevar bastante tiempo. Cuando la cita está registrada, el operador se lo comunica al enfermo, que cuelga el teléfono. Los enfermos siguen haciendo sus cosas, y después de un rato, se presentan en el médico. A veces la sala de espera está llena. En la sala de espera caben cuatro personas. Si la sala de espera está llena, el enfermo tiene que esperar en el pasillo, que no tiene límite de enfermos. Inicialmente, la consulta del médico está libre. Si la consulta del médico está libre, entonces un enfermo de la sala de espera puede pasar y entonces la consulta queda ocupada. El enfermo que lleva más rato esperando es el siguiente en pasar. Los enfermos pasan un rato en la consulta y luego se van, dejando la consulta libre para el siguiente enfermo. Se pide un programa en pseudocódigo que simule la situación descrita usando monitores o semáforos. Utilice dos tipos de proceso: enfermo y operador. Para que la simulación sea inteligible, los enfermos y operadores deben emitir mensajes informativos por pantalla cada vez que su situación se modifique. De esta forma, mirando la salida deberemos poder tener acceso a toda la información. Esto quiere decir que cuando un enfermo x habla con un operador y, debe indicarlo por pantalla, así como cuando reciba su cita. Del mismo modo, cuando la sala esté llena también debe indicarlo. Cuando vaya a la cita debe indicar si espera en la sala de espera o en pasillo. Cuando salga de la consulta también debe indicarlo... y así sucesivamente, de forma que pueda verificarse que el comportamiento descrito es coherente con el enunciado. La simulación debe contar con unas estructuras de datos que permitan resolver razonablemente el problema. Por razonable se entiende también que no enreden innecesariamente la solución. En particular, no se debe realizar gestión explícita de colas, sino utilizar las colas predefinidas por la herramienta de sincronización. Además, se prestará atención para evitar las situaciones de interbloqueo, inanición y espera activa. Se debe procurar un elevado grado de concurrencia entre los procesos. Si se identifica un problema-tipo (productores/consumidores o lectores/escritores) debe mencionarse explícitamente (incluyendo, en su caso, la prioridad más adecuada) antes de proceder con el pseudocódigo. Es muy importante que el comportamiento de los enfermos y operadores se ajuste al enunciado, tanto en los aspectos específicamente concurrentes como en los demás. 1

2 2. Trabajo del alumno Escriba un programa en pseudocódigo para realizar la simulación descrita. El pseudocódigo es una abstracción de un lenguaje de programación: Es un lenguaje formal, debe poder ser traducible fácilmente a un lenguaje de programación concreto, pero debe carecer de las engorrosas convenciones de estos, como podría ser una jerarquía de clases. Cualquier construcción habitual en un lenguaje de programación de alto nivel es aceptable, siempre que no oscurezca la solución con clases, excepciones y procedimientos auxiliares excesivamente numerosos. No se admitirá en ningún caso como pseudocódigo el código en un lenguaje de programación como Java o Ada, cuyas particularidades ocultan lo esencial en un mar de detalles de implementación ajenos al problema original. El libro de texto recomendado es un buen referente sobre como programar en un pseudocódigo parecido al PASCAL-FC. PASCAL-FC es un lenguaje de laboratorio en el que no importan ni la eficiencia, ni la portabilidad, ni ninguna característica avanzada que no esté relacionada con la programación concurrente. Algunos aspectos negativos de PASCAL-FC que deben evitarse en el pseudocódigo son las restricciones a la hora de inicializar o asignar arrays de forma global (e.d. en un pseudocódigo siempre se debe poder hacer) y la ausencia de un tipo de datos adecuado para las cadenas de caracteres (e.d. en un pseudocódigo debe existir un tipo abstracto de datos para manejar cómodamente las cadenas si es necesario). En el mencionado texto base, se eliminan todas las declaraciones que no son esenciales y se incluyen estratégicos puntos suspensivos para indicar que el programa hace otras cosas que no interesan. Conviene resaltar que los puntos suspensivos nunca se emplean como sustituto de un bucle for. Por otra parte, el pseudocódigo es detallado y concreto, en vez de vago y general. El libro de texto no es un buen referente sobre cómo programar en pseudocódigo parecido a Java, porque en Java importan la eficiencia y la portabilidad, y el lenguaje soporta muchas características avanzadas no relacionadas con la concurrencia. Por ese motivo, un buen pseudocódigo no se puede parecer mucho a un programa en Java. El pseudocódigo puede y debe contener comentarios explicativos. Los identificadores utilizados para las variables, los procedimientos etc... deben ser claros y explicativos de su función. Utilice como herramienta concurrente y de sincronización o bien monitores o bien semáforos. Una de las dos. No las dos a la vez. Deben utilizarse únicamente dos tipos de proceso: enfermo y operador. Deben evitarse, entre otros, los siguientes problemas: Violación de la exclusión mutua: Si, por ejemplo, dos enfermos intentaran hablar con el mismo operador al mismo tiempo. 2

3 Interbloqueo Espera ocupada: Por ejemplo, que un enfermo no pare de intentar hablar con un operador hasta que haya uno libre. O que un operador no pare de mirar si hay algún enfermo que necesita cita hasta que lo haya. Inanición: Por ejemplo, que un enfermo nunca consiga hablar con un operador mientras que otros enfermos que han llegado después hayan conseguido sus citas. Ausencia de concurrencia o baja concurrencia: Siempre debe ser posible que todos los operadores estén citando a enfermos al mismo tiempo, si hay suficientes enfermos demandándolo. Otro problema sería que se accediera a la consulta en exclusión mutua, es decir, bloqueando a todos los demás procesos, que tienen otras cosas que hacer (pedir citas, entrar en el pasillo... ). Gestión explícita de colas: Usar arrays para simular colas y gestionar la sincronización de forma explícita. Para lo único que se necesitan los arrays en este problema es para lanzar los procesos y para tener una herramienta de sincronización para cada proceso (e.d. arrays de variables de condición o arrays de semáforos según la herramienta elegida). No es necesario declarar arrays de enteros para almacenar identificadores de proceso. No cumplir el enunciado: Por ejemplo, que un proceso saque un mensaje que diga Soy el enfermo x y estoy hablando con el operador y cuando ese proceso enfermo no se ha comunicado en ningún momento con el proceso operador y. Programar una solución específica para un determinado número de procesos: Lo correcto es declarar unas constantes al principio del programa (p.e. CONST NUMOPERADORES = 5; NUMENFERMOS = 14) y después hacer referencia a esas constantes en el resto del pseudocódigo. Lo que no hay que hacer es un programa que funcione con 5 operadores pero no funcione con 3 o con 1. Establecimiento de turnos. No se debe hacer suposiciones sobre el orden en el que se pasan a ejecutar los procesos. En particular, no se debe establecer turnos. Por ejemplo, hacer que se ejecute un enfermo y luego un operador, luego un enfermo o un operarador y así sucesivamente. Aunque no forma parte de la documentación para la entrega, se recomienda programar la solución en un lenguaje de programación con el objeto de comprobar que no hay errores. En la página web de la asignatura se pueden encontrar compiladores para varios lenguajes de programación concurrente. Para las pruebas, y también para el pseudocódigo se recomienda que los procesos tengan un bucle infinito repeat... forever para que los enfermos, después de salir del médico vuelvan a pedir cita y los operadores sigan dando citas hasta el infinito. 3

4 3. Documentación para la entrega La práctica del alumno producirá únicamente una memoria explicativa. En el documento, preferentemente en formato pdf, se detallará claramente el nombre y apellidos del alumno y se numerarán todas las páginas. Si se ha detectado un problema-tipo aplicable al problema, consígnelo en este documento, junto con la solución al problema en pseudocódigo. La longitud de la memoria no podrá exceder de 10 diez páginas, en el peor de los casos, pero la longitud óptima es claramente mucho menor. La entrega consiste únicamente en la memoria. Dentro de la memoria y dentro del límite de páginas señalado debe encontrarse el programa en pseudocódigo y cuantas observaciones deseen hacerse. 4. Plazos y forma de entrega La memoria explicativa será entregada a través del curso virtual de la asignatura utilizando la herramienta de entrega de trabajos del mismo. El primer plazo de entrega será hasta las 23:50 del 9 de enero de No se admitirá la entrega de prácticas por correo salvo casos especiales (alumnos de centros penitenciarios, alumnos sin acceso al curso virtual o alumnos de convocatoria extraordinaria). En caso de que surja algún problema, es necesario ponerse en contacto con antelación con el equipo docente. Para la convocatoria de Septiembre existirá un nuevo plazo de entrega, desde el 1 hasta el 15 de julio de 2011 a las 23:50. Para la convocatoria extraordinaria de Diciembre de 2011, hay que ponerse en contacto con el equipo docente con suficiente antelación. Sea cual sea la forma de entrega, el plazo de entrega no excederá en ningún caso del comienzo de periodo de exámenes de Diciembre. No se aceptarán prácticas recibidas por correo electrónico u ordinario salvo autorización previa del equipo docente, excepción hecha de los casos mencionados en el primer párrafo de esta sección. 4

5 5. Evaluación La práctica es de carácter obligatorio e individual y la no superación de la misma implicará el suspenso automático en la asignatura. La práctica sólo tendrá la calificación de apto o no apto. Las prácticas aprobadas en la convocatoria de febrero subirán la nota final 0.5 puntos, únicamente en el caso de que la nota del examen sea mayor o igual a 4.5. Las prácticas aprobadas para la convocatoria de septiembre o diciembre no suben nota para el examen. La nota final dependerá de la evaluación y momento de entrega de la práctica y la nota del examen. La nota de la práctica podrá ser consultada a través de la herramienta trabajos del curso virtual. La calificación 1 indicará que la práctica ha sido calificada como no apta. La calificación 2 indicará que la práctica ha sido calificada como apta. Cada alumno puede comprobar a través del curso virtual si la práctica ha sido entregada. En la misma página donde se consulta la calificación de la práctica se puede comprobar si hay algún comentario del equipo docente. Hay que comprobar si hay comentarios antes de preguntar cuales son los errores detectados con la práctica. Hay que tener en cuenta que los resultados de las prácticas podrían no estar disponibles antes de la fecha del examen en cualquiera de las convocatorias. En dicho caso, es necesario presentarse al examen sin conocer si la práctica está aprobada o no. Si un alumno quiere pedir revisión de la práctica pero no hay tiempo para hacerla antes de los exámenes, deberá presentarse al examen, puesto que, si finalmente se aprueba la práctica pero no se ha realizado el examen, el aprobado en dicha convocatoria no sería posible. Los exámenes realizados por alumnos que no han aprobado la práctica no serán corregidos. 6. Dudas Antes de consultar dudas es obligatorio leer este enunciado y la sección de preguntas frecuentes (disponible, al menos, en la página web de la asignatura y a través del curso virtual). Las dudas relativas a la práctica o a cualquier otro aspecto de la asignatura podrán ser consultadas a través de los medios siguientes, clasificados por orden de prioridad: Mediante los tutores de la asignatura, en los centros asociados donde existan. 5

6 Mediante el curso virtual de la asignatura. Por correo electrónico a la dirección: Por teléfono ( ) durante el horario de atención a los alumnos. En persona, durante el horario de atención a los alumnos (actualmente, jueves lectivos de 16 a 20h, si hay cambios serán publicados en el BICI). Por correo ordinario a la siguiente dirección: David Fernández Amorós Despacho 2.11 ETSI Informática UNED C/Juan del Rosal, Madrid 6