Sistemas operativos modernos

3.6.1 Cómo atacar la condición de exclusión mutua Ataquemos primero la condición de exclusión mutua. Si jamás se asignara un recurso en for­ ma exclusiva a un solo proceso, nunca tendríamos bloqueos irreversibles. Sin embargo, tam­ bién es obvio que permitir a dos procesos escribir en una impresora al mismo tiempo conduce al caos. Si hace spooling de las salidas a la impresora, varios procesos pueden generarlas al mismo tiempo. En este modelo, el único proceso que en realidad solicita la impresora física es el demonio de impresión. Puesto que éste nunca solicita otros recursos, podemos eliminar los bloqueos irreversibles a causa de la impresora. Lamentablemente, no todos los dispositivos pueden manejarse con spooling (la tabla de procesos no se presta a ese tratamiento). Además, la competencia misma por espacio en disco para el spooling puede llevar a un bloqueo irreversible. ¿Qué sucedería si dos procesos llena­ ran cada uno con sus salidas la mitad del espacio disponible para spooling y ninguno hubiera terminado todavía de generar salida? Si el demonio se programa de modo que comience a im­ primir antes de haber realizado spooling de todas las salidas, la impresora podría estar inacti­ va si un proceso decidiera esperar varias horas después de la primera ráfaga de salida. Por ello, los demonios generalmente se programan de modo que sólo impriman si ya recibieron todo el archivo de salida. En este caso tenemos dos procesos que sólo han terminado de generar una parte de sus salidas y no pueden continuar. Ninguno de los procesos terminará jamás, así que tenemos un bloqueo irreversible por causa del disco. No obstante, de aquí surge una idea que suele ser útil: evitar asignar un recurso si no es ab­ solutamente necesario, y tratar de asegurarse de que el número de procesos que podrían solici­ tar el recurso sea lo más pequeño posible. 3.6.2 Cómo atacar la condición de retener y esperar La segunda de las condiciones planteadas por Coffman et al. parece un poco más prometedo­ ra. Si podemos evitar que los procesos que tienen recursos esperen cuando tratan de adquirir más recursos, podremos eliminar los bloqueos irreversibles. Una forma de lograr este objetivo es exigir que todos los procesos soliciten lodos sus recursos antes de comenzar a ejecutarse. Si todo está disponible, se asignará al proceso lo que necesita y podrá ejecutarse hasta terminar. Si uno o más recursos están ocupados, no se asignará nada y el proceso tendrá que esperar. Un problema inmediato de este enfoque es que muchos procesos no saben, antes de iniciar su ejecución, cuántos recursos van a necesitar. De hecho, si lo supieran, se podría usar el algo­ ritmo del banquero. Otro problema es que con este enfoque no se hará uso óptimo de los re­ cursos. Consideremos un proceso que lee datos de una cinta, los analiza durante una hora y luego escribe su salida en cinta, además de grafícar los resultados. Si es obligatorio solicitar to­ dos los recursos con antelación, el proceso tendrá ocupados durante una hora la unidad de cin­ ta de salida y el graficador. No obstante, algunos sistemas de procesamiento por lotes en mainframes obligan al usua­ rio a enumerar todos los recursos en la primera línea de cada trabajo. Luego el sistema adquie