Sistemas operativos modernos

de la matriz de la izquierda. El vector de recursos disponibles no es más que la diferencia en­ tre lo que el sistema tiene y lo que se está usando en el momento. Ahora podemos plantear el algoritmo para verificar si un estado es seguro o no. 1. Buscar una fila, R, cuyas necesidades de recursos insafisfechas sean menores o igua­ les que A. Si no existe tal fila, en algún momento el sistema caerá en un bloqueo irre­ versible porque ningún proceso puede terminar. 2. Suponer que el proceso de la fila escogida solicita todos los recursos que necesita (lo cual se garanfiza que es posible) y termina. Ese proceso se marca como terminado y todos sus recursos se suman al vector A. 3. Repetir los pasos 1 y 2 hasta que todos los procesos se hayan marcado como termina­ dos, lo que quiere decir que el estado inicial era seguro, o hasta que se presente un blo­ queo irreversible, lo que indica que no lo era. Si en el paso 1 hay varios procesos que podrían escogerse, no importa cuál se escoja: el con­ junto de recursos disponibles crecerá o, en el peor de los casos, seguirá igual. Volvamos al ejemplo de la figura 3-12. El estado actual es seguro. Ahora supongamos que el proceso B solicita una impresora. Esta solicitud puede concederse porque el estado resultante si­ gue siendo seguro (el proceso D puede terminar, y luego el proceso A o el £, seguidos del resto). Ahora imaginemos que después de entregar a B una de las dos impresoras restantes, E quiere ia última impresora. Satisfacer esa solicitud reduciría el vector de recursos disponibles a (1 OO0), y eso conduciría a un bloqueo irreversible. Es evidente que la solicitud de E debe aplazarse por el momento. Dijkstra fue el primero en publicar el algoritmo del banquero, en 1965. Desde entonces, casi todos los libros sobre sistemas operativos lo han descrito con detalle. Se han escrito innu­ merables artículos acerca de diversos aspectos ^el algoritmo. Lamentablemente, pocos autores han tenido la audacia de señalar que aunque en teoría el algoritmo es maravilloso, en la prác­ tica resulta poco menos que inúfil, porque los procesos casi nunca saben con antelación cuáles serán sus necesidades máximas de recursos. Además, el número de procesos no es fijo, sino que varía en forma dinámica a medida que los usuarios inician o terminan sesiones. Asimismo, los recursos que se creían disponibles pueden desaparecer repentinamente (una unidad de cin­ ta podría sufrir un desperfecto). Por ello, en la práctica, pocos sistemas existentes, o ninguno, utilizan el algoritmo del banquero para evitar bloqueos irreversibles. 3.6 PREVENCION DE BLOQUEOS IRREVERSIBLES Habiendo visto que es casi imposible evitar los bloqueos irreversibles, pues se requiere infor­ mación sobre solicitudes futuras, la cual no se tiene, ¿cómo evitan los sistemas reales caer en bloqueos irreversibles? La respuesta es: volviendo a las cuatro condiciones planteadas por Coffman et al. (1971) para ver si pueden sugerir una solución. Si podemos garantizar que al menos una de esas condiciones nunca se cumpla, los bloqueos irreversibles serán estructural­ mente imposibles (Havender, 1968).