Abrazo mortal o deadlock. La cena de los filósofos

Por Patricia Seuba el 17 noviembre, 2010 en Informático |

El otro día hablaba de bucle y como último paso del bucle os comentaré lo que es un abrazo mortal o deadlock en informática. No hablamos del típico abrazo de oso o abrazo que damos a nuestros seres queridos, sino que hablamos de algo que en informática normalmente no queremos que ocurra ya que en estas situaciones los programas se quedarán “colgados” a falta de algo que necesitan.

Puede ser que este tipo de espera sea totalmente intencionado, del estilo en la vida real, del funcionamiento del teclado, en el cual siempre hay un programa esperando a que alguien teclee y en el momento que teclee, aparezca la tecla tecleada por pantalla.

Este tipo de problemas es muy ilustrativo contarlo con el maestro Dijkstra su cena de los filósofos.
Este problema lo explicaba para poder contar la sincronización entre los distinso procesos (programas en ejecución). Hay que aclarar que la ilustración muestra claramante que los filósofos eran comensales chinos por el tema de poder comer indistintamente con el cubierto derecho o izquierdo, que serían palillos.


Cinco comensales, filósofos, se sientan alrededor de esta mesa circular y se pasan el resto de sus días pensando y comiendo.

Cada filósofo tiene su plato de espagueti. Para poderlos comer se necesitan los dos palillos, debido a lo escurridizos que están.

Estos filósofos debe utilizar su tiempo de forma alterna comiendo o pensando.

Cuando un filósofo tiene hambre, trata de tomar los palillos, los dos que tiene a su lado, en el orden que quiera, pero uno cada vez que mueva la mano. Si logra coger los dos, podrá comer. Una vez que haya terminado de comer, dejará los dos cubiertos y seguirá pensando.

La pregunta al problema es: ¿podemos conseguir que cada filósofo coma y piense sin atorarse?

¿podríamos decidir que el filósofo tomara un cubierto y hasta no estar libre el otro, no soltarlo? Como es fácil deducir, esto haría que hubiera un deadlock ya que si los cinco toman el cubierto izquierdo a la vez, ninguno podría tomar el derecho y se produciría el deadlock.

También se podría hacer que cada vez que un filósofo cogiera el tenedor izquierdo, y no pudiera coger el tenedor derecho, soltara el tenedor izquierdo, esperar un tiempo y volverlo a intentar.
Esta solución también falla, verdad? Podrían, con un poco de mala suerte, que todos los filósofos quisieran comer al mismo tiempo y al final, cogerían el cubierto al mismo tiempo, lo soltarían y este proceso se repetiría indefinidamente sin conseguir que comieran.

Lo siguiente es pensar en que los filósofos comenzaran de forma aleatoria a comer, pero esto también podría darnos alguna repetición de números que podría ocasionarnos problemas. En ciertos sistemas se podría utilizar pero en sistemas de alta seguridad, no es recomendable.

Como habéis visto el nivel de posibilidad de que ocurra un abrazo mortal es alto y debe ser controlado. En el caso de la cena de los filósofos se controla con estrategias informáticas como semáforos y cambios de estado. Los semáforos son, como en la vida real, un indicador de que pude o no puede y cuando uno puede, el resto no. El problema es que sólo comería un filósofo y por ello se implementa un estado para poder controlar los semáforos con más de un filósofo.

Otros artículos que pueden interesarte:

Etiquetas:

1 Comentario

  • Enrique dice:

    Algunos fabricantes de software han implementado acciones a tomar por su cuenta en caso de que el desarrollador no haya tenido en cuenta la posibilidad del deadlock.
    Por ejemplo, Microsoft SQL Server (software de base de datos), cuando detecta un deadlock, automáticamente fulmina a uno de los dos procesos que pelea por el mismo recurso. De ese modo, no es raro encontrar en los logs de sistemas complejos el siguiente error:
    Transaction (Process 123456789) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction
    Traducción: La transacción (proceso nº 123456789) entró en abrazo mortal de recursos con otro proceso y ha sido elegido como víctima. Vuelva a ejecutar la transacción
    Traducción más profana: Había dos procesos peleándose por el mismo recurso y el tuyo ha sido elegido para ser fulminado. Vuelve a ejecutarlo… y entonces piensas “ejecutar ¿el qué?”

Copyright © 2010-2016 Patricia Seuba All rights reserved.

Desarrollado por: Sioseo