Sistemas operativos modernos

teriormente, ejecutando down con el semáforo para adquirir el recurso, usándolo y, por último, ejecutando up con el semáforo para liberar el recurso. Estos pasos se muestran en la figura 3-1 a. typedef int semaforo; typedef int semaforo; semaforo recurso_1 ; semaforo recurso_1 ; semaforo recurso_2; void proceso_A(void) { void proceso_A(void) { down(&recurso_1 ); down(&recurso_1 ); usar_recurso_1 ( ); down(&recurso_2); up(&recurso_1); usar_ambos_recursos( ); } up(&recurso_2): up(&recurso_1); } (a) (b) Figura 3"1. Uso de un semáforo para proteger recursos, a) Un recurso, b) Dos recursos. Hay ocasiones en que los procesos necesitan dos o más recursos. Éstos pueden obtenerse en sucesión, como se muestra en la figura 3-lb. Si se requieren más de dos recursos, simplemen­ te se obtienen uno tras otro. Hasta aquí, no hay problema. En tanto sólo intervenga un proceso, todo funciona bien. Cla­ ro que si sólo hay un proceso, no es necesario obtener formalmente los recursos, pues no hay competencia por ellos. Ahora consideremos una situación con dos procesos. A y B, y dos recursos. En la figura 3-2 se muestran dos situaciones posibles. En la figura 3-2a, ambos procesos piden los recursos en el mismo orden. En la figura 3-2b los solicitan en disfinto orden. Esta diferencia podría pa­ recer insignificante, pero no lo es. En la figura 3-2a, uno de los procesos adquirirá un recurso antes que el otro. El primer pro­ ceso obtendrá con éxito el recurso 2 y realizará su trabajo. Si el otro proceso intenta adquirir el recurso 1 antes de que éste se libere, simplemente se bloqueará hasta que el recurso esté dis­ ponible otra vez. En la figura 3-2b la situación es diferente. Podría suceder que uno de los procesos obten­ ga ambos recursos y bloquee efectivamente al otro hasta terminar. Sin embargo, también po­ dría suceder que el proceso A adquiera el recurso 1 y el proceso B el recurso 2. Ahora los dos se bloquearán al tratar de adquirir el recurso que no tienen. Ninguno de los procesos volverá a ejecutarse. Esta situación es un bloqueo irreversible. Aquí vemos cómo lo que parece ser una diferencia menor en el estilo de codificación —qué recurso se obtiene primero— da pie a la diferencia entre que el programa funcione y que falle por causas difíciles de detectar. Dada la facilidad con que pueden ocurrir los bloqueos irre­ versibles, se han realizado muchas investigaciones sobre las formas de enfrentarlos. En este ca­ pítulo tratamos con detalle los bloqueos irreversibles y lo que puede hacerse al respecto.