Podemos tratar de entender parte de las actividades internas de un sistema operativo Microsoft Windows ejecutando el programa de utilidad denominado Administrador de tareas (pulse las teclas Ctrl, Alt y Supr simultáneamente). En particular, seleccionando la pestaña Procesos en la ventana del Administrador de tareas podemos acceder a la tabla de procesos. He aquí un experimento que puede tratar de realizar: examine la tabla de procesos antes de activar ningún programa de aplicación (es posible que le sorprenda ver que hay tantos proce- sos ya en la tabla. Esos procesos son necesarios para el funcionamiento básico del sistema). Ahora active una aplicación y compruebe cómo se habrá añadido un proceso adicional a la tabla. También podrá ver cuánto espacio de memoria se ha asignado a dicho proceso.
La solución a este problema consiste en garantizar que la tarea de compro- bar y posiblemente configurar el indicador se complete sin interrupciones. Una posibilidad es usar las instrucciones de desactivación y activación de interrup- ciones que se proporcionan en la mayoría de los lenguajes máquina. Al ejecu- tarse, una instrucción de desactivación de interrupciones hace que se bloqueen las interrupciones futuras, mientras que una instrucción de activación de inte- rrupciones hace que el procesador comience de nuevo a responder a las señales de interrupción. Así, si el sistema operativo inicia su rutina de comprobación del indicador con una instrucción de desactivación de las interrupciones y ter- mina esa rutina con una instrucción de activación de las interrupciones, nin- guna otra actividad podrá interrumpir a esa rutina después de que esta haya comenzado.
Otra solución sería emplear la instrucción de comprobación y configura- ción (test-and-set) disponible en muchos lenguajes máquina. Esta instrucción hace que el procesador lea el valor de un indicador, anote el valor recibido y luego configure el indicador, todo ello dentro de una misma instrucción de len- guaje máquina. La ventaja es que, como el procesador siempre completa la ins- trucción en curso antes de atender a ninguna otra interrupción, la tarea de comprobar y configurar el indicador no puede partirse cuando se implementa como una única instrucción.
Un indicador adecuadamente implementado, como por ejemplo de la forma que acabamos de describir, se denomina semáforo, en referencia a las señales de las vías férreas y de las carreteras que se utilizan para controlar el acceso a las distintas secciones de las mismas. De hecho, los semáforos se emplean en los sistemas software de forma bastante similar a como se utilizan sus equivalentes en las líneas férreas. El equivalente a una sección de una vía que solo puede contener un tren al mismo tiempo sería una secuencia de ins- trucciones que solo debe ser ejecutada por un proceso cada vez. A una secuen- cia de instrucciones de este tipo se la denomina región crítica. El requisito de que solo se permita a un proceso cada vez ejecutar una región crítica se conoce con el nombre de exclusión mutua. Resumiendo, una forma común de conse- guir la exclusión mutua para una cierta región crítica consiste en proteger la región crítica mediante un semáforo. Para entrar en la región crítica, el proceso debe encontrarse primero el semáforo desactivado y luego activar el semáforo antes de entrar en dicha región crítica; después, al salir de la región crítica, el proceso debe desactivar el semáforo. Si un semáforo está activado, el proceso que está intentando entrar en la región crítica deberá esperar hasta que el semáforo se desactive.
Interbloqueo
Otro problema que puede surgir durante la asignación de recursos es lo que se conoce con el nombre de interbloqueo, que es la condición en la que dos o más procesos están impedidos de progresar debido a que cada uno de ellos está esperando por un cierto recurso que está asignado al otro. Por ejemplo, un pro- ceso puede tener acceso a la impresora de la computadora pero estar esperando acceder al reproductor de CD, mientras que otro proceso puede tener acceso al reproductor de CD pero estar esperando por la impresora. Otro ejemplo es el que a veces surge en sistemas en los que se permite a los procesos crear nuevos
procesos (una acción denominada bifurcación, forking, en lenguaje UNIX) para realizar subtareas. Si el planificador ya no dispone de espacio libre dentro de la tabla de procesos y cada proceso del sistema tiene que crear un proceso adicional antes de completar la tarea que tiene asignada, entonces ninguno de los procesos podrá continuar. Dichas condiciones, al igual que las que surgen en otros entornos (Figura 3.7), puede degradar seriamente el rendimiento de un sistema.
El análisis de las situaciones de interbloqueo revela que estas situaciones no pueden producirse a menos que se satisfagan las siguientes tres condiciones:
1. Hay una competencia por el acceso a recursos no compartibles.
2. Los recursos se solicitan de manera parcial; es decir, habiendo recibido algunos recursos, un proceso puede volver posteriormente a solicitar recursos adicionales.
3. Una vez que un recurso ha sido asignado, esa asignación no puede ser anulada.
El objeto de enunciar estas condiciones es darnos cuenta de que el problema del interbloqueo puede afrontarse consiguiendo que cualquiera de estas tres condiciones no se cumpla. Las técnicas dirigidas a la tercera de estas condicio- nes caen dentro de la categoría que se conoce con el nombre de esquemas de detección y corrección de interbloqueos. En estos casos, la posibilidad de que se produzca un interbloqueo se considera tan remota que no se intenta hacer ningún esfuerzo para evitar el problema. En lugar de ello, la solución adoptada consiste en detectar el interbloqueo cuando se produce y luego corregirlo anu- lando algunas de las asignaciones de recursos realizadas. Nuestro ejemplo de la tabla de procesos llena podría caer dentro de esta categoría. Si se produjera un interbloqueo debido a que la tabla de procesos está llena, una serie de rutinas del sistema operativo (o quizá un administrador humano, utilizando sus pode- res de “superusuario”) puede eliminar [el término técnico es matar, (kill)] algunos de los procesos. Esto hace que se libere espacio dentro de la tabla de
153 3.4 Gestión de la competición entre procesos
Figura 3.7 Un interbloqueo resultante de la competencia por cruces de vías férreas que no son compartibles.
procesos, rompiendo el interbloqueo y permitiendo a los restantes procesos continuar con sus tareas.
Las técnicas que tratan de lidiar con las dos primeras condiciones se cono- cen con el nombre de esquemas de evitación de interbloqueos. Una de ellas, por ejemplo, trata de que no se cumpla la segunda condición, exigiendo que cada proceso solicite todos los recursos necesarios a la vez. Otro esquema trata de conseguir que no se cumpla la primera condición no eliminando direc- tamente la competición, sino convirtiendo los recursos no compartibles en recursos que sí se puedan compartir. Por ejemplo, suponga que el recurso en cuestión es una impresora y que son varios los procesos que necesitan utili- zarla. Cada vez que un proceso solicite la impresora, el sistema operativo podría conceder dicha solicitud; pero en lugar de conectar el proceso a la impresora, lo que el sistema operativo haría sería conectarlo a un controlador de dispositivo que guardara en el almacenamiento masivo la información que hay que imprimir, en lugar de enviarla a la impresora directamente. De ese modo, cada uno de los procesos pensando que tiene acceso a la impresora, podría ejecutarse en forma normal. Posteriormente, cuando la impresora estu- viera disponible, el sistema operativo podía transferir los datos desde el alma- cenamiento masivo a la impresora. De esta forma, el sistema operativo estaría haciendo que ese recurso no compartible parezca ser compartible, creando la ilusión de que hay más de una impresora. Esta técnica de guardar los datos de salida para enviarlos en un momento posterior más conveniente se denomina spooling.
Hemos introducido el spooling como una técnica que sirve para conceder acceso a varios procesos a un recurso común, lo cual es un tema que tiene múl- tiples variaciones. Por ejemplo, un administrador de archivos podría autorizar que varios procesos accedieran al mismo archivo, si esos procesos están mera-