Up: Programación Concurrente
Previous: NORMAS
Subsections
CONTROLADOR DE UN APARCAMIENTO PARA COCHES Y
CAMIONES
En este documento se recoge el texto de la primera y segunda prácticas
de la asignatura. El problema a resolver será el mismo en cada una de
las prácticas, pero el mecanismo exigido para su resolución es
diferente.
Planteamiento de la práctica
En un aparcamiento se permite el estacionamiento de coches y camiones.
Este aparcamiento tiene una entrada y una salida para coches, y una
entrada y una salida para camiones (Figura 1). En
cada entrada y en cada salida hay una barrera que se levantará cuando
se permita el acceso al aparcamiento a un vehículo, o cuando vaya a
salir un vehículo del aparcamiento. Se supondrá que las plazas del
aparcamiento están numeradas y situadas a lo largo de una alineación,
y que un coche ocupa una plaza del aparcamiento (plazas 2 y 4, en la
figura), en tanto que un camión ocupa dos plazas contiguas (plaza 6,
en la figura). La gestión del aparcamiento se realizará de la
siguiente manera:
- Los vehículos se detienen en la barrera y esperan a que se les
expida una tarjeta con el número de plaza que les ha sido asignada.
Una vez que el usuario retira la tarjeta se levanta la barrera.
Mientras que un coche sólo necesita una plaza libre, un camión
precisa que existan dos plazas libres contiguas (la que se le indica
en la tarjeta y la siguiente).
- Cuando un conductor desee salir del aparcamiento debe insertar
su tarjeta en el lector de la barrera de salida, informando así de
qué plaza deja libre. A continuación se elevará la barrera.
Figure 1:
Esquema del aparcamiento
|
|
Requisitos a cumplir
La práctica consiste en implementar un gestor que controle las
entradas y salidas del aparcamiento. Para hacerlo se apoyará en una
interfaz con el mecanismo de las barreras basada en las operaciones
cuya cabecera y especificación informal aparecen a continuación:
- PROCEDURE ActivarSensorBarreraEnt(tipo: TipoVehiculo);
-
(*
Activa el sensor que hay delante de la barrera de entrada
cuando llega un vehículo.
*)
- PROCEDURE EsperarSensorEnt (tipo: TipoVehiculo);
-
(*
Espera a que llegue un vehículo a la barrera de entrada.
*)
- PROCEDURE EsperarTarjeta (tipo: TipoVehiculo; VAR
tarjeta: TipoPosicion);
-
(*
Espera a que la máquina expendedora emita una tarjeta para el
vehículo que hay delante de la barrera de entrada. A continuación,
se entrega la tarjeta al conductor del vehículo. La tarjeta indicará
la posición de la plaza que el vehículo debe ocupar en el
aparcamiento.
*)
- PROCEDURE LevantarBarreraEnt (tipo: TipoVehiculo; tarjeta: TipoPosicion);
-
(*
Emite la tarjeta para el conductor del vehículo indicando el número
de plaza asignada, levanta la barrera de entrada, espera a que pase el
vehículo, y baja la barrera.
*)
- PROCEDURE DevolverTarjeta (tipo: TipoVehiculo; tarjeta:
TipoPosicion);
-
(*
Introduce la tarjeta en la máquina lectora de tarjetas ubicada en la
barrera de salida.
*)
- PROCEDURE LeerTarjeta(tipo: TipoVehiculo; VAR tarjeta: TipoPosicion);
-
(*
Espera a que el conductor introduzca la tarjeta, la lee, levanta la
barrera de salida, espera a que pase el coche y baja la barrera.
Devuelve el número que le había sido asignado en la tarjeta al entrar
*)
Todas las llamadas anteriores esperan a que se termine la operación
correspondiente.
Figure 2:
Esquema del gestor, los procesos y los recursos externos
disponibles.
|
|
El gestor debe decidir, en las barreras de la entrada, si hay o no
plazas libres, y asignar adecuamente una de ellas al vehículo que
pretende entrar mediante una tarjeta que es recogida por el conductor.
El conductor devuelve esta tarjeta a la salida, y no es necesario
comprobar que la tarjeta que entrega el conductor es correcta.
Es importante que exista equidad entre los camiones y los coches. Si
hay un vehículo en una barrera de entrada debe existir la garantía de
que tarde o temprano va a poder acceder al aparcamiento. Nótese que
cualquier vehículo que esté en el aparcamiento debe salir en algún
momento futuro de él, y por lo tanto es seguro que habrá el espacio
que sea necesario. Por lo tanto, la espera de un vehículo no se debe
prolongar indefinidamente.
El gestor debe asegurar este comportamiento, no admitiéndose
como válidas soluciones en las que la vivacidad se base en retardos
ad-hoc, en un tamaño determinado del aparcamiento, en una
cadencia específica de la llegada y/o salida de coches, o en una
planificación determinada sobre la que no ejercemos control directo.
Hay diversas posibilidades para realizar esto: podéis escoger la que
prefiráis, siempre que no provoque inanición, interbloqueos, etc.
La implementación pedida se debe corresponder con el esquema de
procesos y recursos mostrado en la figura 2. Debe
realizarse el código de los procesos de control de cada una de las
barreras y el del gestor que implementa la sincronización en el
aparcamiento, respetando las indicaciones anteriormente reseñadas.
Entrega de la práctica
La entrega de la primera práctica constará de:
- Una memoria, conteniendo:
- 1.
- El grafo completo de procesos y recursos, mostrando
claramente las operaciones que se han considerado necesarias en el
gestor del aparcamiento, las operaciones del monitor
TipoBarrera, las tareas que simulan los vehículos, las
tareas que implementan las barreras, y qué operaciones de cada
monitor usa cada una de las tareas.
- 2.
- Una memoria con la especificación del C-TADSOL para el
recurso solicitado.
- 3.
- La tabla de desbloqueos del recurso solicitado, basada en las
precondiciones de concurrencia y postcondiciones recogidas en el
C-TADSOL.
- 4.
- Debe comentarse qué política se ha escogido para asegurar la
vivacidad y cómo se ha implementado esta política.
- Una implementación del recurso mediante monitores basada en la
especificación entregada y en la tabla de desbloqueos, usando el
lenguaje CcMódula. Cualquier decisión de diseño motivada
por cuestiones de vivacidad debe ser claramente comentada.
La entrega de la segunda práctica constará de:
- Una memoria, conteniendo:
- 1.
- El grafo de procesos para paso de mensajes.
- 2.
- Debe comentarse qué política se ha escogido para asegurar la
vivacidad y cómo se ha implementado esta política.
- Una implementación del recurso mediante recursos activos y paso
de mensajes, usando el lenguaje CcMódula y basada en la
especificación entregada como parte de la primera práctica.
Las memorias se entregarán en papel al profesor del grupo en el que se
esté matriculado. La implementación, que deberá estar autocontenida
en un fichero llamado aparc.ccm, se entregará en
el ordenador habilitado a tal efecto a la entrada de la Unidad de
Programación. Para facilitar la realización de la práctica se
suministra un esqueleto de programa en CcMódula que contiene:
- Código para simular el funcionamiento de las barreras y la
llegada y salida de los coches.
- Código para representar el estado del aparcamiento tras cada
entrada y salida de un vehículo.
- El programa principal, en el que se lanzan las tareas de control
de las barreras, una tarea que dibuja el estado del aparcamiento, y
la simulación de entrada y salida de los vehículos. Recomendamos,
por sencillez, respetar los nombres de las tareas de control. Salvo
el posible cambio de estos nombres, de los parámetros que definen el
número de vehículos o de los tiempos que cada uno pasa dentro y
fuera del aparcamiento, no debe alterarse el código
original. Debe consultarse con un profesor de la asignatura si
se percibe la necesidad de alterar este código.
- Espacio para incluir el código de las tareas y del recurso a
programar.
El código antedicho estará disponible en la dirección de WWW
El texto de esta práctica se encuentra en
Up: Programación Concurrente
Previous: NORMAS
Manuel Carro
mcarro at fi.upm.es
![\includegraphics[width=0.75\textwidth]{aparcamiento.eps}](img2.gif)
![\includegraphics[width=0.75\textwidth]{gestor}](img3.gif)