Oscar

Captulo 3
Administracin de procesos y del

procesador
hemos explicado en secciones anteriores, una de las principales tareas de un sistema
operativo es la de administrar los programas que corren los usuarios, adems de hacer
las tareas concernientes a la administracin de los recursos del sistema operativo. Los sistemas
operativos antiguos solamente podan correr un solo programa por vez. Cuando el programa
era cargado en memoria, ste tena todo el control de los recursos de la computadora. Como
los computadoras eran demasiado caras, lo que se necesitaba era aprovechar al mximo su potencia. Los sistemas operativos actuales, pueden multiplexar sus recursos para que puedan ser
usados por distintos usuarios, dndoles la impresin de que estos recursos estn dedicados a
ellos, excepto, por ejemplo, cuando usan un dispositivo que es obligatoriamente serial como
una impresora. Existen diferentes trminos para designar las capacidades de una computadora
y por ende tambin de un sistema operativo. en primer lugar, tenemos un sistema monotarea
y monousuario. Quiere decir que, como los sistemas antiguos, solamente soporta un programa
y en consecuencia un solo usuario. De ah pasamos a los sistemas multiusuario y multitarea.
Un sistema operativo multitarea puede tener trabajando varios programas en memoria al mismo
tiempo. Un sistema multiusuario puede permitir la conexin de varios usuarios a la vez. Un sistema multiusuario implica que realiza multitarea pero un sistema multitarea, no puede implicar
que pueda tener mltiples usuarios.
O mo
El siguiente trmino importante es el de los sistemas de multiprocesamiento. Bsicamente

se refiere a un sistema que cuenta con muchos procesadores. Existe la tendencia a confundir
un sistema multitarea con uno de multiprocesamiento, pero la multitarea se puede dar en un
sistema con un solo procesador multiplexando la CPU entre las diferentes tareas. Obviamente
la multitarea tambin se da en un sistema de multiprocesamiento para aprovechar al mximo a
73
74
3.1. CONCEPTO DE PROCESO
todas las CPU. Por ltimo nos referiremos a los sistemas distribuidos. Un sistema distribuido,
se define como la comparticin de tareas entre diferentes computadoras conectadas mediante
una red. Esto es, una red permite compartir recursos, como directorios y archivos, un sistema
distribuido, permite a su vez compartir memoria y procesos o tareas.
3.1. Concepto de proceso

Un programa o proceso necesita recursos para poder ejecutarse en la computadora. El sistema operativo necesita asignarle tiempo de CPU, memoria y oportunidad de realizar sus tareas de
entrada/salida. A la copia del programa que maneja el sistema operativo en memoria se le conoce como proceso o tarea. En lo sucesivo usaremos indistintamente uno u otro nombre. Concepto
de proceso Un proceso es una copia de un programa en memoria. Por lo comn, la carga de un
programa de disco para subirlo en memoria es el resultado de la ejecucin de una orden dada al
sistema operativo por un usuario, ya sea desde una lnea de comandos o a travs de una interfaz
grfica de usuario.
Cuando el sistema operativo recibe la orden, ste crea una estructura de datos que le permite
llevar el control de los recursos asignados al proceso y provee los mecanismos necesarios para
que pueda comunicarse con el. Al momento de creacin, el proceso recibe un nmero que lo
identificar durante toda la vida de ste. Al se le llama PID (Process Identifier). Una vez creado,
el proceso empezar a competir por todos los recursos de la computadora.
Desde el punto de vista del usuario, un proceso es solamente un programa que tiene un
conjunto de instrucciones para realizar una tarea especfica. Para el sistema operativo es una
entidad que debe ser planificada y asignada al procesador para su ejecucin. De este modo, el
sistema operativo lleva un registro que permite controlar dinmicamente la evolucin del proceso
desde su creacin hasta la finalizacin del mismo.
3.2. Estados y transiciones de un proceso.

Un proceso pasa por diferentes estados durante su vida. Un proceso puede estar bsicamente
en dos estados: No ejecucin y En ejecucin.
No ejecucin. Cuando un programa se encuentra en este estado, se dice entonces que est esperando la oportunidad de ejecutarse, por lo tanto, no se encuentra en la CPU. Todo proceso
que es creado, empieza en el estado de no ejecucin.
En ejecucin. Cuando el sistema operativo decide que es tiempo de que un proceso pase a
CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR
75
ejecucin, interrumpe al que se encuentra en la CPU y enva a la CPU otro proceso. La

seleccin del proceso que pasa a ejecucin depende del algoritmo de planificacin que
tenga el kernel del sistema operativo. El proceso que pierde el control de la CPU pasa al
estado de no ejecucin.
Aunque esta estrategia es muy simple, podemos observar que se necesitan definir varios aspectos tales como el tiempo que debe asignarse a cada proceso. qu estrategia debe seguir el
sistema operativo para decidir cual ser el siguiente proceso a ejecutarse. En donde se guardarn los datos de los procesos que estn ejecutndose en ese momento. Entre otras cuestiones
importantes.
En los sistemas operativos actuales el administrador de CPU interrumpir al proceso en ejecucin en intervalos regulares. Si su tiempo no ha concluido, entonces le devuelve nuevamente el
control.de otra forma seleccionar un nuevo proceso de la cola de procesos. La cola de procesos
por lo comn es una lista enlazada cuyos nodos representan procesos que deben ser ejecutados.
La estrategia ms comn es usar la FIFO (First Input Firt Output), esto es, primero en entrar primero en salir. De acuerdo a esta estrategia, el proceso que llega primero, ser el que se atienda
primero. Esto no significa que el proceso deber continuar hasta que termine su ejecucin. Este
se ejecutar hasta que se le agote su tiempo asignado. Cuando se le termine su tiempo -y si todava no termina su tarea- regresar al final de la cola para esperar un nuevo turno de ejecucin.
En el momento en que termine su tarea, el proceso ser eliminado de memoria y la estructura de
datos que lo representa ser eliminado de la cola.
Aunque el modelo de dos estados es conveniente para una aproximacin general. Es comn
que un proceso an no se encuentre listo para ejecutarse debido a que est esperando que termine una operacin de entrada/salida. En ese momento sera intil que el sistema operativo le
concediera su segmento de tiempo, puesto que se lo gastara esperando. Para evitar este y otros
problemas, se aumentan a cinco los posibles estados de un proceso:
1. Estado nuevo
2. Estado de Listo o Preparado
3. Estado de Ejecucin
4. Estado de Bloqueado
5. Estado de Terminado
Explicaremos cada uno de estos estados ms detalladamente.
76
3.2. ESTADOS Y TRANSICIONES DE UN PROCESO.
Figura 3.1: Diagrama de estados de un proceso
Estado nuevo. Son aquellos procesos que acaban de ser solicitados para ejecucin, pero que
an el sistema operativo no termina de generar todas las estructuras de datos necesarias
para pasarlos al estado de listos.
Estado de Listo o Preparado. se encuentran en este estado aquellos procesos que tienen todo
lo necesario para ejecutarse o continuar sus tareas en donde las dejaron. solamente esperan
a que les toque su turno de ejecucin.
Estado de Ejecucin. El proceso que se encuentra en este estado es el que tiene el control del
procesador. Si la arquitectura de la computadora existen muchos procesadores, entonces
es posible que exista ms de un proceso en este estado. Por el contrario, si hablamos de
una computadora con un solo procesador, entonces en un momento cualquiera existir
slo un proceso en este estado.
Estado de Bloqueado. Se encuentran en este estado aquellos procesos que estn esperando
que termine una operacin de entrada/salida, que se libere un recurso -a excepcin del
procesador- o estn esperando una seal externa.
Estado de Terminado. Estn es este estado aquellos procesos que han finalizado su tarea o
incurrieron en algn acceso no autorizado o hubo un error irrecuperable y el sistema operativo los elimin. Tambin es posible que el padre del proceso haya enviado una seal
de terminacin de proceso por que la tarea global ha sido finalizada. Esto significa que
el sistema operativo lo quitar de la lista de ejecucin y despus que haya obtenido las
77
estadsticas referentes al proceso, lo eliminar definitivamente de memoria y desasignar

todos los recursos que tena ese proceso.
Tomando en cuenta estos estados, un proceso puede pasar de uno a otro. A esto le llamamos
transiciones. En la figura 3.1, vemos las transiciones que puede efectuar el proceso. A continuacin explicaremos brevemente cada una de ellas:
Transicin a Nuevo. El usuario ha solicitado la ejecucin de un programa. El sistema operativo
determina la ruta del programa a ejecutar y empieza a construir las estructuras de datos
necesarias para ponerlo en la cola de listos.
Transicin de Nuevo a Preparado. Tiene lugar cuando el SO est preparado para admitir un
proceso ms y ha terminado de inicializar las estructuras de control necesarias. Se tendrn
en cuenta las restricciones de la capacidad de la memoria, de modo que aquellos procesos que tengan baja prioridad o estn bloqueados se enven a la memoria virtual en caso
necesario.
Transicin Preparado a Ejecucin. Esta transicin se genera cuando el planificador del sistema operativo ha seleccionado un nuevo proceso para ejecutar y est realizando un cambio
de contexto.
Transicin Ejecucin a Preparado. Cuando se da esta transicin, indica que el segmento de
tiempo asignado al proceso ha finalizado. El sistema operativo realizar otro cambio de
contexto para asignarle la CPU al siguiente proceso en su cola de ejecucin. Tambin se
puede dar que un proceso con mayor prioridad haya solicitado su ejecucin y en este caso,
el sistema operativo se apropiar de la CPU para cumplir el requerimiento. Otra puede ser
sesin voluntaria del control del procesador al sistema operativo.
Transicin Ejecucin a Bloqueo. Un proceso pasa a bloqueo cuando ha iniciado una operacin de entrada/salida y sta es demasiado lenta. Tambin cuando espera una seal externa.
Transicin Bloqueado a Preparado. Tiene lugar si a un proceso bloqueado se le concede el
recurso solicitado u ocurre el suceso por el que estaba esperando.
Transicin Preparado a Terminado. Esto ocurre cuando un proceso padre ha decidido en un
momento dado finalizar la ejecucin de sus procesos hijos. Si algn proceso se encontraba
en estado preparado realizar esta transicin. Tambin puede deberse a un requisito de
memoria no autorizado.
78
Transicin Bloqueado a Terminado Un proceso hijo puede hacer esta transicin debido a que
el proceso padre envo una seal de terminacin a todos sus hijos. Otra causa puede ser
que el proceso supere el tiempo mximo de espera por un recurso y el sistema operativo
decida entonces terminarlo, aunque comnmente enviar un aviso al usuario del proceso
y que ste decida qu hacer.
Para que el sistema operativo pueda implementar todos estos estados es necesario disponer
de dos colas, una para los procesos preparados y otra para los bloqueados. A medida que se
admiten procesos nuevos en el sistema, stos se van colocando en la cola de preparados. Cuando
el sistema operativo tiene que elegir un proceso para su ejecucin, lo hace sobre esta cola. Si suponemos que no hay una poltica de prioridades entonces la cola puede administrarse mediante
un algoritmo FIFO como se explic en 3.2. Cuando el sistema operativo le quita el procesador a
un proceso, puede ser porque ha terminado su ejecucin, porque ha excedido el tiempo mximo
asignado. En este caso se va agregar al final de la cola de preparados. En caso de que haya quedado bloqueado o a la espera de una seal entonces se agregar al final de la cola de bloqueados.
Cuando tiene lugar una seal todos los procesos que esperaban por ella se envan desde la cola de
bloqueados a la de preparados. Esta ltima medida significa que cuando se produce un suceso,
el sistema operativo debe recorrer toda la cola de procesos bloqueados buscando aquellos que
esperen por la seal. En un sistema operativo grande puede haber una gran cantidad de procesos en la cola de bloqueados, por consiguiente, resultara ms eficiente disponer de un conjunto
de colas, una para cada seal o suceso. De esta forma, cuando se produzca un evento, la lista
entera de procesos en la cola correspondiente a ese suceso podr pasarse a estado preparado. Si
la planificacin de procesos se realiza mediante un esquema basado en prioridades, entonces es
conveniente tener un cierto nmero de colas de procesos listos, una para cada prioridad.
3.2.1. El Estado de Suspendido

Debido a que el procesador es mucho ms rpido que los dispositivos de E/S puede ocurrir
que en un momento dado todos los procesos del sistema se encuentren bloqueados a la espera de
que se complete alguna operacin de E/S. Para solucionar este problema existen dos opciones:
1.Instalar ms memoria principal al sistema de modo que sea posible cargar ms procesos y
aumentar la posibilidad de usar ms efectivamente el procesador.
2. Otra solucin consiste en aplicar una tcnica conocida como intercambio o swapping.
Esta tcnica consiste en que si varios procesos estn bloqueados, el sistema operativo puede
sacarlos de su correspondiente cola y guardarlo en la particin de intercambio. El proceso transferido se dice entonces que queda en estado suspendido. Una vez realizada esta operacin, se
libera memoria y el sistema operativo puede traer de nuevo a memoria a un proceso previamente
79
suspendido o bien aceptar un nuevo proceso. Se considera suspendido a un proceso que presenta
las siguientes caractersticas:
1. Un proceso suspendido se encuentra en la memoria virtual y debe ser cargado para su
ejecucin.
2. Un proceso puede estar esperando o no una seal o la terminacin de su E/S. Si lo est,
la condicin desbloqueado es independiente de la condicin de suspendido y el acontecimiento del suceso que lo bloque no necesariamente lo pondr en estado de ejecucin.
3. El proceso fue situado en estado suspendido por el sistema operativo o el proceso padre
con el fin de que no se ejecute por alguna razn.
4. El proceso no puede cambiarse de estado hasta que se enve la seal correspondiente.
3.2.2. El bloque de control de procesos

Para que el sistema operativo pueda llevar el control durante la vida de un proceso, es necesario contar con mucha informacin. esta informacin se almacena en el bloque de control de
procesos denominado como PCB (Process Control Block). Dentro de los datos ms importantes
del proceso tenemos los siguientes:
Contador de Programa PC. El contador de programa guarda la direccin de la siguiente instruccin a ejecutar del proceso.
Estado del proceso. Puede ser cualquiera de los que analizamos en 3.2.
Informacin de planeacin del CPU. Incluye la prioridad del proceso, los apuntadores a las
colas de planificacin y otra informacin necesaria.
Registros de la CPU. Es necesario guardar una copia exacta del estado en que quedaron los
registros para asegurar que el proceso pueda continuar en el punto en que se suspendi su
ejecucin.
Informacin estadstica. Permite al sistema operativo ir contabilizando el tiempo de ejecucin
en la CPU, PID del proceso, tiempo en el sistema y otra informacin relacionada.
Informacin de la administracin de memoria. Almacena la informacin correspondiente al
uso de la memoria del proceso. Puede incluir registro base y lmite, las tablas de pginas
o las tablas de segmentos. Esta informacin depende del mecanismo de administracin de
memoria que se use.
80
Informacin de estado de E/S. El sistema operativo guarda una lista de dispositivos usados
por el proceso, una lista de archivos el estado en que se encuentran.
En resumen, en PCB es una estructura que permite guardar toda la informacin relativa
al proceso y que cambia durante la ejecucin del mismo. Es importante hacer notar que aqu
se guarda la informacin para que el proceso, al momento de tomar nuevamente el control,
empiece a ejecutarse exactamente donde se qued, independientemente de la operacin que
estaba realizando.
3.2.2.1. Relaciones entre procesos
Podemos encontrar dos relaciones bsicas entre dos procesos:
Competicin
cooperacin
Dado que ambos procesos estn ejecutndose en la misma CPU o en diferentes CPU, stos van
a competir por los dems recursos de la computadora. Tambin es posible que se d la condicin
de cooperacin entre dos o ms procesos para que lleven a cabo una tarea ms eficientemente.
Tanto la competicin como la cooperacin requieren que el sistema operativo proporcione un
soporte conveniente de modo que exista el aislamiento adecuado cuando un proceso acceda a
un recurso -como por ejemplo, su espacio de direcciones- y pueda terminar su tarea con xito.
La cooperacin exige que el sistema operativo proporcione mecanismos de acceso controlado
a los datos y archivos compartidos para asegurar adecuadamente las operaciones atmicas del
proceso, ya sea mediante seales o algn otro mecanismo de sincronizacin.
3.2.2.2. Operaciones sobre los procesos
En los sistemas operativos actuales es comn que los procesos puedan ejecutarse concurrentemente y tambin crearlos y eliminarlos dinmicamente.
creacin de procesos. Para crear un proceso en un sistema UNIX/Linux, En el programa de
la pgina 80 se hace uso de la instruccin fork()
switch (fork())
{
case -1:
/* Aqu insertamos el cdigo para manejar el
81
error de no poder crear un nuevo proceso */

...
break;
case 0:
/* Cdigo que ejecuta el proceso hijo */
...
break;
default:
...
/* Cdigo el proceso padre */
}
Puede usarse tambin condicionales de esta forma:
pid=fork()
if (pid==0)
{ /* Aqu va el cdigo del hijo*/}
else if pid > 0
{ /*Aqu va el cdigo del padre*/}
else
{/*Aqu se maneja el error en caso de que
falle la creacin del proceso*/
}
Hay que observar que incluso los procesos hijos pueden crear nuevos procesos, lo que significa que al final tendremos un rbol de procesos.
Para que podamos ver los procesos que actualmente se estn ejecutando en la computadora
tenemos la instruccin ps en los sistemas UNIX/Linux en los sistemas de Windows tenemos
el administrador de tareas, el cual tambin indica cuanto tiempo de CPU est consumiendo
un proceso y la memoria que tiene ocupada. Para ver el consumo de recursos en UNIX/Linux
usamos el comando top.
Cuando un proceso crea uno nuevo puede darse cualquiera de los acontecimientos siguientes:
1. El padre contina ejecutndose paralelamente junto con el hijo.
2. El padre espera a que los hijos terminen las tareas asignadas, para despus seguir ejecutndose.
Tambin al momento de crear un proceso puede suceder que:
82

1. El hijo sea una copia exacta de padre, incluyendo cdigo y datos.
2. el hijo cargue un nuevo programa mediante una llamada a exec() o alguna de sus variantes.
Eliminacin de procesos. Un proceso termina cuando ejecuta su ltima instruccin y pide al

sistema operativo que lo elimine. Cuando el sistema operativo termina el proceso libera todos
los recursos asignados al mismo, cierra los archivos que utiliz, los bferes asociados a stos y
la memoria fsica y virtual entre otros.
Existen diferentes maneras de eliminar un proceso del sistema. A continuacin explicamos
cuales son stas.
1. El proceso hace una llamada a la funcin exit() para indicarle al sistema operativo que
termin sus tareas y que puede ser eliminado, regresando al padre un cdigo de xito o
error.
2. El proceso padre enva una seal KILL (morir) al proceso hijo para que termine su ejecucin.
3. El sistema operativo enva una seal KILL al proceso a causa de un acceso (a un bloque
de direcciones -por ejemplo-) no autorizado o algn otro evento.
4. El usuario dueo del proceso enva una seal al proceso mediante la funcin kill() o si el
proceso tiene asociado una terminal presionando ctrl-c o ctrl-break
5. El super usuario o el administrador del sistema enva una seal al proceso mediante la
funcin kill() o si el proceso tiene asociado una terminal presionando ctrl-c o ctrl-break
83
3.3. Procesos ligeros: Hilos o hebras

Ya vimos que un proceso es una instancia de un programa en ejecucin. hay ocasiones en
que es necesario, crear nuevos procesos para que hagamos alguna tarea ms eficientemente. Para
crear un nuevo proceso hacemos uso de una llamada a una instruccin especial llamada fork()
como se vio en la seccin 3.2.2.2. Al momento de ejecutar esta instruccin el sistema operativo
crear una copia idntica del programa que se encuentra en memoria, le asignar su PCB y todas
las acciones referentes a la creacin de un proceso. Ahora, al proceso que invoc la llamada
fork() se le denominar proceso padre y al nuevo proceso, se le llama proceso hijo. El proceso
hijo ha adquirido una copia completa de los datos del padre y adems tiene los mismos permisos
sobre los archivos que maneja el padre. Ahora tanto el proceso padre como el hijo competirn
por los recursos de la computadora y se comunicarn de alguna manera para no acceder a los
mismos archivos al mismo tiempo.
La principal desventaja es que tenemos cdigo duplicado, a no ser el proceso haga inmediatamente una llamada a exec(), de tal forma que ahora el sistema operativo reemplazar todo el
cdigo y los datos del proceso hijo con la nueva informacin del proceso que se carg. An as
este proceso es demasiado lento debido a que se tiene interaccin con la memoria secundaria.
Como es posible que el sistema se sobre cargue a causa del cdigo y datos duplicados existe una
alternativa ms viable para cuando un proceso necesite ejecutar una tarea que es susceptible de
separar del programa principal. A esta alternativa se le conoce como hilo.
Un hilo o hebra es una unidad bsica para hacer uso de la CPU, comprende dentro de su
estructura un PID de hilo, el contador de programa, un conjunto de registros y una pila. La
primera ventaja con respecto a un proceso hijo es que todos los hilos pertenecientes a un proceso
comparten la seccin de cdigo, la seccin de datos, los archivos abiertos y las seales.
Desde este punto de vista, cuando el sistema operativo crea un nuevo hilo, necesita solamente
crear un PCB correspondiente a la misma, no necesita hacer la copia completa del proceso, por
lo que es mucho ms rpido y eficiente crear un hilo que un proceso.
Un proceso lleva a cabo su ejecucin siguiendo solamente un hilo de ejecucin y aunque
existan varios procesos cada uno seguir cada uno llevando slo un hilo de ejecucin debido
a sus caractersticas inherentes de no compartir su cdigo y sus datos. Con la implementacin
de hilos, en la actualidad la mayora de los sistemas operativos permiten que un proceso tenga
muchos hilos de control.
Vamos a poner un ejemplo: cuando en un sistema multitarea se haca una solicitud de servicio
el proceso encargado de proporcionarlo creaba una copia de s mismo mediante la llamada a
fork() y el hijo creado era el que realmente proporcionaba el servicio repitindose este proceso
por cada solicitud que llegara.
84
3.3. PROCESOS LIGEROS: HILOS O HEBRAS
Como podemos observar cada proceso hace exactamente el mismo trabajo: atender una solicitud del mismo tipo de servicio. Sin embargo por cada solicitud se crea un nuevo proceso con
cdigo y datos. No tiene sentido tener todo ese cdigo duplicado si solamente cambia el valor
de algunas variables de los datos. Adems hay que contar la sobrecarga del sistema debido a la
tarea de copiar todo el contexto del proceso.
En la actualidad la mayora de las aplicaciones estn usando los hilos en vez de procesos.
Como se coment tienen ms ventajas que los procesos tradicionales.
incluso varios de los sistemas operativos actuales usan kernels multi hilo; esto significa que
existen varios hilos ejecutando tareas especficas como la administracin de memoria y la administracin de los dispositivos de entrada salida.
3.3.1. Ventajas de la programacin multi hilo

Podemos dividir las ventajas de la programacin con hilos en:
Economa. Hacer un cambio de contexto de un hilo es mucho ms rpido que hacer el cambio
de contexto de un proceso.
Aumento en la capacidad de respuesta. Si hacemos uso de varios hilos en una aplicacin interactiva, podemos lograr que nuestra aplicacin siga respondiendo a nuestro usuario,
puesto que si se hace una tarea muy larga, como una bsqueda, los hilos encargados de la
interfaz grfica podrn estar trabajando para procesar entradas del usuario.
Recursos compartidos. Los hilos comparten tanto el cdigo, como los datos del proceso que
los cre, si necesitan informacin local pueden pedirla independientemente del proceso
padre.
Soporte de multiproceso. Es posible ejecutar paralelamente los hilos en un sistema multiprocesador, aumentando significativamente la velocidad.
3.3.2. Implementacin de hilos en GNU/Linux

GNU/Linux cuenta con una librera denominada Pthreads. Est basado en el estndar POSIX en donde describen la especificacin para el comportamiento de los hilos. Entindase por
especificacin la manera en la cual deben comportarse las funciones dadas. A diferencia de una
implementacin la cual est sujeta al diseo particular de cada desarrollador. A continuacin se
muestra un programa que utiliza la librera antes mencionada.

#include <pthread.h>
//
/* Funcin que va a ejecutar el hilo
correspondiente al hijo */
void *hilo(void *nollevonada);
/* Contadorcomun, global para que sea visible
desde el principal y desde hilo */
int contadorcomun = 0;
int veceshilo=0;
int vecespadre=0;
int main()
{
/* Identificador del hilo hijo */
pthread_t Hilo;
/* error devuelto por la funcin de
creacin del hilo */
int error;
/* se crea el hilo.
* En Hilo tendremos el PID del nuevo hilo,
* Pasamos la funcin que se ejecutar en el nuevo hilo
* Pasamos NULL como parmetro para esa funcin de manera
que obtenga los valores por defecto. */
//
error = pthread_create (&Hilo, NULL, hilo, NULL);
//
/* Comprobamos el error al arrancar el hilo */
if (error != 0)
{
perror ("No puedo crear el hilo");
exit (-1);
}
/* Bucle infinito para incrementar el contador
y mostrarlo en pantalla */
while (1)
{
contadorcomun++;
vecespadre++;
printf("Padre : %d veces %d\n", contadorcomun, vecespadre);
85
86
3.3. PROCESOS LIGEROS: HILOS O HEBRAS

if (vecespadre>10000)
break;
}
if vecespadre>veceshijo
printf("Termin primero el padre");
else
printf("Termin primero el hijo");
return(0);
}
/* Funcin ejecutndose en el hilo hijo.*/
void *hilo(void *nollevonada)
{
/* Bucle infinito para decrementar contador
y mostrarlo en pantalla. */
while (1)
{
contadorcomun--;
veceshijo++;
printf ("Hilo : %d veces %d\n", contadorcomun,veceshijo);
if (veceshijo>10000)
break;
}
pthread_exit(0);
}
Observe que para terminar el hilo se usa la llamada a funcin ptrhead_exit() con un valor de 0
que indica que no hubo problemas en la ejecucin. Cuando es necesario esperar a que termine
la ejecucin de una o ms hilos entonces el padre usar la llamada a funcin pthread_join().
3.3.3. Consideraciones finales

Algunos sistemas UNIX implementan dos llamadas a fork(), dependiendo de la funcin que
se desee realizar dentro de un hilo, una funcin puede ser duplicar el proceso padre y todos
los hilos o solamente el hilo que llam a fork(). Tambin cuando se usa exec() se llamar
una versin o la otra. Si exec se llama inmediatamente despus de fork(), no hay necesidad de
duplicar los hilos, por que el programa que se cargar sobre escribir toda el rea de cdigo y
datos.
87
3.3.3.1. Eliminacin de hilos

es la accin de eliminar de memoria un hilo que an no termina su ejecucin. Esto es necesario por que hay ocasiones en que, por ejemplo si tenemos una bsqueda concurrente sobre
una base de datos y se lanzaron varios hilos, cada uno de ellos con una parte de la misma, alguno encontrar primero los datos y entonces no ser necesario que las dems sigan haciendo la
bsqueda y habr que eliminarlas.
El problema de la cancelacin viene a que, al igual que los procesos, no existe garanta total
de que los recursos regresen al sistema. Por ejemplo, cuando un proceso o un hilo pidieron
memoria dinmicamente. Esta memoria no se regresar hasta que no la devuelva explcitamente
el hilo o proceso que la solicit, generando lo que se conoce como fuga de memoria, un problema
que debe tratarse con mucho cuidado en la programacin con lenguaje C. La eliminacin del hilo
puede hacerse de dos formas:
1. Asncrona. El hilo puede terminarse inmediatamente por el proceso que la cre.
2. Sncrona. El proceso que cre el hilo, verifica si es posible terminarlo, si no, espera y
vuelve a repetir el proceso, dando oportunidad al hilo de terminar adecuadamente.
3.4. Concurrencia y secuenciabilidad

En la seccin 3.1 hemos hablado de cmo es que es sistema operativo puede controlar muchos procesos ejecutndose en la misma computadora. Cuando hay varios procesos compitiendo
por los mismos recursos, y dado el caso de que dos o ms procesos quieran acceder al mismo
recurso en el mismo instante de tiempo, entonces decimos que tenemos un caso de concurrencia.
Esto es, varios procesos concurren por un recurso al mismo tiempo. si hablamos de computadoras con un solo procesador, se puede argumentar que los procesos siempre corren solos sobre
un recurso, pero hay que recordar que por lo comn la mayora de los recursos son decenas o
centenas de veces ms lentos que el procesador. Esto indica que existen muchsimas posibilidades de que el tiempo asignado al proceso termine mucho antes de que algn dispositivo de
entrada/salida, como un disco duro, por ejemplo, haya terminado su operacin correspondiente.
Esto significa que otro proceso que tenga que trabajar sobre el mismo registro almacenado en el
disco duro lo vea desocupado en el momento siguiente, aunque el proceso que ocup ese registro no haya terminado de hacer su operacin y ya no se ejecute en ese momento. Como puede
verse el segundo proceso trabajar sobre datos no vlidos puesto que se encontraban, tal vez en
un proceso de actualizacin.
88
3.4. CONCURRENCIA Y SECUENCIABILIDAD
Con la memoria sucede un caso similar, si dos procesos tienen acceso a un rea de memoria
comn, deben de ponerse de acuerdo en la forma de acceder a sta, tanto para la lectura como
para la escritura. Ambos procesos deben de acceder al recurso en instantes diferentes de tiempo
y adems deben de ser capaces de terminar la operacin que empezaron. de otro modo, los datos
de esa rea de memoria pueden corromperse, cuando los procesos sobre escriban informacin
que corresponde a cada uno de ellos.
3.4.1. Definiciones
Concurrencia es cuando dos o ms procesos quieren acceder a un recurso al mismo tiempo. El sistema operativo debe garantizar la integridad de la informacin, haciendo que entren al
recurso proceso por proceso y garantizar tambin que terminen de hacer las operaciones sobre
el recurso correspondientes. A lo anterior le llamamos exclusin mutua. La exclusin mutua,
por tanto, es hacer que un proceso ejecute sus operaciones de entrada salida sobre su recurso sin
que entre otro proceso en ese instante. A este conjunto de operaciones les llamaremos seccin
crtica, por que si llega a suceder alguna intromisin puede que haya corrupcin de datos. La
inanicin se da cuando un proceso no puede ejecutar jams su seccin crtica, casi siempre indica que el algoritmo de exclusin mutua no garantiza que todos los procesos ejecuten su seccin
crtica de una forma cclica. tenemos una condicin de carrera cuando dos o ms procesos observan que el recurso est desocupado y tienden a reservarlo y puede suceder entonces que estos
procesos obtengan el derecho a ejecutar su seccin crtica, con resultados desastrosos. Por ltimo, la sincronizacin es el mecanismo que usan los procesos para poder entrar ordenadamente
a un recurso compartido.
El sistema operativo es el encargado de proporcionar los medios adecuados para permitir
la concurrencia y tambin de proporcionar las llamadas de sistema convenientes para que los
procesos puedan hacer uso de ellas y lograr la exclusin mutua y la sincronizacin. A veces
se le deja esta tarea al programador, pero solamente el sistema operativo es el nico capaz de
administrar los accesos de los procesos a los recursos a bajo nivel y hacerla de rbitro, para
indicar a qu proceso le corresponde acceder en su momento a los datos. En el programa de la
pgina 84, el proceso principal suma uno y el hilo lo resta Qu pasara si el padre tuviera que
realizar operaciones adicionales con ese nmero ? es obvio que los resultados estaran alterados
por que ambos escriben sobre la variable en el momento en que les toca ejecutarse, sin saber si
otro proceso est usando esa variable.
89
3.4.2. Principios generales de la concurrencia

La concurrencia es fundamental en reas tales como el diseo de programas, tanto de sistemas como de aplicaciones y para el desarrollo de sistemas operativos. La concurrencia comprende un gran nmero de cuestiones de diseo, incluida la comunicacin entre procesos, comparticin y competencia por los recursos, sincronizacin de la ejecucin de varios procesos y
asignacin del tiempo de procesador a los procesos. Se ver que estas cuestiones no solo surgen
en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador.
La concurrencia puede presentarse en tres contextos distintos:
Mltiples aplicaciones. La multitarea se desarroll para permitir que el tiempo de CPU de la
computadora fuese compartido dinmicamente entre varias aplicaciones activas.
Aplicaciones estructuradas. Como ampliacin de los principios del diseo modular y la programacin orientada a objetos, algunas aplicaciones pueden implementarse eficazmente
como un conjunto de procesos concurrentes o un conjunto de hilos.
Sistemas operativos. Las mismas ventajas se aplican a los programadores de sistemas. Incluso
algunos sistemas operativos estn implementados como un conjunto de procesos o hilos.
En un sistema multitarea con una CPU, los procesos se intercalan en el tiempo aparentando una
ejecucin simultnea. Aunque no se logra un procesamiento paralelo y produce una sobrecarga
en los intercambios de procesos, la ejecucin intercalada produce beneficios en la eficiencia de
la ejecucin y en el desarrollo de programas basados en hilos o procesos, esto es, a medida que
crean ms procesos o hilos pueden terminar ms rpidamente su tarea. Si se hace uso de una
computadora con mltiples procesadores, el sistema operativo tendr la posibilidad de asignar
cada proceso o hilo a otro procesador, sin hacer cambio alguno en la aplicacin.
La intercalacin y la superposicin pueden contemplarse como ejemplos de procesamiento
concurrente en un sistema monoprocesador, los problemas son consecuencia de la velocidad
de ejecucin de los procesos que no pueden predecirse y depende de las actividades de otros
procesos, de la forma en que el sistema operativo trata las interrupciones surgen las siguientes
dificultades:
1. Compartir recursos globales es riesgoso.
2. Para el sistema operativo es difcil administrar la asignacin ptima de recursos.
Las dificultades anteriores tambin se presentan en los sistemas multiprocesador. El hecho
de compartir recursos ocasiona problemas, por esto es necesario proteger a dichos recursos. Los
problemas de concurrencia se producen incluso cuando hay un nico procesador.
90
3.4.3. La seccin crtica

Sea un sistema que consta de n procesos {PO , P1 , P2 , ..., Pn1 } cada proceso tiene un fragmento de cdigo que se denomina seccin crtica. Esta seccin de cdigo podemos identificarla
fcilmente por que ser aquella parte del proceso que modifique datos, registros o archivos que
estn compartidos con otros procesos. La caracterstica especial que tiene es que cuando un proceso est ejecutando su seccin crtica, no puede ser interrumpido por otros procesos, o en otras
palabras, dos procesos no pueden ejecutar su seccin crtica en el mismo instante. Entonces el
problema de la seccin crtica consiste en disear un conjunto de protocolos que ayuden a los
procesos a llevar a cabo su tareas en las cuales haya recursos compartidos. As, cada proceso
debe solicitar permiso, al sistema operativo o a los dems procesos para poder acceder al recurso, asegurndose de esta forma que ser el nico en ese momento. Ya que tiene el acceso, debe
bloquear la entrada a los dems procesos, de modo que no puedan interrumpirlo. Al terminar de
usar el recurso compartido debe de desbloquearlo para que puedan acceder los dems procesos
al mismo.
Se han desarrollado diversos algoritmos para afrontar la ejecucin de la seccin crtica. Para
que una solucin sea adecuada, debe cumplir al menos los siguientes puntos:
1. Asegurar la ejecucin de una sola seccin crtica excluyendo a los dems el acceso al
recurso compartido.
2. No se deben hacerse suposiciones en lo que respecta a las velocidades de ejecucin y
prioridades de los procesos que comparten datos, archivos o dispositivos.
3. Garantizar que la terminacin anormal de un proceso fuera de su seccin crtica, no afecte
el funcionamiento de los dems procesos al acceder a su seccin crtica.
4. Cuando dos o ms procesos desean ejecutar su seccin crtica, se les debe proporcionar el
acceso a cada uno de ellos en un tiempo finito.
3.4.4. Exclusin mutua; solucin por hardware y software

La exclusin mutua es asegurar que solamente un proceso est ejecutando su seccin crtica
y que los dems procesos no puedan interrumpirlo. Existen dos enfoques para asegurar la exclusin mutua, el primero depende de que el hardware tenga los mecanismos adecuados para
hacerlo. Lo ms comn es que el diseador del microprocesador incluya algunas instrucciones
especiales para permitir operaciones atmicas sobre las variables en memoria y ste se encargar
de determinar quien modifica en primer lugar la variable y as permitir el acceso a la misma en
un orden dado. Tambin en sistemas mono procesador el hardware utiliza interrupciones. Si se
91
proporciona un medio a los procesos para poder deshabilitarlas puede conseguirse la exclusin
mutua, aunque puede ocasionar muchos problemas. El segundo enfoque consiste en el diseo y
utilizacin de algoritmos de software que permitan la sincronizacin y garanticen la ejecucin
exclusiva para cada proceso de su seccin crtica.
3.4.4.1. Inhabilitacin de interrupciones
En una mquina monoprocesador, la ejecucin de procesos concurrentes no puede superponerse. los procesos solo pueden intercalarse. Es ms, un proceso continuar ejecutndose hasta
que solicite un servicio el sistema operativo o hasta que sea interrumpido. Por lo tanto, para
garantizar la exclusin mutua, es suficiente con impedir que un proceso sea interrumpido. Esta
capacidad puede ofrecerse en forma de primitivas definidas por el ncleo del sistema para habilitar o inhabilitar las interrupciones. Un proceso puede hacer cumplir la exclusin mutua del
siguiente modo:
While (cierto)
{
/*inhabilitar interrupciones */;
/* seccin crtica */;
/* habilitar interrupciones */;
/* resto */;
}
Puesto que la seccin crtica no puede ser interrumpida, la exclusin mutua est garantizada. Sin
embargo, el precio de esta solucin es alto. La eficiencia de la ejecucin puede verse notablemente degradada debido a que se limita la capacidad del procesador para intercalar programas.
Un segundo problema es que esta tcnica no funciona en arquitecturas de multiprocesador. Cuando el sistema tenga ms de un procesador, es posible (y habitual) que haya ms de un proceso
ejecutndose al mismo tiempo. En este caso, inhabilitar las interrupciones no garantiza la exclusin mutua. Hay que agregar que si el reloj se actualiza mediante interrupciones el inhabilitarlas
puede ocasionar un mal funcionamiento del mismo.
3.4.4.2. Instrucciones especiales de hardware
En configuraciones multiprocesador, varios procesadores comparten el acceso a una memoria principal comn. En este caso, no hay relacin maestro/esclavo, sino que los procesadores
funcionan independientemente en una relacin de igualdad. No hay un mecanismo de interrupciones entre los procesadores en el que se pueda basar la exclusin mutua.
92
A nivel de hardware, como se ha mencionado, los accesos a posiciones de memoria excluyen cualquier otro acceso a la misma posicin. Con esta base, los diseadores han propuesto
varias instrucciones de mquina que realizan dos acciones atmicamente, tales cono leer y escribir o leer y examinar, sobre una misma posicin de memoria en un nico ciclo de lectura de
instruccin.
Puesto que estas acciones se realizan en un nico ciclo de instruccin, no estn sujetas a ser
interrumpidas por parte de otras instrucciones.
-La instruccin comparar y fijar (TS, Test and Set) se puede definir de la forma siguiente:
boolean testset(int &i)
{
if (!i)
{
i=1;
return verdadero;
}
else
{
return falso;
}
}
La instruccin examina el valor de su argumento i. Si el valor es 0 , lo cambia por 1 y devuelve
verdadero. En otro caso, el valor no se modifica y se devuelve falso. La funcin Comparar y Fijar
se ejecuta atmicamente en su totalidad, esto es, no est sujeta a interrupciones. Si estamos en
un ambiente multiproceso y dos o ms procesadores intentan ejecutar al mismo tiempo esta funcin entonces se ordenarn aleatoriamente y se ejecutarn secuencialmente en sus procesadores
respectivos.
La instruccin intercambiar se puede definir como sigue:
void intercambiar (int registro, int memoria)
{
int aux;
aux = memoria;
memoria = registro;
registro = aux;
}
93
Esta instruccin intercambia el contenido de un registro con el de una posicin de memoria. Durante la ejecucin de la instruccin, se bloquea el acceso a la posicin de memoria de
cualquier otra instruccin que haga referencia a la misma posicin.
Enseguida analizaremos los algoritmos correspondientes a estas instrucciones. El siguiente
listado muestra un algoritmo clsico sobre el uso de cerrojos para solucionar el problema de la
seccin crtica.
/* programa que intenta resolver el
problema de exclusin mutua
*/
int n = /*numero procesos*/
int cerrojo;
void P(int i) {
while (true) {
/* cerrojo esla variable que indica si
pueden entrar a su seccin crtica.
*/
while (!testset(cerrojo)) {
/* Esperando .... */
}
/*seccin crtica*/
cerrojo = 0;
/*dems cdigo aqu*/
}
}
int main() {
cerrojo = 0;
/*Iniciamos n procesos en paralelo*/
parallelbegin(P(1),P(2) ... P(n));
return 0; /*regresa el control al S. O.*/
}
Cuando se inicia el programa, se da un valor inicial al cerrojo = 0. El nico proceso que puede
ingresar a la seccin crtica es aquel que encuentre el cerrojo en 0. Todos los dems procesos
estn en espera en el ciclo while. Cuando el proceso termine la seccin crtica, abre nuevamente
el cerrojo haciendo cerrojo = 0. El primer proceso que ejecute testset ser el que ejecute la
seccin crtica. En el siguiente programa vemos el uso de la funcin intercambiar.
94
/* exclusion mutua con funcin intercambiar*/

int n = /*numero procesos*/
int cerrojo;
void P(int i) {
int clave;
while (true) {
clave = 1;
while (clave!=0) {
exchange(clave,cerrojo);
}
/*Cdigo de seccin critica*/
intercambiar(clave,cerrojo);
/*Dems cdigo Aqu*/
}
}
int main() {
cerrojo = 0;
return 0,
}
El programa principal comienza con una variable compartida cerrojo = 0. Cada proceso tiene una
variable local iniciada en 1. clave = 1. El nico proceso que puede entrar a la seccin crtica es el
que encuentre el cerrojo abierto en 0; colocndolo en 1 (cerrado). Cuando un proceso abandona
la seccin crtica, vuelve a abrir el cerrojo colocndolo en cero.
3.4.4.3. Propiedades de las soluciones con instrucciones de mquina
El uso de instrucciones especiales de la mquina para cumplir con la exclusin mutua tiene
varias ventajas:
Es aplicable a cualquier nmero de procesos en sistemas con memoria compartida, tanto
de monoprocesador como de multiprocesador.
Es simple y fcil de verificar.
Puede usarse para disponer de varias secciones crticas; cada seccin crtica puede definirse con su propia variable.
95
Algunas desventajas importantes son las siguientes:

Se emplea espera activa. As pues, mientras un proceso est esperando para acceder a la seccin crtica, contina consumiendo tiempo del procesador.
Puede producirse inanicin. Cuando un proceso abandona la seccin crtica y hay ms de un
proceso esperando, la seleccin es arbitraria. As pues se podra denegar el acceso a algn
proceso indefinidamente.
Puede producirse interbloqueo. Suponiendo la siguiente escena en un sistema monoprocesador. El proceso P1 ejecuta una instruccin especial (sea testset o intercambiar) y entra su
seccin crtica. Se interrumpe a P1 para dar el procesador a P2 , que tiene mayor prioridad.
Si P2 intenta ahora usar el mismo recurso que P1 , se le negar el acceso por el mecanismo
de exclusin mutua. De este modo, P2 entrar en un bucle de espera activa. Sin embargo,
P1 nunca ser ejecutado porque su prioridad es menor que la del proceso listo P2 .
3.4.5. Semforos
Dentro de las soluciones de software tenemos a los semforos. Un semforo es un tipo de
datos abstracto que proporciona la capacidad de hacer uso de un recurso de manera exclusiva
cuando varios procesos estn compitiendo por ste.
El semforo cumple la siguiente semntica:
1. El estado interno del semforo lleva la cuenta de cuntos procesos pueden utilizar el recurso. Se puede implementar, por ejemplo, con un nmero entero que nunca llega a ser
negativo.
2. Existen tres operaciones con un semforo:
init(). Inicializa el semforo antes de que cualquier proceso haya ejecutado una operacin
wait() ni una operacin signal() al nmero nmero de procesos que tengan derecho
a acceder el recurso. Si se inicializa con 1, tenemos entonces un semforo binario.
wait(). Si el estado indica cero, el proceso queda suspendido por el semforo hasta que sea
despertado por otro proceso. Si el estado indica que un proceso ms puede acceder
el recurso se decrementa el contador y la operacin termina con xito.
signal(). Una vez se ha terminado el uso del recurso, el proceso se lo indica al semforo
con esta instruccin. Si hay algn proceso bloqueado en el semforo entonces uno
de stos se pasar al estado de listo, de otra forma se incrementa el contador.
96
La operacin wait() debe ser implementada como una instruccin atmica. No obstante, en
muchas implementaciones se puede interrumpir. Normalmente existe una forma de comprobar
si la salida del wait() es debido a una interrupcin o porque se ha dado acceso al semforo. La
operacin signal() tambin tiene que ser implementada como instruccin atmica. En ciertas
implementaciones se puede comprobar si se ha despertado un proceso con xito en caso que
hubiera alguno bloqueado.
Para despertar los procesos se puede implementar varias formas que se distinguen , por
ejemplo con un simple sistema tipo FIFO.
El acceso a regiones crticas puede hacerse con un semforo que permita el acceso a un slo
proceso.
En la seccin 3.2 hablamos sobre los estados en los que puede estar un proceso. Para evitar
que un proceso consuma tiempo de CPU es necesario crear un nuevo estado, se denomina estado
en espera. De esta forma, dos o ms procesos pueden cooperar mediante seales de forma que
pueda obligar a detenerse a un proceso hasta que reciba una seal para que contine. As es
posible lograr que se comuniquen varios procesos de modo que todos ellos puedan acceder a
su seccin crtica en un momento dado. Para lograr esto se usa una variable llamada semforo
para intercambiar seales. Si un proceso est en espera de una seal, se suspende hasta que la
seal sea enviada por otro proceso. Como se mencion wait() y signal() son operaciones que
no pueden interrumpirse. El semforo mantiene una cola de procesos en espera. La manera en
que los procesos salen de la cola en espera es mediante una poltica primero en entrar, primero
en salir. En la figura 3.2 tenemos el diagrama de estados de los procesos incluido el estado de
espera.
A continuacin tenemos los algoritmos y las estructuras que se usan para construir un semforo binario.
struct semaforo_binario {
enum(zero,one) value;
queueType queue;
};
void waitB(semaforo_binario s)
{
if (s.value == 1)
s.value=0;
else {
/*colocar este proceso P
en la cola s.queue*/

/*bloquear el proceso*/
}
}
void signalB(semaforo_binario s)
{
if (s.queue.is_empty())
s.value=1;
else {
/*remover el proceso P
de la cola s.queue*/
/*colocar el proceso P
como listo para ejecucion*/
}
}
Figura 3.2: Los estados de un proceso ms el estado de espera
97
98
3.4.5.1. Algoritmo para un semforo binario

Un semforo, como se mencion, cuenta en su estructura con una cola de procesos que
esperan que el semforo les d el paso libre. En la operacin wait(s), si el semforo est libre
(valor 1), cierra el paso (valor 0). En la operacin wait(s), si el semforo cierra el paso (valor
0), coloca el proceso en la cola de espera de este semforo. En la operacin signal(s), si la cola
de espera est vaca, el semforo se coloca como libre (valor 1) En la operacin signal(s), si
la cola de espera no esta vaca, el primer proceso de la cola en espera se coloca en la cola de
preparados, listos para que el planificador de procesos lo lleve al CPU para su ejecucin. En el
siguiente listado tenemos un programa ejemplo de la utilizacin de un semforo binario.
El funcionamiento general de un semforo es el siguiente: Sean n procesos en el vector
P(i), en cada proceso se ejecuta un wait(s) antes de la ejecucin de la seccin crtica. El primer
proceso que cambie el semforo lo har del valor 1 al valor 0, cerrando el paso, los dems
procesos que encuentren el semforo cerrado (valor 0) se encontrarn en la cola de espera de
este semforo. Una vez que el primer semforo termine la seccin crtica, ejecutar un signal(s)
que colocar el valor del semforo en 1 y que habilitar para su ejecucin al siguiente proceso
de la cola de espera del semforo.
El algoritmo quedara as:
/* programa de exclusin mutua usando un semforo*/
int n = /*nmero procesos*/
semaforo s=1;
void P(int i) {
while (true) {
wait(s);
/*seccion crtica*/
signal(s);
/*cdigo restante*/
}
}
int main() {
}
Observamos los siguiente detalles:
1. Si algn proceso no libera el semforo, se puede provocar un bloqueo.
99
2. No hace falta que un proceso libere su propio recurso, es decir, la operacin signal() puede
que sea ejecutada por otro proceso.
3. Con simples semforos no se puede imponer un orden en los procesos accediendo a diferentes recursos.
Unas principales desventajas de semforos son:
1. Depende del programador el uso correcto de los wait() y signal()
2. El recurso es independiente del semforo.
3. Entre wait() y signal() el usuario puede realizar cualquier operacin con el recurso.
3.4.6. Monitores
Los monitores son estructuras que implementa un lenguaje de programacin y ofrece una
mayor funcionalidad que los semforos pues son ms fciles de controlar. El concepto de monitor fue definido por primera vez en Hoare mencionado por [33]. La estructura de monitor se ha
implementado en varios lenguajes de programacin como: Pascal concurrente, Modula-2, Java,
y otros.
En concreto, para una lista enlazada se puede necesitar un cerrojo que bloquee todas las
listas enlazadas o bien un cerrojo por cada elemento de una lista. En la figura 3.3
Figura 3.3: Estructura general de un monitor
100
3.4.6.1. Monitores con Seales

Un monitor es un mdulo de software que consta de uno o ms procedimientos[48], una
secuencia de inicio y uno datos locales. Sus caractersticas son las siguientes:
1. Slo los procedimientos del monitor acceden a variables de datos locales.
2. Un proceso entra en el monitor invocando a uno de sus procedimientos.
3. En el monitor solo un proceso puede ser ejecutado en un momento dado; cualquier otro
proceso quedar suspendido esperando la disponibilidad del monitor.
Al ser un proceso por vez, el monitor puede ofrecer un servicio de exclusin mutua fcilmente. As una estructura de datos puede protegerse situndola dentro de un monitor.
Los monitores deben ofrecer herramientas de sincronizacin. Por ejemplo: si un proceso
llama a un monitor y una vez dentro de l el proceso queda suspendido esperando alguna condicin, har falta un servicio que libere al monitor y lo deje disponible para el siguiente proceso.
Ms tarde cuando la condicin se cumpla, el proceso suspendido podr regresar al monitor y
ejecutarse desde el momento de la suspensin.
El monitor proporciona variables de condicin que son accesibles slo desde dentro del
monitor.
Hay dos funciones para operar variables de condicin:
cwait (c). Suspende la ejecucin del proceso que llama bajo la condici+n ". El monitor est
ahora disponible para otro proceso.
csignal (c). Retorna la ejecucin de un proceso suspendido despus de un cwait, bajo la misma
condicin. Si hay varios procesos elige uno de ellos.
Si un proceso de monitor ejecuta un csignal() y no hay tareas esperando entonces el csignal() se pierde.
Aunque un proceso puede entrar al monitor llamando a cualquiera de sus procedimientos, se
puede decir que el monitor tiene un solo punto de acceso, custodiado para que slo un proceso
est en el monitor en un instante dado. Si existen otros procesos tratando de entrar al monitor,
stos se colocan en una cola de procesos suspendidos esperando la disponibilidad del monitor.
Un proceso dentro de un monitor puede suspenderse a s mismo, temporalmente, bajo la
condicin X ejecutando cwait(x), entonces se coloca en una cola de procesos que esperan que
cambie la condicin X entonces ejecuta un csignal(x) que avisa a la cola de condicin correspondiente de que la condicin a cambiado.
101
3.4.6.2. Monitores con Notificacin y Difusin

Son varios los inconvenientes que presenta la solucin de Hoare[48, 60]:
1. Si el proceso que ejecuta el csignal() no ha terminado en el monitor, se necesitarn dos
cambios de procesos adicionales: uno para suspender el proceso y otro para reanudarlo.
2. La planificacin de procesos asociados con las seales debe ser muy fiable. Si un proceso
ejecuta un csignal(), el proceso de la cola de condicin correspondiente debe activarse de
inmediato, antes de que ingrese otro proceso del exterior o cambie la condicin bajo la
que se activ el proceso.
Lampson y Redell desarrollaron una definicin de monitores para el lenguaje MESA [60].
La estructura de mesa reemplaza la primitiva csignal() por cnotify(). Cuando un proceso ejecuta
cnotify(x) enva una notificacin a la cola de condicin X, lo cual no significa que el proceso
que esta ocupando el monitor vaya a detenerse, simplemente el cnotify(x) avisa al proceso de la
cola de condicin correspondiente de que ser reanudado en un futuro cercano. Puesto que sta
no garantiza que un proceso exterior entre al monitor, el proceso debe comprobar la condicin
nuevamente.
En el cdigo, la sentencia IF se reemplaza por un bucle While, lo cual genera una evaluacin
extra de la variable, pero sin embargo no hay cambios de procesos extra.
Una modificacin til sera asociar un temporizador de guardia a cnotify() que permitira
que un proceso que ha esperado durante el intervalo mximo sea situado en estado de listo,
independientemente de si se ha notificado la condicin o no.
Con la norma de notificar a los procesos en lugar de reactivarlos, es posible aadir una primitiva de difusin cbroadcast(). La difusin provoca que todos los procesos que estn esperando
por una condicin se coloquen en el estado de listo. Esto es til cuando un proceso no sabe
cuantos procesos deben reactivarse.
El mtodo Lampson/Redell es menos propenso a errores debido a que cada procedimiento
comprueba la condicin luego de ser despertado, por medio de la instruccin while, un proceso
puede realizar una seal o una difusin incorrectamente sin provocar un error en el programa
que la recibe.
Adems este modelo presenta un mtodo ms modular de construccin de programas.
Hay dos niveles de condicin que deben satisfacerse para los procesos secuenciales cooperantes.
1. Estructura de datos consistentes: significa que el monitor hace cumplir la exclusin mutua
y concluye la operacin de entrada o salida antes de permitir cualquier otra operacin
sobre el bfer.
102
2. La misma condicin del nivel 1 y, adems disponer de suficiente memoria para que este
proceso pueda completar su solicitud de asignacin.
Un monitor, a diferencia de un semforo es una estructura que permite tener un control mayor sobre los procesos que van a hacer uso de un recurso. Los sistemas operativos y los lenguajes
de programacin proporcionan mecanismos muy similares para implementar las funcionalidades de semforos y monitores. Por ejemplo Solaris pone a disposicin del programador mtex
adaptativos, variables de condicin, semforos, bloqueos o cerrojos del tipo lector-escritor y colas de bloqueos. Solaris se apega a la estructura de monitor analizada en esta seccin. Adems,
Solaris uso ciclos infinitos para proteger el acceso a datos compartidos, solamente si el cdigo
consta de algunos cientos instrucciones, de otra forma este mecanismo sera muy ineficiente.
Cuando el cdigo se excede de este nmero de instrucciones entonces se usa un semforo o
variables de condicin. De esta forma si el hilo ya est ocupando el cerrojo, entrar en un ciclo
infinito y pasar al estado durmiente. Cuando se libere el cerrojo, el hilo que la ocupa ejecutar
una instruccin signal() dirigida al hilo siguiente en estado de espera, de modo que pueda pasar
a ejecucin. Es ms econmico en trminos de instrucciones de CPU, realizar un cambio de
contexto a estar ejecutando quizs miles de ciclos de espera en un ciclo infinito.
Windows XP al igual que en Solaris protege los bloques de datos mediante ciclos infinitos
en segmentos de cdigo pequeos, pero por razones de eficiencia, el kernel no sacar un hilo
mientras mantenga un cerrojo que est ejecutando un ciclo infinito. Para la sincronizacin de
hilos que no se ejecutan en el kernel Windows XP proporciona mtex, semforos, sucesos y
temporizadores. El sistema protege los datos compartidos requiriendo que un hilo adquiera la
propiedad de un mtex para acceder a los datos y libere dicha propiedad cuando termine. Los
sucesos son similares a las variables de condicin y los temporizadores se emplean para notificar
a uno o ms hilos que ha transcurrido un determinado perodo de tiempo.
En Linux la sincronizacin se lleva a cabo mediante ciclos infinitos y semforos usando
tambin versiones lector-escritor de stos, de esta forma, se pueden establecer bloqueos en el
kernel. En una mquina de multiprocesadores, el mecanismo fundamental de bloqueo se basa en
ciclos infinitos y el kernel se disea de modo que dicho tipo de bloqueo se mantenga slo durante
perodos de tiempo cortos. En mquinas monoprocesador, los bloqueos mediante ciclos infinitos
no resultan apropiados y se reemplazan por un mecanismo de activacin y desactivacin de la
funcin de apropiacin en el ncleo.
3.4.7. Paso de mensajes

Los semforos, los monitores y los mtex estn pensados principalmente para la sincronizacin entre procesos. Los monitores proporcionan adicionalmente abstraccin de datos, pero
103
tienen algunos problemas de implementacin y tienden a ser restrictivos en cuanto al rango de

interpretaciones permisibles de los datos. Adems, la implementacin de esos mecanismos tiende a confiar en gran medida en la suposicin de acceso comn a memoria por parte de todos
los procesos que intervienen en la sincronizacin. Por ejemplo, las variables semforo son globales y las estructuras de monitor (datos locales, procedimientos pblicos) estn generalmente
centralizados. El acceso a las variables globales puede ocasionar considerables retrasos de comunicacin en sistemas distribuidos que no disponen de memoria comn. Como resultado, la
aplicacin directa de mecanismos centralizados para control de concurrencia en entornos distribuidos suele ser ineficaz y lenta.
Los mensajes son un mecanismo relativamente sencillo adecuado tanto para comunicacin
como para sincronizacin entre procesos en entornos centralizados adems de entornos distribuidos. Muchos sistemas operativos de multiprogramacin comerciales soportan algn tipo de
mensajes entre procesos. El envo y recepcin de mensajes es una forma estndar de comunicacin entre nodos de redes de computadoras, lo que hace que sea muy atractivo aumentar esta
facilidad para proporcionar las funciones de comunicacin y sincronizacin entre procesos. Por
esta razn, los mensajes son muy populares en sistemas operativos distribuidos.
En esencia, un mensaje es una coleccin de informacin que puede ser intercambiada entre
un proceso emisor y un receptor. Un mensaje puede contener datos, rdenes de ejecucin o
incluso cdigo a transmitir entre dos o ms procesos. Los mensajes suelen ser utilizados en
sistemas distribuidos para transferir porciones importantes del sistema operativo y/o programas
de aplicacin a nodos remotos.
El formato del mensaje es flexible y negociable por cada pareja especfica emisor-receptor.
Un mensaje se caracteriza por su tipo, longitud, identificadores de emisor y receptor y un campo
de datos.
3.4.7.1. Operaciones tpicas de los mensajes
Las operaciones ms comunes que proporcionan los sistemas operativos son enviar (send)
mensaje y recibir mensaje. Los aspectos de implementacin ms importantes acerca de los mensajes son:
Denominacin Existen dos tipos:
Denominacin directa. Es aquella que cuando se invoca una operacin de mensaje, cada
emisor debe designar al receptor especfico, y a la inversa, cada receptor debe designar una
fuente desde la cual desea recibir un mensaje. Por ejemplo
104
proceso A;
/*Mucho cdigo de A*/
send(B, mensaje)
/*Ms Cdigo de A*/
fin
proceso B;
/*Mucho cdigo de B*/
receive(A, mensaje)
/*Ms Cdigo de B*/
fin
donde mensaje es el mensaje que se ha transmitido desde A hacia B. A y B son las entidades que interactan y que deben ser especificadas al momento de efectuar las correspondientes
llamadas. En este caso, si B se ejecuta antes, tendr que esperar a que A enve el mensaje. Si
A se ejecuta antes B tendr que esperar a que B pueda recibir el mensaje. Esta forma de comunicacin es segura en el sentido de que los procesos saben exactamente a donde va y de donde
viene la informacin, pero bajo ciertos entornos no puede ser posible tener una lista de todos los
emisores y receptores.
Denominacin indirecta. Los mensajes son enviados y recibidos a travs de depsitos especializados dedicados para este propsito. A estos depsitos se les denomina buzones debido a su
modo de funcionamiento. Un ejemplo del uso de buzones puede verse en el siguiente listado:
proceso A;
/*Mucho cdigo de A*/
send(buzn1, mensaje)
/*Ms Cdigo de A*/
fin
proceso B;
/*Mucho cdigo de B*/
receive(buzn1, mensaje)
/*Ms Cdigo de B*/
fin
Observe que ahora que A no necesita que est disponible B o viceversa. Si A se ejecuta antes
enva su mensaje al buzn y hasta que se ejecute B lo podr recoger. Si B se ejecuta antes que A
tendr que esperar a que llegue el mensaje al buzn revisndolo continuamente.
105
El sistema operativo tendr que proporcionar las facilidades necesarias para poder hacer uso
de los buzones, tal como la de crear un nuevo buzn y la de eliminar un buzn.
La comunicacin indirecta es muy verstil en el sentido de que puede proporcionar correspondencias uno a uno o de uno muchos, de muchos a uno y de muchos a muchos entre los
procesos emisores y los receptores.
Copia. El intercambio de mensajes entre dos procesos, por definicin, transfiere el contenido
del mensaje desde el espacio de direcciones del emisor al espacio de direcciones del receptor.
Esto se logra copiando todo el mensaje al espacio de direcciones del receptor o simplemente
pasando un apuntador al mensaje entre los dos procesos. En otras palabras, la transferencia
del mensaje puede ser por valor o por referencia. En sistemas distribuidos que no disponen de
memoria comn, la copia es obviamente inevitable. En sistemas centralizados, el compromiso
est entre la seguridad y la eficiencia.
Como aspecto negativo, la copia de mensajes consume memoria y ciclos de CPU. La comunicacin asncrona de mensajes y/o esquemas de proteccin de memoria pueden requerir que
cada mensaje sea copiado primero desde el espacio del emisor a un bfer en el sistema operativo
y desde ah posteriormente al espacio de proceso del receptor. Esto significa que se hace una
doble copia para un solo mensaje. Aparte la estructura de datos dinmica que debe de manejar
el sistema operativo para la administracin de los mensajes. Algunos diseadores enfrentan este
problema proporcionando solamente un apuntador al espacio de direcciones del emisor, pero
este enfoque disminuye la seguridad al estar abriendo una ventana al proceso receptor con sus
consecuentes peligros.
Mach. enfrenta este problema al asignar una sola copia, tanto al emisor como al receptor,
siempre y cuando slo la usen para lectura. En el momento en que alguno quiera realizar una
operacin de escritura, se crea entonces una copia fsica se actualizan las tablas de direcciones
y entonces cada proceso contina con una copia separada del mensaje.
Intercambio sncrono frente a asncrono. El intercambio de un mensaje entre un emisor y un
receptor pude ser sncrono o asncrono. Cuando un intercambio de mensajes es sncrono, tanto
el emisor como el receptor deben de proceder juntos a completar la transferencia. En sistemas
sncronos la operacin enviar es bloqueante. es decir, cuando un emisor desea enviar un mensaje
para el cual no se ha emitido el correspondiente recibir, el emisor debe quedar suspendido hasta
que un receptor acepte el mensaje. En consecuencia, slo puede haber un mensaje pendiente
como mximo en cada momento por cada emisor-receptor.
Las ventajas del mecanismo sncrono de enviar-recibir mensajes son su recargo comparativamente bajo y su facilidad de implementacin, adems del hecho de que el emisor sabe que
106
sumensaje ha sido realmente recibido en el momento en que deja atrs la operacin enviar. Una
desventaja de este mtodo es la obligada operacin sncrona de emisores y receptores, que puede
no ser deseable en algunos casos.
Con el intercambio asncrono de mensajes, el emisor no queda bloqueado cuando no hay
un recibir pendiente. El enviar asncrono, sin bloqueo, se implementa haciendo que el sistema
operativo acepte y almacene temporalmente los mensajes pendientes hasta que se emita el correspondiente recibir. De esta forma el emisor puede continuar su ejecucin despus de enviar
un mensaje y no necesita quedar suspendido, independientemente de la actividad de los receptores. Este modo de operacin de depositar y olvidar aumenta el grado de concurrencia del
sistema. Por ejemplo, un proceso que desee imprimir algo puede incluir simplemente los datos
en cuestin en un mensaje y enviarlo al proceso servidor de impresoras. Incluso si el servidor de
impresoras est ocupado en ese momento, el mensaje ser almacenado en la cola por el sistema y
el emisor podr continuar sin necesidad de esperar. Esta forma de operar tambin conlleva riesgos. Podemos notar que si se llega a tener un proceso que genere muchos mensajes sin sentido
puede llegar a llenar el almacenamiento temporal del sistema operativo, impidiendo as la comunicacin normal entre los dems procesos. Una forma de evitar este problema es imponiendo
un lmite al nmero de mensajes que puede tener pendiente un proceso.
Un problema relacionado con el anterior se le llama aplazamiento indefinido. Este ocurre
cuando se enva un mensaje pero nunca se recibe debido, por ejemplo, a que el receptor ya no
est en el sistema, o cuando un receptor est esperando un mensaje que nunca se produce. Para
evitar este tipo de problemas se puede implementar a recibir sin bloqueo. De esta forma si el
mensaje se encuentra disponible, lo leer, de otro modo, continuar con su ejecucin normal y
despus en otro momento volver a intentar la lectura para ver si est disponible, evitando as el
bloqueo.
Longitud. El ltimo punto en cuanto a la implementacin de los mensajes es determinar el tamao adecuado de cada mensaje, esto es, si deben de tener longitud fija o longitud variable. Aqu
tenemos un compromiso de recargo del sistema frente a flexibilidad. Se se hace la transferencia
va apuntadores, entonces no hay tanto problema. Sin embargo, cuando los mensajes deben ser
copiados y almacenados temporalmente este aspecto debe ser evaluado cuidadosamente.
Los mensajes de tamao fijo suelen producir una recarga del sistema relativamente baja,
en virtud de que permite a los buferes del sistema ser tambin de longitud fija, lo que hace su
asignacin bastante sencilla y eficaz. Aqu el problema es que en un ambiente real, los mensajes
llegan de todos tamaos haciendo casi imposible la asignacin de memoria sin desperdicio de
sta. Los mensajes de tamao dinmico alivian este problema pero incrementan la complejidad
del diseo del manejador de memoria del sistema operativo al tener que manejar estructuras de
107
control para memoria dinmica, que puede conducir a problemas de fragmentacin de memoria.
3.4.7.2. Comunicacin y sincronizacin interprocesos con mensajes

Aunque los mensajes son adecuados tanto para comunicacin como para sincronizacin entre procesos, analicemos primero el aspecto de la sincronizacin de sus operaciones con el fin
de establecer un punto de referencia con lo visto en el punto 3.4.7.1. Hay que observar que intercambiar un mensaje vaco, sin datos entre dos procesos equivale a sealizar. Un proceso al
enviar un mensaje, transfiere una seal de temporizacin a otro proceso, el receptor. Por lo que
se refiere a la sealizacin, esto tiene el mismo efecto que si un proceso (el emisor) ejecuta una
operacin signal() y el otro (el receptor) ejecuta un wait() sobre el mismo semforo. En esta
analoga. la identidad del buzn corresponde con el nombre de la variable del semforo.
Dado el poder de sealizacin del de los mensajes, la exclusin mutua puede lograrse siguiendo la lgica de una solucin similar con semforos. En el siguiente algoritmo se representa
el cdigo de usuario que accede a un recurso compartido protegido por el buzn mtex. De
acuerdo con la lgica de los semforos, cuando se crea un buzn est vaco, es decir, no contiene mensajes. Esto es equivalente a los semforos se inicialicen por el sistema en ocupado. Para
hacer que el recurso est disponible para el primer solicitante, el proceso padre enva un mensaje
al buzn antes de iniciar los procesos usuarios del recurso. Puesto que este mensaje se utiliza
nicamente para fines de sealizacin, su contenido es irrelevante, y se supone que es un mensaje nulo, vaco. Algn tiempo despus, el primer proceso que desea utilizar el recurso invoca la
operacin recibir sobre el buzn mtex. Esto ocasiona a que el mensaje nulo inicial sea retirado
del buzn y entregado al proceso a travs del parmetro mensaje. Cuando ya recibi el mensaje,
el proceso es libre de continuar y entra a la seccin crtica. Si cualquier otro proceso ejecuta
una instruccin recibir sobre el buzn mtex durante ese tiempo quedar suspendido debido a
que el buzn se encuentra vaco. Cuando el proceso completa su seccin crtica, el propietario
devuelve un mensaje en mtex y contina ejecutndose. Uno de los procesos suspendidos en
mtex, si los hay, recibe entonces el mensaje y por tanto, se ve capacitado para proseguir con su
seccin crtica. Los restantes procesos es espera, en caso de que los haya, obtendrn sus turnos,
uno cada vez, cuando el mensaje sea devuelto por os procesos que abandonen su seccin crtica.
Como se ve, este esquema es conceptualmente parecido al de los semforos. Un solo mensaje circula a lo largo del sistema como testigo del permiso de utilizacin del recurso compartido.
puesto que slo un proceso como mximo puede tener la propiedad del mensaje en cada instante, la exclusin mutua est asegurada. Esto, naturalmente, depende de la suposicin de que
la operacin recibir es indivisible en el sentido de entregar el mensaje, en caso de haberlo, a
un solo invocador cuando sea invocado concurrentemente por varios. Virtualmente todas las im-
108
plementaciones de mensajes proporciona este tipo de facilidad y se supone que esta propiedad
existe a lo largo del anlisis efectuado en esta seccin. Cuando se utilizan para sealizacin, el
mismo acto de recibir un mensaje logra el propsito deseado, y el contenido efectivo del mensaje
no importa. Despus se ver que la verdadera potencia de los mensajes es cuando los procesos
transfieren datos al mismo tiempo, combinando as la comunicacin y la sincronizacin entre
procesos dentro de una sola actividad.
En el algoritmo siguiente vemos cmo podra implementarse la proteccin de la seccin
crtica con mensajes.
...
const int tamano;
typedef struct mensaje{
char elmensaje[tamano];
/*Otra informacin del mensaje*/
} Tmensaje;
int usuarioX(){
Tmensaje mensaje;
while (true) {
recibir(mtex, mensaje);
seccin_critica(),
enviar(mtex, mensaje);
} /*fin while*/
}
/*Fin usuarioX*/
/*Cuerpo del proceso padre*/
int main(){
/*Todos los procesos hijo
acceden al buzn
*/
crear_buzon(mtex);
enviar(mtex,nulo);
parallelbegin(proceso1,proceso2,...,procesoX);
}
El programa de la pgina 108 demuestra informalmente cmo se puede utilizar una facilidad de mensajes para implementar semforos binarios. La implicacin importante es que los
109
mensajes no son un mecanismo ms dbil que los semforos. Los semforos generales pueden
simularse aumentando el nmero de mensajes testigo en el sistema hasta que coincida con el
valor inicial de un semforo general equivalente.
3.4.7.3. Envo de seales de interrupcin con mensajes
El mecanismo de interrupcin proporciona un enlace entre los sucesos externos asncronos
y las rutinas software que le prestan el servicio. Esto es, las interrupciones indican la llegada de
sucesos externos. Tericamente es como si un proceso enviara una seal dado un cierto suceso.
Tomando en consideracin lo anterior, es posible implementar mecanismos de seales que sea
uniforme y que incluya tanto la sincronizacin ordinaria como las interrupciones, ya sea de
hardware o de software. En la realidad, la mayora de los sistemas comerciales tienden a separar
el manejo de interrupciones y el de las seales debido a que las primeras cuentan con mayor
informacin para ser se manejadas por rutinas generales.
No obstante, desde el punto de vista conceptual, la sincronizacin tiene requisitos parecidos
en ambos casos y tiene poca justificacin mantener dos conjuntos de procesos separados a nivel
de usuario. El sistema operativo podra convertir cada interrupcin en una seal enviada por el
sistema a un proceso que la espere. Por ejemplo, puede crearse un semforo por cada interrupcin. entonces las rutinas de servicio de interrupcin pueden conectarse a los sucesos externos
ejecutando una operacin wait() sobre el semforo asociado cada vez que estn preparadas para
dar servicio a una interrupcin. La llegada de un suceso externo, indicada por una interrupcin,
se puede utilizar para activar el servidor mediante la operacin signal() ejecutada por el sistema
operativo sobre el semforo asociado.
3.4.8. Concurrencia e interbloqueo (deadlock)

En general, una elevada utilizacin de recursos y la posibilidad de la operacin paralela
de muchos dispositivos de entrada/salida gobernados por procesos concurrentes, contribuyen
a mejorar el potencial de rendimiento de los sistemas multitarea y de multiprogramacin. Al
mismo tiempo, la concurrencia y la elevada utilizacin de recursos tambin proporciona las
condiciones necesarias y la base para que se produzcan interbloqueos que puedan ocasionar que
el rendimiento general del sistema baje, en ocasiones hasta quedar completamente inutilizado.
int proceso1(){
...
wait(impresora);
wait(disco1);
int proceso2()\{
....
wait(disco1);
wait(impresora);
110

wait(disco2);
procesar(disco1,
disco2,
impresora);
signal(disco1);
signal(disco2);
signal(impresora);
.....
procesar(disco1,impresora);
signal(impresora);
signal(disco1);
.....
}
Hasta ahora hemos hablado de los mecanismos para poder manejar la seccin crtica evitando
que lleguen a acceder dos o ms procesos al mismo tiempo y al mismo recurso. No obstante,
un mal uso, algunas omisiones e incluso algn cdigo malicioso, pueden llegar a hacer que
los procesos queden esperando indefinidamente por un recurso que muchas de las veces est
desocupado, pero por los problemas anteriores parece que est siendo utilizado por otro proceso.
Un interbloqueo (tambin conocido como deadlock o abrazo mortal) es una situacin donde
un conjunto de procesos estn permanentemente bloqueados como consecuencia de que cada
proceso ha adquirido un subconjunto de los recursos necesarios para su operacin y est esperando la liberacin de los recursos restantes mantenidos por otros del mismo grupo, haciendo
imposible que alguno de los procesos pueda continuar su ejecucin.
Los interbloqueos pueden ocurrir en entornos concurrentes como resultado de la concesin
incontrolada de recursos del sistema a los procesos que hacen la peticin.
Vamos a poner un ejemplo, considrese que un sistema contiene una impresora y dos unidades de disco. Supngase que dos procesos concurrentes efectan las peticiones de recursos
indicadas en la pgina 109. La secuencia presentada supone que los recursos son solicitados
y devueltos al asignador de recursos por medio de las operaciones que ya conocemos wait() y
signal() sobre las variables de semforo binario impresora y disco (general inicializado a dos),
respectivamente, Ahora suponemos que tenemos dos procesos concurrentes P1 y P2, se entrelazan de tal modo que en un cierto momento el proceso P1 tiene concedido el uso de la impresora
y P2 trata de conseguir una unidad de disco. En este caso, los dos procesos estn interbloqueados, ya que ninguno de ellos puede adquirir el conjunto de recursos que necesita para continuar
su ejecucin y liberar los recursos que le han sido asignados.
3.4.9. Principios del interbloqueo

Generalizando algunas caractersticas de los interbloqueos, el listado de la pgina 109 ilustra
que el problema es el resultado de la ejecucin concurrente, ya que cada proceso podra com-
111
pletarse correctamente si se ejecutase en forma serie en cualquier orden arbitrario. Adems, el

problema slo ocurre para algunas situaciones especficas de entrelazamiento de los dos procesos. Esto es, si alguno logra hacerse de los recursos que necesita antes de que el otro tome
alguno, entonces no se dar el interbloqueo y ambos podrn ejecutarse adecuadamente. En el
listado de la pgina 109 se hace uso de wait() y signal para hacer notar que los procesos mantienen los recursos que han obtenido, mientras esperan los que que necesitan, tambin se sugiere
que slo pueden entrar a su regin crtica en el momento en que disponen de todos los recursos
solicitados, tambin en el ejemplo se usaron dispositivos fsicos, pero en realidad, puede usarse cualquier recurso del sistema. en general los interbloqueos pueden ocurrir como resultado de
competencias sobre cualquier clase de recurso compartido, incluyendo la memoria principal, datos globales, bferes y archivos o registros. Las situaciones mencionadas anteriormente ilustran
las condiciones necesarias para que se produzca el interbloqueo, las cuales pueden formularse
ms explcitamente del modo siguiente:
Exclusin mutua. Los recursos compartidos son asignados y usados de modo mutuamente exclusivo, esto es, por un proceso como mximo en cada instante.
Conservar y esperar. Cada proceso conserva los recursos que ya le han otorgado mientras espera a adquirir los otros recursos que necesita.
No expropiacin. Solamente el proceso puede regresar voluntariamente los recursos que le han
sido asignados. El sistema operativo no puede revocarlos.
Espera circular. Los procesos interbloqueados forman una cadena circular de modo que cada
proceso conserva uno o ms recursos que son requeridos por el siguiente proceso de la
cadena.
La existencia simultnea de estas condiciones define el estado de interbloqueo. En otras
palabras, las cuatro condiciones deben estar presentes para que se produzca un interbloqueo. Por
lo tanto, un modo de manejar los interbloqueos es asegurarse que en cada momento al menos una
de las cuatro condiciones necesarias para que se produzca el interbloqueo sea evitada por diseo.
Otra posibilidad es hacer que el asignador de recursos examine las posibles consecuencias de
asignar un recurso solicitado particular y evite las situaciones inseguras que puedan conducir
a interbloqueos y tomar acciones que lo remedien cuando sea necesario. La mayora de las
tcnicas de manejo de interbloqueos caen en una de esas tres categoras, que normalmente se
denominan prevenir, evitar, detectar y recuperarse de un interbloqueo.
112
3.4.10. Acciones a realizar ante un interbloqueo

Antes de hablar de las tcnicas de prevenir, evitar, detectar y recuperarse de un interbloqueo,
es necesario saber algunas caractersticas de los recursos del sistema.
3.4.11. Recursos reutilizables y consumibles del sistema

Los recursos de un sistema de computadora cuya asignacin est sujeta a interbloqueos se
pueden clasificar en dos grupos:
1. Recursos reutilizables.
2. Recursos consumibles.
Los recursos reutilizables se caracterizan porque pueden ser utilizados con seguridad por un
proceso slo cada vez como mximo. Tales recursos son normalmente asignados a un proceso
solicitante cuando estn disponibles. Cuando son liberados explcitamente pos su propietario
temporal, un recurso reutilizable puede ser asignado al siguiente proceso solicitante, si es que
hay alguno. Los recursos hardware compartidos y las estructuras de datos globales estticas y
a largo plazo pertenecen habitualmente a esta categora. algunos ejemplos incluyen la memoria
principal, los buses de entrada salida, las unidades de disco y los bferes del sistema. por lo
comn existe un nmero fijo de recursos reutilizables en el sistema. Pueden existir diferentes
instancias de un mismo tipo de recurso reutilizable, como las pginas de memoria o impresoras.
Si las unidades individuales de un tipo particular de recurso son indistinguibles en el sentido
de que cualquiera de ellas puede satisfacer una solicitud determinada, entonces tales unidades
no son tenidas en cuenta separadamente por lo que respecta a la deteccin de interbloqueos; el
sistema nicamente contabiliza el nmero total. En cada momento, cada recurso reutilizable est
o bien disponible, o bien temporalmente concedido a un proceso. La suposicin ms comn es
que el propietario temporal de un recurso lo devolver en un tiempo finito a menos que resulte
interbloqueado.
Los recursos consumibles, por ejemplo los mensajes, se producen y se consumen por procesos que se encuentran activos. Esto significa que el nmero de esos recursos puede variar a
medida que transcurre el tiempo. Una causa que es comn de ocasionar un interbloqueo y que
afecta a los recursos consumibles es la espera de un evento, por ejemplo una seal o un mensaje,
que nunca van a llegar. Esto suele suceder por una sincronizacin inadecuada, un direccionamiento errneo de los mensajes, el proceso encargado de generar la seal o el mensaje termin
anormalmente o en ltima instancia a errores de programacin.
113
3.4.11.1. Prevencin de interbloqueos

Como se mencion en la seccin 3.4.9, el punto bsico es evitar al menos una de las cuatro
condiciones necesarias para que se produzcan los interbloqueos. La exclusin mutua es generalmente difcil de evitar, por lo que es costumbre prevenir una o ms de las tres condiciones
restantes.
Exclusin mutua Esta se aplica a los recursos que no pueden ser compartidos. Por ejemplo,
varios procesos no pueden compartir simultneamente una impresora. Los recursos que s pueden compartirse y por lo tanto, no pueden generar una situacin de interbloqueo. Dentro de stos
podemos poner como ejemplo un archivo de slo lectura. Si varios procesos desean abrir un archivo en modo de slo lectura entonces se les puede conceder a todos de forma simultnea. As
un proceso no necesita esperar por un recurso compartible. No obstante, no se puede ignorar
la exclusin mutua diciendo que simplemente nunca va a suceder, por que varios recursos son
explcitamente no compartibles.
Conservar y esperar Esta condicin se puede eliminar exigiendo o forzando a un proceso
a que libere todos los recursos asignados a l cada vez que solicite un recurso que no est
disponible. Esto quiere decir que los interbolqueos se previenen debido a que los procesos en
espera no retienen recursos. Existen dos posibles formas de implementar esta estrategia:
Solicitar todos los recursos. El proceso solicita de una sola vez todos los recursos antes de
entrar en su seccin crtica. esto es, espera hasta que pueda recibir los recursos necesarios
antes de que pueda ejecutarse.
Peticin incremental de recursos. El proceso pide los recursos uno a uno, pero si se niega
alguna peticin de recurso y tiene recursos asignados entonces los libera.
Para solicitar los recursos al comienzo, un trabajo o proceso debe de indicar al sistema operativo todas sus necesidades de recursos. Esto implica que se debe de saber con anticipacin
todos los recursos que va a ocupar el proceso y muchas veces, se sobreestima el nmero de
recursos que se usan dejando muchos de ellos inutilizados por largos perodos de tiempo. Por
ejemplo, esto puede pasar cuando se trabaja con una base de datos, en vez de solicitar un conjunto de registros sobre los que se va a trabajar, puede solicitarse la base de datos completa con
la subsecuente prdida de disponibilidad del recurso.
Cuando el sistema operativo asigna todos los recursos a un proceso, stos quedan fuera
del alcance de los dems procesos durante todo el tiempo de vida del proceso propietario, en
contraposicin con los realmente utilizados durante una parte de la ejecucin del proceso en
114
cuestin. El problema es que algunos recursos son utilizados una pequea parte del tiempo de
ejecucin del proceso, por lo tanto pueden permanecer inactivos o sin ser utilizados por otros
procesos durante perodos de tiempo relativamente largos. Pero para garantizar la prevencin
del interbloqueo no pueden ser asignados a otros procesos, aunque ya no los ocupe el proceso
propietario.
Cuando el proceso adquiere los recursos incrementalmente, segn se vayan necesitando, y
evitar interbloqueos mediante la liberacin de todos los recursos retenidos por un proceso si
solicita un recurso temporalmente inalcanzable. Esta estrategia evita las desventajas de solicitar
todos los recursos desde el comienzo del proceso. Sin embargo, las desventajas es que algunos
recursos no pueden ser liberados y readquiridos en tiempo posterior fcilmente. Por ejemplo
algunos cambios efectuados en memoria o sobre archivos pueden corromper el sistema si no
se llevan a cabo completamente. As la reanudacin de un recurso solo tiene sentido si no se
compromete la integridad del sistema y adems cuando el gasto debido a las operaciones de
guardar y restablecer el estado del proceso por la reanudacin es lo suficientemente pequeo.
Otro problema con este enfoque es que puede pasar un tiempo exageradamente largo debido
a que puede existir un recurso que sea ocupado continuamente y como el proceso, cada vez que
solicita todos los recursos, no lo encuentra disponible liberar nuevamente todos los ya adquiridos generndose entonces un problema de inanicin, esto es, el proceso nunca se ejecutar por
falta de uno o dos recursos.
No expropiacin La condicin de no expropiacin puede ser negada obviamente permitiendo
que el sistema operativo pueda apropiarse de la CPU y de los recursos a los procesos bloqueados.
Como el proceso no cede voluntariamente los recursos, el sistema operativo tiene que encargarse de guardar y restaurar su estado cuando el proceso vuelva a ponerse en ejecucin, esto hace
que la expropiacin de recursos se an ms difcil que la liberacin voluntaria y reanudacin de
recursos analizada anteriormente. La expropiacin se puede llevar a cabo sobre ciertos recursos
tales como la CPU y la memoria principal. Sin embargo, algunos recursos como los archivos
parcialmente escritos, no pueden ser expropiados sin riesgo de corromper el sistema. Sin embargo, como algunos recursos no pueden ser expropiados con garantas, este mtodo por s mismo
no puede proporcionar prevencin completa de los interbloqueos.
Espera circular Para evitar esta condicin un enfoque es ordenar linealmente los diferentes
tipos de recursos del sistema. Con este mtodo, los recursos del sistema se dividen en clases diferentes. Los interbloqueos se previenen exigiendo que todos los procesos soliciten y adquieran
sus recursos en orden estrictamente creciente de las clases de recursos de sistema especificados.
Adems, la adquisicin de todos los recursos pertenecientes a una clase deben efectuarse con
115
una sola peticin y no incrementalmente. Esto quiere decir que si ya solicit un recurso de una
clase colocada delante de un recurso de otra clase ya no podr solicitar ninguno anterior. La
ordenacin lineal elimina la posibilidad de espera circular, por que con este enfoque, ningn
proceso puede esperar un recurso que debi haber solicitado antes.
Una desventaja de este mtodo es que los recursos deben ser adquiridos en el orden prescrito,
en vez de ser solicitados cuando realmente se ocupen. Esto puede hacer que algunos recursos
sean adquiridos con bastante antelacin a su uso efectivo, bajando as el grado de concurrencia
de todo el sistema al impedir que otros procesos hagan uso de ese recurso cuando no se ocupa.
3.4.11.2. Evitar interbloqueos
El principio bsico para evitar interbloqueos es conceder nicamente las peticiones de recursos disponibles que no puedan dar lugar a un estado de interbloqueo. La estrategia se implementa
haciendo que el asignador de recursos examine los efectos de la concesin de una peticin particular. Se la concesin de un recurso no puede de ningn modo conducir a interbloqueo, se
concede el recurso al proceso solicitante. De otro modo, el proceso que lo solicita queda suspendido hasta el momento en que su peticin pendiente pueda ser concedida sin problemas. Esto
suele pasar despus de que han sido liberados los recursos ocupados por otros procesos.
Esta estrategia requiere que todos los procesos especifiquen los recursos que van a usar. Una
vez que el el proceso comienza su ejecucin, cada proceso solicita sus recursos como y cuando
los necesita, hasta el lmite mximo solicitado. El planificador de recursos lleva la cuenta del
nmero de recursos que lleva asignados cada proceso y del nmero de recursos disponibles de
cada tipo, adems de anotar el nmero de recursos restantes solicitados con anticipacin pero
an no requeridos por el proceso en ejecucin. Si un proceso solicita un recurso que no est
disponible tendr entonces que esperar. En cambio, si est disponible, el planificador de recursos
examina si la concesin de la peticin puede conducir a interbloqueo comprobando si cada uno
de los procesos ya activos puede terminar su ejecucin sin problemas, en ese caso se asigna el
recurso al proceso.
Estado seguro Un estado es seguro si el sistema puede asignar recursos a cada proceso (hasta
su mximo) en determinado orden sin que eso produzca un interbloqueo. Ms formalmente, un
sistema se encuentra en estado seguro slo si existe lo que se denomina secuencia segura. Una
secuencia de procesos < P1 , P2 , ..., Pn > es una secuencia segura para el estado de asignacin
actual si, para cada Pi , las solicitudes de recursos que PI pueda todava hacer se pueden satisfacer mediante los los recursos que se disponen actualmente, junto con los recursos retenidos por
todos los Pj , con j < i. Bajo esta situacin, si los recursos que Pi necesita no estn inmediata-
116
mente disponibles, entonces Pi puede esperar a que todos los Pj hayan terminado, cuando esto
suceda, Pi puede obtener los recursos faltantes para que pueda terminar su tarea asignada, y devolver entonces todos los recursos que solicit y terminar su ejecucin. Cuando Pi termina Pi+1
puede obtener los recursos que necesita y continuar de esta forma para los dems procesos. Si tal
secuencia no existe, entonces se dice que el estado actual del sistema es no seguro o inseguro y
por lo tanto existe un riesgo potencial de interbloqueo, y viceversa un estado seguro implica que
no puede producirse un interbloqueo. Hay que aclarar, que no obstante, un estado inseguro no
implica que habr interbloqueo, como se dice existe un riesgo potencial. Pero un estado seguro
no podr llevar nunca a un interbloqueo. Como ejemplo supongamos que se tiene un sistema de
arreglos de discos con 12 unidades en total y tenemos a su vez tres procesos P0 , P1 , P2 , el proceso P0 requiere para trabajar diez unidades, el proceso P1 puede necesitar como mucho cuatro
unidades, y el proceso P2 puede necesitar hasta nueve. Ahora suponemos que en el instante t0 el
proceso P0 tiene asignadas cinco unidades, el proceso P1 est usando dos unidades y el proceso
P2 tiene dos unidades. Esto significa que quedan tres unidades libres.
P0
P1
P2
Necesidades mximas Necesidades actuales

10
5
4
2
9
2
Cuando el sistema se encuentra en el instante t0 , el sistema est en estado seguro. La secuencia < P1 , P0 , P 2 > satisface la condicin de estado seguro. Al proceso P1 se le pueden asignar
inmediatamente todas sus unidades, despus de los cual el proceso terminar por devolverlas
teniendo entonces el sistema cinco unidades disponibles. En seguida, el proceso P0 puede tomar
las unidades que le restan para completar sus necesidades y devolverlas cuando las desocupe.
en este instante el sistema contar con diez unidades y por ltimo el proceso P2 puede obtener
todas sus unidades y devolverlas. Al final el sistema tendr las doce unidades disponibles. Obsrvese que un sistema puede pasar de un estado seguro a uno inseguro. Vamos a suponer ahora
que en el instante t1 el proceso P2 hace una solicitud y se le asigna una unidad ms. El estado
del sistema pasar a inseguro. En este momento, slo pueden asignarse todas sus unidades al
proceso P1 y cuando las devuelva, el sistema slo dispondr de cuatro unidades. Pero como el
proceso P1 tiene asignadas cinco, pero puede solicitar hasta diez, y en ese instante el sistema
no podr cubrir este requerimiento y tendr entonces que esperar. El proceso P2 tiene asignadas
en este punto tres unidades pero para completar su tarea necesita solicitar seis lo que tampoco
es posible dado que el sistema solo tiene cuatro disponibles de modo que tambin tendr que
esperar, dando lugar a un interbloqueo. El error que se cometi fue autorizar la solicitud de una
unidad al proceso P2 . Si se hubiera hecho esperar a P2 hasta que los dems procesos hubieran
117
terminado y liberado sus recursos no se hubiera generado el interbloqueo.

Grafos de asignacin de recursos En un sistema de asignacin de recursos que tenga slo
una instancia de cada tipo de recurso, se puede utilizar una variante del grafo para describir
los algoritmos usados para evitar el interbloqueo. Dado el grafo G = (N, A) que consta de un
conjunto finito no vaco de nodos (vrtices), N, y arcos, A. Si los arcos son pares ordenados de
nodos (x, y), se dice que el grafo es dirigido. Un camino en un grafo dirigido es una secuencia de
arcos de la forma (x1 , x2 ), (x2 , x3 ), ...(xn1 , xn ),. Un ciclo es un camino formado por al menos
dos nodos, en donde el primer nodo y el ltimo son iguales. Un grafo bipartito (bicoloreado) es
un grafo G cuyos nodos pueden ser particionados en dos subconjuntos disjuntos, P y R, tales
que cada arco de G conecta un nodo de P y un nodo de R, tales que cada arco de G conecta
un nodo de P y un nodo de R. A la representacin descrita se le denomina grafo general de
recursos. El grafo es dirigido y bipartito, formado por dos subconjuntos disjuntos de nodos
procesos y nodos recursos.
El grafo general de recursos de un estado posible del sistema descrito en relacin con el
algoritmo de la pgina 109 se muestra en la tabla 3.1. En la figura 3.4 vemos que los procesos
estn representados por un cuadrado y los recursos se representan por un crculo. Dentro de
el crculo se representa cada instancia del mismo con un crculo ms pequeo. Los nodos de
los procesos estn etiquetados como P1 y P2. Los nodos de los recursos se etiquetan con R1
y R2 respectivamente. Ahora supongamos que R1 representa una impresora, mientras que R2
representa a una unidad de disco. Los crculos pequeos dentro de los grandes indican entonces
que tenemos solamente una impresora y que tenemos dos unidades de disco.
Figura 3.4: Estado del sistema
La asignacin de recursos a un proceso se representa mediante un arco que va desde el nodo
118
recurso correspondiente hasta el nodo proceso asociado. De este modo en la figura 3.4 el proceso
P1 tiene la prioridad de la impresora. Una peticin de un recurso se representa mediante un arco
que va desde el nodo proceso solicitante hasta el nodo recurso solicitado. Por ejemplo en la
figura 3.4 se ha representado la peticin que hace el proceso P2 de la unidad de disco.
El planificador de recursos puede entonces determinar si es segura o no la concesin de un
recurso utilizando variantes de la representacin del grafo general de recursos. Una de estas
representaciones es mediante una matriz bidimensional en donde los procesos son las filas y los
tipos de recursos las columnas. Siguiendo esta lnea, los elementos de la matriz corresponden
con los arcos individuales. Llamemos ahora a esta matriz asignados, y supngase que cada
elemento aij indica el nmero de unidades de tipo j retenidas por el proceso i. En la tabla 3.1a
podemos ver ver un ejemplo de recursos asignados. En este caso, el proceso P1 tiene asignado
el recurso R1, para el sistema representado en la figura 3.4.
el nmero de recursos de cada tipo disponibles para asignacin en un momento determinado
puede representarse por un vector fila de enteros disponibles, que se observan en la tabla 3.1b.
Las relaciones de recursos de recursos no utilizados pueden representarse por medio de una
matriz reclamados, semejante a la matriz asignados. Los elementos de esta matriz se pueden
calcular mediante la diferencia entre el nmero mximo de recursos de un tipo determinado
solicitado con anticipacin por el proceso correspondiente y el nmero de recursos del mismo
tipo actualmente en propiedad de ese proceso. En la tabla 3.1b tenemos un ejemplo de la matriz
asignados antes de que sea concedida la peticin de una unidad de disco solicitada por el proceso
P2.
La parte ms importante para evitar interbloqueos es la prueba de seguridad. Podemos decir
que un estado es seguro si todos los procesos que ya tienen concedidos sus recursos tienen la
oportunidad de terminar su ejecucin en algn orden determinado incluso si cada uno de estos
procesos utilizase todos los recursos a los que tiene derecho. De acuerdo a lo anterior, una prueba
de seguridad prctica debe determinar si existe tal ordenacin.
Ahora ya podemos definir una operacin menor que o igual sobre los vectores, C y A,
de idntico tamao r como C A si y solo si C[i] A[i] para todo i = 1, 2, ..., r. Con estas
definiciones podemos ahora definir la operacin del planificador de recursos cuando recibe una
peticin de un proceso.
Peticin de recurso.
1. Para cada peticin de recurso, verificar que el proceso que la realiza est autorizado a
realizar la peticin, esto es, ha solicitado con anterioridad este recurso. No se deben de
autorizar peticiones que no hayan sido expresadas con anterioridad.

R1 R2
P1 1
0
P2 0
0
Asignados
R1 R2
P1 1
0
P2 0
1
Asignados
119
R1 R2
R1 R2
P1 0
2
0
2
P2 1
1
Reclamados
Disponibles
a) Antes de la asignacin
R1 R2
R1 R2
P1 0
2
0
1
P2 1
0
Reclamados
Disponibles
b) Despus de la asignacin
Tabla 3.1: Representacin de estados
2. Si un proceso solicita un recurso que no est disponible, entonces ste ser suspendido
hasta que pueda ser asignado cuando haya liberado y pueda ser asignado con seguridad.
3. Si un proceso solicita un recurso libre, se asume que el recurso se le concede actualizando
las estructuras de datos de asignados, reclamados y disponibles . Enseguida desmarcar
todos los procesos.
4. Encontrar un proceso desmarcado tal que: reclamadosi disponibles Si se encuentra,
marcar el proceso i,actualizar los vectores disponibles, disponibles := disponibles +
asignadosi y repetir este paso. Si no hay procesos que cumplan esta condicin, pasar al
paso que sigue.
5. Si todos los procesos ya estn marcados, el estado del sistema es seguro; por lo tanto, se
concede el recurso solicitado, se restaura el vector disponibles a su valor establecido en el
paso 2 y salir al sistema operativo. En caso contrario, el estado del sistema no es seguro
y por lo tanto se debe suspender el proceso solicitante, restaurar Xasignados, reclamados y disponibles a sus valores anteriores a la ejecucin del paso 2 y regresar al sistema
operativo.
Liberacin del recurso.
Cuando se libera un recurso, se debe actualizar la estructura de datos de disponibles y
reconsiderar las peticiones pendientes, si las hay, del tipo de recurso que se liber.
120
Como se ha visto, el evitar los interbloqueos no requiere la adquisicin de todos los recursos
de una vez, ni tampoco necesita la expropiacin de recursos. Los recursos son solicitados como
y cuando se necesitan. Esto elimina el problema de la inactividad de los recursos debido a
un adquisicin prematura, que aparece con frecuencia en otras estrategias de prevencin de
interbloqueos. Una de sus desventajas, de evitar los interbloqueos requiere que los procesos
soliciten previamente sus recursos e impone recargos de almacenamiento y tiempo de cmputo
para detectar los estados inseguros del sistema.
La estrategia de evitar interbloqueos tiende a ser conservadora y por lo tanto, reduce la
concurrencia en los sistemas donde se utiliza y puede posponer innecesariamente la asignacin
de recursos disponibles a procesos que los solicitan.
3.4.11.3. Deteccin y recuperacin de interbloqueos
Varios sistemas operativos, en vez de sacrificar el rendimiento previniendo o evitando los interbloqueos, conceden libremente los recursos disponibles a los procesos solicitantes y comprueban ocasionalmente el sistema para determinar si existen interbloqueos con el fin de reclamar
los recursos retenidos por los procesos involucrados, si es que existen.
Se ha demostrado que la existencia de un ciclo (o un circuito) en un grafo general de recursos es una condicin necesaria para la existencia de interbloqueo. La existencia de un ciclo
del cual ninguno de los nodos que lo forman sale un camino que no sea ciclo, es condicin
suficiente para la existencia de interbloqueos en un grafo general de recursos. De este modo la
existencia de interbloqueos puede determinarse mediante el uso de algoritmos muy conocidos
para la determinacin de ciclos en grafos. El mtodo ms comn es intentar reducir el grafo
general de recursos suprimiendo todas las retenciones y peticiones de cada proceso cuyas solicitudes puedan ser concedidas, hasta que se efecten todas las reducciones posibles. Si el grafo
queda completamente reducido (no quedan arcos) despus de esta operacin, el estado del sistema no presenta interbloqueos. En otro caso, existirn procesos o (nodos con arcos) que son los
involucrados en el interbloqueo.
Cuando un algoritmo de deteccin determina que existe un interbloqueo, se tienen varias
alternativas. Una de ellas es informar al operador que se ha producido un interbloqueo y dejar
que lo trate manualmente. Otra posibilidad es dejar que sea el sistema el que haga la recuperacin
del interbloqueo de forma automtica. Existen dos opciones para romper un interbloqueo. Una
de ellas consiste en interrumpir uno o ms de los procesos bloqueados.
Terminacin de procesos Para eliminar un interbloqueo interrumpiendo uno o ms procesos
, se puede utilizar cualquiera de los dos siguientes mtodos:
121
Interrumpir todos los procesos bloqueados. Este mtodo interrumpir todos los procesos involucrados en el interbloqueo, pero el costo ser muy alto. Es posible que varios procesos
hayan invertido ya mucho tiempo de ejecucin y hecho clculos que deben reiniciarse
despus de que se ponga en marcha nuevamente el proceso.
Interrumpir un proceso por vez. Este mtodo requiere una gran cantidad de trabajo extra, por
que despus de haber interrumpido un proceso, es necesario llamar al algoritmo de deteccin de interbloqueos.
Este mtodo, en general no toma en cuenta los potenciales daos que pueden ocasionarse al
sistema de archivos por una actualizacin incorrecta o a la prdida de consistencia en los datos
por una actualizacin no llevada a trmino adecuadamente. Decidir qu proceso debe eliminarse
no es una cuestin sencilla. Es comn establecer una mtrica desde un punto de vista de coste
mnimo, no obstante ser algo difcil de precisar. Dentro de los factores que se consideran pueden
ser:
1. La prioridad del proceso.
2. Tiempo que lleva en ejecucin el proceso.
3. Qu tipo de recursos ha usado y durante cunto tiempo.
4. Cuntos recursos adicionales requiere para terminar.
5. Cuntos procesos tendrn que eliminarse para que pueda continuar.
6. En interactivos o procesamiento por lotes.
Apropiacin de recursos Con este mtodo el sistema operativo va quitando recursos a los
procesos y asignndolos a otros hasta que se interrumpa el interbloqueo. Para llevar a cabo esta
estrategia es necesario tomar en cuenta lo siguiente.
1. Seleccin de un proceso a eliminar. El sistema debe seleccionar un proceso con un recurso determinado que ayude a eliminar el interbloqueo.
2. Anulacin. Qu debe hacerse con el proceso al que se le expropi el recurso? Este proceso debe suspenderse y colocarlo en un estado tal que pueda reanudar sus operaciones
cuando las condiciones lo permitan.
3. Inanicin. El sistema debe asegurarse de que al proceso al que se le expropiaron los
recursos, pueda continuar su ejecucin en un tiempo finito a partir del momento de la
expropiacin.
122
3.5. NIVELES, OBJETIVOS Y CRITERIOS DE PLANIFICACIN
3.5. Niveles, objetivos y criterios de planificacin
N este captulo se analizarn las diversas formas de administrar el tiempo de la CPU. Cuando
tenemos una sola CPU, entonces se puede atacar el problema de la ejecucin de muchos
procesos organizndolos serialmente, ya sea por como van llegando, por tiempo aproximado
de ejecucin o para que se ejecuten solamente un determinado tiempo en la CPU Todos estos
algoritmos son la base para el desarrollo de los sistemas operativos multiprogramacin.
3.5.1. Planeacin de trabajos

La administracin del CPU es una de las tareas ms importantes en los sistemas operativos
con multiprogramacin. Mediante la conmutacin de la CPU entre distintos procesos, el sistema
operativo puede hacer que la computadora sea ms productiva y darle al usuario la sensacin
de que tiene un equipo de cmputo dedicado. En este captulo se analizarn las tcnicas de administracin del procesador ms comunes usadas en los sistemas operativos actuales. Ya hemos
hablado en el captulo 3 de cmo es que se administran los procesos y los hilos. En este captulo
se hablar de los diferentes algoritmos utilizados para poder distribuir el tiempo de la CPU entre
los diferentes procesos y los hilos.
3.5.2. Conceptos bsicos de planificacin

En una computadora de un solo procesador solamente puede ejecutarse un proceso cada
vez, cualquier otro proceso tendr que esperar hasta que la CPU se desocupe para que pueda
tomar el control otro proceso y si el que se estaba ejecutando necesita ejecutarse nuevamente
debe entonces ser replanificado. El objetivo de un sistema multitarea o multiprogramacin es
tener continuamente varios procesos en ejecucin con el fin de maximizar el uso de la CPU. El
concepto bsico es muy sencillo: un proceso se ejecuta hasta que tenga que esperar, normalmente
porque es necesario completar alguna solicitud de entrada/salida. En una computadora de un
solo procesador, la CPU permanece inactiva la mayor parte del tiempo y todo ese tiempo de
espera se desperdicia y no se realiza ningn trabajo til. Con la multitarea o multiprogramacin
se intenta usar ese tiempo de forma productiva. En este caso se mantienen varios procesos en
memoria a la vez. Cuando un proceso tiene que esperar, el sistema operativo retira el uso de la
CPU a ese proceso y se lo cede a otro proceso. Este ciclo se repite continuamente y cada vez
que un proceso tiene que esperar, otro proceso puede hacer uso de la CPU. Este es el trabajo
fundamental del sistema operativo; casi todos los recursos de la computadora se planifican antes
de usarlos. Por supuesto, la CPU es uno de los principales recursos de la computadora, as que
su correcta planificacin resulta crucial en el diseo del sistema operativo.
123
3.5.2.1. Ciclos de CPU y ciclos de entrada/salida

Una planificacin adecuada de la CPU depende de una propiedad observada de los procesos:
la ejecucin de un proceso consta de un ciclo de ejecucin en la CPU, seguido de una espera de
entrada/salida; los procesos alternan entre estos dos estados. La ejecucin del proceso comienza
con una rfaga de CPU. Esta va seguida de una rfaga de entrada/salida, a la cual sigue otra
rfaga de CPU, luego otra rfaga de entrada/salida. la rfaga final de la CPU concluye con una
solicitud al sistema para terminar la ejecucin.
La duracin de las rfagas de CPU se ha medido exhaustivamente en la prctica. Aunque
varan enormemente de un proceso a otro y de una computadora a otra, tienden a presentar
una curva de frecuencia que es de tipo exponencial o hiperexponencial, con un gran nmero de
rfagas de CPU cortas y un nmero menor de rfagas de CPU largas. Normalmente, un programa
limitado por la entrada/salida presenta muchas rfagas de CPU cortas. Esta distribucin puede
ser importante en la seleccin de un algoritmo apropiado para la planificacin de la CPU.
3.5.3. Niveles de planificacin

Cuando la CPU queda inactiva, el sistema operativo debe seleccionar uno de los procesos
que se encuentran en la cola de procesos preparados para ejecucin. En general existen tres
diferentes tipos de planificadores mediante los cuales puede escogerse al siguiente proceso a
ejecutarse. Estos diferentes tipos de planificadores pueden coexistir en un sistema operativo
complejo. stos son: planificadores a largo plazo, a mediano plazo y a corto plazo. Estos a su
vez se pueden caer dentro de dos tipos de planificacin planificacin apropiativa y planificacin
no apropiativa
3.5.3.1. Planificacin apropiativa

El sistema operativo debe de decidir qu proceso es el que entrar a la CPU en cualquiera de
los siguientes casos:
1. Cuando un proceso cambia del estado de ejecucin al estado de espera.
2. Cuando un proceso cambia del estado de ejecucin al estado preparado.
3. Cuando un proceso cambia del estado de espera al estado preparado.
4. Cuando finaliza un proceso.
124
3.5. NIVELES, OBJETIVOS Y CRITERIOS DE PLANIFICACIN
En las opciones 1 y 4 slo hay una opcin en trminos de planificacin que es la de seleccionar un nuevo proceso para su ejecucin. En las opciones 2 y 3 existe la opcin de planificar
un nuevo proceso o no.
Cuando las decisiones de planificacin tienen lugar en las circunstancias 1 y 4, se dice que
el esquema de planificacin es no apropiativo. Esto es, el sistema operativo no podr obtener la
CPU a menos que el proceso la entregue voluntariamente. En el esquema apropiativo el sistema
operativo obtendr el control de la CPU en el momento que considere necesario. En Microsoft
windows 3.x se usaba un esquema no apropiativo, mientras que en windows 95 se cambi por
un esquema apropiativo y actualmente la mayora de los sistemas operativos comerciales usan
un esquema apropiativo.
3.5.4. Objetivos y criterios de planificacin

Se ha propuesto una gran diversidad de criterios para comparar los algoritmos de planificacin y aquellos que se utilicen pueden afectar enormemente las bondades o fortalezas de los
algoritmos que se comparen. Dentro de los muchos criterios utilizados a continuacin se proporciona una lista de los ms comunes:
Tiempo de respuesta. En sistemas multiusuario de de tiempo real es importante que el
sistema operativo sea capaz de responder lo suficientemente rpido como para no notar
que se estn compartiendo los recursos.
Utilizacin de CPU. La CPU debe de estar ocupada el mayor tiempo posible haciendo
tareas tiles. Es comn medir su ocupacin en trminos de porcentajes. esto es, en un
sistema real la utilizacin de la CPU debe variar entre un 40 por ciento para un sistema
desahogado y un 90 por ciento para un sistema cargado. Ir abajo de este lmite indica
que la CPU est siendo desaprovechada y arriba del 90 por ciento indica que no se est
excediendo la capacidad de respuesta del sistema.
Tiempo de ejecucin. Desde el punto de vista de un proceso individual, el criterio importante es cuanto tarda en ejecutarse un proceso. El intervalo que va desde el instante en
que se ordena la ejecucin de un proceso hasta el instante en que se completa el tiempo de
ejecucin. Ese tiempo de ejecucin es la suma de los perodos que el proceso invierte en
esperar para cargarse en memoria, esperar en la cola de procesos preparados, ejecutarse
en la CPU y realizar sus operaciones de entrada/salida.
Tasa de procesamiento. Es el nmero de procesos que se completan por unidad de tiempo. Para procesos que tardan mucho puede ir en intervalos de horas o procesos por hora.
125
En procesos que se ejecutan rpido esta tasa puede hasta de diez o ms procesos por segundo.
Tiempo de espera. Es el tiempo transcurrido entre el envo de una solicitud al sistema
operativo para ejecutar un programa y hasta que ste entregue los primeros resultados. Es
comn que este tiempo de respuesta est afectado principalmente por las operaciones de
entrada/salida que por la velocidad de la CPU.
3.6. Tcnicas de administracin del planificador

Los diferentes algoritmos de planificacin de la CPU tienen distintas propiedades, y la eleccin de un algoritmo es particular puede favorecer a una clase de procesos sobre otros. Al momento de decidir qu algoritmo se debe de utilizar en una situacin particular, se debe considerar
las propiedades de diferentes algoritmos.
De acuerdo a lo visto hasta ahora el objetivo principal es la maximizacin del uso de tiempo
de la CPU y por lo tanto, elevar la tasa de procesamiento, minimizando el tiempo de espera y el
tiempo de respuesta.
3.6.1. Tipos de planeacin

La planificacin hace referencia a un conjunto de polticas y mecanismos incorporados al
sistema operativo que gobierna el orden en que se ejecutan los trabajos que deben ser ejecutados
por la computadora.
Como se coment en la seccin 3.5.3 existen tres tipos de planificadores: planificadores a
corto, mediano y largo plazo. Ahora nos dedicaremos a analizar estas formas de planificacin.
3.6.1.1. Planificador a largo plazo
Cuando se implementa este tipo de planificador, y el sistema operativo usa procesamiento
por lotes, trabaja con la cola de lotes y selecciona el siguiente trabajo por lotes a ejecutar. Los
trabajos por lotes estn generalmente reservados a programas de baja prioridad y de uso intensivo
de recursos y que comnmente son utilizados como relleno para tener ocupada a la CPU. Los
trabajos por lotes tienen adems un conjunto de recursos necesarios para llevar a cabo su tarea
previamente especificados por el programador, lo que facilita la tarea de planificacin del mismo.
El principal objetivo del planificador a largo plazo es proporcionar una mezcla equilibrada
de trabajos, de modo que puedan satisfacerse sus requerimientos de procesador y de tiempo de
entrada/salida de modo que pueda proporcionar esta planificacin al planificador de corto plazo.
126
3.6. TCNICAS DE ADMINISTRACIN DEL PLANIFICADOR
El planificador de largo plazo acta como una vlvula de admisin de primer nivel para mantener la utilizacin de recursos al nivel deseado. Por ejemplo, cuando la utilizacin del procesador
es baja, el planificador puede admitir ms trabajos para incrementar el nmero de procesos que
se hallen en la cola de preparados, y con ello la probabilidad de disponer de alguna operacin
til que espere asignacin de procesador. En caso contrario, si se observa que el procesador est
en un porcentaje alto de utilizacin entonces el planificador puede decidir bajar el nmero de
procesos seleccionados para ejecucin, de modo que el procesador pueda responder mejor a todos los trabajos que se estn ejecutando. El planificador a largo plazo es generalmente mandado
a traer cuando un proceso finaliza su ejecucin.
3.6.1.2. Planificador a mediano plazo
Cuando un proceso se ha ejecutado durante algn tiempo, puede resultar que debe suspenderse debido a una solicitud de entrada/salida o al emitir una llamada al sistema. Dado que los
procesos suspendidos no pueden progresar hacia su terminacin hasta que se elimine la condicin de suspensin, en ocasiones es conveniente retirarlos de memoria principal de modo que
el sistema pueda acomodar otros procesos que estn listos para ejecutarse. Cuando una serie de
estos procesos resultan estar en el estado de suspendidos y todos ellos permanecen en memoria
llegar el momento en que el sistema operativo no tendr opcin para elegir un proceso para
ejecucin sabiendo, obviamente que estn suspendidos esperando una seal de terminacin de
operacin de entrada/salida, lo que ocasionara una degradacin significativa del tiempo de respuesta del sistema frente a otros procesos que s pueden ejecutarse. cuando un proceso se lleva
desde memoria principal hasta la memoria secundaria, se dice que el sistema tiene soporte de
memoria virtual. A esta operacin se le denomina intercambio y al proceso que se elimin de
memoria se le denomina retirado. El planificador a medio plazo tiene la misin de manejar los
procesos retirados, y tiene poco que hacer mientras un proceso permanezca suspendido. Cuando
desaparece la condicin de suspensin, el planificador a medio plazo intenta asignarle la cantidad necesaria de memoria principal, de modo que pueda incorporarse a la memoria principal y
dejarlo en el estado de preparado. La informacin que necesita para trabajar este planificador es
la cantidad de memoria que usa el proceso al regresar a la memoria y la cantidad de memoria
que ocupan los procesos suspendidos, lo que en la prctica no es difcil de implementar.
3.6.1.3. Planificador a corto plazo
El planificador a corto plazo asigna el procesador entre el conjunto de procesos preparados
residentes en memoria. Su objetivo principal es maximizar el rendimiento del sistema de acuerdo
con el conjunto de criterios elegidos.
127
Al estar a cargo de las transiciones de estado de preparados a ejecucin, el planificador a

corto plazo debe ser invocado en cada conmutacin de proceso para seleccionar el siguiente
proceso a ser ejecutado por la CPU. En un sistema operativo real, el planificador a corto plazo
es invocado tambin cuando sucede un evento externo, interno o cuando ocurre una seal o
una interrupcin. Esto es debido a que cualquiera de los eventos mencionados anteriormente
puede causar que un proceso sea suspendido o haya pasado al estado de preparado, de modo que
el planificador a corto plazo tendra que ser ejecutado para determinar si realmente ocurrieron
tales cambios y de esta forma, verificar si es necesario seleccionar un nuevo proceso para su
ejecucin. Algunos sucesos que tienen la capacidad de modificar el estado global del sistema
son:
Tics de reloj (Interrupciones basadas en el tiempo).
Interrupciones y terminaciones de operaciones de entrada/salida.
La mayora de las llamadas al sistema operativo.
El envo y recepcin de seales.
La activacin de programas interactivos.
En general cada vez que sucede uno de estos eventos el sistema operativo invoca al planificador a corto plazo para determinar si debera planificarse otro proceso para su ejecucin. La
mayora de las tareas de administracin de procesos analizados en la seccin 3.1 requieren que
se mande a llamar al planificador a corto plazo como parte de su procesamiento.
Los programas interactivos suelen entrar a la cola de preparados directamente despus de
ser remitidos al sistema operativo, lo que ocasiona la creacin del proceso correspondiente. A
diferencia de los trabajos por lotes, el flujo de programas interactivos no est limitado, y puede
supuestamente saturar el sistema.
La figura 3.5 ilustra objetivamente los papeles y la interaccin entre los diferentes tipos de
planificadores en un sistema operativo. Muestra el caso ms general en donde estn presentes
los tres tipos. Es claro que de todos los planificadores pueden convivir en un sistema operativo
grande y que puede dar soporte a una gran empresa, pero en un sistema operativo pequeo
y posiblemente de uso personal puede que solamente tenga un planificador a corto plazo. El
planificador a mediano plazo lo podemos encontrar en sistemas operativos que tienen soporte
de memoria virtual para poder hacer el intercambio de procesos a disco. En la actualidad la
mayora de los sistemas operativos comerciales usan algn tipo de memoria virtual, por ejemplo,
los sistemas operativos basados en UNIX/Linux usan un rea de intercambio que est definida
desde el momento de la instalacin del sistema operativo. Es un rea llamada swap y los usuarios
128
Figura 3.5: Ubicacin de los planificadores
no tienen derecho a escribir en ella. Los basados en windows XX, XP o vista normalmente
toman parte de la capacidad del disco no usada por el usuario como rea de intercambio, por
lo que se debe tener cuidado de dejar siempre varios megabytes (por lo comn el doble de
memoria principal) para que el sistema operativo pueda funcionar sin problemas. No obstante
el usuario puede guardar informacin en todo el disco duro, de esa forma la memoria virtual
va disminuyendo hasta que sea incapaz de trabajar normalmente, siendo un error oscuro por
resolver, debido a que el usuario determinar que es el sistema operativo el que est funcionando
mal, no obstante, como se coment, el problema se soluciona dejando libres varios megabytes
para que el sistema operativo lo use como memoria virtual.
3.6.1.4. First In First Out (FIFO)
La disciplina de planificacin ms sencilla es la FIFO o la FCFS (First-Come, First-Served)
o primero en llegar, primero en ser atendido. La carga de trabajo se procesa simplemente en
orden de llegada, sin expropiaciones. La implementacin del planificador FIFO es bastante directa, y su ejecucin da lugar a pocos recargos.
Por no tener en consideracin el estado del sistema ni las necesidades de recursos de las
entidades de planificacin individuales, la planificacin FIFO puede dar lugar a rendimientos
pobres. Como consecuencia de la no expropiacin, la utilizacin de componentes y la tasa de
129
productividad del sistema puede ser bastante baja. Como no existe discriminacin en base al
servicio solicitado, los trabajos cortos pueden sufrir retrasos considerables en los tiempos de
retorno y de espera cuando hay uno o ms trabajos largos en el sistema. Por esta razn, el
tiempo medio de espera con el algoritmo FIFO es frecuentemente muy grande.Vamos a suponer
que el siguiente conjunto de procesos llega en el instante 0, estando la duracin de la rfaga de
la CPU especificada en milisegundos:
Proceso
P1
P2
P3
Tiempo de Rfaga
25
4
4
Figura 3.6: Tiempos totales de ejecucin de los procesos
en la figura 3.6 observamos que de acuerdo al orden de llegada de los procesos P1 , P2 y

P3 el planificador los ejecutar en ese orden dando como resultado que el proceso P1 espere 0
segundos, el proceso P2 , tiene que esperar 25 milisegundos, y el proceso P3 espera 29 milisegundos. El tiempo promedio es entonces (0 + 25 + 29)/3 = 18 milisegundos. Si el orden de
llegada fuera P2 , P3 y por ltimo P1 entonces el tiempo promedio de espera es para P2 de 0
milisegundos, para P3 ser de 4 milisegundos y para P1 es entonces de 8 milisegundos dando
entonces un promedio de espera total de (0 + 4 + 8)/3 = 4 milisegundos. como puede verse en
la figura 3.7.
Figura 3.7: Tiempos totales de ejecucin de los procesos
Como puede observarse, hay una drstica reduccin del tiempo medio de espera, pero no
es generalmente el mnimo y puede variar significativamente si la duracin de las rfagas de
130
CPU de los procesos es muy variable. Depende mucho de la duracin de los procesos y puede
llegarse el momento en que haya tantos procesos de corta duracin esperando a que termine
uno de larga duracin, lo que ocasiona una utilizacin menor de la CPU y de los dispositivos
de entrada/salida que la que se conseguira si se permitiera a los procesos ms cortos ejecutarse
primero.
3.6.1.5. Round Robin (RR)
En entornos interactivos, tal como en sistemas de tiempo compartido, el requisito principal
es compartir los recursos del sistema equitativamente entre todos los usuarios. Como puede
verse, slo las estrategias expropiativas pueden ser consideradas en tales entornos, y una de las
ms populares es la reparto de tiempo. Bajo esta estrategia, el tiempo del procesador se divide
en cuantos de tiempo. Un grupo de cuantos de tiempo forma la cuota que se le concede a cada
proceso. Ningn proceso puede ejecutarse durante ms de una cuota de tiempo si es que hay ms
procesos en el sistema. Si un proceso necesita ms tiempo para completarse despus de agotar su
cuota de tiempo, se coloca al final de la lista de preparados para esperar una asignacin posterior.
Esta reordenacin de la lista de preparados tiene el efecto de rebajar la prioridad de planificacin
del proceso expropiado. En la figura 3.8 podemos ver cmo el proceso Px va al final de la cola
cuando ha terminado su cuota de tiempo.
Figura 3.8: Funcionamiento del algoritmo Round Robin
En el caso de que el proceso en ejecucin ceda el control al sistema operativo antes de acabar
su tiempo asignado, se declara un suceso significativo y se planifica la ejecucin de otro proceso.
De esta manera, el tiempo del procesador es asignado efectivamente a procesos en ase a una
131
prioridad rotatoria y cada uno de ellos recibe aproximadamente 1/N de tiempo del procesador
en donde N es el nmero de procesos preparados.
La planificacin por reparto del tiempo logra una comparticin equitativa de los recursos
del sistema. Los procesos cortos pueden ser ejecutados dentro de una nica cuota de tiempo
y por tanto exhiben buenos tiempos de respuesta. Los procesos largos pueden requerir varias
cuotas y por tanto, ser forzados a circular a travs de la cola de preparados unas cuantas veces
antes de terminar. con la planificacin RR, el tiempo de respuesta de los procesos largos que
constan de una serie de secuencias interactivas con el usuario, lo que importa principalmente es
el tiempo de respuesta entre dos interacciones consecutivas. Si las necesidades computacionales
entre dos de tales secuencias pueden completarse dentro de una sola cuota de tiempo, el usuario
debera experimentar un buen tiempo de respuesta. RR tiende a someter a los procesos largos sin
secuencias interactivas a tiempos de espera y de retorno relativamente largos. Sin embargo, tales
procesos pueden ser mejor ejecutados en modo lote, y podra ser incluso deseable desaconsejar
a los usuarios que los remitan al planificador interactivo.
La implementacin de la planificacin por reparto de tiempo requiere el soporte de un temporizador de intervalos -preferiblemente uno dedicado, en lugar de compartir la base de tiempos
del sistema-. El temporizador se programa generalmene para que interrumpa al sistema operativo cada vez que expire una cuota de tiempo forzando as la invocacin del planificador. El propio
planificador almacena simplemente el contexto del proceso en ejecucin, lo translada al final de
cola de preparados y despacha el proceso que se encuentre a la cabeza de la cola de preparados
El planificador tambin es invocado para despachar un nuevo proceso cada vez que el proceso
en ejecucin cede el control al sistema operativo antes de que expire su cuota de tiempo, por
ejemplo, cuando el procesos se suspende debido a una solicitud de entrada/salida. El temporizador de intervalos es generalmente reinicializado en ese momento, con el fin de proporcionar un
intervalos de tiempo completo al nuevo proceso en ejecucin. La frecuente inicializacin y reinicializacin de un temporizador de intervalos dedicado hace deseable la existencia de soporte de
hardware en sistemas que utilizan cuotas de tiempo.
El rendimiento de la planificacin por reparto del tiempo es muy sensible a la eleccin de
la cuota del tiempo. Por esta razn, la duracin de la cuota de tiempo suele ser modificable por
el usuario durante la compilacin o instalacin del sistema operativo, aunque en los sistemas
operativos actuales esta tarea se deja solamente a usuarios administradores avanzados.
La relacin entre la cuota de tiempo y el rendimiento es pronunciadamente no lineal. La reduccin de la cuota no debera ser llevada demasiado lejos tratando de alcanzar mejores tiempos
de respuesta. Una cuota demasiado corta puede dar lugar a significativos recargos debido a las
frecuentes interrupciones del temporizador y consiguientes cambios de contexto de los procesos
involucrados. Por ejemplo, una cuota de dos milisegundos en un sistema donde una conmuta-
132
cin de proceso tarda quinientos microsegundos supone un recargo del veinticinco por ciento.
Por otra parte, una cuota de tiempo demasiado larga reduce el recargo por expropiacin pero
aumenta el tiempo de respuesta. Por ejemplo, una cuota de 100 milisegundos en un sistema con
50 usuarios activos implica un molesto tiempo de respuesta de 5 segundos. En el extremo, una
cuota muy larga transforma un planificador RR en un planificador FIFO.
En resumen, la planificacin por reparto del tiempo se utiliza principalmente en sistemas
multiusuario de tiempo compartido en donde es importante el tiempo de respuesta de terminal.
La planificacin por reparto de tiempo penaliza generalmente a los trabajos largos no interactivos y depende de la eleccin juiciosa de la cuota de tiempo para obtener un rendimiento
adecuado. La duracin de una cuota de tiempo es un parmetro ajustable del sistema que puede
ser modificado durante la compilacin o instalacin del sistema operativo.
3.6.1.6. Shortest Job First (SJF)
Otro mtodo de planificacin de la CPU es el algoritmo de planificacin con seleccin del
trabajo ms corto. Este algoritmo asocia con cada proceso la duracin de la siguiente rfaga de
CPU del proceso. Cuando la CPU est disponible, se asigna al proceso que tiene la siguiente
rfaga de CPU ms corta. Si las siguientes rfagas de CPU de dos procesos son iguales, se usa
la planificacin FIFO para romper el empate. Considrese el siguiente conjunto de procesos,
estando especificada la duracin de la rfaga de CPU en milisegundos.
Proceso
P1
P2
P3
P4
Tiempo de Rfaga
11
8
9
7
Usando SJF, los procesos quedaran como se muestra en la figura 3.9. Para el proceso P4 el
tiempo de espera es de 0 milisegundos. El tiempo de espera es de 7 milisegundos para el proceso
P3 , para el proceso P2 es de 15 milisegundos y para el proceso P1 es de 24 milisegundos. Por lo
tanto, el tiempo medio de espera es de (0 + 7 + 15 + 24)/4 = 15,3 milisegundos. Si se usara el
esquema de planificacin FIFO el tiempo promedio de espera sera (0 + 11 + 19 + 28)/4 = 19,3
milisegundos.
El algoritmo de planificacin es probablemente ptimo, en el sentido de que proporciona
el tiempo medio de espera mnimo para un conjunto de procesos dado. Anteponer un proceso
corto a uno largo disminuye el tiempo de espera del proceso corto en mayor medida de lo
que incrementa el tiempo el tiempo de espera del proceso largo. Por lo tanto, el tiempo medio
133
Figura 3.9: Organizacin para ejecutar los cuatro procesos con SJF
de espera disminuye. El principal problema de la estrategia SJF es conocer la duracin de la

siguiente solicitud de CPU. En una planificacin a largo plazo de trabajos en un sistema de
procesamiento por lotes, podemos usar como duracin el lmite de tiempo del proceso que el
usuario especifique en el momento de enviar el trabajo. Con este mecanismo, los usuarios estn
motivados para estimar el lmite de tiempo del proceso en forma precisa, dado que el valor
menor puede significar una respuesta ms rpida.
Aunque el algoritmo SJF es ptimo , no puede implementarse en el nivel de la planificacin
de la CPU a corto plazo, ya que no hay manera de conocer la duracin de la siguiente rfaga de
la CPU directamente. No obstante, se puede predecir su valor por el mtodo de confiar en que
la siguiente rfaga de CPU ser similar en duracin a las anteriores. De este modo, calculando
una aproximacin de la duracin de la siguiente rfaga de CPU, se puede tomar el proceso que
tenga la rfaga de CPU predicha ms corta.
3.6.1.7. Shortest Remaining Time (SRT)

La estrategia de planificacin en seguida el de menor tiempo restante es aquella en la que
la siguiente entidad de planificacin, trabajo o proceso, se selecciona sobre la base del menor
tiempo de ejecucin restante. La planificacin SRT puede ser implementada ya sea en forma
expropiativa en su versin no expropiativa. La versin no expropiativa de SRT se denomina SJF
vista en la seccin anterior. En cualquier caso, cada vez que e invoca al planificador SRT, ste
busca en la correspondiente cola (de lotes o de preparados) el trabajo o proceso con el menor
tiempo de ejecucin restante. La diferencia entre los dos casos se encuentra en las condiciones
que conducen a la invocacin del planificador y, en consecuencia, en su frecuencia de ejecucin.
Sin expropiacin, el planificador SRT es invocado cada vez que se completa un trabajo o que el
proceso en ejecucin cede el control al sistema operativo. En la versin expropiativa, cada vez
que ocurre un suceso que hace que un nuevo proceso est preparado, se invoca al planificador
para que compare el tiempo de ejecucin restante del proceso actualmente en ejecucin con el
tiempo necesario para completar la siguiente rfaga de procesador del proceso recin llegado.
Dependiendo del resultado, el proceso en ejecucin puede continuar o puede ser expropiado
134
y substituido por el proceso con tiempo restante ms corto. Si es expropiado, el proceso en

ejecucin se une a la cola de preparados.
LA estrategia SRT es ptima en el sentido de que minimiza el tiempo medio de espera de
una carga de trabajo determinado. La estrategia SRT se efecta de una manera consistente y
predecible, favoreciendo los trabajos cortos. Aadiendo la expropiacin, puede acomodar trabajos cortos que lleguen despus de comenzar un trabajo largo. El tratamiento preferencial de
los trabajos cortos en SRT tiende a aumentar los tiempos de espera de los trabajos largos en
comparacin con FIFO, pero en general es un costo aceptable.
SRT planifica ptimamente suponiendo que los tiempos futuros de ejecucin de los trabajos
o procesos son conocidos con exactitud en el momento de la planificacin. En el caso de la
planificacin a corto plazo y de las expropiaciones, se requiere un conocimiento incluso ms
detallado de la duracin de cada rfaga de procesador individual. La dependencia sobre el
conocimiento futuro tiende a limitar en la prctica la efectividad de las implementaciones SRT,
ya que en general el comportamiento futuro del proceso es desconocido y difcil de estimar
fiablemente, excepto para algunos casos determinados muy especializados.
La planificacin SRT tiene importantes implicaciones tericas y puede servir como referencia para valorar el rendimiento de otras disciplinas de planificacin realizables en trminos de
su desviacin con respecto al ptimo. En la prctica su aplicacin depende de la precisin de
predecir el comportamiento del trabajo y del proceso, sabiendo que aumentar la precisin supone emplear mtodos ms sofisticados y por tanto, producir un sobrecargo mayor. La variedad
expropiativa de SRT incurre en el recargo adicional de las frecuentes conmutaciones de procesos
y de invocaciones al planificador para examinar todas y cada una de las transiciones de procesos
al estado de preparado. Estas acciones son intiles cuando el nuevo proceso preparado tiene un
tiempo de ejecucin restante mayor que el de los procesos en ejecucin actual.
3.6.1.8. Highest Response Ratio Next (HNR)

Brinch Hansen desarroll la estrategia de prioridad a la tasa de respuesta ms alta (HNR,
highest-response-ratio-next) que corrige algunas deficiencias de SJF, particularmente el retraso
excesivo de trabajos largos y el favoritismo excesivo para los trabajos cortos. HRN es un disciplina de planificacin no apropiativa en la cual la prioridad de cada proceso no slo se calcula
en funcin del tiempo de servicio, sino tambin del tiempo que ha esperado para ser atendido.
Cuando un trabajo obtiene el procesador, se ejecuta hasta terminar. Las prioridades dinmicas
en HNR se calculan de acuerdo con la siguiente expresin:
prioridad = (tiempo de espera + tiempo de servicio)/tiempo de servicio
Como el tiempo de servicio aparece en el denominador, los procesos cortos tendrn prefe-
135
rencia. Pero como el tiempo de espera aparece en el numerador, los procesos largos que han
esperado tambin tendrn un trato favorable. Obsrvese que la suma tiempo de espera mas el
tiempo de servicio es el tiempo de respuesta del sistema para el proceso si ste se inicia de
inmediato.
3.6.2. Multiprocesamiento
El objetivo principal de los desarrolladores de hardware de procesadores es el incremento
de velocidad de proceso. La velocidad de proceso puede incrementarse bsicamente de dos
maneras:
Incremento de la velocidad de reloj. Incrementando el nmero de ciclos del reloj del procesador, es posible tambin incrementar la velocidad de ejecucin de las microinstrucciones
y por ende tambin las instrucciones mquina. No obstante, el principal problema es que
a mayor velocidad de reloj se produce un calentamiento mayor de los circuitos y se incrementa tambin la posibilidad de interferencias. Deben de resolverse estos problemas antes
de pensar en un incremento de velocidad de reloj.
Agregar ms procesadores de baja velocidad al sistema. La otra posibilidad es la de agregar
ms procesadores a la placa base de modo que pueda ejecutarse el doble de instrucciones
en el mismo sistema. Los problemas que se presentan ahora son para el sistema operativo
que debe de administrar los procesos que se van a ejecutar en cada procesador.
3.6.3. Conceptos bsicos

Como se coment en 3.6.2, existen dos maneras de incrementar la velocidad. La primera
tiene lmites tecnolgicos obvios, en cuanto al incremento de la velocidad de reloj y el diseo
de los componentes de la placa base.
Al agregar un mayor nmero de procesadores es posible incrementar la velocidad de procesamiento con una relacin de costo/beneficio ms favorable.
3.6.3.1. multiprocesador
Se define como una computadora que contiene dos o ms unidades de procesamiento que trabajan sobre una memoria comn bajo un sistema operativo que proporciona control integrado.
Si el sistema de multiprocesamiento posee procesadores de las mismas caractersticas, hablamos entonces de multiprocesamiento simtrico; de otra forma se habla de multiprocesamiento
asimtrico.
136
Si un procesador falla, los restantes continan operando, lo cual no es automtico y requiere

de un diseo cuidadoso. Un procesador que falla habr de informarlo a los dems de alguna
manera, para que se hagan cargo de su trabajo . Los procesadores en funcionamiento deben
poder detectar el fallo de un procesador determinado. El Sistema Operativo debe percibir que
ha fallado un procesador y ya no podr asignarlo y tambin debe ajustar sus estrategias de
asignacin de recursos para evitar la sobrecarga del sistema que est degradado.
El multiprocesamiento puede proporcionar las siguientes ventajas:
Aumento de productividad. Pueden ejecutarse tantos procesos como procesadores tenga
el sistema en paralelo, incrementando de esta forma el tiempo de respuesta.
Disminuir el tiempo de ejecucin de un proceso. Mediante el uso de tcnicas de multiprogramacin es posible dividir un proceso en varias tareas independientes que pueden
ejecutarse en paralelo.
En entornos multiusuario, la productividad puede aumentarse ejecutando una serie de procesos de usuario no relacionados entre s sobre diferentes procesadores corriendo en paralelo. As
aunque no se incrementa la velocidad de ejecucin de un proceso, s es posible mejorar la productividad al terminar un mayor nmero de tareas por unidad de tiempo, no habiendo necesidad
de modificar las aplicaciones de usuario para adecuarlo a un sistema multiprocesamiento. La
ganancia de velocidad para una aplicacin en particular involucra modificar la aplicacin para
poder ejecutar en paralelo aquellas tareas que sean independientes entre s, siendo entonces responsabilidad de los programadores la comunicacin entre estas tareas, para llevar a buen trmino
la tarea global encomendada. Estas tareas pueden implementarse de las formas vista en las secciones 3 y en la seccin 3.3, esto es, pueden crearse varios procesos en donde cada uno resuelve
una parte del problema o pueden crearse tambin varios hilos para atacar ms eficientemente el
problema.
Hay fuertes investigaciones en cuanto a la automatizacin de estas tareas y el resultado
de estas investigaciones es en parte los llamados compiladores paralelizantes que ayudan a
encontrar aquellos conjuntos de instrucciones que no dependen de otras y que son susceptibles
de ejecutarse en paralelo.
Como puede verse, la otra forma es permitir al programador que indique cuales son aquellas
tareas que deben de ejecutarse en paralelo y cules son las que deben de ejecutarse en serie.
Las diferentes partes de una aplicacin paralelizada necesitan generalmente sincronizarse e
intercambiar datos despus de completar una etapa de clculo. La comunicacin y sincronizacin entre los procesadores reduce la ganancia de velocidad global al frenar clculos individuales
y consumir mucho de banda de interconexin del sistema. Uno de los principales retosen el di-
137
seo de sistemas multiprocesadores es la reduccin de las interacciones entre procesadores y

proporcionar un mecanismo eficiente para llevarlas a cabo cuando sean necesarias.
3.6.4. Paralelismo
El paralelismo consiste en ejecutar ms instrucciones en una misma unidad de tiempo, aunque las instrucciones sigan tardando lo mismo en ejecutarse. Estas instrucciones le dicen al
procesador cmo tiene que ir modificando diferentes posiciones de memoria, y le indican el flujo de ejecucin. Se tiende a pensar, que un procesador con un reloj a 400 MHz (400 millones de
ciclos por segundo) ejecuta 400 millones de estas operaciones por segundo. Por lo comn una
instruccin no se ejecuta en un ciclo de reloj, salvo algunas instrucciones sencillas como la instruccin INC sobre un registro interno. La mayora de las instrucciones tardan en promedio de
5 a 15 ciclos, llegando algunas a necesitar 50 o ms ciclos para completarse, como por ejemplo
aquellas instrucciones que llevan a cabo operaciones con nmeros reales de doble precisin o
aquellas instrucciones utilizadas en el manejo de vdeo, por ejemplo en juegos.
3.6.5. Paralelismo por hardware

Es aquella en la que la ejecucin de un programa se lleva a cabo tomando en consideracin
el hardware con que va a ser ejecutado.
Un procesador incluye dentro de su arquitectura una manera de ejecutar ms eficientemente
sus instrucciones. En general lo primero que debe de hacer es traer de memoria la instruccin
que va a ejecutar. A este proceso se le denomina fetch. Cuando ya ha trado la instruccin de
memoria, ahora s ya pasa a su ejecucin, pero mientras est ejecutando la instruccin, el mdulo
de fetching est obteniendo una nueva instruccin y depositndola en la cola de instrucciones. Si
el procesador efecta una instruccin de salto, entonces las instrucciones que se encuentran en
la cola deben ser borradas y el mdulo de fetching empezar nuevamente a traer las siguientes
instrucciones a ejecutar.
Como se puede apreciar, tenemos ya dentro de un procesador al menos dos mdulos que
trabajan en paralelo, el mdulo de fetching y la unidad de ejecucin. De esta manera, Se puede
dividir cualquier instruccin en fases ms o menos comunes a todas: fetch (traer la instruccin
desde la memoria al procesador), decodificacin (determinar la instruccin que se va a ejecutar),
carga de operandos, ejecucin de la operacin y modificacin de los registros o las localidades de
memoria afectadas, as como el registro de banderas en donde se guarda el estado del procesador.
Este esquema simplificado, proporciona una idea de las fases que todo microprocesador tiene.
Vamos a suponer un microprocesador ideal donde todas las operaciones que se pueden ejecutar
138
en l tardan 15 ciclos, correspondientes a tres ciclos por cada una de las 5 fases que hemos
descrito. Si ejecutramos tres de estas operaciones sin ningn tipo de paralelismo, tardaramos
45 ciclos, segn el siguiente esquema:
Instruccin
Ciclos de Ejecucin
Mov AX,Arreglo[20] 111222333444555
Add AX,Arreglo[21] 111222333444555
Mov AX,Arreglo[22] 111222333444555
Ahora dividamos el microprocesador en circuitos independientes de modo que cada uno
pueda ejecutar cada una de las cinco fases anteriores. As, cuando la instruccin uno ha acabado
ya la fase de fetch y pasa a la decodificacin, deja libre el mdulo que se encarga del fetch,
donde puede estar ejecutndose la segunda instruccin. As se ahorra tiempo y no se neceesita
esperar a que se termine de ejecutar una instruccin antes de traer otra a la unidad de ejecucin.
Resultado: las tres instrucciones, por separado, siguen ejecutndose en el mismo tiempo, pero
en conjunto ya no tardan 45 ciclos, sino solo 21 ciclos. Ms de un 45 % de incremento en el
rendimiento.
Instruccin
Mov AX,Arreglo[20]
Add AX,Arreglo[21]
Fetch
111
Decodificacin
222
Fetch
111
Mov AX,Arreglo[22]
Carga
333
Decodificacin
222
Fetch
111
Ejecucin
444
Carga
333
Decodificacin
222
Resultados
555
Ejecucin
444
Carga
333
Resultados
555
Ejecucin
444
Resultados
555
De esta forma es como algunos procesadores muy paralelizados logran ejecutar, en promedio, ms de una instruccin por ciclo de reloj, aunque estas instrucciones tarden, por s mismas,
ms de un ciclo en ejecutarse. En la realidad, no todo es sencillo y existen muchos problemas
al disear un procesador con paralelismo. Por citar algunos de los problemas ms comunes, hay
veces que una instruccin no se puede ejecutar ya que requiere un dato que quizs calculaba la
operacin anterior (cosa muy habitual). Claro, si ante este problema detuviramos la anterior
instruccin, bloqueara el procesador y se acabara el paralelismo hasta que acabara la primera
instruccin y con ella se pudiera reanudar la segunda. Para evitar estos problemas se recurre a
cortocircuitos, o lo que es lo mismo, se comunican diferentes fases del microprocesador internamente para pasarse antes los datos. Esto, sin embargo, tambin nos da otros problemas, ya
mucho ms complicados, como el encontrarnos con que hay que decidir que datos son los correctos en cada momento. Estos problemas se pueden resumir en que el procesador ha de decidir
como paralelizar las instrucciones.
3.6.5.1. Paralelismo por software
En el paralelismo por software ya no es el procesador el que decide cmo paralelizar las instrucciones, sino que es el compilador del software es el que decide qu conjunto de instrucciones
139
puedeejecutar el procesador paralelamente.

Se define paralelismo en software como la ejecucin de un programa sin tomar en cuenta
al hardware con que va ser ejecutado. El paralelismo en software es considerado como el caso
ideal de la ejecucin de las instrucciones que forman parte de un programa, ya que no toma en
cuenta las limitantes del hardware con que el mismo va ser ejecutado.
El paralelismo en Software representa el caso ideal con que dicho programa puede ser ejecutado. Por otro lado podemos observar las limitantes que genera la ejecucin de este mismo
programa con un hardware en particular (procesador Superescalar con capacidad de ejecutar
un acceso a la memoria y una operacin aritmtica simultneamente) obteniendo 6 ciclos de
maquina para ejecutar el programa. Tomando como base este ejemplo, la ejecucin paralela de
las instrucciones de un programa se mide mediante el parmetro conocido como Promedio de
Ejecucin Paralela de instrucciones (PEP). Este parmetro est definido como la relacin entre
el nmero de instrucciones del programa y el nmero de ciclos de mquina realizados en su
ejecucin. Su expresin matemtica es: PEP = No. de Instrucciones / No. de Ciclos de Mquina.
Por consiguiente, el promedio de ejecucin paralela de instrucciones en software para este
ejemplo es: 8/3 = 2,667 y el promedio de ejecucin paralela de instrucciones en hardware es:
8/6 = 1,333.
El desarrollo de hardware y software es un proceso integral que busca soluciones que permitan satisfacer cada vez ms las condiciones de paralelismo con el fin de incrementar el promedio
de ejecucin paralela de instrucciones. Para lograr este objetivo es necesario detectar y resolver
las dependencias entre instrucciones. El proceso de deteccin y resolucin de dependencias entre
instrucciones se conoce como el proceso de planificacin de instrucciones. Cuando la planificacin de instrucciones es llevada a cabo nicamente por el compilador se dice que la planificacin
de instrucciones es esttica. Y cuando la planificacin de instrucciones es llevada a cabo nicamente por hardware, se dice que la planificacin de instrucciones es dinmica. La planificacin
de instrucciones en los microprocesadores sper escalares es un proceso de planificacin de
instrucciones esttico y dinmico.
Las tcnicas estticas de planificacin de instrucciones estn compuestas por tres grupos:
Planificacin de instrucciones de bloques de un programa. Divide un programa en bloques
para luego detectar y resolver solamente las dependencias entre las instrucciones de cada
bloque. Esta tcnica es la ms utilizada en los ltimos veinte aos ya que es la ms simple
de implementar.
Planificacin de instrucciones de lazos iterativos continuos. Consiste planificar las instrucciones que forman parte de los lazos continuos de un programa. Esta tcnica est compuesta bsicamente por dos tcnicas: Unrolling y Software Pipeline.
140
planificacin de instrucciones global. Planifica todas las instrucciones que forman parte de un
programa.
3.6.6. Sistemas multiprocesamiento

Un sistema multiprocesador, es una computadora que tiene soporte para ms de un procesador.
Cuando se han colocado dos procesadores en la misma placa base, hablamos entonces de
procesamiento dual. Por ejemplo, el procesador Pentium MMX, Pentium II, Pentium III con
ncleo Katmai o Coppermine, Pentium III-S de Intel y el Athlon MP de AMD pueden funcionar
en modo dual. Para que puedan trabajar los dos procesadores se necesita tener una placa base y
un sistema operativo que permita explotar estas configuraciones por ejemplo tenemos a Windows
NT/2000/XP o Linux. Las aplicaciones tambin deben de estar diseadas de manera que puedan
aprovechar el aumento de velocidad. No pueden combinarse procesadores de formatos diferentes
en una misma placa base, deben utilizarse siempre dos variantes con el mismo formato.
Es comn que en multiprocesamiento se combinen los procesadores en potencias de dos.
Tenemos multiprocesamiento cuando se utilizan ms de dos procesadores juntos en un mismo sistema. El Pentium Pro, Pentium II/III Xeon, Xeon (basado en Pentium 4) y el Itanium de
Intel, as como el Opteron de AMD, estn especialmente diseados para el multiprocesamiento
y pueden trabajar en grupos de dos, cuatro, ocho y ms.
En la figura 3.10 puede verse cmo se organiza la placa madre para dar cabida a cuatro
procesadores.
Slo pueden emplearse uno, dos, cuatro o ms procesadores de distintos tipos en una placa
si todos ellos estn diseados para el procesamiento dual o multiprocesamiento. Adems los requerimientos de disipacin de calor o de refrigeracin aumentan con el nmero de procesadores.
Intel ha presentado una nueva tecnologa llamada HyperThreading Pentium 4 a partir de 3,06
GHz y el Xeon a partir de 2,4 GHz. El HyperThreading consiste en que dentro del procesador
se tienen dos procesadores lgicos. Algunos sistemas operativos pueden ejecutarse ms rpido
as como algunas aplicaciones de software. No obstante, el incremento de velocidad no es tan
elevado como en el caso de un sistema dual con dos CPUs fsicas.
Tanto Intel como AMD han desarrollado ya la tecnologa de los llamados procesadores de
doble ncleo. Estos procesadores tienen colocados dos ncleos de procesador completos dentro
de un mismo recubrimiento que cuente con una conexin para el socket de la placa base. Este
truco tcnico ofrece las prestaciones de un sistema dual en una placa base que slo tiene un
socket (se requiere que sea compatible con el sistema operativo).
A principios del 2007 Intel lanz al mercado procesadores cudruples y AMD los hizo a
141
Figura 3.10: Placa base para cuatro CPUs
mediados del mismo ao. El problema principal es que la tecnologa del software tarda ms en
aprovechar toda esa potencia de cmputo.
Los sistemas basados en Linux tienen soporte actualmente hasta para 16 procesadores y
Solaris puede soportar hasta 256 procesadores.
Los sistemas operativos de microsoft, por ejemplo windows XP tiene soporte solamente hasta dos procesadores, y su ltima versin windows vista tiene soporte hasta cuatro procesadores
en versiones domsticas o pequeas empresas, pero puede soportar 8 o hasta 32 procesadores
en el servidor avanzado y en el servidor de centro de datos, aunque bsicamente es el mismo
ncleo.
Sin embargo, tanto Intel como AMD planean sacar al mercado procesadores con 8 procesadores para el siguiente ao.
3.6.6.1. Ventajas de los sistemas multiprocesadores
Las principales ventajas de los sistemas de multiprocesamiento incluyen:
Crecimiento modular. Puede adquirirse una placa base que soporte varios procesadores
con slo uno e ir adquiriendo los dems a medida que vayan aumentado las exigencias de
cmputo.
142

Tolerancia a fallos. Si algn procesador deja de funcionar, el rendimiento se degrada,
pero el sistema continuar trabajando,
Rendimiento. Si tenemos una aplicacin diseada para explotar el paralelismo, sta podr
ejecutarse mucho ms rpido.
Relacin Costo/Beneficio.los procesadores comerciales son mucho ms baratos, que los
de una sper computadora. As, podemos encontrar diferentes configuraciones multiproceso de acuerdo a las necesidades de cmputo.
3.6.6.2. Clasificacin de los sistemas multiprocesadores

Existen diversas categoras para los sistemas multiprocesadores. Flynn [40] introdujo un esquema general para clasificar a las arquitecturas de computadora de acuerdo a cmo la computadora relaciona sus instrucciones con los datos a procesar. As define los siguientes grupos:
SI. Single Instruction (Una sola instruccin).
MI. Multiple Instruction (Mltiples instrucciones).
SD. Single Data (Operacin sobre un solo dato).
MD. Multiple Data (Operacin sobre mltiples datos).
Con estas definiciones puede hacerse la siguiente clasificacin:
SISD. Flujo de una sola instruccin con flujo de un solo dato. Incluye a las computadoras
serie convencionales.
SIMD. Flujo de una sola instruccin, Flujo de mltiples datos. Se refiere a los tpicos
procesadores vectoriales y a los arreglos de computadoras en donde una sola instruccin
puede operar sobre diferentes datos en unidades distintas de ejecucin.
MISD. Flujo de mltiples instrucciones con flujo de un solo dato. Esta organizacin casi
no se utiliza, pero bsicamente sera aquella en la que mltiples instrucciones operan sobre
un nico flujo de datos, lo que puede compararse con las tcnicas de acceso concurrente.
MIMD. Flujo de mltiples instrucciones con flujo de mltiples datos. La ejecucin simultnea de mltiples instrucciones que operan sobre varios flujos de datos.
Los sistemas MIMD, se basan en la relacin entre procesadores y memoria, los multiprocesadores se pueden clasificar bajo este enfoque es:
143
Sistemas multiprocesadores Fuertemente acoplados. Los multiprocesadores contienen

memoria globalmente compartida a la que todos los procesadores tienen acceso.
Sistemas multiprocesadores dbilmente acoplados. Los procesadores individuales tienen memorias privadas y no existe una memoria global compartida.
Esta divisin no es muy estricta y podemos encontrar sistemas que manejen tanto memoria
compartida como memoria privada. La memoria compartida es esencial para la comunicacin
y sincronizacin entre procesadores en sistemas fuertemente acoplados. Estos sistemas se han
distinguido por tener un mayor ancho de banda y menores retardos en sus rutas de interconexin.
En los sistemas dbilmente acoplados puros, el mecanismo principal de comunicacin entre
procesadores es el paso de mensajes. En el pasado stos estaban caracterizados por un reducido
ancho de banda y por retardos elevados en sus rutas de interconexin.
Las configuraciones hbridas y algunos sistemas dbilmente acoplados permiten a los procesadores acceder a una memoria no local e incluso a la memoria privada de otros procesadores.
Existe generalmente una penalizacin por acceder a la memoria no local en forma de retardos
aadidos provocados por el arbitraje de contencin y el paso a travs de las rutas de interconexin procesador-memoria. Estos factores dan lugar a la siguiente clasificacin de los sistemas
multiprocesadores de memoria compartida en base a la arquitectura de la memoria y los retardos
de acceso.
Acceso uniforme a memoria. (UMA, Uniform memory access). Sistemas en donde los
procesadores pueden acceder a toda la memoria disponible con la misma velocidad; esto
incluye muchas arquitecturas con bus compartido.
Acceso no uniforme a memoria. (NUMA nonuniform memory access). Sistemas en donde existe una diferencia de tiempo en el acceso a diferentes reas de memoria, dependiendo de la proximidad a un determinado procesador y la complejidad del mecanismo de
conmutacin entre el procesador y la seccin referenciada de la memoria del sistema. En
ocasiones de le aade a esta clasificacin una tercera categora denominada acceso no
remoto a memoria (NORMA no remote memory access).
3.6.7. Organizacin del multiprocesador

En esta seccin haremos una descripcin bsica de los tipos de multiprocesador ms comunes incluyendo:
Sistemas orientados a bus.
144

Sistemas conectados por barras cruzadas.
Hipercubos.
Sistemas basados en conmutadores multicapa.
Los sistemas multiprocesadores se caracterizan por los siguientes aspectos:

1. Un multiprocesador contiene dos o ms procesadores con capacidades aproximadamente
comparables.
2. Todos los procesadores comparten el acceso a un almacenamiento comn y a canales de
Entrada / Salida, unidades de control y dispositivos.
3. Todo est controlado por un Sistema Operativo que proporciona interaccin entre procesadores y sus programas en los niveles de trabajo, tarea, paso, archivo y elementos de
datos.
3.6.7.1. Sistemas orientados a bus.
Uno de los modos ms sencillos de construir un multiprocesador es utilizar un bus compartido para conectar procesadores y memorias. En la figura 3.11 podemos ver el esquema bsico
del mtodo de bus compartido.
Figura 3.11: Organizacin de un sistema multiprocesador orientado a bus
145
El bus comn es en esencia una unidad pasiva. Un procesador o procesador de Entrada/Salida

que desee transferir datos debe efectuar los siguientes pasos:
1. Verificar que el conductor no est ocupado y que est disponible la unidad de destino.
2. Avisar a la unidad destino de lo que se va a hacer con los datos.
3. Comenzar la transferencia de datos.
Las unidades receptoras deben poder reconocer qu mensajes del bus son enviados hacia
ellas y confirmar las seales de control recibidas de la unidad emisora.
Una multitud de procesadores pueden comunicarse unos con otros y con la memoria globalmente compartida a travs de un bus compartido. Puede haber muchas variantes de este esquema
bsico: los procesadores individuales pueden o no disponer de memoria privada. Los dispositivos de entrada/salida pueden estas conectados a procesadores individuales o al bus compartido y
la propia memoria compartida se implementa generalmente en forma de mltiples bancos fsicos
conectados al bus compartido.
Se deben tener en cuanta dos aspectos importantes: El propio bus y la memoria compartida.
Para disminuir los tiempos de contencin es comn que se use una memoria cach entre la
memoria compartida y cada procesador. De esta forma la mayora de las referencias pueden
ser resueltas por la memoria cach y hacer un menor uso del bus comn. Si no hay memoria
cach puede llegar a haber una saturacin del bus y los tiempos de espera pueden llegar a ser
intolerables en un sistema con mucho trfico entre los procesadores y la memoria.
Si los procesadores usan memoria cach entonces tericamente existe una proporcin de
aciertos del 90 %, lo que podra permitir a un bus compartido de la misma velocidad soportar
diez veces el nmero de procesadores que se soportaran si no existiera la memoria cach.
Es una organizacin econmica, simple y flexible pero con una sola va de comunicacin,
por lo cual pueden generarse los siguientes problemas.
El sistema falla totalmente si falla el bus.
La tasa neta de transmisiones est limitada por la tasa neta de transmisin del conductor.
La contencin por el uso del bus en un sistema sobrecargado puede ocasionar una seria
degradacin.
Debe de mantenerse la coherencia de la cach de modo que mltiples copias fsicas de una
sola localidad de memoria contengan los mismos valores en las cachs correspondientes.
146
3.6.7.2. Sistemas de Barras Cruzadas e Interruptores

La conmutacin por barra cruzada es la nica fuente de retardo entre un procesador y una
memoria. Si los procesadores no tienen memorias privadas, el sistema resultante es un multiprocesador con acceso uniforme a memoria (UMA).
En este caso existe un camino diferente para cada unidad de almacenamiento, por lo cual las
referencias a dos unidades diferentes de almacenamiento no son bloqueantes sino simultneas y
la multiplicidad de caminos de transmisin puede proporcionar tasas de transferencia muy altas.
Figura 3.12: Conexin mediante barra cruzada
El esquema de barras cruzadas permite un elevado grado de paralelismo entre tareas no

relacionadas, pero la contencin de memoria es probable si la sincronizacin entre procesos y
entre procesadores est basada en memoria compartida.
La barra cruzada requiere N 2 conmutadores de punto de cruce para conectar completamente
N puntos con otros N puntos, tales como procesadores y memorias. El crecimiento cuadrtico
de la complejidad con el nmero de componentes hace que las barras cruzadas sean costosas y
limiten la escalabilidad de los sistemas resultantes.
En la figura 3.12 se observa cmo se implementa este tipo de conexin. La propia barra
cruzada no tiene contencin. Permite el acceso simultneo de N procesadores a N memorias,
supuesto que cada procesador acceda a una memoria diferente. La barra es el opuesto al bus
comn.
147
3.6.7.3. Hipercubos
La topologa de hipercubos afronta cuestiones de escalabilidad y costos cuyas complejidad
de conexiones crece logartmicamente. En general la topologa de un hipercubo, puede representarse en tres dimensiones con un cubo, y en cada vrtice se coloca un nodo, dando en total
ocho. En la figura 3.13 vemos cmo se representa este hipercubo.
Figura 3.13: Hipercubo con ocho nodos
Aunque son posibles otras distribuciones, el sistema multiprocesador dibujado en la figura

3.14 est construido con nodos formados por un procesador y su memoria privada. El resultado
es un multiprocesador tipo NORMA, que es una implementacin bastante comn de hipercubo.
Los hipercubos tienen una serie de interesantes propiedades matemticas. Por ejemplo, cada
procesador de un hipercubo tiene enlaces fsicos directos con log2 N nodos en un sistema de N
nodos. La mxima distancia entre dos nodos cualesquiera, medida como el nmero de enlaces
fsicos entre nodos, es tambin log2 N. Los hipercubos son estructuras recursivas en el sentido
de que los hipercubos de dimensiones mayores contienen hipercubos de dimesiones menores
como subconjuntos propios. Por tanto un hipercubo complejo puede particionarse en una serie
de hipercubos ms simples de dimensin menor. en el ejemplo del sistema dibujado en la figura
3.14, para N = 8; cada nodo tiene enlaces directos con log2 8 = 3 otros nodos, la mxima
distancia entre nodos es 3, y el sistema puede particionarse en dos hipercubos bidimensionales
disjuntos de tres modos distintos.
148
Figura 3.14: Conexiones entre procesadores
Los hipercubos proporcionan una buena base para sistemas escalables, ya que su complejidad crece logartmicamente con el nmero de nodos. Al mismo tiempo, la comunicacin entre
nodos adyacentes es directa y el mayor retardo entre nodos est acotado por log2 N. Los hipercubos son adecuados para muchos problemas que encajan fcilmente en su estructura, especficamente aquellos que se apoyan en la recursin o que exhiben localidad de referencias en forma
de afinidad para comunicacin con nodos adyacentes. los hipercubos estn considerados como
una prometedora base para el multiprocesamiento a gran escala.
Las implementaciones hipercubo de principios de los noventa tienden a incorporar memorias
privadas en cada procesador. La arquitectura NUMA resultante dicta el paso de mensajes como
mecanismo primario de comunicacin y sincronizacin entre procesadores. Adems de efectuar
el procesamiento, los nodos individuales manejan generalmente protocolos de comunicacin.
Tambin se encargan de encaminar y entregar mensajes externos para formar rutas de comunicacin. Tambin se encargan de encaminar y entregar mensajes externos para formar rutas de
comunicacin indirectas ente nodos remotos directamente conectados unos a otros. Los dispositivos de entrada/salida pueden estar asociados localmente a nodos individuales. Para aumentar
el ancho de banda de entrada/salida, algunas implementaciones disponen de nodos inteligentes
de entrada/salida dedicados que actan como fuentes y depositarios de los flujos de datos de
entrada/salida para grupos de nodos.
149
3.6.7.4. Sistemas basados en conmutadores multietapa

Los procesadores y las memorias de un sistema multiprocesador pueden conectarse por medio de un conmutador multietapa. Existen muchas variantes de este mtodo. Una forma generalizada de este tipo de interconexin proporciona enlaces entre N entradas y N salidas. Tiene
m = log2 N etapas. Cada etapa consta de un conjunto de N enlaces conectad a N/2 cajas de
intercambio.
Las redes de conmutacin multietapa proporcionan una forma de conmutacin de circuito.
Existe un breve tiempo para la preparacin de la interconexin, pero una vez establecida, se
aprovecha todo el ancho de banda, y es deseable transferir bloques de memoria grandes de
modo que una sola preparacin pueda aprovecharse mejor.
El conmutador multietapa puede conectar simultneamente todas las entradas a todas las
salidas, suponiendo que no haya dos procesadores que intente acceder al mismo mdulo de
memoria al mismo tiempo. En caso contrario, puede aparecer contencin en los mdulos de
memoria y dentro de la red de conmutacin lo que hace que el trfico descienda.
El almacenamiento en bferes dentro de la red de conmutacin o en la memoria puede aliviar
parte de la contencin, pero no puede hacer desparecer los puntos calientes de los mdulos
de memoria. Un punto caliente ocurre cuando algunos mdulos de memoria son referenciados
frecuentemente por una serie de procesadores. Es obvio que solamente un procesador puede
tener acceso al mdulo de memoria y los restantes deben esperar su turno. El problema es que
ese punto caliente puede tambin bloquear otras rutas de otros mdulos de memoria durante
largos largos perodos de tiempo, afectando en consecuencia la capacidad de otras entradas y
salidas no relacionadas para establecer conexiones.
3.6.8. Sistemas operativos del multiprocesador

Cuando surgen nuevas tecnologas emergentes, el estmulo de las primeras investigaciones y
las implementaciones de los primeros multiprocesadores se dedican la demostracin de conceptos. Los principales objetivos de investigacin eran las arquitecturas y los modos de explotar el
paralelismo para aumentar la velocidad.
Debido a la relativa falta de experiencia y al limitado uso de los multiprocesadores queda
mucho trabajo por realizar en cuanto al desarrollo e implementacin de los principios sobre la
metodologa de diseo para sistemas operativos en multiprocesadores. Los tres tipos bsicos de
sistemas operativos multiprocesadores son:
1. Supervisores separados. Cada nodo tiene un sistema operativo autnomo que administra
el procesador local, la memoria y los recursos de entrada/salida
150
2. Maestro/esclavos. Un procesador se dedica a ejecutar el sistema operativo y los restantes

procesadores son generalmente idnticos y forman un depsito de procesadores computacionales.
3. Simtrico. Todos los procesadores son funcionalmente idnticos. Todos los recursos estn
disponibles para todos los procesadores. Si slo algunos procesadores tienen acceso a
algunos recursos entonces se habla de un sistema asimtrico.
3.6.8.1. Supervisores separados

Los sistemas supervisores separados, tienen nodos que contienen un sistema operativo independiente que administra el procesador local, la memoria y los recursos de entrada/salida. En
su forma rudimentaria este mtodo administra efectivamente cada procesador como un sistema
independiente. Slo hay que aadir unos pocos servicios y estructuras de datos adicionales para
soportar los aspectos multiprocesadores del hardware. Tales implementaciones de supervisores
separados ofrecen poca capacidad de equilibrio de cargas y raramente soportan el paralelismo
dentro de las aplicaciones.
3.6.8.2. Maestro/Esclavos
En este mtodo, un procesador se dedica a ejecutar el sistema operativo. los dems procesadores comnmente son idnticos y estn disponibles para ejecutar las tareas que les asigne
el procesador maestro. El procesador maestro, planifica las tareas y controla la actividad de los
esclavos. Casi todas las estructuras de datos concernientes al sistema operativo las controla el
procesador maestro y las almacena en su memoria privada. Los procesadores esclavos pueden
ser capaces de procesar directamente algunas consultas locales simples, pero la mayora de los
servicios del sistema operativo son proporcionados por el procesador maestro.
Esta disposicin permite el paralelismo dentro de una aplicacin mediante la asignacin a
ella de mltiples esclavos. No obstante, poco o ningn paralelismo es posible para el sistema
operativo, ya que ste se ejecuta en un solo procesador.
Los temas maestro/esclavo son relativamente fciles de desarrollar e implementar. Aadindole la planificacin de esclavos a un sistema operativo monoprocesador serie se puede
adaptar con bastante facilidad para que pueda operar como un sistema multiprocesador maestro/esclavos. El problema principal con este enfoque es su poca escalabilidad, puesto que con
muchos procesadores el sistema operativo ejecutndose en un solo procesador se vuelve un cuello de botella.
151
3.6.8.3. Simtrico
En esta arquitectura, todos los procesadores son funcionalmente idnticos. El sistema operativo tambin es simtrico en el sentido de que cualquier procesador puede ejecutarlo. En teora,
la organizacin simtrica permite la ejecucin paralela del sistema operativo en varios procesadores. A este extremo, el sistema operativo necesita ser codificado en forma de una serie de
tareas autnomas, y tienen que existir los cerrojos adecuados para acceder a estructuras de datos
compartidas.
En la forma ms sencilla de organizacin simtrica, la conocida como maestro flotante, el
sistema operativo es ms o menos una nica seccin critica de grandes dimensiones. En respuesta a los requisitos de la carga de trabajo y la disponibilidad de procesadores, el sistema operativo
se ejecuta en diferentes procesadores en instantes diferentes. Bajo esta organizacin, el procesador en donde se ejecuta el sistema operativo acta como maestro en el sentido de que se encarga
de planificar las tareas para los dems procesadores. As el sistema operativo no est ligado a
ningn procesador y flota de un procesador a otro.
Como ejemplo podemos hablar un poco del sistema operativo Solaris. La Arquitectura avanzada de este sistema operativo incluye multiprocesamiento totalmente simtrico (SMP) y multithreading sofisticado (MT). El SMP/MT acelera el rendimiento del sistema al permitir que diferentes aplicaciones puedan ejecutarse en mltiples procesadores concurrentemente. As mismo,
SUN implementa un kernel de multithreading sin quebrar las interfaces del SVR4. El Kernel
de multithreading le asigna "multithreading.al hardware; esto es, muchos procesos pueden ejecutarse paralelamente en diferentes CPUs incrementando el rendimiento del sistema; muchas
aplicaciones pueden beneficiarse con esto, incluyendo manejadores de bases de datos.
La multitarea significa que el sistema operativo puede realizar varias tareas al mismo tiempo.
El multiprocesamiento simtrico permite sacar toda la ventaja de los procesadores mltiples. El
multiprocesamiento asimtrico (en donde un microprocesador se dedica exclusivamente a una
tarea especfica), da lugar a que un microprocesador permanezca inactivo en cuanto finaliza su
tarea. En el multiprocesamiento simtrico, el sistema operativo puede asignar diferentes tareas
a un mismo procesador; as, si uno de ellos termina su trabajo antes que otro, el sistema operativo podr ocuparlo en otra actividad. El multiprocesamiento simtrico es bastante difcil de
implementar, pero ofrece un rendimiento muy superior. Cabe mencionar que la caracterstica de
multithreading slo se presenta en equipos de arquitectura Sun4m, Sun4d y Sun4u.
3.7. Problemas
3.1. Defina con sus propias palabras qu es un proceso.
152
3.7. PROBLEMAS
3.2. Describa brevemente los estados de un proceso.
3.3. Dibuje un diagrama que indique las transiciones de un proceso.
3.4. Qu es la concurrencia?
3.5. Proporcione cinco ejemplos de la vida real en donde est presente la concurrencia.
3.6. Qu problemas se presentan en la concurrencia?
3.7. De qu manera evitara los problemas de concurrencia de la pregunta anterior?
3.8. Cmo definira la seccin crtica?
3.9. Proporcione cinco ejemplos de la vida real en la que se presente algo parecido a la
seccin crtica (Solamente una entidad puede estar haciendo uso de un recurso en un
solo momento).
3.10. A qu se refiere la exclusin mutua?

3.11. Explique las formas para garantizar la exclusin mutua.
3.12. Quin invent los semforos? Defina con sus palabras un semforo.
3.13. Qu es un monitor?
3.14. Seale las ventajas y desventajas de un monitor con respecto a un semforo.
3.15. Para qu sirven los mensajes?
3.16. Describa las operaciones tpicas de los mensajes.
3.17. Es posible garantizar la exclusin mutua por medio de mensajes? Explique su respuesta.
3.18. Qu es una interrupcin?
3.19. Por qu es necesario el bloqueo de recursos?
3.20. Defina qu es un interbloqueo.
3.21. Cules son las condiciones para que se d un interbloqueo?
3.22. En qu recursos no es posible que se d un interbloqueo y en cules s es posible?
Explique.
153
3.23. Cmo se previenen los interbloqueos? Explique.

3.24. Es posible que un sistema operativo no apropiativo pueda evitar un interbloqueo?
Sustente su respuesta.
3.25. Qu tan correcto es terminar un proceso para romper un interbloqueo? Explique.
3.26. Investigue las formas en las que los sistemas operativos comerciales enfrentan el problema de interbloqueo.
3.27. Explique el concepto de espera circular.
3.28. Cuando sabemos que el sistema se encuentra en estado seguro?
3.29. Suponga que usted es el encargado de determinar la existencia de interbloqueos. Bajo
qu condiciones indicara que existe un interbloqueo?
3.30. Explique las ventajas y desventajas de que el sistema operativo se apropie de los recursos que tiene asignados un proceso.
3.31. Defina qu es un trabajo(job).
3.32. Qu es un ciclo de instruccin?, Qu es un ciclo de reloj?,Cul es la diferencia?
3.33. Defina qu es un ciclo de entrada/salida.
3.34. Por qu surgi la necesidad de planificar el tiempo de CPU?
3.35. Explique las dos estrategias generales de planificacin de CPU.
3.36. Explique los criterios de planificacin. Cules piensa que son ms importantes? .Por
qu?
3.37. Explique brevemente los tipos de planeacin ms utilizados.
3.38. Qu tipo de planeacin se considera ptimo?
3.39. Cmo est constituido un sistema multiprocesador?
3.40. Defina los conceptos de multiprogramacin, multitarea, tiempo compartido y multiprocesamiento.
3.41. Explique las diferencias clave entre los conceptos anteriores.
154
3.7. PROBLEMAS
3.42. Qu es paralelismo?
3.43. Explique las formas con las que se puede implementar el paralelismo.
3.44. Considerando la precedencia de operadores, escriba cinco ecuaciones y determine qu
operaciones pueden ejecutarse en paralelo.
3.45. Obtenga el promedio de ejecucin de las ecuaciones anteriores. Establezca sus propios
tiempos de ejecucin para cada operacin.
3.46. Defina un sistema operativo para multiprocesamiento.
3.47. Qu ventajas y desventajas ofrecen los sistemas de multiprocesamiento?
3.48. Describa otras maneras de reducir el tiempo de ejecucin de un proceso.
3.49. Mencione la clasificacin de los sistemas multiprocesadores.
3.50. Describa brevemente los tipos de multiprocesador ms comunes.
3.51. Cules son las caractersticas de los sistemas multiprocesadores?
3.52. Describa la arquitectura orientada a bus. Cules son sus ventajas y desventajas?
3.53. Qu ventajas ofrece que cada procesador tenga su propia memoria cach?
3.54. Qu desventajas tiene la arquitectura orientada a bus?
3.55. Describa la arquitectura de los sistemas de multiprocesamiento de barras cruzadas.
3.56. Qu ventajas y desventajas presenta esta arquitectura?
3.57. Haga un diagrama que represente la arquitectura de multiporcesador usando hipercubos.
3.58. Describa sus ventajas y desventajas.
3.59. Explique la arquitectura de un sistema multiprocesador basado en conmutadores multicapa.
3.60. Cules son los tres tipos bsicos de sistemas operativos multiprocesadores? Explique
cada uno de ellos.
3.61. Cmo implementa Solaris el multiprocesamiento simtrico?
3.62. Como definira el multiprocesamiento asimtrico?
155
3.8. Lecturas adicionales

En Silberchatz[95] pginas 137-169 podemos encontrar los criterios y algoritmos ms importantes para la planificacin de la CPU. Milenkovic[94] no separa la planificacin de la CPU
e incluye estos algoritmos como parte de los procesos en las pginas 65 a la 94. Tanenbaum[98],
al igual que Milenkovic no presentan una separacin entre procesos y la planificacin del procesador, pero podemos ver en Tanenbaum[98, 101] a partir de la pgina 84 una descripcin de
los algoritmos de planificacin en Tanenbaum[101] lo denomina calendarizador de procesos.
En cuanto a la investigacin sobre la planificacin de procesos tenemos muchsimos trabajos
que hablan acerca de ella.
Chekuri[26] habla sobre algunos algoritmos de aproximacin para problemas de planificacin.
Chaitanya Swamy y Sachin Jain[97] explican algunos algoritmos de planificacin
Laurent George, Nicolas Rivierre y Marco Spuri[41] desarrollaron una versin modificada
del algoritmo de asignacin de prioridad ptimo propuesto por Audsley[9, 10], para planificadores expulsivos y no expulsivos.
Yue[110], por su parte, aborda el tema de asignacin dinmica de procesadores en el sistema
Solaris. Bogdan Caprita, Wong Chun Chan, Jason Nieh, Clifford Stein y Haoqiang Zheng[19]
hablan sobre el algoritmo de planificacin Roun-Robin modificado con una tasa de grupo y
sobre la planificacin proporcional compartida.
Ellard Roush[89] compara el desempeo del subsistema de procesos de un sistema operativo.
En la actualidad, ha cobrado mucha importancia el procesamiento masivamente paralelo.
Engels y Feldman [36] hablan sobre la planificacin de procesadores paralelos con restricciones
de retardo.
El equipo de Emilia Rosti[88] habla sobre las planeacin de polticas de ahorro de procesadores para sistemas multiprocesador.
Audsley[9, 10] explica que la planificacin de procesos es un problema difcil, pero que
la mayora de las veces se simplifica imponiendo severas restricciones sobre las caractersticas
del tiempo proporcionado a cada proceso, e investiga qu tanto influye la asignacin de tiempo
cuando sta es menor al perodo asignado por el procesador.
Liu y James W. Layland[66] abordan los algoritmos de planificacin en entornos de multiprogramacin en ambientes de tiempo real y Damir Isovic[52] trata sobre una planificacin
flexible para un entorno de tiempo real con recursos restringidos.
En los artculo de Ritchie[84, 83] podemos apreciar los comienzos del sistema operativo
UNIX.
Jochen Liedtke[65] justifica desde el punto de vista de tecnologa del software que es mejor
156
3.8. LECTURAS ADICIONALES
la construccin de -kernels que los kernels monolticos.

Hoare[48] describe las primitivas necesarias para la comunicacin secuencial interprocesos.
Lampson [60] describe su experiencia al usar procesos y monitores con mesa.
Tevanian[103] explica la implementacin de los hilos en el sistema operativo Mach y en
UNIX. David. L. Black[16] describe la planificacin para el soporte de concurrencia y paralelismo en el sistema operativo Mach
Feitelson[38] nos habla sobre la teora y la prctica de la planificacin de trabajos que corren paralelamente (procesamiento paralelo). Blumofe[17] hace lo propio pero enfocado en a la
ejecucin de programas con hilos o trheads.

Oscar

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Oscar

Enviado por

Direitos autorais:

Formatos disponíveis

Captulo 3

Administracin de procesos y del

El siguiente trmino importante es el de los sistemas de multiprocesamiento. Bsicamente

3.1. CONCEPTO DE PROCESO

3.1. Concepto de proceso

3.2. Estados y transiciones de un proceso.

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

ejecucin, interrumpe al que se encuentra en la CPU y enva a la CPU otro proceso. La

3.2. ESTADOS Y TRANSICIONES DE UN PROCESO.

Figura 3.1: Diagrama de estados de un proceso

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

estadsticas referentes al proceso, lo eliminar definitivamente de memoria y desasignar

3.2. ESTADOS Y TRANSICIONES DE UN PROCESO.

3.2.1. El Estado de Suspendido

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.2.2. El bloque de control de procesos

3.2. ESTADOS Y TRANSICIONES DE UN PROCESO.

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

error de no poder crear un nuevo proceso */

3.2. ESTADOS Y TRANSICIONES DE UN PROCESO.

Eliminacin de procesos. Un proceso termina cuando ejecuta su ltima instruccin y pide al

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.3. Procesos ligeros: Hilos o hebras

3.3. PROCESOS LIGEROS: HILOS O HEBRAS

3.3.1. Ventajas de la programacin multi hilo

3.3.2. Implementacin de hilos en GNU/Linux

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.3. PROCESOS LIGEROS: HILOS O HEBRAS

3.3.3. Consideraciones finales

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.3.3.1. Eliminacin de hilos

3.4. Concurrencia y secuenciabilidad

3.4. CONCURRENCIA Y SECUENCIABILIDAD

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.4.2. Principios generales de la concurrencia

3.4. CONCURRENCIA Y SECUENCIABILIDAD

3.4.3. La seccin crtica

3.4.4. Exclusin mutua; solucin por hardware y software

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.4. CONCURRENCIA Y SECUENCIABILIDAD

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.4. CONCURRENCIA Y SECUENCIABILIDAD

/* exclusion mutua con funcin intercambiar*/

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

Algunas desventajas importantes son las siguientes:

3.4. CONCURRENCIA Y SECUENCIABILIDAD

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

Figura 3.2: Los estados de un proceso ms el estado de espera

3.4. CONCURRENCIA Y SECUENCIABILIDAD

3.4.5.1. Algoritmo para un semforo binario

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

Figura 3.3: Estructura general de un monitor

3.4. CONCURRENCIA Y SECUENCIABILIDAD

3.4.6.1. Monitores con Seales

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.4.6.2. Monitores con Notificacin y Difusin

3.4. CONCURRENCIA Y SECUENCIABILIDAD

3.4.7. Paso de mensajes

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

tienen algunos problemas de implementacin y tienden a ser restrictivos en cuanto al rango de

3.4. CONCURRENCIA Y SECUENCIABILIDAD

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR

3.4. CONCURRENCIA Y SECUENCIABILIDAD

CAPTULO 3. ADMINISTRACIN DE PROCESOS Y DEL PROCESADOR