1. Enunciado El problema de las ocho reinas consiste en situar ocho reinas en un tablero de ajedrez de forma que ninguna de ellas ataque a otra. Una solución clásica consiste en generar todas las posiciones legales mediante backtracking, de forma que cada vez que se logra una solución se imprime por pantalla. Contamos con un ordenador con n CPU disponibles y queremos aprovechar su potencia. Se pide resolver el problema de las ocho reinas mediante un programa concurrente escrito en pseudocódigo utilizando semáforos o bien monitores (no una mezcla de ambos) y memoria compartida. Utilice un único tipo de proceso: gestor. Queremos utilizar un gestor por cada una de las CPU disponibles. Los gestores parten de una solución parcial al problema e intentan extenderla añadiendo una reina más en posición legal (e.d. una disposición de las reinas en el tablero de forma que ninguna reina ataque a otra). Por ello, cada gestor va a funcionar en un bucle principal en el que se realizan una serie de tareas. En primer lugar se toma una solución parcial disponible. Si la solución parcial es una solución completa entonces se imprime la solución por pantalla. Si no, se genera un conjunto de nuevas soluciones parciales (solo si es posible extender la solución parcial) que cuentan con una reina más en posición legal y las pone a disposición de todos los gestores (incluido él mismo). El bucle se sigue ejecutando hasta que todas las posiblidades hayan sido analizadas, en cuyo momento todos los gestores deben finalizar. El programa principal se encargará de que una primera solución parcial vacía quede lista antes de lanzar los procesos gestores para permitir el arranque de todo el mecanismo. La simulación debe contar con unas estructuras de datos que permitan resolver el problema de forma razonable. 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 gestores 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 el cálculo descrito. 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 1
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 dicho texto base, se eliminan todas las declaraciones que no son esenciales y se incluyen estratégicos puntos suspensivos para no aburrir al lector. Al mismo tiempo, 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 deber 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. Debe utilizarse un único tipo de proceso: gestor. Deben evitarse, entre otros, los siguientes problemas: Interbloqueo Espera ocupada Inanición Ausencia de concurrencia o baja concurrencia. Por ejemplo, que un gestor bloquee el funcionamiento de los demás, no permitiendo que evalúen y generen nuevas soluciones parciales mientras él lo hace. Errores de sincronización. Por ejemplo, que varios gestores lean e intenten extender la misma solución parcial, o lo que sería incluso peor, que una solución parcial se pierda y no sea extendida por ningún gestor. Aunque no forma parte de la documentación para la entrega, se recomienda programar 2
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 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á entregadada 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 18 de enero de 2009. 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 1 de julio hasta el 15 de julio de 2009 a las 23:50. Para la convocatoria extraordinaria de Diciembre de 2009, 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. 3
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. Las prácticas aprobadas para la convocatoria de septiembre o diciembre no suben nota para el examen. El tiempo empleado en el curso virtual y la participación en los foros serán evaluados al final del cuatrimestre y podrán aumentar la nota de la asignatura hasta en 0.5 puntos. La nota final dependerá de la evaluación y momento de entrega de la práctica, de la consulta de contenidos del curso virtual, la participación en los foros 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. 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 (91 398 82 41) durante el horario de atención a los alumnos (jueves lectivos de 16 a 20h). 4
En persona, durante el horario de atención a los alumnos (jueves lectivos de 16 a 20h). 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