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

Transcripción

1 1. Enunciado En el bingo hay un presentador y varios jugadores. Antes de comenzar el juego, cada cliente se genera aleatoriamente una cantidad de cartones entre 1 y 10. Obviamente, todos los números de un cartón son distintos. Cada cartón contiene 15 números, de los 90 posibles. Cuando todos los jugadores han generado sus cartones, el presentador empieza a cantar los números. Cuando algún jugador tiene bingo, se lo comunica al presentador. El presentador confía en que los jugadores no le engañan con respecto al bingo, pero sólo el primero en gritar bingo es el ganador, de forma que el presentador debe confirmar al ganador y entonces la partida termina. Cada jugador empieza con 100. Cada cartón cuesta 5 y por cada bingo recibe el 90 % de lo recaudado. Un jugador no puede generar más cartones de los que puede pagar. Cuando la partida termina, se comienza una nueva entre los jugadores que todavía tengan suficiente dinero. Si no hay al menos dos jugadores que puedan pagar un cartón, el presentador cierra el bingo y todo acaba. 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. 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 algún 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 del presentador y los jugadores se ciñan al enunciado, tanto en los aspectos relativos a la concurrencia y sincronización como en los funcionales. Se pide un programa en pseudocódigo que simule la situación descrita usando monitores, semáforos o invocación remota. Si utiliza monitores o semáforos, emplee únicamente dos tipos de proceso: presentador y jugador. Si utiliza invocación remota, use cuantos tipos de proceso adicionales necesite. Para que la simulación sea inteligible, el presentador y los jugadores 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 jugador está listo para jugar, procesa un número, espera a que salgan número nuevos o tiene bingo, debe indicarlo en un mensaje por pantalla junto con toda la información complementaria necesaria (cuáles son los cartones que ha generado, cual es el número que va a procesar, cuánto dinero le queda... ). Análogamente, el presentador debe emitir mensajes cuando empieza una nueva partida, cuando emite números, cuando espera a que alguien anuncie un bingo... y así sucesivamente, de forma que pueda verificarse que el comportamiento descrito es coherente con el enunciado. 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), 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). Otro aspecto que mejora la legibilidad del pseudocódigo es el uso de tipos definidos por el usuario, otra característica que se echa en falta en PASCAL-FC. 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: 2

3 Pérdida de números: Unos jugadores leen los números que ha leído el presentador más rápido que otros, pero hasta que todos los jugadores no hayan leído un número salido del bombo, este no debe ser borrado de la estructura de datos correspondiente. Violación de la exclusión mutua: Si, por ejemplo, el presentador quiere introducir un nuevo número en un buffer de números que han salido del bombo mientras otro proceso le del mismo buffer. Inanición: Si, por ejemplo, un jugador se queda bloqueado esperando a que el presentador lea nuevos números y mientras tanto, otro jugador consigue bingo y el primer jugador nunca es despertado. Espera activa: Por ejemplo, que un jugador compruebe constantemente si el presentador ha anunciado números nuevos. Lo correcto es quedarse bloqueado y que el presentador lo despierte en su momento. Establecimiento de turnos: No se debe hacer suposiciones sobre el orden en el que se pasan a ejecutar los procesos. Por ejemplo, que el presentador espere a que todo los jugadores procesen un número antes de anunciar uno nuevo. El presentador debe leer los números tan rápido como sea posible hasta que alguien obtenga bingo o bien se acaben los números. Otro caso de establecimiento de turnos se produciría si los jugadores gestionaran sus cartones en exclusión mutua, uno cada vez. Ausencia de concurrencia o baja concurrencia: Por ejemplo, si la gestión de los cartones se hiciera en exclusión mutua. Se supone que los cartones son locales a cada proceso, por lo que cada jugador puede marcar los números que ya han salido a su ritmo. Lógicamente, los jugadores que juegan más cartones tenderán a tardar más en hacerlo que los que tienen menos, por lo que es de esperar que acumularán cierto retraso en el procesamiento de los números con respecto a los otros jugadores. Programar una solución específica para un determinado número de procesos o cantidad fija: Lo correcto es declarar unas constantes al principio del programa (p.e. CONST JUGADORES = 5; DINEROINICIAL=100; PRECIO=5 etc... ) 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 jugadores pero no funcione con 3 o con 4. Aunque no forma parte de la documentación para la entrega, se recomienda encarecidamente programar la solución en un lenguaje de programación concurrente con el objeto de comprobar que no hay errores. En la página web de la asignatura 3

4 se pueden encontrar compiladores para varios lenguajes de programación concurrente. No se aprobarán prácticas con errores obvios en el pseudocódigo como semáforos sin inicializar, ausencia de programa principal, procesos que no se lanzan etc Documentación para la entrega La práctica del alumno producirá únicamente una memoria explicativa. En el documento, 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 completo o a un subproblema, 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 8 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 14 de julio de 2012 a las 23:50. Para la convocatoria extraordinaria de Diciembre de 2012, 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 au- 4

5 torizació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. 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 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 5

6 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 , 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