Sistemas operativos modernos

typedef int semaforo; semaforo recurso_1 ; semaforo recurso_2; void proceso_A(void) { down(&recurso_1); down{&recurso_2); usar_ambos_recursos{ ); up{&recurso_2); up(&recurso_1); } void proceso_B(void) { dovk/n(&recurso_1 ); down{&recurso_2); usar_ambos_recursos{ ); up(&recurso_2); up(&recurso_1); } semaforo recurso_1 ; semaforo recurso_2; void proceso_A(void) { down(&recurso_1); down(&recurso_2): usar_ambos_recursos( ); up(&recurso_2): up{&recurso_1); } void proceso_B(void) { down(&recurso_2): down(&recurso_1); usar_ambos_recursos( ); up(&recurso_1): up{&recurso_2); } (a) (b) Figura 3-2. a) Código sin bloqueos irreversibles, b) Código con un bloqueo irre­ versible potencial. 3.2 INTRODUCCIÓN A LOS BLOQUEOS IRREVERSIBLES Un bloqueo irreversible puede definirse de manera formal como se muestra a continuación: Un conjunto de procesos cae en un bloqueo irreversible si cada proceso del conjunto está es­ perando un suceso que sólo otro proceso del conjunto puede causar. Puesto que todos los procesos están esperando, ninguno de ellos causará jamás ninguno de los sucesos que podrían despertar a algún otro miembro del conjunto, y todos seguirán esperando en forma indefinida. En este modelo damos por hecho que los procesos tienen un solo subpro­ ceso y que no puede haber interrupciones que activen a un proceso bloqueado. Se requiere la condición de no interrupciones para evitar que un proceso que haya caído en un bloqueo irre­ versible sea activado por, digamos, una alarma, y luego cause sucesos que liberen a otros pro­ cesos del conjunto. En casi todos los casos, el suceso que los procesos están esperando es la liberación de al­ gún recurso que está en manos de otro miembro del conjunto. En otras palabras, cada miem­ bro del conjunto de procesos que haya caído en un bloqueo irreversible está esperando un recurso poseído por un proceso que también cayó en el bloqueo irreversible. Ninguno de los procesos puede ejecutarse, ninguno puede liberar recursos y ninguno puede despertar. No im