94

Capitulo 4 Procesos
cabecera de cola cola de procesos listos

I r,Ep,', e 1 i , 4 : DOCUKEY'~"A~:ICIN Y 7-51;'1 ,TOTEC&

:?

-1

4.2 Planificaci6n de procesos

95

MONTEVU)b:O

I7T?TTf;IIAY

cola de p llstos

flnal solicttud de US

unidad de cinta rnagnetica 0

final

exp~ro porcion de tlernpo

i
unidad de cinta rnagnetica 1

PCB,

unidad de dlsco 0

Figura 4.5 Representacidn con diagrama de colas de la planificaci6n de procesos.

PCB,

Figura 4.4 Cola de procesos listos y diversas colas de dispositivos de E/S.

El proceso podria emitir una solicitud de E/S, y entonces colocarse en una cola de E/S. El proceso podria crear un nuevo subproceso y esperar a que termine. El proceso podria ser desalojado por la fuerza de la CPU, como resultado de una interruption, y ser colocado otra vez en la cola de procesos listos. En 10s dos primeros casos, el proceso tarde o temprano pasara del estado de espera a1 estado listo, y se le colocara de nuevo en la cola de procesos listos. Cada proceso continua este ciclo hasta terminar, y entonces se le elimina de todas las colas; su PCB y todos sus recursos se liberan.

4.2.2 Planificadores
Un proceso migra de una cola de planificacidn a otra durante toda su existencia. Para fines de planificacion, el sistema operativo debe seleccionar procesos de estas colas de alguna manera. El planificador apropiado se encarga de este proceso de seleccidn.

En un sistema por lotes, es comun que haya mas procesos presentados de 10s que se pueden ejecutar inmediatamente. Estos procesos se colocan en spool en un dispositivo de almacenamiento masivo (por lo regular un disco), y ahi esperan hasta que pueden ejecutarse. El planificador a largo plazo (o planificador de trabajos) escoge procesos de esta reserva y 10s carga en la memoria para que se ejecuten. El planificador a corto plazo (o planificador de CPU) escoge entre 10s procesos que estan listos para ejecutarse, y asigna la CPU a uno de ellos. La distincion primaria entre estos dos planificadores es la frecuencia con que se ejecutan. El planificador a corto plazo debe seleccionar un proceso nuevo para la CPU de forma relativamente frecuente. Un proceso podria ejecutarse durante unos cuantos milisegundos antes de esperar una solicitud de E/S. En muchos casos, el planificador a corto plazo se ejecuta por lo menos una vez cada 100 milisegundos. Dada la brevedad del lapso entre ejecuciones, el planificador a corto plazo debe ser muy rapido. Si se requieren 10 milisegundos para tomar la decision de ejecutar un proceso durante 100 milisegundos, se estara gastando (desperdiciando) el 10/(100 + 10) = 9% del tiempo de CPU simplemente para planificar el trabajo. El planificador a largo plazo, en cambio, se ejecuta con una frecuencia mucho menor. Podrian pasar minutos entre la creacidn de procesos nuevos en el sistema. El planificador a largo plazo controla el gmdo de multiprogramacid~z (el numero de procesos que estan en la memoria). Si el grado de multipr~gramacion es estable, la frecuencia promedio de creacidn de procesos debe ser iga&.i la frecuencia promedio de salida de procesos del sistema. Asi, podria ser que s61GSea necesario invocar el planificador a largo plazo cuando un proceso sale del sistema. Como el interval0 entre ejecuciones es mas largo, el planificador a largo plazo puede darse el lujo de tardar mds en decidir cual proceso escogerh para ejecutarlo.

96

Capitulo 4 Procesos

4.3 Operaciones con procesos

97

Es importante que el planificador a largo plazo haga una selecci6n cuidadosa. En general, 10s procesos pueden describirse como limitados por E/S o limitados por CPU. Un proceso limitado por EIS es uno que dedica la mayor parte de su tiempo a operaciones de E/S, y menos a realizar c~lculos. Un proceso limitado por CPU, en cambio, genera solicitudes de E/S con poca frecuencia, y dedica mas de su tiempo a realizar calculos que un proceso limitado por E/S. Es importante que el planificador a largo plazo escoja una buena mezcla de procesos limitados por E / S y limitados por CPU. Si todos 10s procesos estdn limitados por E/S, la cola de procesos listos casi siempre estard vacia, y el planificador a corto plazo casi no tendra qu6 hacer. Si todos 10s procesos estan limitados por CPU, la cola de espera de E/S casi siempre estara vacia, 10s dispositivos estaran ociosos, y una vez mas el sistema estara desbalanceado. El sistema con el mejor rendimiento tiene una combinaci6n de procesos limitados por E/S y limitados por CPU. En algunos sistemas, el planificador a largo plazo podria estar ausente o ser minimo. Por ejemplo, es comun que 10s sistemas de tiempo compartido no tengan planificador a largo plazo y se limiten a colocar todos 10s procesos nuevos en la memoria para el planificador a corto plazo. La estabilidad de estos sistemas depende de una limitaci6n fisica (corno el nfimero de terminales disponibles) o bien de la naturaleza autoajustable de 10s usuarios humanos. Si el desempefio baja a niveles inaceptables, algunos usuarios simplemente se daran por vencidos y haran alguna otra cosa. Algunos sistemas operativos, como 10s de tiempo compartido, godrian introducir un nivel adicional, intermedio, de planificaci6n. Este planificador a mediano plazo se muestra en forma de diagrama en la figura 4.6. La idea clave en que se basan 10s planificadores a mediano plazo es que a veces puede ser provechoso sacar procesos de la memoria (y de la contenci6n activa por la CPU) a fin de reducir el grado de multiprogramacion. En algun momento posterior, el proceso se reintroducira en la memoria y podrd continuar su ejecuci6n donde se qued6. Este esquema se denomina intercambio (swapping). El planificador a mediano plazo intercambia el proceso a disco y luego lo intercambia a la memoria. Esto puede ser necesario para mejorar la mezcla de procesos o cuando un cambio en las necesidades de memoria ha distribuido la memoria disponible entre demasiados procesos, y es preciso liberar algo de memoria. El intercambio se estudiard con mas detalle en el capitulo 8.
sale por ~ntercsmb~o

4.2.3 Conmutacicin de contexto

El cambio de la CPU a otro proceso requiere guardar el estado del proceso anterior y cargar el estado guardado del nuevo proceso. Esta tarea se denomina conmutacibn de contexto (context switch). El tiempo de conmutaci6n de contexto es exclusivamente gasto extra (overhead),porque el sistema no realiza trabajo util durante la conmutaci6n. La rapidez de conrnutaci6n varia de una mdquina a otra, dependiendo de la velocidad de la memoria, el numero de registros que hay que copiar y la existencia de instrucciones especiales (como una sola instrucci6n para cargar y almacenar todos 10s registros). Por lo regular, el tiempo de conmutaci6n varia entre 1 y 1000 microsegundos. Los tiempos de conmutaci6n de contexto dependen en buena medida del apoyo del hardware. Por ejemplo, algunos procesadores (como el DECSYSTEM-20) cuentan con varios conjuntos de registros. Una conmutaci6n de contexto simplemente implica cambiar el puntero a1 conjunto de registros actual. Desde luego, si hay mas procesos activos que conjuntos de registros, el sistema tendri que recurrir a copiar 10s datos de registros en la memoria, igual que antes. Ademas, cuanto mas complejo es el sistema operativo, mds trabajo hay que efectuar durante una conmutaci6n de contexto. Como veremos en el capitulo 8, las tecnicas de gesti6n de memoria avanzadas podrian requerir la conmutaci6n de datos adicionales con cada contexto. Por ejemplo, se hace necesario preservar el espacio de direcciones del proceso actual antes de preparar el espacio para la siguiente tarea. La manera como se preserva el espacio de direcciones, y la cantidad de trabajo que implica, dependen del metodo de gesti6n de memoria del sistema operativo. Como veremos en la secci6n 4.5, la conmutaci6n de contexto se ha convertido en un cuello de botella tan importante para el desempefio que se estdn empleando estructuras nuevas (hilos) para evitarla hasta donde sea posible.

4.3

Operaciones con procesos

Los procesos del sistema se pueden ejecutar de forma concurrente, y se deben crear y eliminar dindmicamente. Por ello, el sistema operativo debe contar con un mecanismo para crear y terminar procesos.

4.3.1 Creacicin de procesos

Un proceso puede crear varios procesos nuevos, a traves de una llamada a1 sistema de "crear proceso", durante el curso de su ejecuci6n. El proceso creador se denomina proceso padre, y 10s nuevos procesos son 10s hijos de ese proceso. Cada uno de estos procesos nuevos puede a su vez crear otros procesos, formando un arbol de procesos (Fig. 4.7). En general, un proceso necesita ciertos recursos (tiempo de CPU, memoria, archivos, dispositivos de EIS) para efectuar su tarea. Cuando un proceso crea un subproceso, 6ste tal vez pueda obtener sus recursos directamente del sistema operativo, pero podria estar restringido a un subconjunto de 10s recursos del proceso

colas de espera de E/S

Figura 4.6 Adicion de planificacidn a mediano plazo a1 diagrama de colas.

4.3

Operaciones con procesos

99

98

Capitulo 4 Procesos

El proceso hijo es un duplicado del proceso padre. Se carga un programa en el proceso hijo.
I

pagedaemon

~ n ~ t

Figura 4.7 Arb01 de procesos en un sistema UNIX representativo.

padre. El padre quiza tenga que dividir sus recursos entre sus hijos, o tal vez varios de sus hijos puedan compartir algunos recursos (como memoria o archivos). La restricci6n de un proceso hijo a un subconjunto de 10s recursos del padre impide que cualquier proceso sobrecargue el sistema creando demasiados subprocesos. Ademas de 10s diversos recursos fisicos y logicos que un proceso obtiene cuando se crea, el proceso padre podria pasar a su hijo datos de iniciaci6n (entradas). Por ejemplo, consideremos un proceso cuya funci6n es exhibir la situacidn de un archivo, digamos Al, en la pantalla de una terminal. En el momento de crearse recibir$ como entradas de su proceso padre, el nombre del archivo Al, y se ejecutard utilizando ese dato para obtener la informaci6n deseada. El proceso tambien podria recibir el nombre del dispositivo de salida. Algunos sistemas operativos pasan recursos a 10s procesos hijos. En un sistema semejante, el proceso nuevo podria obtener dos archivos abiertos, A1 y el dispositivo de terminal, y tal vez s610 tendria que transferir el dato entre 10s dos. Cuando un proceso crea un proceso nuevo, hay dos posibilidades en tQminos de ejecuci6n: El padre sigue ejecutiindose de forma concurrente con sus hijos. El padre espera hasta que algunos de sus hijos, o todos, han terminado. Tambien hay dos posibilidades en terminos del espacio de direcciones del nuevo proceso:

Para ilustrar estas diferentes implementaciones, consideremos el sistema operativo UNIX. En UNIX, cada proceso se identifica con su identificador de proceso, que es un entero unico. Se crea un proceso nuevo con la llamada a1 sistema fork (bifurcar). El nuevo proceso consiste en una copia del espacio de direcciones del proceso original. Este mecanismo permite a1 proceso padre comunicarse fdcilmente con su proceso hijo. Ambos procesos (el padre y el hijo) continuan su ejecuci6n con la instrucci6n que sigue a1 fork con una diferencia: el c6digo de retorno que el proceso nuevo (hijo) recibe del fork es cero, per0 a1 padre se devuelve el identificador de proceso (distinto de cero) del hijo. Por lo regular, uno de 10s dos procesos utiliza la llamada a1 sistema execve despues del fork para reemplazar su espacio de memoria con un programa nuevo. La llamada execve carga un archivo binario en la memoria (destruyendo la imagen de memoria del programa que contenia la llamada execve) e inicia su ejecuci6n. De esta forma, 10s dos procesos pueden comunicarse, y luego cada uno sigue su propio camino. El padre puede crear mAs hijos o, si no tiene nada mds que hacer mientras el hijo se ejecuta, puede emitir una llamada a1 sistema wait (esperar) para sacarse a si mismo de la cola de procesos listos hasta que el hijo termine. El sistema operativo DEC VMS, en contraste, crea un proceso nuevo, carga un programa especificado en ese proceso, e inicia su ejecuci6n. El sistema operativo Microsoft Windows NT maneja ambos modelos: el espacio de direcciones del padre podria duplicarse, o el padre podria especificar el nombre de un programa que el sistema operativo cargard en el espacio de direcciones del nuevo proceso.

4.3.2 Terminaci6n de procesos

Un proceso acaba cuando termina de ejecutar su ultimo enunciado y le pide a1 sistema operativo que lo elimine utilizando la llamada al sistema salir (exit). En ese momento, el proceso podria devolver datos (salidas) a su proceso padre (por medio de la llamada a1 sistema esperar). El sistema operativo liberara todos 10s recursos del proceso, incluidos memoria fisica y virtual, archivos abiertos y btlffers de EIS. Hay otras circunstancias en las que ocurre la terminaci6n. Un proceso puede causar la terminaci6n de otro con una llamada a1 sistema apropiada (por ejemplo, abortar). Normalmente, s610 el padre del proceso que se terminard puede emitir tal llamada. De otro modo, 10s usuarios podrian matar arbitrariamente 10s trabajos de otros usuarios. Es evidente que el padre necesita conocer la identidad de sus hijos. Por ello, cuando un proceso crea un proceso nuevo, el sistema operativo le pasa la identidad del proceso recien creado. Un padre podria terminar la ejecuci6n de uno de sus hijos por diversas razones, como: El hijo se ha excedido en la utilizaci6n de algunos de 10s recursos que se le asignaron.