Академический Документы
Профессиональный Документы
Культура Документы
O mo
74
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.
75
76
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
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.
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.
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
82
83
84
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.
85
86
}
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().
87
88
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
90
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
95
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*/
97
98
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
100
101
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.
103
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.
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.
int proceso2()\{
....
wait(disco1);
wait(impresora);
110
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.
111
112
113
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
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
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
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
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
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.
123
124
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.
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.
126
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
128
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
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.
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
134
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.
136
137
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.
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
140
planificacin de instrucciones global. Planifica todas las instrucciones que forman parte de un
programa.
141
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
143
144
145
146
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.
148
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
150
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).
153
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
156