1. Enunciado Tres barberos trabajan en una barbería. La barbería cuenta con tres sillones de barbero, cada uno asignado a uno de los barberos. Cada barbero desarrolla el siguiente plan de trabajo: El barbero duerme en su sillón cuando no hay ningún cliente esperando ni sentado en su sillón. Si hay clientes esperando, despierta al primero de la cola y le corta el pelo. Mientras duerme, el barbero espera a ser despertado por un nuevo cliente. Una vez despierto, el barbero corta el pelo del cliente en su sillón de barbero. Cuando el corte de pelo termina, el barbero se lo comunica al cliente, que paga al barbero y se marcha de la tienda. Después de cobrar, el barbero llama al siguiente cliente, si lo hay. Si hay algún cliente, este se sienta en el sillón del barbero, que comienza a cortarle el pelo. Si no hay clientes esperando, el barbero vuelve a dormir. Los clientes, a su vez, actúan según el siguiente esquema: Cuando el cliente entra en la barbería, si hay diez personas esperando, se va inmediatamente. En otro caso, el cliente entra y espera. Si algún barbero duerme, el cliente despierta al barbero que lleve más tiempo durmiendo y se sienta en su sillón, después de que el barbero se levante del mismo. Si todos los barberos están ocupados, el cliente se queda de pie. Los clientes llevan la vez, así que la persona que lleve más tiempo esperando desde que entró en la tienda es siempre la próxima en cortarse el pelo. Se pide simular el funcionamiento de la barbería mediante un problema concurrente escrito en pseudoćodigo. Los procesos deben emitir unos mensajes que ayuden a seguir la simulación, de forma que pueda saberse qué proceso emite el mensaje y qué acción realiza (entrar en la tienda, despertar a un barbero,... Si es un cliente o bien dormir, despertarse, cortar el pelo, cobrar,... Si es un barbero). Es muy importante que los tres barberos puedan estar simultáneamente cortando el pelo. Hay que tener en cuenta que cada corte de pelo puede tener una duración 1
distinta, por lo que cada barbero debe ser consciente de quién es su cliente, para avisar al cliente correcto y esperar al cobro. La simulación debe contar con unas estructuras de datos que permitan resolver el problema de forma razonable, sin usar colas. Además, se prestará atención para evitar las situaciones de interbloqueo, inanición y espera activa. Se debe procurar el máximo nivel 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 barberos y clientes se ajuste al enunciado, tanto en los aspectos específicamente concurrentes como en los demás. 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 2
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 monitores. Deben utilizarse únicamente dos tipos de proceso: barbero y cliente. No realice ninguna gestión explícita de colas. Las únicas colas deben ser las correspondientes a las variables de condición, que se manejan implícitamente mediante delay y resume. Deben evitarse, entre otros, los siguientes problemas: Gestión explícita de colas: Como por ejemplo, meter los identificadores de los clientes en una cola e ir sacándolos a medida que se sientan en un sillón de barbero. Interbloqueo. Espera activa. Inanición. Ausencia de concurrencia o baja concurrencia: En caso de que haya suficientes clientes, debe ser posible que los tres barberos esten cortando el pelo a la vez en un determinado momento. No se debe realizar el corte de pelo dentro de un procedimiento del monitor. 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. 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 3
de 4 cuatro páginas, en el peor de los casos, pero la longitud óptima es claramente mucho menor. El tamaño mínimo de punto será 12pt. 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 2013. 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 14 de julio de 2013 a las 23:50. Para la convocatoria extraordinaria de Diciembre de 2013, 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. 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. 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. 4
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 cuáles 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. Mediante el curso virtual de la asignatura. Por correo electrónico a la dirección: Por teléfono, actualmente 91 398 82 41, 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,16, 28040 Madrid 5