*HVWLyQGH3URFHVRV

Como se vio en la Introduccin, en los sistemas operativos actuales se puede

disponer de varios programas en memoria que se pueden ejecutar, dependiendo de
la poltica de planificacin, de una forma ms o menos simultnea.
En este captulo nos vamos a ocupar de cmo el sistema operativo se encarga de
controlar todos los procesos cargados en memoria, de la asignacin de la CPU a
cada uno de los procesos, y, cuando se trate de procesos cooperantes, de la
comunicacin y sincronizacin entre ellos.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

,QWURGXFFLyQ
Sabemos que la CPU realiza ciertas actividades. En un sistema de tratamiento por
lotes (EDWFK), se ejecutan trabajos; en un entorno de tiempo compartido hay
programas de usuarios, o tareas; incluso en un ordenador personal, hoy da un
usuario puede ejecutar varios programas simultneamente, uno interactivo, y otros
en segundo plano (EDFNJURXQG. La cuestin es cmo llamar a todas estas
actividades que realiza la CPU. Pues bien, a estas actividades las denominaremos
SURFHVRV.

 &RQFHSWRGH3URFHVR
Se han odo muchas definiciones de proceso, pero, sin duda, la ms popular y
acertada es la que dice que XQSURFHVRHVXQSURJUDPDHQHMHFXFLyQ.
Ya que no es nada fcil dar una definicin autoexplicativa de lo que es un proceso,
vamos a tratar de explicarlo mediante ideas y ejemplos. Ante todo, se debe tener
muy presente que un proceso asocia programa+actividad.
Cuando decimos que un proceso es un programa en ejecucin, nos referimos al
hecho de llevar a cabo o realizar las instrucciones que contiene el programa en el
orden establecido. Un programa es una lista de instrucciones escritas en un papel,
un fichero en disquete, disco duro, memoria RAM o cualquier otro soporte, pero el
simple hecho de que estas instrucciones estn escritas no implica que se estn
llevando a cabo. Pues bien, cuando se leen estas instrucciones y se hacen ejecutar,
entonces ya tenemos programa+actividad, es decir, un proceso.
Hacemos hincapi en DFWLYLGDG para diferenciarlo bien de un mero programa, ya que
una caracterstica bsica de los programas es que son estticos. Ya hemos dicho
que un programa es una secuencia de rdenes que, por mucho que la miremos, no
vara nunca. Las variables no tienen valores, las rutinas no tienen direccin, las
condiciones estn sin evaluar. Un programa es simplemente XQ DOJRULWPR D
HMHFXWDU
En cambio, un proceso es dinmico. Tiene vector de estado indicando el momento y
estado de su ejecucin, las variables tienen valores, las rutinas se encuentran en
alguna direccin de memoria, y las condiciones son evaluables. El proceso es OD
HMHFXFLyQGHODOJRULWPR
Un ejemplo que puede describir la relacin programa-proceso puede ser el manual
de montaje de un aeromodelo que viene despiezado. Las instrucciones de montaje
que vienen en la caja son algo esttico (por eso aunque dejemos mucho tiempo las
instrucciones en la caja, el aeromodelo no aparece construido al cabo de un tiempo.
Sin embargo, cuando cogemos las instrucciones y empezamos a hacer lo que
indican, es cuando empieza la actividad, entonces comienza el SURFHVR de montaje.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

&RQFHSWRGH3URFHVR

,QWURGXFFLyQ

4XpHVXQ3URFHVR"
(VXQ3URJUDPDHQ(MHFXFLyQ
8Q3URJUDPD (VHVWiWLFR1RYDUtDQDGD
1RWLHQHYHFWRUGHHVWDGR
9DULDEOHVVLQYDORUHV

1RUHTXLHUH
SURFHVDGRU

5XWLQDVVLQGLUHFFLyQ
&RQGLFLRQHVVLQHYDOXDU
(VHODOJRULWPRDHMHFXWDU
8Q3URFHVR

(VGLQiPLFR

1HFHVLWD
SURFHVDGRU
/DVYDULDEOHVWLHQHQYDORUHV
7LHQHYHFWRUGHHVWDGR

/DVUXWLQDVHVWiQHQDOJXQDGLUHFFLyQ
/DVFRQGLFLRQHVVHSXHGHQHYDOXDU
(VODHMHFXFLyQGHODOJRULWPR
352&(62
(VWDGR

6H
QHFHVLWD
6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

3URJUDPD

3URFHVDGRU

8Q&3
8QiUHDGHWUDEDMR

(VWDGR

SRUSURFHVR

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

Si en la construccin del aeromodelo, quien lleva a cabo las instrucciones del

manual de montaje es la persona, que lee las instrucciones y las va ejecutando; en
un ordenador, el ente que va leyendo las instrucciones del programa (que est en
memoria) y ejecutndolas, es la CPU. As, tenemos que el tndem
programa+procesador es el que hace que el estado de desarrollo de un determinado
trabajo evolucione y cambie de un estado a otro.
Al igual que para la construccin del aeromodelo se necesita un rea de trabajo (una
mesa o algo similar), para la ejecucin de un programa, tambin se requiere un rea
de trabajo, esto es, ODSLODdel proceso. La pila es la zona de memoria en la que se
guardan los parmetros, variables locales, direcciones de retorno de subprogramas
y, en general, los datos temporales del proceso. Un proceso tambin se caracteriza
porque en un momento dado de su ejecucin dispone de ciertos valores en los
registros del procesador, entre ellos, el &RQWDGRU GH 3URJUDPD que contiene la
direccin de la instruccin que va a ejecutar el proceso a continuacin. As, el
Contador de Programa es el registro que indica el punto de ejecucin del programa
en el que se encuentra el proceso.
Se debe tener en cuenta que la relacin entre un programa y su proceso no es
biunvoca. Esto se debe al hecho de que en un momento dado puede haber varios
procesos correspondientes al mismo programa. Por ejemplo, en una clase de
trabajos manuales pueden estar escritas en la pizarra las instrucciones de montaje
de un aeromodelo (un programa) y todos los alumnos estn montando un
aeromodelo siguiendo las mismas instrucciones (varios procesos). Un ejemplo ms
informtico puede ser el de varios alumnos que, en un momento dado, estn
utilizando el editor de texto en distintos terminales de un sistema de tiempo
compartido. Hay un nico programa editor de texto, pero puede haber varios
procesos simultneos ejecutando tal programa.

 'HVFULSWRUGH3URFHVR
Como ya sabemos, en un sistema multiprogramado se pueden ejecutar
simultneamente varios programas, es decir, en un momento dado puede haber
varios procesos. En un sistema con un nico procesador no se puede decir que
haya varios programas ejecutndose estrictamente de una forma simultnea. En
realidad, la posesin del procesador se va repartiendo entre los distintos procesos,
dando lugar a una ejecucin pseudoparalela. No obstante, por simplicidad, nos
referiremos, en general, a ejecucin simultnea o paralela, tanto si es estricta
(sistema multiprocesador) como si no lo es (con un solo procesador).
El FRQWH[WR de un proceso se define como la informacin necesaria para especificar
completamente su estado actual. Esto incluye toda la informacin que ha de
salvarse cuando un proceso pierde la posesin de la CPU, y hay que restaurar
cuando se le vuelve a conceder la posesin del procesador.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

El contexto de un proceso, dependiendo del lugar donde reside la informacin, est

formado por tres tipos de informacin:
Bloque de Control de Proceso (BCP)
Contexto de Memoria
Contexto del Procesador
El %ORTXH GH &RQWURO GH 3URFHVR (o Descriptor de Proceso) comprende la
informacin que siempre est en la memoria principal durante la existencia del
proceso. El BCP contiene la informacin relativa a un proceso que requiere el
sistema operativo para gestionarlo. Igual que en una empresa se dispone de las
fichas de los empleados, con los datos necesarios para la administracin (Datos
personales, profesionales, salarios, horas extraordinarias, etc.), el sistema operativo
dispone de los BCP de cada uno de los procesos que tiene en cada momento.
Aunque el contenido de los descriptores de procesos vara de un sistema a otro, en
la Figura 2 se puede ver un ejemplo con algunos datos tpicos que suelen contener.
A lo largo de este captulo se ir viendo el significado y utilidad de estos datos del
BCP, as como las estructuras de datos que contiene el sistema operativo para
mantener los BCPs de todos los procesos.
El &RQWH[WR GH 0HPRULD contiene lo que es el programa en s, es decir, las
instrucciones y los datos del programa. Esta parte solamente necesita estar en
memoria principal cuando el proceso est realmente en ejecucin, o sea, que tiene
la CPU asignada; el resto del tiempo, el contexto de memoria puede encontrarse en
disco, liberando as espacio de memoria principal.
El &RQWH[WR GHO 3URFHVDGRU es la parte del contexto del proceso almacenado en
los registros del procesador. En estos registros se mantienen datos tales como el
Contador de Programa, el estado de la CPU, el puntero de la pila utilizada por el
proceso, registros de control y registros de propsito general para mantener datos
de las variables o constantes del programa.
Como ya hemos dicho, el BCP es algo as como la ficha de control del proceso, por
esto, en l tambin se encuentra la informacin necesaria para poder acceder tanto
al contexto de memoria como al del procesador.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

'HVFULSWRUGH3URFHVR

,QWURGXFFLyQ

&yPR9HHO62DORV3URFHVRV"
0HGLDQWHVXYHFWRUGHHVWDGRHQXQ
'HVFULSWRUGH3URFHVR

(O'HVFULSWRUGH3URFHVRFRQWLHQHLQIRUPDFLyQ
GHO3URFHVR
GHVX0HPRULD
GH(VWDGRGHO3URFHVDGRU5HJLVWURV

&RQWH[WR
GHOSURFHVR

W\SH DESCRIPTOR_PROCESO LV
UHFRUG
Id_Proceso
Siguiente
Estado
Puntero_Pila
Memoria_Utilizada
Ficheros_Abiertos
Proceso_Padre
Procesos_Hijos
Dormido_Hasta
HQGUHFRUG;

6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

6LVWHPDV0XOWLSURFHVR3DUDOHOLVPR
En la Introduccin ya se vio, por encima, la utilidad de ejecutar varios programas de
forma simultnea para evitar el desaprovechamiento de los tiempos de espera de
CPU a las respuestas de los dispositivos perifricos en las operaciones de
entrada/salida que realiza un proceso.
Otra justificacin de la ejecucin paralela de programas viene dada por las leyes de
la fsica, pues segn la Teora de la Relatividad de Albert Einstein es imposible
transmitir seales elctricas a ms velocidad que la de la luz, esto es, unos 30cm
por nanosegundo. Esto quiere decir que el tiempo mnimo que puede tardar en
transmitirse una seal entre dos componentes de un ordenador separados 30cm es
1ns. O sea, que los ordenadores tendran que empezar a fabricarse cada vez ms
pequeos, pero claramente, sabemos que esto tiene ciertas limitaciones. Por otra
parte, algunos programas (clculo cientfico, tiempo real, etc.) requieren, a menudo,
ciertas velocidades de ejecucin, para que el resultado sea exitoso. Una forma de
conseguir que un programa se ejecute ms rpidamente que ejecutando una
instruccin tras otra, consiste en dividir el programa en varias tareas o procesos y
ejecutndolos en paralelo. Un smil de la vida real puede ser el proceso de
fabricacin de los automviles. Las cadenas de montaje de los coches no fabrican
primero las ruedas, luego el motor, a continuacin el chasis, despus la carrocera,
luego los cristales, ...; sino que cada uno de estos elementos se fabrica por
separado de forma paralela y simultnea, y cuando estn todos construidos, se
realiza el proceso de ensamblaje para formar el automvil completo. De esta forma
se consigue construirlo en bastante menos tiempo.
Ya tenemos, por tanto, dos buenas razones para la multiprogramacin:
Los procesos cooperantes, para realizar un trabajo en conjunto.
Mejorar el rendimiento del ordenador, aprovechando la CPU en sus tiempos de
espera por dispositivos de E/S, dando lugar a sistemas multiusuario o
simplemente de multiproceso.
No debemos confundir un sistema PXOWLSURFHVR con PXOWLXVXDULR. Un entorno
multiproceso es el que permite varios procesos simultneos, por ejemplo, una
persona en un terminal con ventanas tal que en cada ventana tiene distintos
procesos en ejecucin (un editor de texto, un reloj, un videoclip, etc.). En este
sistema es posible que no haya ms puestos de trabajo o terminales, con lo que
sera un entorno multiproceso monousuario. Si se dispone de varios terminales en
un sistema, entonces, adems de multiproceso, es multiusuario.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

6LVWHPDV0XOWLSURFHVR3DUDOHOLVPR
3UREOHPDVGHO3URFHVDPLHQWR6HFXHQFLDO
/DVOH\HVGHODItVLFD
LPSRQHQOLPLWDFLRQHV
GHYHORFLGDG

1RVHDSURYHFKD
OD&38

62/8&,1

352&(6$0,(1723$5$/(/2RVHXGRSDUDOHOR
08/7,352*5$0$&,1

3URFHVRV
&RRSHUDQWHV

0XOWLSOH[DFLyQGHOD
&38HQWUHSURFHVRV
FRQFXUUHQWHV
FRRSHUDQWHVRQR

0XOWLSURFHVR0XOWLXVXDULR

6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

 6LVWHPDV0XOWLSURFHVDGRU0RQRSURFHVDGRU
0XOWLSOH[DFLyQGHOD&38
Sabemos que para que un programa se ejecute, hay que convertirlo en proceso, y
para que ste evolucione de un estado a otro se requiere un procesador. Si
hablamos de sistemas multiproceso, es decir, que hay varios programas
simultneamente en memoria, lo ms conveniente para la ejecucin ms rpida es
asignar un procesador a cada uno de los procesos, para que evolucionen todos de
una forma realmente paralela o simultnea. Este es el caso de los ordenadores con
mltiples procesadores, en los que en un momento dado se encuentran realmente
en ejecucin varios programas. Si bien esta es la forma ms rpida de ejecutar
mltiples programas, tambin resulta ser, obviamente, la ms cara. No solamente
por la cantidad de hardware utilizado (cuando menos, varias CPUs), sino tambin
por el hardware y software adicional necesario para poder sincronizar y gestionar
mltiples CPUs, algo mucho ms complejo que cuando solamente se dispone de un
nico procesador. (Resultan mucho ms sencillos los departamentos de personal,
marketing, fabricacin, distribucin etc. de una empresa de 2, 3 o 4 empleados, que
los de una multinacional de miles de empleados).
Ya que la mayora de los ordenadores actuales de propsito general constan de un
slo procesador, vamos a centrarnos aqu en los ordenadores monoprocesadores,
dejando los de mltiples procesadores para otras asignaturas de arquitecturas
avanzadas.
Si tenemos un sistema operativo multiproceso y contamos con un nico procesador,
solamente tenemos una eleccin: +D\TXHUHSDUWLUHOSURFHVDGRUHQWUHORVSURFHVRV.
De esta manera, lo que conseguimos es simular una mquina multiprocesador, es
decir, tendremos un pseudoparalelismo en la ejecucin de los procesos. As, aunque
no obtengamos todas las ventajas de una ejecucin puramente paralela, s
aprovecharemos el hecho de que durante la ejecucin de un programa hay muchos
momentos en que no se puede continuar su ejecucin hasta que no se produzca
algn evento externo a la CPU, como por ejemplo la realizacin de una operacin
solicitada a un dispositivo de E/S, la pulsacin de un carcter en el teclado, la
llegada de un carcter por la lnea de comunicaciones, una interrupcin generada
por un detector, etc.
Quizs nos puedan servir como ejemplo las partidas de ajedrez simultneas que
mantienen los maestros de ajedrez con 20 principiantes. Cuando el maestro realiza
una jugada con un principiante, ste tarda mucho tiempo hasta que decide mover;
mientras tanto, el maestro puede realizar jugadas con el resto de los aprendices, y
seguramente, le dar tiempo a hacer un movimiento con cada uno de los rivales
antes de que el primero de ellos se haya decidido a mover una figura.
En este ejemplo tan optimista, esta partida simultnea se realiza en 1/20 del tiempo
que se tardara si el maestro primero se dedicase por entero a jugar una partida con
el primer aficionado, hasta finalizarla; luego comenzar otra partida con el segundo y
as sucesivamente hasta haber jugado las 20 partidas. En los casos reales de
nuestros ordenadores, el reparto de la CPU no suele resultar tan provechoso como
en el caso del maestro de ajedrez, pues a menudo, tambin hay procesos a los que

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

6LVWHPDV0XOWLSURFHVR
0iTXLQD0XOWLSURFHVDGRU
8Q3URFHVR

8Q3URFHVDGRU

0iTXLQD0RQRSURFHVDGRU
+D\TXHVLPXODUXQDPiTXLQDPXOWLSURFHVDGRU
6HXGRSDUDOHOLVPR

+D\TXHUHSDUWLUHOSURFHVDGRU

HQWUHORVSURFHVRV
3URFHVR

3URFHVR

3URFHVR

0XOWLSURFHVDGRU

0RQRSURFHVDGRUPXOWLSOH[DGR

3URFHVRHQHMHFXFLyQ
3URFHVRHQHVSHUD

6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

se les quita la posesin de la CPU antes de que ellos la liberen por una de sus
esperas a un evento externo, por lo que nos encontramos con procesos que estn
parados cuando s podran ejecutarse de tener una CPU disponible. En el peor de
los casos, es decir cuando se disponga de varios procesos que no tienen esperas
de E/S, la diferencia entre ejecutarlos en un entorno multiprocesador o
monoprocesador es la que se muestra en el grfico de la Figura 5, en la que se
aprecia que la CPU se reparte en porciones de tiempo entre los distintos procesos,
por lo que mientras uno se ejecuta, los dems deben esperar su turno de CPU. En
este caso decimos que la utilizacin de la CPU est PXOWLSOH[DGDHQHOWLHPSR.

 (VWDGRV\7UDQVLFLRQHVGHORV3URFHVRV
Anteriormente hemos visto que un ejemplo del FLFORGHYLGD de un proceso podra
estar caracterizado por esta secuencia:
1. Se est ejecutando (posee la CPU).
2. Realiza una operacin de E/S y se pone a esperar la respuesta (abandona la
CPU).
3. Cuando recibe la respuesta de la operacin de E/S desea continuar la
ejecucin (necesita otra vez la CPU).
Tambin hemos visto con anterioridad que en otras ocasiones, el tiempo de CPU se
reparte en porciones entre todos los procesos que lo solicitan, por lo que un proceso
puede ver cmo pierde la posesin del procesador, de forma involuntaria, cuando se
le acaba la porcin de tiempo que tena asignada.
Este ciclo de vida de un proceso lo podemos ver en la Figura 6. En esta figura, los
crculos son recursos o condiciones deseadas por un proceso, mientras que los
rectngulos representan las colas de procesos que esperan por tales recursos. As,
vemos que un proceso recin creado inmediatamente quiere ejecutarse, para lo cual
necesita la CPU, por lo que pasa a la cola de los procesos que esperan por el
procesador (cola de procesos SUHSDUDGRV). Una vez que le llega el turno, ejecuta
las instrucciones, hasta que por uno de los motivos mencionados (operacin de E/S,
fin de la porcin de tiempo, etc.) pierde la posesin de la CPU y pasa a la cola del
recurso solicitado (Disco 1, Unidad de Cinta 3, esperar a las 2:00 de la maana). Si
la posesin del procesador se ha perdido por finalizar la porcin de tiempo asignado
o bien porque un proceso de mayor prioridad requiere el procesador, el recurso que
necesita el proceso expulsado (o expropiado) es la propia CPU, por lo que pasa a la
cola correspondiente (la de los procesos preparados).
Este ciclo se repite una y otra vez hasta que el proceso ejecuta su ltima instruccin,
o sea, que finaliza el trabajo, con lo que voluntariamente cede el control de la CPU y
da por concluida su existencia como proceso.
As, llegamos ya al diagrama bsico de estados de un proceso, que lo vemos
representado en la parte superior de la Figura 7. En l tenemos que un proceso est
ejecutando instrucciones ((Q (MHFXFLyQ), esperando a que le concedan la CPU
$SXQWHVGH62,



*HVWLyQGH3URFHVRV

para ejecutar instrucciones (3UHSDUDGR), o esperando a que se produzca algn

evento externo ((Q(VSHUDoEORTXHDGR).

&LFORGH9LGDGHXQSURFHVR

6LVWHPDV0XOWLSURFHVR




&UHDFLyQ

35(3$5$'2

&38

7HUPLQDFLyQ

load
store
add
store
read fichero
(VSHUD(6

store
increment
write fichero
(VSHUD(6

load
store
add
store
read fichero
(VSHUD(6

([SXOVLyQ
3HULRGR
&38

3HULRGR
(6

'LVFR


',6&2

3HULRGR
&38
3HULRGR
(6

(VOD
KRUD

'RUPLGRKDVWD
ODV

3HULRGR
&38

&LQWD


&,17$

3HULRGR
(6



6LVWHPDV2SHUDWLYRV,

*HVWLyQGH3URFHVRV

Vamos a ver cmo se producen las transiciones entre estos tres estados.
&UHDFLyQ3UHSDUDGR
Inicialmente, al crear un proceso, no puede pasar directamente al estado de
Espera, pues no se ha ejecutado ninguna instruccin que as se lo indique; por
lo tanto, expresa su necesidad de ejecucin entrando en la cola de procesos
Preparados.
3UHSDUDGR(Q(MHFXFLyQ
Una vez que el proceso est preparado, solamente tiene que esperar a que le
llegue el turno. Los turnos del procesador se establecen en funcin de la
poltica de planificacin de la CPU. Cuando le llegue el turno tomar posesin
del procesador y empezar a ejecutar instrucciones.
Como podemos ver en el grfico, desde el estado de Ejecucin se puede pasar
a cualquiera de los otros dos estados (Espera y Preparado).



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

(VWDGRVGHO3URFHVR

6LVWHPDV0XOWLSURFHVR

(Q
(MHFXFLyQ

&UHDFLyQ

3UHSDUDGR

7HUPLQDFLyQ

(Q
(VSHUD

MAX_PROCESOS : constant 100;

type ID_PROCESOS is INTEGER range 0..MAX_PROCESOS;
type&2/$B352&(626is
record
Primero : ID_PROCESOS := 0;
Ultimo

: ID_PROCESOS := 0;

end record;

3URFHVRV : array [1..MAX_PROCESOS] of DESCRIPTOR_PROCESOS;

(QB(MHFXFLyQ : ID_PROCESOS;
3UHSDUDGRV

: COLA_PROCESOS;

(QB(VSHUD

: COLA_PROCESOS;

6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

(Q(MHFXFLyQ3UHSDUDGR
Pasar a Preparado si abandona la CPU involuntariamente, es decir si se le
expulsa (o expropia), bien porque haya terminado su porcin de tiempo, o
porque haya pasado a Preparado otro proceso de mayor prioridad.
(Q(MHFXFLyQ(VSHUD
En cambio, pasa al estado de Espera si cede voluntariamente el procesador,
por tener que esperar a que se produzca un evento externo a la CPU.
(VSHUD3UHSDUDGR
Desde el estado de Espera no se puede volver directamente a Ejecucin, sino
que cuando se haya cumplido el evento externo, para recuperar la posesin del
procesador hay que pasar de nuevo por la cola de los procesos preparados.
As tenemos que para conseguir la posesin de la CPU siempre hay que pasar
por su cola correspondiente (como un recurso ms que es).
(Q(MHFXFLyQ7HUPLQDFLyQ
Como ya hemos dicho antes, el proceso termina cuando ejecuta su ltima
instruccin, luego siempre pasar al estado de Terminado desde Ejecucin.

Como hemos visto, a medida que progresa su ejecucin, un proceso va cambiando

de estado. A excepcin de los estados obvios de &UHDFLyQ y 7HUPLQDFLyQ, un
proceso tiene dos estados bsicos: $FWLYR y (Q(VSHUD
$FWLYR

El proceso no depende de ninguna condicin externa al procesador

para poder continuar su ejecucin. O bien se est ejecutando, o se
encuentra esperando en la cola de procesos Preparados a que le
concedan la posesin de la CPU.

(Q(VSHUD El proceso no puede continuar la ejecucin. Est bloqueado, a la

espera de que se cumpla un evento externo a la CPU, tal como una
respuesta de un dispositivo de E/S, que llegue una hora determinada,
etc.

Vistos los estados que puede tener un proceso y las transiciones entre ellos, nos
interesa saber FyPR HO VLVWHPD RSHUDWLYR OOHYD FRQWURO GH WRGRV ORV SURFHVRV
FUHDGRV, cmo se realizan estas colas de procesos y cmo se sabe qu proceso
est en ejecucin.
En un apartado anterior hemos visto que hay una estructura de datos que contiene
toda la informacin de control que requiere el sistema operativo para ocuparse de la
gestin o administracin del proceso. Nos estamos refiriendo al Descriptor de
Proceso o Bloque de Control de Proceso (BCP). Pues bien, entonces lo que el
sistema operativo necesita es mantener la coleccin de todos los BCPs de los
procesos existentes en cada momento. Esta coleccin de BCPs se puede organizar
de distintas maneras: mediante una cola esttica, con una cola dinmica, o
simplemente utilizando una tabla, es decir, un vector o array de BCPs. As vemos


$SXQWHVGH62,

*HVWLyQGH3URFHVRV

(VWDGRVGHO3URFHVR

6LVWHPDV0XOWLSURFHVR

(1B(-(&8&,1

35(3$5$'26

%&3

%&3

%&3

%&3

3ULPHUR
OWLPR

'LVFR
3ULPHUR
OWLPR

&LQWD

%&3

3ULPHUR
OWLPR

%&3

7HUPLQDO
3ULPHUR
OWLPR


7DEOD
GH%&3V
6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,









6LJQLO 6LJQLO6LJ 6LJ 6LJQLO6LJQLO 6LJ6LJQLO6LJQLO



















*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

en el recuadro inferior de la Figura 7 la declaracin de Procesos como un array de

tamao Max_Procesos y formado por elementos de tipo Descriptor_Procesos.
De esta manera, el sistema operativo puede consultar el BCP de cada proceso
accediendo a la tabla Procesos utilizando el identificador del proceso como ndice.
Tambin se puede apreciar que la variable En_Ejecucion contiene el identificador
del proceso que actualmente se encuentra en posesin de la CPU. Por ltimo,
podemos observar la implementacin del estado de Preparado, o sea, una variable
de tipo Cola_Procesos (que hace de cabecera de una cola), que no es ms que
un registro con dos campos que indican, respectivamente, cul es el primero y el
ltimo elemento de una cola de procesos. Cada elemento de la cola de procesos es
un BCP, y si nos fijamos en su declaracin de la Figura 3 podemos ver que gracias
al campo Siguiente, que es el enlace, resulta fcil formar dicha cola. El campo
Siguiente contiene un identificador de proceso (el siguiente en la cola) o bien el
valor NIL si es el ltimo de la cola.
Habiendo visto cmo se construye la cola de Preparados, resulta fcil imaginar que
las colas de procesos para cada uno de los recursos por los que se puede esperar
(dispositivos de E/S, etc.) se implementan de igual forma.
En la Figura 8 se muestra un ejemplo del estado de los procesos en un momento
determinado. Por una parte tenemos que el proceso en Ejecucin es el 6, y que la
cola de los procesos Preparados est formada por los procesos 7 y 2. No hay
ningn proceso esperando para acceder al Disco_1, mientras que por la Cinta_3
estn esperando los procesos 3, 4 y 1. Por ltimo, tenemos al proceso 5 que est
esperando por el Terminal_1. En la parte inferior de esta Figura 8 tenemos la tabla
de BCPs en la que se pueden observar los valores que toman los campos
Siguiente para formar las colas de procesos de este ejemplo.

 &DPELRGH3URFHVRHQ(MHFXFLyQ&DPELRGH&RQWH[WR
Cuando un proceso en ejecucin pierde la posesin de la CPU, se debe a uno de
los siguientes motivos:
Llamada al sistema
Interrupcin
Fin del proceso
Est claro que ante ciertas llamadas al sistema (una peticin de E/S, dormir, etc.) el
proceso en cuestin queda bloqueado, sin poder continuar la ejecucin de
instrucciones, hasta que se atienda el servicio solicitado; por esto, cede la posesin
del procesador para que pueda ejecutar instrucciones otro proceso que est
preparado.
Tambin puede ocurrir que una interrupcin anuncie el final de la actual posesin
del procesador. Esto ser as si la interrupcin es la generada por el reloj del
sistema y se detecta que se ha consumido la porcin de tiempo asignada (en un



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

6LVWHPDV0XOWLSURFHVR

&DPELRGH3URFHVR

HQHMHFXFLyQ

+//$0$'$$/6,67(0$

0RWLYRV
+,17(5583&,1
GHO&DPELR

3HWLFLyQGH(6
'RUPLU

)LQGHODURGDMDGHWLHPSR
6HSUHSDUDXQSURFHVRGH
PD\RUSULRULGDG

+),1'(/352&(62
&DPELRHQ'RV)DVHV

6HOHFFLRQDUHO6LJXLHQWH3URFHVR
3/$1,),&$'25

&DPELDUHO&RQWH[WRGH(MHFXFLyQ
',63$7&+(5

(O&DPELRGH3URFHVR&RQVXPH7LHPSR

0LQLPL]DUORV&DPELRVGH3URFHVRV

6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

sistema de tiempo compartido); o bien la interrupcin la ha generado algn

dispositivo de E/S indicando el fin de una operacin previamente solicitada, con lo
que el proceso que la haba requerido sale de su situacin de espera y pasa al
estado de Preparado. En un entorno de planificacin de CPU por prioridades, si este
proceso que acaba de pasar a Preparado tiene mayor prioridad que el que est en
Ejecucin, se le quita a ste ltimo el procesador para asignrselo al proceso de
mayor prioridad.
Por ltimo, el motivo trivial de prdida de procesador se debe a que el proceso en
Ejecucin llega a su fin. Detectado esto, el sistema operativo asigna la CPU a algn
proceso preparado.
Si un proceso pierde el control de la CPU habr que asignrselo a otro proceso!
Efectivamente, y hay que realizarlo en dos pasos:
1 Seleccionar el siguiente proceso
2 Realizar el cambio de contexto
De realizar el primer paso se encarga el SODQLILFDGRU (o VFKHGXOHU), que utilizando la
poltica establecida de planificacin a corto plazo selecciona un proceso de la cola
de Preparados. Esta poltica de SODQLILFDFLyQDFRUWRSOD]Restablece la asignacin
de la CPU a uno de los procesos preparados, mientras que la poltica de
SODQLILFDFLyQDODUJRSOD]R se utiliza para elegir uno de los trabajos que estn en el
disco duro esperando para ser cargados en memoria y comenzar su ejecucin.
Una vez conocido el identificador del proceso que va a apropiarse de la CPU, hay
que cederle el control del procesador, pero no antes de realizar el cambio de
contexto. Para esto, se da control al 'LVSDWFKHU, que es la parte del sistema
operativo que se encarga de terminar de salvar el contexto del programa que
abandona la CPU (o perderlo definitivamente si se debe a una terminacin del
proceso) y establecer el contexto del proceso seleccionado. De hecho, el ltimo de
los pasos de que consta el cambio completo del contexto, consiste en restaurar el
Contador de Programa del proceso elegido. Una vez que el registro Contador de
Programa es restaurado, la siguiente instruccin que se ejecuta es ya una
instruccin del proceso seleccionado.
La Figura 12 muestra una secuencia completa de dos cambios de contexto. El
primero se debe a la prdida de la CPU del Proceso A en favor de Proceso B,
mientras que en el segundo cambio, el Proceso A recupera el procesador. Veamos
con cierto detalle un posible algoritmo que realiza este cambio de contexto. No
obstante, este grado de detalle dista bastante de ser completo, ya que para ello
habra que particularizar las operaciones el cambio de contexto para un procesador
concreto y un conjunto dado de Llamadas al Sistema.
Llamada al sistema o interrupcin de un dispositivo. En cualquier caso, esto
implica automticamente una copia del REGISTRO DE ESTADO y del
CONTADOR DE PROGRAMA a la Pila del proceso en ejecucin, al que
llamaremos Proceso A.
Se comienza a realizar el servicio solicitado o el tratamiento de la interrupcin.


$SXQWHVGH62,

*HVWLyQGH3URFHVRV

(O3ODQLILFDGRU

&DPELRGH3URFHVR

6HOHFFLRQDHO6LJXLHQWH3URFHVRD(MHFXWDU
6HJ~QOD3ROtWLFDGH3ODQLILFDFLyQ

12(;38/625(6

(;38/625(6

3),)2
3(OPiVFRUWRHOSULPHUR
33ULRULGDGHV

35RXQG5RELQ
33ULRULGDGHV

),1'(/$52'$-$
'(7,(032

-- Actualizar el final de la cola Preparados.

Procesos(Preparados.Ultimo).Siguiente := En_Ejecucin;
Preparados.Ultimo := En_Ejecucin;
-- Seleccionar un proceso.
Proceso_Seleccionado := Preparados.Primero;
-- Actualizar el principio de la cola Preparados.
Preparados.Primero := Procesos(Preparados.Primero).Siguiente;
-- Cambiar el contexto del procesador.
Dispatcher;

6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

Se salvan todos los registros del procesador en la Pila del proceso actualmente
en ejecucin (el A). A excepcin del REGISTRO DE ESTADO (RE), CONTADOR
DE PROGRAMA (CP) y PUNTERO DE PILA (PP).
Tras decidir que el proceso en ejecucin debe abandonar la CPU, el Planificador
elige el proceso que pasar a Ejecucin, al que nos referiremos como Proceso
B.
Se llama al 'LVSDWFKHU y comienza el cambio de contexto. Se producen las
siguientes acciones:
1. El Puntero de Pila del proceso A se guarda en su Descriptor de Proceso.
2. Se carga el Puntero de Pila a partir del PP guardado en el Descriptor del
Proceso B. Ahora la Pila de trabajo es la del proceso B
3. Se cargan todos los registros generales del procesador a partir de los datos
contenidos en la Pila, a excepcin del RE, el CP y el PP.
4. El valor que queda en la cima de la Pila es la direccin de vuelta del ltimo
punto en el que se llam al Dispatcher cuando el proceso B perdi el control de
la CPU.
5. Se actualiza la variable En_Ejecucin con Proceso_Seleccionado.
6. El Dispatcher termina. Al ejecutar la instruccin de RETORNO DE SUBRUTINA,
se devuelve el control al punto en el que se haba llamado al Dispatcher para
que el proceso B perdiese el control del procesador.
7. El sistema operativo termina de realizar el servicio que el Proceso B le haba
solicitado, por lo que ejecuta la instruccin mquina RETORNO DE
INTERRUPCIN. Esta instruccin origina que se cargue el REGISTRO DE
ESTADO y el CONTADOR DE PROGRAMA con los dos datos que se sacan de la
cima de la Pila.
8. Con el nuevo CONTADOR DE PROGRAMA, la instruccin que se ejecuta es la
siguiente al punto en el que el proceso B realiz una Llamada al Sistema (lo
que supuso su paso a Espera).

Ya hemos visto que el cambio de CPU de un proceso a otro requiere una serie de
acciones que se encargan de realizarlas el Planificador y el 'LVSDWFKHU. Pues bien,
estas acciones se ejecutan en un tiempo que, desde luego, no es nulo. La eleccin
del proceso a ejecutar suele ser muy simple y no supone una prdida de tiempo
considerable; pero el cambio de contexto s puede acarrear una gran cantidad de
instrucciones, incluidas operaciones de E/S si los contextos de memoria de los
procesos que intervienen hay que salvarlos y traerlos, respectivamente, del disco
duro, cosa que suele realizarse en los actuales sistemas con Memoria Virtual.
No es deseable, en absoluto, que el tiempo dedicado al cambio de proceso sea
considerable. Pensemos en un caso exagerado : si el 20% de las instrucciones
ejecutadas en la CPU son las dedicadas a realizar el cambio de ejecucin de dos
procesos, esto quiere decir que a las instrucciones de los programas del usuario



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

( O' L V S D W F K H U

& D P E LR G H 3 U R F H V R

( V H O( Q F D U J D G R G H & H G H U
H O& R Q W U R OG H  OD & 3 8 D O3 U R F H V R
6 H OH F F LR Q D G R S R U H O3 OD Q L I LF D G R U

6 X V  $ F F L R Q H V  % i V L F D V 6 R Q 

7 H U P LQ D U G H V D OY D U H OF R Q W H [ W R G H O
3 U R F H V R $ F W X D OP H Q W H H Q ( M H F X F L y Q

( V W D E OH F H U H O3 X Q W H U R  G H 3 LOD G H O 1 X H Y R
3 U R F H V R T X H 3 D V D D ( M H F X F Ly Q

5 H V W D X U D U OR V 5 H J L V W U R V G H  OD & 3 8 D
3 D U W L U G H  OD  1 X H Y D 3 L OD  H [ F H S W R  & 3 \ 5 ( 

57(

 5 H V W D X U D 5 (

P R G R X V X D U L R

 5 H V W D X U D & 3

6 LV W H P D V 2 S H U D W LY R V ,

* H V W Ly Q G H 3 U R F H V R V  

solamente se le dedica el 80% del tiempo de CPU, mientras que, claramente, lo ms

deseable es que se acercara lo ms posible al 100%.
De la observacin anterior se deduce que conviene:
- minimizar el nmero de cambios de proceso,
- o minimizar las operaciones del cambio de contexto.
Esta conclusin la tendremos presente en los siguientes apartados, en los que
vamos a tratar ms a fondo las acciones concretas del Dispatcher y algunas de las
polticas ms comunes de planificacin de CPU.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

&DPELRGH3URFHVR

6LVWHPDV0XOWLSURFHVR

352&(62
$
HQHMHFXFLyQ

6,67(0$
23(5$7,92
S
int. o

352&(62
%

all
ys_c

SUHSDUDGR
6DOYDU
5HJLVWURV3B$

HQHVSHUD





6HOHFFLRQDU
3URFHVR
&DUJDU
5HJLVWURV3B%

HQHMHFXFLyQ
SUHSDUDGR

int. o
S

ys_ca
ll

6DOYDU
5HJLVWURV3B%





HQHVSHUDR
SUHSDUDGR

6HOHFFLRQDU
3URFHVR
&DUJDU
5HJLVWURV3B$

HQHMHFXFLyQ

6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

 3URFHVR2FLRVR
Veamos ahora una situacin, a primera vista comprometida, que se puede dar en un
sistema multiproceso. Sabemos que cuando un proceso cede voluntariamente el
control de la CPU, el Planificador tiene que elegir otro proceso de usuario que est
preparado, pero
Qu pasa si no hay ningn proceso Preparado?
Si no hay ningn proceso que quiera ejecutar instrucciones qu hace la CPU?
Esta situacin no solamente es perfectamente posible, sino que se da con mucha
frecuencia. En un sistema con cinco usuarios qu impide que en un instante
determinado cuatro de los procesos estn esperando una respuesta del disco duro,
la llegada de un carcter por una lnea de comunicaciones, o que llegue una hora
determinada? La respuesta es: nada. Pues si en este momento el proceso del
quinto usuario tambin realiza una peticin a un dispositivo de E/S, tambin pasa a
Espera. En este momento el Planificador tendra que seleccionar un proceso de la
cola de Preparados, para darle el control, pero ya no hay ms procesos! qu va a
hacer la CPU mientras todos los procesos estn en Espera?
Hemos mencionado solamente los procesos de usuario, pero tambin hay procesos
del sistema operativo que pueden estar realizando servicios que se les haya
solicitado con anterioridad, por ejemplo, imprimiendo un fichero. De cualquier forma,
tampoco hay nada que impida que en un momento dado no haya ningn proceso
con necesidad de ejecutar instrucciones.
Para estos casos, en todos los sistemas suele haber un proceso del sistema
denominado 3URFHVR2FLRVR. Este proceso consta de un bucle infinito ejecutando
un algoritmo muy sencillo (puede ser incluso la instruccin 1R2SHUDFLyQ) en el que
no figura ninguna instruccin que pueda generar un paso a Espera. El proceso
ocioso puede estar continuamente realizando estudios estadsticos de utilizacin del
sistema, calculando decimales del numero , o cualquier trabajo infinito de la menor
prioridad. De esta forma, siempre tendremos un proceso Activo.
Diremos que la CPU est ociosa cuando est ejecutando el Proceso Ocioso.
Los procesadores suelen disponer de la instruccin HALT (o WAIT), la cual hace
que se detenga la ejecucin de instrucciones en la CPU, es decir, se deja de extraer
instrucciones de la memoria, y la CPU pasa al estado 'HWHQLGR, en el que
permanece hasta que se produce una interrupcin, pues en ese momento el
procesador la atiende y comienza a ejecutar las instrucciones de su rutina de
tratamiento.

 3ODQLILFDFLyQGH3URFHVRV
Habiendo visto el ciclo de vida de los procesos, sabemos que un proceso que se
est ejecutando, eventualmente, por diversos motivos que se han comentado,
abandona la posesin del procesador voluntaria o involuntariamente, por lo que hay

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

que cederle la CPU a un proceso que sea lgicamente ejecutable, es decir, que est
Preparado. Si hay ms de un proceso Preparado, el sistema operativo debe decidir
cul de ellos se ejecutar primero. La parte del sistema operativo que le
corresponde tomar tal decisin es el 3ODQLILFDGRU, que seleccionar un proceso
basado en una poltica o algoritmo de planificacin.
El estado de Preparado se implementa como una cola de procesos dispuestos a
ejecutar instrucciones con ayuda de la CPU. Ahora bien, debemos a aclarar que
esta cola no tiene por que ser una cola FIFO (Primero en Entrar, Primero en Salir),
tambin podra ser una cola ordenada por prioridades, un rbol o, simplemente, una
lista desordenada. El Planificador debe seleccionar uno de los procesos de la lista,
pero no basndose necesariamente en la propia estructura de la lista. La estructura
de la lista nicamente debe ayudar al Planificador a aplicar el algoritmo de
planificacin.

 &ULWHULRV
Antes de ver algoritmos concretos de planificacin debemos recordar, que la
eleccin que el Planificador va a realizar debe hacerse persiguiendo el bien del
sistema, pues es uno de los cometidos del sistema operativo. No obstante, distintas
polticas de planificacin tienen diferentes propiedades, y favorecen ms a un tipo
de procesos que a otros. Antes de elegir el algoritmo a utilizar en una situacin
concreta, debemos considerar las propiedades de varios algoritmos.
Se han sugerido muchos criterios para comparar algoritmos de planificacin de
CPU. Decidir las caractersticas que se van a utilizar en la comparacin es
fundamental para la eleccin del algoritmo ms apropiado. Veamos los criterios de
comparacin ms comnmente utilizados:
-XVWLFLD. Cada proceso debe conseguir su porcin correspondiente de CPU en
un tiempo finito.
(ILFLHQFLD. Se debe intentar mantener la CPU ocupada el mayor tiempo posible.
Al decir ocupada queremos decir ejecutando cualquier proceso que no sea el
Proceso Ocioso. En un sistema real, el porcentaje de utilizacin de CPU suele
estar en el rango 40-90%. Una utilizacin mayor del 90% significara que el
Planificador siempre encuentra procesos en la cola Preparados, o sea, que dicha
cola suele contener un nmero considerable de procesos. En un sistema
interactivo, esto puede suponer que los usuarios quizs se estn impacientando
por obtener las respuestas.
7LHPSRGH5HWRUQR (WXUQDURXQGWLPH). Desde el punto de vista de un proceso, el
criterio ms importante es cunto tiempo se va a necesitar para ejecutarse
completamente. El Tiempo de Retorno es la suma de los periodos que se pasan
esperando a cargarse en memoria, esperando en la cola de Preparados,
ejecutndose en la CPU, y esperando por operaciones de E/S. As pues, se debe
minimizar el tiempo de retorno de un proceso. Afecta principalmente a los
procesos EDWFK.
7LHPSRGH(VSHUD El algoritmo de planificacin de CPU no afecta a la cantidad
de tiempo que un proceso se pasa realizando operaciones de E/S, solamente


$SXQWHVGH62,

*HVWLyQGH3URFHVRV

6LVWHPDV0XOWLSURFHVR

3ODQLILFDFLyQGH3URFHVRV

(O3ODQLILFDGRUVH(QFDUJDGH6HOHFFLRQDU
HO3URFHVRTXH3DVDD(MHFXFLyQ
\'HFLGH6HJ~QXQD3ROtWLFD
%DVDGDHQ$OJXQRV&ULWHULRV
-XVWLFLD

7LHPSRGH5HVSXHVWD

(ILFLHQFLD

7LHPSRGH(VSHUD

7LHPSRGH5HWRUQR

5HQGLPLHQWR

3ROtWLFDVGH3ODQLILFDFLyQ

1R([SXOVRUDV
EDWFK

3(O3ULPHURHQ/OHJDU
3(O0iV&RUWR3ULPHUR
33RU3ULRULGDGHV

([SXOVRUDV
PXOWLXVXDULR\
WLHPSRUHDO

37LHPSR&RPSDUWLGR
5RXQG5RELQ
33RU3ULRULGDGHV
30~OWLSOHV&RODV
30~OWLSOHV&RODV
5HDOLPHQWDGDV

6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

afecta al tiempo que un proceso se pasa en la cola Preparados. El Tiempo de

Espera es la suma de todos los momentos que un proceso pasa en la cola de los
procesos preparados.
7LHPSR GH 5HVSXHVWD. En un sistema interactivo, el Tiempo de Retorno puede
no ser un buen criterio. A menudo, un proceso puede producir algunos resultados
al principio, y puede continuar calculando nuevos resultados mientras los
anteriores se le muestran al usuario. As, tenemos que otra medida es el tiempo
que transcurre desde que se le hace una peticin al sistema hasta que empieza a
responder, sin tener en cuenta el tiempo que se tarda en mostrar la respuesta
completa.
5HQGLPLHQWR. Se debe maximizar el nmero de trabajos procesados por unidad
de tiempo.
Es deseable maximizar la utilizacin de la CPU y minimizar los tiempos de retorno,
de espera y de respuesta, todo ello con la mayor justicia para todos los procesos.
Sin embargo, es fcil observar que algunos de estos criterios son contradictorios.
Por ejemplo, para que en los procesos interactivos el tiempo de respuesta sea
bueno, se puede impedir que se ejecuten procesos batch por el da, reservando
para stos las horas nocturnas en las que no suele haber usuarios en los terminales.
Esto no les sentar muy bien a los usuarios que han encargado trabajos en batch,
pues ven que el tiempo de retorno se incrementa. Como en otros aspectos de la
vida, lo que beneficia a unos, perjudica a otros; as que, en cualquier caso, no habr
que olvidarse nunca del criterio que hace referencia a la justicia.
En pro de la justicia, en la mayora de los casos se suelen optimizar los valores
medios, no obstante, bajo algunas circunstancias, es deseable optimizar los
mnimos o los mximos valores, en lugar de la media. Por ejemplo, para garantizar
que todos los usuarios obtienen un buen servicio, lo que se desea es minimizar el
tiempo mximo de respuesta.
Tambin se ha sugerido que, en los sistemas interactivos, es ms importante
minimizar la varianza en el tiempo de respuesta, que minimizar su valor medio. Es
preferible un sistema con un tiempo de respuesta razonable y predecible, que otro
que aunque por trmino medio resulte ms rpido, sea altamente variable.

 3ROtWLFDVGH3ODQLILFDFLyQ
En los diagramas de estados de los procesos, vimos que cuando un proceso en
Ejecucin abandona tal estado pasa a Espera o a Preparado, dependiendo si deja el
procesador voluntaria o involuntariamente. Si los procesos de un sistema nunca
dejan la CPU de forma involuntaria, se dice que la poltica de planificacin de CPU
es QRH[SXOVRUD o no expropiativa (QRQSUHHPSWLYHVFKHGXOLQJ). Por el contrario, si
pueden perder la posesin del procesador sin solicitarlo, nos encontramos con una
planificacin H[SXOVRUD o expropiativa (SUHHPSWLYHVFKHGXOLQJ).



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

Las polticas no expulsoras suelen aplicarse en sistemas batch o en pequeos

entornos monousuario, como el sistema operativo MS-DOS o el entorno
Windows-95/98, ambos de Microsoft. Algunos algoritmos que se emplean en esta
planificacin son SULPHUR HQ OOHJDU  SULPHUR HQ VHUYLU, HO PiV FRUWR SULPHUR, y SRU
SULRULGDGHV.
Por otra parte, los algoritmos expropiativos se utilizan en sistemas de control
industrial y entornos multiusuario. Los algoritmos ms utilizados aqu incluyen
5RXQG5RELQ, SRUSULRULGDGHV, de P~OWLSOHVFRODV y de P~OWLSOHVFRODVUHDOLPHQWDGDV
(como es el caso de Unix y Windows/NT).
Veamos a continuacin algunos comentarios sobre estos algoritmos.
3ULPHURHQOOHJDU3ULPHURHQVHUYLU
Este algoritmo, cuyo nombre abreviaremos con FCFS ()LUVW&RPH)LUVW6HUYHG),
es, con mucho, el algoritmo ms simple. Segn este esquema, el primer proceso
que reclama la CPU, es el primero en conseguirla. En cuanto a la
implementacin, no merece la pena dar muchas explicaciones, pues basta con
mantener, por ejemplo, una cola FIFO de los descriptores de los procesos que
van solicitando la CPU.
El tiempo medio de espera es muy variable y raramente es el mnimo. En el
grfico superior de la Figura 14 se muestra un caso que segn ese orden de
llegada, resulta un tiempo medio de espera de 17 ms. En cambio, si el orden de
llegada de los trabajos o procesos hubiera sido T2, T3, T1, se puede comprobar
que habra dado lugar a un tiempo medio de espera de 3 ms.
Otro problema que puede aparecer al aplicar este algoritmo se da en el siguiente
escenario. Supongamos un sistema con esta poltica FCFS en el que hay un
proceso (Proceso-CPU) que consume grandes porciones de CPU y realiza pocas
operaciones de E/S. Por el contrario, hay muchos otros procesos con un ciclo en
el que realizan frecuentes operaciones de E/S y ejecutan muy pocas
instrucciones sobre la CPU (Procesos-E/S). Mientras el Proceso-CPU se ejecuta,
los Procesos-E/S acabarn sus operaciones con los dispositivos perifricos y
pasarn a la cola Preparados, quedando libres los dispositivos de E/S. En algn
momento, el Proceso-CPU acabar por realizar una operacin de E/S y pasar a
Espera. Los Procesos-E/S, que necesitan poca CPU se ejecutan rpidamente y
vuelven a las colas de espera de los perifricos de E/S. La CPU queda ociosa. El
Proceso-CPU finaliza la operacin de E/S y vuelve a tomar control del
procesador. Otra vez, los Procesos-E/S terminarn sus operaciones de E/S y
pasarn a Preparados, esperando todos a que el Proceso-CPU realice otra
operacin de E/S. Cuando se produce esta situacin, en la que muchos procesos
que necesitan poca CPU esperan por uno que consume mucho tiempo de
procesador, se denomina HIHFWR FRQYR\. Este efecto provoca una menor
utilizacin de la CPU y de los perifricos de la que se podra conseguir si se
concediese la posesin de la CPU a los procesos que requieren poco tiempo de
procesador, en lugar de cedrselo a un proceso que va a hacer esperar mucho
tiempo a muchos procesos.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

3ROtWLFDVGH3ODQLILFDFLyQ

6LVWHPDV0XOWLSURFHVR

(O3ULPHURHQ/OHJDU3ULPHURHQ6HUYLU
J(VVLPSOH
L7LHPSRGHHVSHUDYDULDEOH5DUDPHQWHHOPtQLPR
L'HVDSURYHFKDORVGLVSRVLWLYRVGH(6
7UDEDMR




7LHPSRQHFHVDULR




7UDEDMR

7U 7U







7LHPSRPHGLRGHHVSHUD  

(O0iV&RUWRHO3ULPHUR
J2IUHFHVLHPSUHHOPtQLPRWLHPSRPHGLRGHHVSHUD
7UDEDMR




7U 7U


7LHPSRQHFHVDULR




7UDEDMR




7LHPSRPHGLRGHHVSHUD  

J(VySWLPR
L&XiOHVODQHFHVLGDGUHDOGHOWUDEDMR"
0iVXWLOL]DGRHQODSODQLILFDFLyQDODUJRSOD]R
6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

(OPiVFRUWRSULPHUR
Este algoritmo, tambin conocido como SJF (6KRUWHVW-RE)LUVW), concede la CPU
al proceso que durante menos tiempo necesita la CPU de forma ininterrumpida.
Debe quedar claro que se selecciona el que menor porcin de tiempo de CPU
necesita en el momento de hacer la eleccin, no aquel cuyo tiempo total de CPU
es el menor de todos. Si dos procesos necesitan el procesador durante el mismo
tiempo, se elige uno mediante FCFS.
En la parte inferior de la Figura 14 tenemos la aplicacin de este algoritmo a
nuestro ejemplo. Como se puede ver, consigue el menor tiempo de espera
posible. Poniendo a un proceso corto por delante de uno largo, se decrementa el
tiempo de espera del corto ms de lo que se incrementa el del largo.
Consecuentemente, el tiempo medio decrece.
Este algoritmo, probablemente el ptimo, se comporta bien en la planificacin a
largo plazo de los procesos batch, en los que se conocen los requisitos de tiempo
total de CPU indicados por el usuario; pero en la planificacin de la CPU se
presenta el problema de que en el momento en que hay que asignar la CPU, no
hay forma de conocer a priori la porcin de tiempo que necesita cada proceso,
por lo que es difcilmente implementable. Se puede intentar una aproximacin al
SJF puro, haciendo una estimacin de la porcin necesaria basndose en
estadsticas de ejecuciones anteriores.

5RXQG5RELQ
Este algoritmo est especialmente diseado para los sistemas multiusuario de
tiempo compartido. Es similar al FCFS, pero se le aade la expropiacin de la
CPU cuando la posesin continuada de sta sobrepasa un tiempo preestablecido
(SRUFLyQGHWLHPSR), que suele ser del orden de 10 a 100 milisegundos.
La implementacin de este algoritmo se realiza con una cola FIFO para los
procesos Preparados. Los nuevos procesos se aaden al final de la cola. Cuando
el planificador tiene que seleccionar un proceso, elige el primero de la cola,
establece una temporizacin correspondiente a la porcin de tiempo, y le cede el
control. Ahora pueden ocurrir dos cosas:
1) El proceso termina o realiza una operacin de E/S antes de que se acabe su
porcin de tiempo, en cuyo caso cede la CPU voluntariamente, pasa a espera
y el planificador selecciona el siguiente proceso de la cola Preparados.
2) El proceso se ejecuta hasta dar lugar a que venza la temporizacin
establecida. En este caso, el dispositivo temporizador genera una interrupcin
que captura el sistema operativo, dando lugar a que se le expropie la CPU al
proceso en ejecucin, que pasa al final de la cola Preparados, y a que el
planificador seleccione al primer proceso de la cola para pasar a ejecucin.
Ya habamos comentado anteriormente la falta de eficiencia que pueden causar
los cambios continuos del proceso en ejecucin. En el caso de que la poltica de
planificacin del procesador sea por Prioridades de los procesos, se nos hace
imposible establecer la frecuencia de los cambios, pues vendr impuesta por los

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

6LVWHPDV0XOWLSURFHVR

 3ROtWLFDVGH3ODQLILFDFLyQ

7LHPSR&RPSDUWLGR5RXQG5RELQ
3URFHVR
3URFHVR
3URFHVR

3URFHVRHQHMHFXFLyQ
3URFHVRHQHVSHUD
7UDEDMR




7LHPSRQHFHVDULR




7U 7U7U 7U





7U


7U 7U






(O5HQGLPLHQWRGHO6LVWHPD
'HSHQGHGHOD3RUFLyQGH7LHPSR

*UDQGH

3HTXHxD

6RORKD\
FDPELRVGHFRQWH[WR

6LVWHPDV2SHUDWLYRV,



)&)6

*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

fenmenos externos que afectan a los procesos correspondientes. En cambio, si

la planificacin es por Tiempo Compartido, s est en nuestra mano establecer
porciones de tiempo de CPU muy grandes, tal que en una unidad de tiempo se
produzcan muy pocos cambios del proceso en ejecucin. Sin embargo, esto no
resulta tan fcil de decidir, pues si la porcin de tiempo se hace muy grande, el
aprovechamiento de la CPU por parte del usuario se ve altamente incrementada,
pero, por contra, tambin ocurrir que los usuarios de los terminales notarn que
se les tarda mucho en atender, pues se ha degenerado en una poltica FCFS.
Por el contrario, si la porcin se hace muy pequea, se les atiende enseguida,
pero durante muy poco tiempo, con la consiguiente degradacin en el
aprovechamiento de la CPU por parte del usuario.
3RU3ULRULGDGHV
Uno de los factores a tener en cuenta en la planificacin de los procesos es la
justicia, pero justicia no siempre significa un reparto a partes iguales, sino la
asignacin ms conveniente que aconsejen las circunstancias. As, por ejemplo,
tenemos que en un programa de control y supervisin de una central nuclear,
compuesto por diversos procesos, no se debe esperar que todos los procesos
cuenten inexcusablemente con la misma porcin de tiempo de CPU, ni segn un
turno circular. Evidentemente, no es tan importante el proceso interactivo que se
encarga de mostrar a los visitantes un vdeo de la historia de la central y
responder a sus preguntas, como los procesos encargados de supervisar los
niveles de presin, temperatura, radioactividad, etc., y que en caso de que se
sobrepasen los lmites de seguridad activan las vlvulas y avisos
correspondientes.
Los criterios para establecer las prioridades pueden ser variados: por razones
fsicas, como en el caso de los sistemas de tiempo real, por rangos o categoras
de los usuarios (sistemas multiusuarios), por factores polticos, etc. En sistemas
multiusuario, es muy comn tener prioridades por grupos de trabajo o
departamentos, y a los procesos de la misma prioridad aplicarles una poltica
reparto de tiempo compartido.
Este algoritmo puede ser H[SXOVRU o QR H[SXOVRU. Cuando un proceso llega a la
cola Preparados, se compara su prioridad con la del proceso en ejecucin. Con
un algoritmo expulsor por prioridades, si la prioridad del recin llegado es mayor
que la del proceso en ejecucin, se le expropia la CPU a este ltimo en favor del
recin llegado. Si la poltica es no expulsora, simplemente se coloca al nuevo
proceso a la cabeza de la cola. El algoritmo SJF es un caso particular de este
algoritmo con poltica no expulsora, donde la prioridad es la inversa del tiempo
requerido de CPU.
Un problema que se puede dar con este tipo de algoritmos de planificacin es el
bloqueo indefinido o LQDQLFLyQ. Un proceso que est preparado, pero que no
adquiere la CPU, se puede decir que est bloqueado en espera de procesador.
Pues bien, con un algoritmo por prioridades puede darse el caso de dejar a un
proceso de baja prioridad esperando indefinidamente por el procesador si
siempre hay algn proceso de alta prioridad que puede colarse. (Existe el rumor
de que cuando en 1973 se paro el sistema IBM 7094 del Instituto Tecnolgico de

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

Massachusetts para sustituirlo por otro, se encontr un proceso que llevaba en

espera de CPU desde que se haba creado en 1967 y todava no haba podido
llegar a ejecutarse por primera vez.)
Una primera aproximacin al problema de la inanicin en sistemas con
prioridades, puede consistir en repartir la CPU entre los procesos de la misma
prioridad, es decir, tener una poltica de tiempo compartido dentro de cada cola
de prioridad.
Una tcnica ms refinada es la del HQYHMHFLPLHQWR. Con esta sistema, la
prioridad de los procesos preparados se incrementa gradualmente a medida que
esperan en la cola Preparados, donde permanecen hasta alcanzar,
inevitablemente, la prioridad necesaria para conseguir la CPU.

6 LV W H P D V 0 X OW LS U R F H V R

 3 R OtW L F D V  G H 3 OD Q L I L F D F Ly Q

3 U L R U LG D G H V  H [ S X OV R U D V 
+ / R V  3 U R F H V R V 7 L H Q H Q 3 U L R U LG D G H V
7 R P D H O & R Q W U R OG H OD & 3 8  L Q P H G L D W D P H Q W H 
H O3 U R F H V R G H 0 D \ R U 3 U L R U LG D G 

$ 3/,&$ &,2 1 (6

* U X S R V  G H 3 H U V R Q D V
 F D W H J R U tD V 

& X L G D G R F R Q  OD
, Q D Q L F Ly Q
6 2 /8 &,2 1 (6


 3 5 R X Q G  5 R E LQ S R U S U L R U LG D G H V
 3  3 U LR U L G D G H V
G LQ i P L F D V

6 LV W H P D V 2 S H U D W LY R V ,



7 LH P S R  5 H D O

( Q Y H M H F LP LH Q W R

* H V W Ly Q G H 3 U R F H V R V  

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

0~OWLSOHVFRODV
Existe otro tipo de algoritmos para situaciones en las que los procesos estn
claramente clasificados en diferentes grupos. Por ejemplo, una divisin muy
comn es la que se hace entre procesos interactivos de primer plano (IRUHJURXQG)
y los procesos batch que suelen ejecutarse en un segundo plano (EDFNJURXQG).
Estos dos tipos de procesos tiene distintos requisitos en sus tiempos de
respuesta, por lo que podran tener distintos algoritmos de planificacin cada uno.
Adems, los procesos interactivos podran tener mayor prioridad que los se
ejecutan en un segundo plano.
Para esto, la cola Preparados podra estar dividida en varias colas separadas,
una por cada tipo de proceso. Cada proceso siempre se encola en su cola
correspondiente. As nos encontramos con que para elegir la cola de la que se va
a sacar un proceso se utiliza una poltica, mientras que para seleccionar qu
proceso se va a sacar de la cola elegida, se utiliza un algoritmo distinto. Tambin
puede ocurrir que en dos colas distintas se utilice la misma poltica de
planificacin, por ejemplo, tiempo compartido, pero que la porcin de tiempo sea
distinta en una cola que en otra.

0~OWLSOHVFRODVUHDOLPHQWDGDV
Una mezcla de las tcnicas de envejecimiento y de las mltiples colas, resulta en
las mltiples colas realimentadas.
Las distintas colas pueden tener polticas de tiempo compartido, pero las ms
prioritarias poseen una mayor porcin de tiempo. Cuando un proceso lleva mucho
tiempo en una cola de poca prioridad, se le pasa a otra cola de mayor prioridad,
consiguiendo as mayores porciones de tiempo.

 3ODQLILFDFLyQHQ6LVWHPDV0XOWLSURFHVDGRU
Hasta ahora hemos tratado con algoritmos de asignacin de CPU en sistemas con
un solo procesador. Si se dispone de mltiples procesadores, la planificacin se
vuelve bastante ms compleja.
Al igual que en el caso de los sistemas monoprocesador, no existe la solucin
ptima, sino que sta depende de varios factores, y siempre hay unos procesos
beneficiados y otros perjudicados. Vamos a tratar simplemente algunos conceptos
generales sobre la planificacin de mltiples CPUs. Un estudio en profundidad de
este apartado puede encontrarse en literatura sobre arquitecturas avanzadas y
paralelas.
Cuando todos los procesadores de un sistema tienen la misma funcionalidad
(VLVWHPD KRPRJpQHR), cualquier procesador disponible puede utilizarse para
ejecutar un proceso preparado. Pero si los procesadores son distintos (VLVWHPD
KHWHURJpQHR), slo los programas compilados para un procesador determinado
pueden ejecutarse en ese procesador. Este es el caso de los sistemas distribuidos.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

3ODQLILFDFLyQ

&RQ0~OWLSOHV3URFHVDGRUHV
/RVSURFHVDGRUHVSXHGHQVHU

',)(5(17(6
6LVWHPD+HWHURJpQHR

,*8$/(6
6LVWHPD+RPRJpQHR

&DGDSURFHVDGRUWLHQHVX
SURSLDFROD\VXSURSLD
SODQLILFDFLyQ

9DULDVFRODV"
L&DUJDGHVHTXLOLEUDGD

&DGDSURFHVRVHDVLJQDDO
WLSRGHSURFHVDGRUTXHOH
FRUUHVSRQGH

$XWRSODQLILFDFLyQ
8QSURFHVDGRUOLEUHVDFD
XQSURFHVRGHODFROD
&8,'$'2

6LVWHPDV2SHUDWLYRV,



'HEHKDEHUXQD~QLFDFRODGH
SURFHVRV

8QSURFHVDGRUKDFHGH
3ODQLILFDGRU\UHSDUWHORV
SURFHVRVHQWUHORV
SURFHVDGRUHV

*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

Tambin puede haber algunas limitaciones en la asignacin de CPU en los sistemas

homogneos, como es el caso de un programa que haga uso de un dispositivo
especial de E/S conectado a un bus privado de un procesador concreto, en cuyo
caso solamente se le puede asignar tal CPU para ejecutarse.
En el caso de los sistemas heterogneos, cada procesador dispone de su propia
cola Preparados y de su planificacin particular, y cada proceso entra en la cola del
procesador que le corresponde.
En los sistemas homogneos se podran tener tambin varias colas, una por
procesador, pero esto podra dar lugar a una carga desequilibrada, con algunas
colas con muchos procesos, y otras colas vacas con su CPU ociosa. Para evitar
esto, suele ser mejor disponer de una nica cola de procesos preparados. Hay dos
mtodos para sacar los procesos de la cola.
Uno es mediante DXWRSODQLILFDFLyQ, en el que cada procesador que queda libre
saca un proceso de la cola. En este mtodo hay que controlar la posibilidad de
que dos procesadores intenten sacar simultneamente al mismo proceso de la
cola.
El otro sistema es dedicando un procesador a trabajar como planificador, siendo
l el nico que saca procesos de la cola y los asigna entre los procesadores,
evitando as los conflictos del mtodo anterior.

 /D3ODQLILFDFLyQGH$OJXQRV6LVWHPDV2SHUDWLYRV
Aunque los conceptos de sistemas operativos pueden estudiarse o considerarse en
trminos puramente tericos, resulta conveniente observar cmo se han
implementado algunos sistemas operativos comerciales. As, ahora vamos a
comentar, aunque solo sea superficialmente, algunas de las decisiones de diseo
que se han tomado sobre la planificacin de la CPU en Unix, Linux y Windows NT.

8QL[
La primera versin de Unix se desarroll en 1969 por Ken Thompson en los
Laboratorios Bell. Muchas versiones y emulaciones se han hecho desde entonces.
Una de las ltimas versiones de Unix es la 6\VWHP9UHOHDVH, aparecida en 1989.
No obstante, muchos otros fabricantes tambin han desarrollado sus propias
versiones de este popular sistema operativo. As tenemos las versiones de IBM
(AIX), HP (HP-UX), Sun (Sun OS y Solaris), DEC (Ultrix) y algunas ms. Tambin se
han desarrollado versiones para PCs, como la de Microsoft (Xenix), la de Santa
Cruz y la de Tanenbaum (Minix), y para las ms variadas plataformas, desde el
Macintosh de Apple hasta supercomputadores como el Cray II.
Una de las versiones de Unix ms populares ha sido la desarrollada en la
Universidad de Berkeley por el Departamento de Defensa norteamericano para
$SXQWHVGH62,



*HVWLyQGH3URFHVRV

utilizarlo en instalaciones gubernamentales. Esta versin fue la 4BSD, siendo

concretamente la 4.3BSD (ao 1986) una de las que tuvieron ms auge de
utilizacin.
Tambin merece especial mencin Linux, que desde mediados de los aos 90 ha
tenido una espectacular difusin, y al que le trataremos en un apartado particular.
Ahora vamos a comentar aqu la poltica de planificacin del procesador utilizada por
Unix en su versin 4.3BSD.
Ya que se trata de un sistema operativo multiusuario, la planificacin de Unix est
diseada para favorecer a los procesos interactivos, para lo cual utiliza una
planificacin por prioridades, cediendo la CPU en porciones de tiempo al proceso
ms prioritario. El algoritmo concreto es el de colas multinivel con realimentacin
(mediante envejecimiento), de tal manera que para procesos con gran carga de
CPU el algoritmo de planificacin se convierte en URXQGURELQ. Vemoslo con cierto
detalle.
Las porciones de tiempo son de 100 ms., por lo que cuando un proceso llega al
trmino de su porcin sin haber cedido la CPU, se le quita la CPU para cedrsela al
proceso preparado con mayor prioridad. Las prioridades, no obstante, son
dinmicas, es decir, que la prioridad de un proceso va variando a lo largo de su
vida. Aunque las porciones de tiempo son de 100 ms. la reevaluacin de las
prioridades se realiza una vez por segundo, para que no suponga una sobrecarga
considerable. Esto quiere decir que cada segundo se aplica el algoritmo que
establece la prioridad de cada proceso. El algoritmo en cuestin es el siguiente:
3 (L) = %DVH +
M

&38 (L 1)

&38 =
M

8 (L)
M

+ QLFH

&38 (L 1)
M

donde
3 L

Prioridad del proceso M al comienzo del intervalo L. Cuanto menor

sea este nmero, mayor es la prioridad.

%DVH

Prioridad de base del proceso M.

&38 L = Media ponderada exponencial de la utilizacin de CPU del proceso M

en el intervalo L.
M

8ML

= Utilizacin de CPU del proceso M en el intervalo L.

QLFH

= Factor de ajuste controlado por el usuario.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

El propsito de la prioridad base es establecer bandas fijas de prioridades, de tal

manera que a los distintos tipos de procesos se les asigna una prioridad base
predeterminada. Las bandas son, en orden de prioridad decreciente, para los
siguientes tipos de procesos:

Procesos de intercambio a disco

Procesos de dispositivos de E/S por bloques
Procesos de gestin de archivos
Procesos de dispositivos de E/S de caracteres
Procesos de usuario

Prioridad

Esta jerarqua tiende a proporcionar un aprovechamiento ms eficiente de los

dispositivos de E/S. Obsrvese que dentro de los procesos de usuario, tambin se
tiende a penalizar a los procesos que consumen mucha CPU, pues cuanto ms
procesador consume un proceso, menor se hace su prioridad, lo cual termina
favoreciendo a los procesos que ms utilizan los dispositivos de E/S. Esto tiende a
evitar el efecto convoy comentado en la planificacin FIFO. Tambin debemos
observar que ya que se tiene en cuenta (y se penaliza) el consumo de CPU que ha
realizado cada proceso en su anterior posesin del procesador, este algoritmo
tambin se comporta como una aproximacin a el ms corto - el primero, el cual ya
vimos que ofrece los mejores tiempos medios de espera.
Ya que a todos los procesos de usuario se les asigna la misma prioridad base, para
este tipo de procesos el algoritmo se comporta como si fuera 5RXQG5RELQ (aunque
como ya hemos dicho, favoreciendo a los procesos con poca carga de CPU), no
obstante, se puede favorecer en cierta manera a algunos procesos de usuario
mediante el comando nice.
Debido a este algoritmo con envejecimiento, resulta muy difcil que un proceso
pueda apropiarse de forma exclusiva de la CPU evitando as la inanicin de los
procesos.

/LQX[
Linux es otro sistema operativo tipo Unix en el que aunque la compatibilidad con
Unix era uno de los objetivos de diseo, tiene algunas particularidades que difieren
del Unix estndar, entre ellas la poltica de planificacin de procesos, y dada la
popularidad que ha adquirido en estos ltimos aos, merece la pena comentarlo.
El desarrollo de Linux comenz en 1991, cuando el estudiante finlands Linus
Torvalds escribi un pequeo kernel o ncleo para el procesador 80386 de Intel y lo
puso a disposicin de todo el mundo de forma gratuita a travs de Internet. Este
ncleo implementaba un subconjunto de la funcionalidad de Unix, pero fue
creciendo hasta adquirir la funcionalidad completa.
Alrededor del nico NHUQHO GH /LQX[ se han construido multitud de programas que
constituyen el VLVWHPD /LQX[. Alguno de estos programas se ha construido

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

expresamente para Linux, mientras que otros se han tomado prestados de otros
sistemas o proyectos de colaboracin.
Una GLVWULEXFLyQGH/LQX[ consta de los componentes estndar de un sistema Linux,
ms un conjunto de herramientas de administracin que ayudan a simplificar la
instalacin y mantenimiento del sistema. Aunque la primera distribucin de Linux fue
la de SLS y la de Slackware posiblemente la ms popular, hoy da hay numerosas
distribuciones, entre ellas: Red Hat, Debian, Caldera, Craftworks, SuSE, Unifix, etc.
No obstante, debe tenerse en cuenta que todas ellas comparten el mismo kernel, y
los paquetes o utilidades que ofrece cada una suelen ser compatibles con las
dems distribuciones.
En este apartado vamos a centrarnos en los aspectos de planificacin del kernel de
Linux en su versin 2.0. Aunque este sistema operativo est preparado para
sistemas multiprocesador, aqu vamos a comentar nicamente la planificacin con
un nico procesador.
Linux dispone de dos algoritmos de planificacin (dos clases de planificacin). Uno
es el de tiempo compartido, para un reparto justo entre mltiples procesos; el otro
est diseado para tareas de tiempo real, donde las prioridades son ms
importantes que la justicia. Cada proceso puede acogerse a cualquiera de estas
polticas de planificacin, y as consta en su BCP.
Para los procesos de tiempo compartido, se utiliza un algoritmo basado en crditos.
Cada proceso dispone de un cierto nmero de crditos, de tal manera que para
seleccionar la siguiente tarea a ejecutarse, se elige a la que tiene ms crditos
acumulados. Cada vez que se produce una interrupcin de reloj, el proceso en
ejecucin pierde un crdito; cuando su nmero de crditos llega a cero, pierde la
CPU y se selecciona otro proceso.
Cuando no queda ningn proceso preparado con crditos, Linux vuelve a asignar
crditos a todos los procesos del sistema segn la regla siguiente:
&UpGLWRV =

FUpGLWRV UHVWDQWHV
+ SULRULGDG
2

Este algoritmo considera dos factores: la historia del proceso y su prioridad. Se

mantiene la mitad de los crditos de los que el proceso conserva desde la ltima
asignacin de crditos, recordando as parte de la historia del comportamiento ms
reciente del proceso. Los procesos con mucha carga de CPU tienden a gastar sus
crditos rpidamente, mientras que los que suelen estar suspendidos en espera de
operaciones de E/S van acumulando crditos a lo largo de la historia, de tal manera
que cuando estn en espera de la CPU tendrn ms prioridad para ejecutarse, lo
cual produce un tiempo de respuesta muy rpido para los procesos interactivos.
El factor prioridad en el clculo de la asignacin de crditos permite afinar la
prioridad real de los procesos. Al asignar una baja prioridad a algunos procesos en
EDFNJURXQG, automticamente recibirn menos crditos que los procesos



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

interactivos, y tambin recibirn un menor porcentaje de CPU que trabajos similares

a los que se les haya asignado una mayor prioridad.
Gracias a este sistema de prioridades dinmicas, procesos de distintas prioridades
pueden competir por el procesador, evitando as el problema de la inanicin.
Para tiempo real, Linux implementa los dos algoritmos expulsores o expropiativos
requeridos por POSIX: ),)2 y 5RXQG5RELQ. Esto quiere decir que la informacin de
cada proceso debe indicar si se acoge a planificacin de tiempo compartido o de
tiempo real, y en caso de ser este ltimo, debe especificar si utiliza el algoritmo ),)2
o 5RXQG5RELQ. Veamos cmo se comporta la planificacin con cada uno de estos
dos algoritmos de tiempo real.
El algoritmo FIFO es el ya conocido para tiempo real, en el que la CPU siempre se
le concede al proceso con mayor prioridad, y no se le quita a no ser que pase a
preparado un proceso de mayor prioridad. En cambio, los procesos de la misma
prioridad con planificacin 5RXQG5RELQ, se reparten la CPU en idnticas porciones
de tiempo por turno rotatorio.
Cuando se le solicita al planificador que elija un proceso para pasar a ejecucin,
busca en la cola de los preparados, eligiendo siempre a un proceso de tiempo real
antes que a los de tiempo compartido.
Cuando finaliza una rodaja de tiempo, se comprueba la poltica de planificacin del
proceso en ejecucin. Si es de tiempo compartido se decrementa un crdito, y si ha
llegado a cero, se le quita la CPU, cedindosela al proceso preparado con ms
crditos. Si es GHWLHPSRUHDO),)2FRQWLQ~DFRQODHMHFXFLyQ6LHVGHWLHPSRUHDO
FRQ 5RXQG Robin y no hay ms procesos preparados de la misma prioridad,
continua la ejecucin, pero si hay otros procesos preparados de la misma prioridad,
se le quita la CPU, se le enva a la cola de preparados, y se le asigna la CPU al
siguiente proceso preparado de esa prioridad.
Ya que la planificacin, en cualquier caso, es expulsora, si un proceso pasa a
preparado y es de mayor prioridad que el actual proceso en ejecucin, se le asigna
la CPU inmediatamente al proceso de mayor prioridad.

:LQGRZV17
Este sistema operativo naci como consecuencia de que Microsoft decidi construir
un nuevo sistema operativo partiendo de cero y con una Nueva Tecnologa, que
soportara las aplicaciones tanto para OS/2 como para POSIX, Windows y MS-DOS.
Hay dos versiones de Windows NT: ZRUNVWDWLRQ (puesto de trabajo para un usuario)
y VHUYHU (utilizado como servidor para aplicaciones cliente-servidor), sin embargo
ambas utilizan el mismo ncleo, por lo que las caractersticas de planificacin que
comentaremos aqu se aplican a las dos versiones.
Aunque Windows NT dispone de un sistema de proteccin para mltiples usuarios,
no debe entenderse como un sistema multiusuario, pues no permite mltiples
$SXQWHVGH62,



*HVWLyQGH3URFHVRV

usuarios conectados simultneamente (aunque s permita mltiples accesos

simultneos como servidor).
La arquitectura de Windows NT est basada en un PLFURNHUQHO (como Mach), de tal
forma que facilita las actualizaciones de partes del sistema operativo sin afectar al
resto. Y como es tpico en los sistemas basados en PLFURNHUQHOV, dispone de
procesos o tareas y de procesos ligeros o WKUHDGV. Las notas sobre planificacin que
vamos a comentar se aplican tanto a los procesos como a los WKUHDGV de Windows
NT en su versin 4.0
Los objetivos de planificacin de Windows NT son diferentes a los de Unix. ste
est pensado para dar servicio equitativo y rpido a todos los usuarios del sistema,
mientras que Windows NT se dise para ser especialmente sensible a las
necesidades de un nico usuario en un entorno muy interactivo o en el papel de un
servidor.
El planificador utiliza un esquema de 32 prioridades para determinar el orden de
ejecucin. Las prioridades estn divididas en dos clases: la FODVH YDULDEOH (con las
prioridades 0 a 15) y la FODVH GH WLHPSR UHDO (con las prioridades 16 a 31). Un
nmero ms alto indica una mayor prioridad. Cuando se crea un proceso se le
asigna una prioridad base. Las prioridades de la clase variable se suelen utilizar
para los procesos de usuario, mientras que las de tiempo real se reservan para las
actividades derivadas del servidor.
Se utiliza una cola para cada una de estas prioridades, de tal manera que para
elegir el siguiente proceso que pasa a ejecucin, se recorren todas las colas, de
mayor a menor prioridad hasta que se encuentra un proceso preparado. Si no hay
ningn proceso preparado, se le cede el control al WKUHDGRFLRVR.
La CPU siempre se asigna al proceso de mayor prioridad, aunque las prioridades se
gestionan de forma diferente en las dos clases. En la clase de tiempo real todos los
procesos mantienen su prioridad base, que no cambia nunca, y la CPU se reparte
por turno rotatorio entre todos los procesos de la mxima prioridad que tenga
procesos preparados. En la clase de prioridad variable, la prioridad de un proceso
parte de su prioridad base y puede subir o bajar (dentro de un cierto margen) a lo
largo de la vida del proceso. As, por cada nivel de prioridad hay una cola FIFO, pero
un proceso puede pasar a la cola de otra prioridad dentro de las de prioridad
variable. La prioridad de un proceso no puede cambiar a la prioridad de otra clase
distinta a la que pertenece.
Cuando a un proceso en ejecucin se le acaba su porcin de tiempo, si pertenece a
la clase de tiempo real y hay ms procesos preparados de la misma prioridad, se le
quita la CPU y pasa al final de la cola de su prioridad, cediendo la CPU al siguiente
proceso de esa cola. Si la prioridad del proceso pertenece a la clase variable, se le
disminuye la prioridad (hasta cierto lmite). De esta manera se tiende a limitar el alto
consumo de CPU que realizan los procesos de clculo (con poca E/S); por otra
parte, cuando un proceso que estaba en espera pasa a preparado, se le aumenta su
prioridad. Este aumento depende del motivo por el que estaba esperando. Los
procesos que esperan por una interrupcin de teclado o de ratn son los que



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

consiguen un mayor aumento de prioridad, mientras que los que esperan por la
conclusin de una operacin con el disco slo consiguen un ligero aumento. Esta
estrategia tiende a ofrecer un buen tiempo de respuesta a los procesos interactivos
elevando la prioridad a los procesos que esperan por teclado o ratn, dejando que
los procesos con gran carga de procesador se ejecuten en tiempos muertos en
segundo plano.
Aunque esta planificacin expulsora siempre le otorga el procesador al proceso
preparado con mayor prioridad, no se puede decir que Windows NT sea un sistema
operativo de tiempo real estricto, pues no garantiza el tiempo mnimo que se tarda
en darle control a un proceso de alta prioridad que pasa a preparado.
3ODQLILFDFLyQHQ6LVWHPDV0XOWLSURFHVDGRUHV
Cuando Windows NT se ejecuta con un nico procesador, el proceso preparado de
mayor prioridad siempre est en ejecucin, y si hay ms de un proceso con la mayor
prioridad, la CPU se reparte por turno rotatorio entre todos los procesos preparados
de esa prioridad.
En un sistema multiprocesador con 1 procesadores, siempre se mantiene en
ejecucin a los 1 procesos de mayor prioridad, ejecutndose de manera exclusiva
en los 1 procesadores. El resto de los procesos de menor prioridad comparten el
nico procesador que queda.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

&RPXQLFDFLyQ\6LQFURQL]DFLyQHQWUH3URFHVRV
Normalmente, los procesos que cooperan en la realizacin de un trabajo,
necesitarn durante su ciclo de vida la sincronizacin o comunicacin entre ellos o
con el proceso maestro que les haya creado. Se hace necesario algn sistema de
comunicacin cuando se requiere el intercambio de informacin entre dos o ms
procesos. Por ejemplo, un proceso puede estar produciendo una serie de datos que
sirven a su vez de entrada a otro proceso (como ocurre con el SLSH | de Unix). En
otros casos, como en los momentos en que se accede a estructuras de datos
comunes a varios procesos, se requiere algn mecanismo de sincronizacin para
que dos procesos no intenten acceder simultneamente a dicha estructura para
realizar operaciones de lectura/escritura de forma incontrolada.
As pues, en los siguientes apartados trataremos los problemas que pueden darse y
algunos mecanismos propuestos para comunicacin y sincronizacin entre procesos
cooperantes que comparten el mismo espacio lgico de direcciones.

 &RQGLFLyQGH&DUUHUD
Como ya hemos dicho anteriormente, un sistema puede estar compuesto de
mltiples procesos que se pueden ejecutar en paralelo (simultneamente) si se
dispone de mltiples procesadores. Cuando solamente se dispone de una CPU, el
efecto del procesamiento paralelo puede simularse si los procesos se ejecutan
turnndose en la posesin del procesador. En otras palabras, el procesador puede
compartirse entre varios procesos. Incluso simulando el procesamiento paralelo,
resulta til ver cada proceso como si tuviera su propio procesador virtual dedicado.
Muchas de las dificultades que surgen en el verdadero procesamiento paralelo
tambin se producen en el caso simulado. Uno de estos problemas se muestra en el
ejemplo del programa superior de la Figura 18.
El primer proceso, el 2EVHUYDGRU, es el responsable de observar y contar eventos. El
segundo proceso, el 5HSRUWHUR, ocasionalmente imprime informes sobre el nmero
de eventos observados hasta el momento y seguidamente pone el &RQWDGRU de
eventos a cero. Cuando ambos procesos se ejecutan concurrentemente, puede
producirse la siguiente situacin. Supongamos que el reportero acaba de imprimir un
10, y antes de que pueda poner el &RQWDGRU a cero se produce la interrupcin de
tiempo y se concede el control de la CPU al 2EVHUYDGRU. ste, entonces, incrementa
el &RQWDGRU a 11. A continuacin, el 5HSRUWHUR vuelve a tomar posesin del
procesador y pone, por fin, el &RQWDGRU a cero, lo cual significa que un evento queda
sin ser contabilizado. En general, el 5HSRUWHUR puede fallar al informar de cualquier
nmero de eventos, ya que el incremento de la variable &RQWDGRU puede producirse
entre la impresin del valor, y su puesta a cero.
En este ejemplo se muestra que los resultados son impredecibles, ya que los
procesos se ejecutan con velocidades relativas igualmente impredecibles. Cuando el
resultado de un clculo depende de las velocidades relativas de los procesos, se
dice que hay una FRQGLFLyQ GH FDUUHUD. Las condiciones de carrera se producen


$SXQWHVGH62,

*HVWLyQGH3URFHVRV

cuando procesos paralelos comparten datos o recursos, como la variable &RQWDGRU

del ejemplo.

6LQFURQL]DFLyQGH3URFHVRV
SURJUDP Cuenta_Eventos;
Contador : INTEGER := 0;
SURFHVV Observador;
UHSHDW
Esperar_Evento;
Contador := Contador + 1;
IRUHYHU;
HQG Observador;
SURFHVV Reportero;
UHSHDW
Imprimir (Contador);
Contador := o;
IRUHYHU;
HQG Reportero;
EHJLQ
Observador;
Reportero;
HQG Cuenta_Eventos;

6HSURGXFHXQD&RQGLFLyQGH&DUUHUD
(ODFFHVRDODYDULDEOHQRHVDWyPLFR
process Observador;
repeat
Esperar_Evento;
(QWUDUB5&;
Contador := Contador + 1;
6DOLUB5&;
forever;
end Observador;

6HSLHUGHQ
HYHQWRV

62/8&,1
3URSRUFLRQDU
([FOXVLyQ0XWXD
5HJLyQ&UtWLFD

process Reportero;
repeat
(QWUDUB5&;
Imprimir (Contador);
Contador := 0;
6DOLUB5&;
forever;
end Reportero;
6LVWHP DV2SHUDWLY RV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

 ([FOXVLyQ0XWXD\5HJLyQ&UtWLFD
Cmo evitar las condiciones de carrera? La clave para evitar problemas en las
situaciones en que se comparten objetos o recursos es encontrar algn modo de
prohibir que haya ms de un proceso leyendo o escribiendo el dato compartido al
mismo tiempo. En otras palabras, lo que se necesita es H[FOXVLyQPXWXD, es decir,
asegurarse de que si un proceso est accediendo a un dato compartido, el otro o los
otros procesos estarn imposibilitados para poder hacerlo tambin.
El problema de nuestro ejemplo es que el proceso 2EVHUYDGRU puede acceder al
&RQWDGRU (lo incrementa) antes de que el 5HSRUWHUR haya acabado de realizar las
operaciones con la variable (le faltaba ponerla a cero), o sea, se accede a la variable
antes de que el proceso que la est modificando la deje en un HVWDGRFRQVLVWHQWH.
Y este problema se produce porque las operaciones de acceso a la variable
compartida no son indivisibles en su ejecucin, es decir, porque no son DWyPLFDV o
ininterrumpibles.
En la vida de un proceso, parte del tiempo est ocupado con clculos internos y otro
tipo de cosas que no conducen a una condicin de carrera. Pero en otras ocasiones,
el proceso accede a variables o ficheros compartidos que s puede conducir a la
condicin de carrera. La parte del programa en la que se accede a memoria
compartida se denomina UHJLyQFUtWLFD. Si nos las pudiramos apaar para que dos
procesos no estuvieran al mismo tiempo en su regin crtica, evitaramos las
condiciones de carrera.

 ,PSOHPHQWDFLyQGHOD([FOXVLyQ0XWXD
En la parte inferior de la Figura 18 tenemos nuestro ejemplo transformado de
acuerdo a la premisa del acceso a la regin crtica. En este programa transformado
se muestra una solucin abstracta al problema de la exclusin mutua. Podemos ver
que la regin crtica de cada proceso est encerrada entre sendas sentencias de
entrada y salida de la regin ((QWUDUB5& y 6DOLUB5&). Estara bien que estas
primitivas de acceso a la regin crtica se comportasen como porteros, tal que si un
proceso intentara entrar en la regin crtica ocupada por otro proceso, el primero
quedara bloqueado por el portero hasta que el otro proceso saliese de ella.

 &RQGLFLRQHVSDUDHO6LQFURQLVPRGH3URFHVRV&RRSHUDQWHV
Aunque con la exclusin mutua se evitan las condiciones de carrera, no es condicin
suficiente para que una serie de procesos paralelos cooperen correcta y
eficientemente utilizando datos compartidos. Se requieren las siguientes condiciones
para obtener una buena solucin:
1. Dos procesos no pueden estar al mismo tiempo dentro de la misma regin
crtica.
2. No se deben hacer suposiciones sobre el hardware, es decir, sobre la
velocidad o el nmero de procesadores que intervienen.


$SXQWHVGH62,

*HVWLyQGH3URFHVRV

3. No se deben hacer suposiciones sobre las velocidades relativas de los

procesos.
4. Ningn proceso fuera de su regin crtica puede bloquear a otros procesos.
5. Ningn proceso deber esperar eternamente a entrar en su regin crtica.
6. No se debe posponer indefinidamente la decisin de cul es el siguiente
proceso que debe entrar.

 0HFDQLVPRV
En este apartado examinaremos, tanto a nivel hardware como software, algunos de
los muy diversos mtodos de sincronizacin que existen para resolver el problema
de la exclusin mutua. Estos son:

Inhibicin de interrupciones
Espera activa
Semforos
Monitores

Sobre las versiones originales de algunos de estos mecanismos (semforos y

monitores) ha habido diversas modificaciones a lo largo de la historia, por ello aqu
vamos a comentar los conceptos bsicos o el cometido fundamental que se busca
con cada uno de ellos, pues su estudio en profundidad sera ms propio de un curso
de Programacin Concurrente. No obstante, en la bibliografa se citan algunos libros
en los que se puede encontrar informacin adicional sobre este tema.
,QKLELFLyQGH,QWHUUXSFLRQHV
Si se pretende evitar que mientras un proceso est dentro de una regin crtica, otro
proceso pueda entrar tambin, la forma ms fcil de conseguirlo es evitando que el
proceso que se encuentra dentro de la regin pierda el control del procesador antes
de abandonarla.
Un proceso pierde la posesin de la CPU solamente si realiza una operacin de E/S
o, si debido a una interrupcin, se detecta que se le acab su porcin de tiempo o
que otro proceso de mayor prioridad pasa a Preparado y seguidamente se apropia
de la CPU. Sabido esto, por una parte se puede hacer que un proceso que se
encuentra dentro de una regin crtica no realice operaciones de E/S, y por otra
parte lo que falta por hacer es inhibir la aceptacin de interrupciones por parte del
procesador mientras el proceso est dentro de la regin. Es decir, que las
sentencias Entrar_RC y Salir_RC se podran corresponder, respectivamente, con
las instrucciones mquina DISABLE (inhibir aceptacin de interrupciones) y ENABLE
(aceptar interrupciones). As, una vez que un proceso ha inhibido las interrupciones,
puede examinar y actualizar la memoria compartida sin miedo a que otro proceso
intervenga, pues la secuencia de instrucciones que componen la regin crtica se
convierte en una nica operacin atmica o indivisible.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

([FOXVLyQ0XWXD

6LQFURQL]DFLyQ

5HTXLVLWRVSDUDVX,PSOHPHQWDFLyQ

'RVSURFHVRVQRSXHGHQHVWDUDOPLVPRWLHPSRGHQWUR
GHODPLVPDUHJLyQFUtWLFD

1RVHGHEHQKDFHUVXSRVLFLRQHVVREUHHOKDUGZDUH
YHORFLGDGRQGHSURFHVDGRUHV

1RVHGHEHQKDFHUVXSRVLFLRQHVVREUHODYHORFLGDGHV
UHODWLYDVGHORVSURFHVRV

1LQJ~QSURFHVRIXHUDGHVXUHJLyQFUtWLFDSXHGH
EORTXHDUDRWURVSURFHVRV

1LQJ~QSURFHVRGHEHUiHVSHUDUHWHUQDPHQWHDHQWUDU
HQVXUHJLyQFUtWLFD

1RVHGHEHSRVSRQHULQGHILQLGDPHQWHODGHFLVLyQGH
FXiOHVHOVLJXLHQWHSURFHVRTXHGHEHHQWUDU

9$5,26
6,67(0$6

,QKLELFLyQGH,QWHUUXSFLRQHV
9DULDEOH&HUURMR(VSHUD$FWLYD
6HPiIRURV
0RQLWRUHV


6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

La ventaja de este sistema es su simplicidad. Sin embargo, tambin da lugar a

varios inconvenientes:
La regin crtica debe ser corta, pues de lo contrario se podran perder
interrupciones generadas por los dispositivos de E/S si no se tratan a tiempo.
Inhibiendo las interrupciones, no solamente se impide que otro proceso
cooperante que desee entrar en la regin crtica pueda continuar su ejecucin,
sino tambin a procesos cooperantes que no intentan en la regin crtica. Y lo
que es peor, tambin se impide que prosigan el resto de los procesos del
sistema, que por no ser cooperantes, en ningn momento intentarn acceder a
los datos compartidos que se estn protegiendo.
Este mtodo slo es apropiado para sistemas monoprocesador, pues en un
entorno con mltiples CPUs la prohibicin de las interrupciones en un
procesador no afecta a los dems. Una solucin a este problema podra ser el
centralizar en un nico procesador la gestin de interrupciones, pero no
siempre esto es posible.
Resulta peligroso darle al usuario un medio para inhibir las interrupciones,
pues podra ocurrir que por un error de programacin o por cualquier otro
motivo no las volviera a permitir, provocando la consiguiente prdida de las
subsiguientes interrupciones y el acaparamiento en exclusiva de la CPU.
Sin embargo, con frecuencia resulta conveniente para el ncleo del sistema
operativo la inhibicin de interrupciones durante unas pocas instrucciones mientras
actualiza estructuras de datos del sistema, por ejemplo, para actualizar la lista de
procesos Preparados, pues si se dejase en un estado inconsistente, el sistema se
ira al traste.
Como conclusin, se puede decir que la inhibicin de interrupciones resulta, a
veces, una tcnica til o prctica para el ncleo, pero no es apropiada como
mecanismo general de exclusin mutua para los procesos de usuario.
Acabamos de ver una solucin hardware al problema de la exclusin mutua.
Pasemos a tratar algunas soluciones basadas en algoritmos software que tratan de
evitar la prdida de interrupciones y la injusticia de que la proteccin de una regin
crtica perjudique a todos los procesos del sistema, incluso a aquellos que no tienen
ninguna relacin con la estructura de datos compartida que se quiere proteger.

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

([FOXVLyQ0XWXD

,QKLELFLyQGH,QWHUUXSFLRQHV

,QWHUUXSFLRQHV
,QKLELGDV

3RVHVLyQLQGHILQLGDGHOD&38

352%/(0$6
36HSXHGHQSHUGHULQWHUUXSFLRQHV
36HSULYDD72'26ORVSURFHVRVGHOD&38
33HOLJURVRHQPDQRVGHOXVXDULR

62/8&,1(VSHFLILFDUOD5HJLyQ&UtWLFD
...
Entrar_RC (RC_Eventos);
...
...
Salir_RC (RC_Eventos);
...

8WLOSDUDORVQ~FOHRVGHORVVLVWHPDVRSHUDWLYRV

6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

(VSHUD$FWLYD&HUURMRV
Otra posibilidad de impedir el acceso simultneo de dos procesos a la regin crtica
es haciendo que una variable acte como cerrojo o indicador de si la regin crtica
est ocupada o no. Esto se puede hacer con una variable booleana que tome los
valores 0 (libre) y 1 (ocupada). Todos los procesos que deseen acceder a una
regin crtica deben cumplir un protocolo de acceso y salida de la regin. Cuando un
proceso llegue a la entrada de la regin debe consultar el valor de la variablecerrojo; si el valor es 0, la pone a 1 y entra en la regin crtica; si la variable ya
estaba a 1, el proceso debe esperar hasta que valga 0.
La idea de este mtodo es similar al acceso al lavabo de un avin de pasajeros. Si
el cartel indica /LEUH, entramos, cerramos la puerta, y el cartel pasa a indicar
2FXSDGR. En cambio, si al intentar acceder al lavabo, el cartel indica 2FXSDGR,
simplemente esperamos a que quede libre.
Por desgracia, esta idea contiene el mismo problema que nuestro ejemplo de los
procesos Observador y Reportero. Supongamos que un Proceso A lee el cerrojo y
ve que est a 0. Antes de que pueda ponerlo a 1, pierde el control de la CPU y lo
toma otro Proceso B que tambin quiere entrar en la regin crtica. Este ltimo
consulta tambin el valor del cerrojo (que sigue a 0), lo pone a 1 y entra en la regin.
Antes de salir de la regin crtica, finaliza su porcin de tiempo y se le devuelve el
control al Proceso A, que contina lo que estaba haciendo, con lo que pone el
cerrojo a 1 (otra vez) y entra en la regin crtica, creyendo que l es el nico que
est dentro, porque ha entrado siguiendo el protocolo de acceso.
Como vemos, el problema se debe a que la consulta del cerrojo y su posterior
puesta a 1 (ocupado) no se realiza como una accin atmica.
Para solucionar esto han surgido diversos algoritmos, entre ellos, el de la panadera
(de Lamport); el algoritmo de Decker (para 2 procesos); el de Dijkstra (para n
procesos); el de Knuth, Eisemberg y McGuire; y el de Peterson. La descripcin de
estos algoritmos puede encontrarse en cualquiera de los textos indicados en la
bibliografa.
Se consigue una buena solucin con un poco de ayuda hardware. Los procesadores
de propsito general suelen ofrecer la siguiente instruccin mquina (por lo tanto,
ininterrumpible en su ejecucin):
TAS (Cerrojo, Valor)
Esta instruccin (7HVW DQG 6HW) acta de la siguiente manera. Se lee la variable
&HUURMR, y en funcin de su valor, se establecen los IODJV correspondientes en el
Registro de Estado del procesador. Por ltimo, a dicha variable se le asigna el
contenido del segundo parmetro, 9DORU. De esta forma se consigue realizar las dos
acciones de comprobacin y asignacin del valor ocupado sin ninguna
interrupcin.
En la implementacin de Entrar_RC y Salir_RC con TAS de la Figura 21 se
puede ver que cuando un proceso llega a la entrada de la regin crtica, si la

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

9DULDEOH&HUURMR

([FOXVLyQ0XWXD

(QWUDUB5&

6DOLUB5&

TST
BNZ
MOV
RET

RC_Eventos
Entrar_RC
1, RC_Eventos

MOV
RET

0, RC_Eventos

5&B(YHQWRV DB

(VWDP
RV
DOSUL FRPR
QFLSLR

+D\9DULRV$OJRULWPRVTXHOR6ROXFLRQDQ
'HNNHUSURFHVRV'LMNVWUDQSURFHVRV
.QXWK(LVHQEHUJ 0F*XLUH
$OJRULWPRGHOD3DQDGHUtDGH/DPSRUW
3HWHUVRQ
0HMRUFRQ$\XGDGHO+:

Test and Set

Entrar_RC

TAS
BNZ
RET

RC_Eventos,1
Entrar_RC

Salir_RC

MOV
RET

0,RC_Eventos

+3UREOHPDGHOD,QYHUVLyQGH3ULRULGDGHV
+\VLKD\P~OWLSOHVSURFHVDGRUHV"

(O*UDQ3UREOHPDGHHVWDV6ROXFLRQHV
(63(5$
$&7,9$
6LVWHPDV2SHUDWLYRV,



&RQVXPH5RGDMDVGH7LHPSR

*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

variable-cerrojo RC_EVENTOS no tiene el valor 0, todo lo que tiene que hacer es

ejecutarse en bucle hasta que la consulta del Registro de Estado indique que la
variable tena el valor 0. Para anunciar la salida de la regin crtica, lo nico que hay
que hacer es simplemente poner el valor 0 en el cerrojo.
Un problema que se puede producir aqu es que un proceso cumpla con el protocolo
de entrada a la regin crtica y acceda a ella, pero que a la salida se le olvide
liberarla. El acceso a la regin queda bloqueado indefinidamente.
Hasta ahora este mtodo funciona porque las acciones de FRPSUREDU \ SRQHU se
ejecutan como una sola instruccin ininterrumpible, pero veamos con mayor detalle
cmo se ejecuta la instruccin TAS. En primer lugar la CPU toma posesin del bus
(direcciones, datos y control) para leer el contenido del cerrojo de su posicin de
memoria. Una vez trado el dato, el procesador suelta la posesin del bus para
analizar el contenido de la variable leda y establecer los IODJV del Registro de
Estado de acuerdo a su valor. Por ltimo, vuelve a aduearse del bus y realiza la
escritura del cerrojo con el valor que corresponda.
Pues bien, funcionara esto en un sistema multiprocesador? La respuesta es no.
Entre la lectura y la escritura del cerrojo, el bus de acceso a memoria queda libre,
con lo que nada impide que otro procesador lea el contenido del cerrojo en ese
intervalo y se crea con permiso para entrar en la regin crtica. Para solucionar esto,
suele disponerse de una instruccin TASL7HVWDQG6HWZLWK/RFN), que mantiene el
bus retenido para la CPU durante toda la operacin de lectura y escritura del cerrojo.
Hemos dicho que FXDQGR XQ SURFHVR OOHJD D OD HQWUDGD GH OD UHJLyQ FUtWLFD VL OD
YDULDEOHFHUURMR QR WLHQH HO YDORU  WRGR OR TXH WLHQH TXH KDFHU HV HMHFXWDUVH HQ
EXFOH KDVWD TXH OD FRQVXOWD GHO UHJLVWUR GH HVWDGR LQGLTXH TXH OD YDULDEOH WHQtD HO
YDORU. Esto es un problema, o al menos, un gasto intil de CPU. Si el cerrojo tiene
el valor 1 y el proceso que desea acceder a la regin crtica est comprobando
LQLQWHUUXPSLGDPHQWH su valor, est claro que dicho valor no va a cambiar, al menos
mientras tal proceso contine ejecutando la instruccin TAS. Seguramente habr
que esperar a que se acabe su porcin de tiempo, tome control el proceso que se
encuentra dentro de la regin y al finalizar ponga a 0 el cerrojo. As tenemos que el
proceso que quiere entrar gasta intilmente sus porciones de tiempo esperando a
que aparezca el valor 0, cosa que nunca va a suceder mientras l tenga la posesin
de la CPU.
Por esto, a este mtodo para conseguir la exclusin mutua se le conoce como
HVSHUDDFWLYD, pues el proceso espera su turno consumiendo, intilmente, tiempo
de procesador.
Cuando la poltica de planificacin de CPU es por prioridades, utilizando
mecanismos de sincronizacin de espera activa, se puede presentar el siguiente
escenario, conocido como el problema de la LQYHUVLyQ GH SULRULGDGHV.
Supongamos dos procesos cooperantes, P1 con prioridad 1 (alta) que est en
espera, y otro proceso P2 con prioridad 2 (baja) que est en ejecucin. El proceso
P2 entra en la regin crtica, y antes de abandonarla, el proceso P1 sale de espera y
pasa a Preparado, y debido a su mayor prioridad pasa inmediatamente a Ejecucin,
$SXQWHVGH62,



*HVWLyQGH3URFHVRV

por lo que al proceso P2 se le expulsa a Preparados. El proceso P1 se ejecuta hasta

llegar a la entrada de la regin crtica, pero tras consultar el estado del cerrojo, se
dedica a realizar la espera activa hasta que el cerrojo quede libre. Como su prioridad
es mayor que la del proceso que se encuentra dentro de la regin crtica (P2), nunca
va a ceder el procesador, con lo que el proceso P2 no va a continuar ejecutndose y
nunca abandonar la regin crtica. Los dos procesos quedan bloqueados.
6HPiIRURV
En apartados anteriores hemos hablado sobre el ciclo de vida de un proceso,
durante el cual se pasa por periodos de instrucciones de CPU y por periodos de
espera de E/S. Debido a que las operaciones con recursos externos tardan mucho
tiempo en realizarse (incluso puede haber una cola de procesos requiriendo sus
servicios), los procesos que solicitan una operacin de E/S pasan a estado de
Espera y ceden la CPU a otro proceso, no desperdiciando as el tiempo de
procesador.
E.W. Dijkstra propuso en 1965 el Semforo como mecanismo de sincronizacin.
Una de sus principales peculiaridades es que evita la espera activa. La idea era
tratar las regiones crticas como recursos de acceso exclusivo por los que compiten
los procesos, de tal manera que el que consigue el permiso entra en la regin
crtica, y el resto de los procesos quedan en estado de Espera hasta que les llegue
el turno de acceso.
Un semforo es un tipo abstracto de datos con dos operaciones bsicas ms una de
inicializacin (Figura 22). A las dos operaciones bsicas las llamaremos %DMDU y
6XELU, aunque originalmente se llamaran 3 y 9, y posteriormente hayan recibido
otros nombres muy utilizados como (VSHUDU y 6HxDODU :DLW y 6LJQDO. Para cada
regin crtica se declara una variable de tipo Semforo que identifica a la regin
como un recurso compartido.
Estas dos operaciones bsicas se corresponden con los protocolos de acceso y
salida de la regin crtica, tal que para entrar en ella hay que ejecutar una operacin
Bajar sobre el semforo asociado a esa regin, y a la salida debe llamarse a la
instruccin Subir sobre el mismo semforo.
Desde un punto de vista abstracto, el comportamiento de estas dos primitivas es el
siguiente:
%DMDU6 ZKLOH S 0 GR Esperar;
S := S-1;
6XELU6 S := S+1;
Con esta descripcin ya puede empezarse a entender cmo funcionan los
semforos, pues su comportamiento es similar a las acciones realizadas con el
mecanismo de espera activa. Pero ya hemos dicho que en este caso, no hay espera
activa, as que profundicemos, con ayuda de la Figura 22, en los significados de las
operaciones Bajar y Subir. Centrmonos en la accin (VSHUDU que se realiza dentro
de la operacin Bajar de un semforo. Esta accin significa:



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

1. Meter al proceso llamante en la cola de espera de los procesos que quieren

entrar en la regin crtica.
2. Quitarle la CPU, pues no puede continuar la ejecucin.
3. Llamar al Planificador para que seleccione un proceso de la cola Preparados
y seguidamente se le ceda el control del procesador.

6HP iIRURV

([FOXVLyQ0 XWXD
Package Semaforos is
type SEMAFOROS is private;
procedure ,QLFLDOL]DU(S
: SEMAFOROS;
Valor : INTEGER);
procedure %DMDU (S: SEMAFOROS);

/ODP DGDVDO6LVWHP D
DWyPLFDV

procedure 6XELU (S: SEMAFOROS);

end Semaforos;

%$ -$ 5 LI9DORUB6HP iIRUR WKHQ

&HGHUB&38
3DVDUBDB(VSHUD
HOVH
9DORUB6HP iIRUR 9DORUB6HPiIRUR
HQGLI
68 %,5

LI9DORUB6HP iIRUR!WKHQ
9DORUB6HP iIRUR 9DORUB6HPiIRUR
HOVH
LI+ D\B$ OJ~QB3URFHVRB(VSHUDQGRWKHQ
3RQHUORB3UHSDUGR
3ODQLILFDGRU
HOVH
9DORUB6HP iIRUR 
HQGLI
HQGLI

6 LV WH P D V 2 S H UD WLY R V ,

$SXQWHVGH62,

* H V WLy Q G H 3 U R F H V R V  



*HVWLyQGH3URFHVRV

Nos queda hablar de la inicializacin del semforo. Como ya veremos en las notas
sobre su implementacin, un semforo tiene un contador interno asociado, tal que
cada vez que un proceso realiza una operacin Bajar sobre l, se decrementa en 1,
hasta llegar a cero. Por esto, el valor inicial de dicho contador indica el nmero
mximo de procesos que pueden utilizar simultneamente el recurso asociado. En el
caso de que el recurso sea una regin crtica, el valor inicial del semforo deber ser
1, pues es el nmero mximo de procesos que pueden acceder simultneamente a
la regin. Los valores que puede tomar el contador del semforo son, entonces, 0 y
1; por esto a un semforo de este tipo se le denomina VHPiIRURELQDULR.
Ahora podemos ver, en la Figura 23, la versin con semforos de nuestro ejemplo
del Observador y el Reportero. Obsrvese que el programa Cuenta_Eventos
comienza inicializando a 1 el semforo S, y arrancando a continuacin los dos
procesos.

H Q  Q X H V W U R  H M H P S O R

6 HP iIRURV

Program Cuenta_Eventos;
Contador : INTEGER;
S
: SEMAFOROS;
process Observador;
repeat
Esperar_Evento;
%DMDU6
Contador := Contador
6XELU6
forever;
end Observador;

1;

process Reportero;
repeat
%DMDU6
Imprimir (Contador);
Contador := 0;
6XELU6
forever;
end Reportero;
begin
,QLFLDOL]DU6
Observador;
Reportero;
end Cuenta_Eventos;

6 LV W H P D V 2 S H U D W LY R V ,



* H V W Ly Q G H 3 U R F H V R V  

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

En la Figura 24 se muestra una aproximacin a la implementacin del semforo.

Ciertos detalles concretos pueden variar de un sistema a otro, sobre todo
dependiendo de la poltica de planificacin utilizada. Como se puede ver, un
Semforo es un registro con dos campos: el FRQWDGRU indicador del nmero de
procesos que pueden acceder al recurso, y una FROD para los procesos que tengan
que esperar su turno. Como comentario adicional a lo mostrado en dicha Figura 24,
cabe resaltar el hecho de que las operaciones sobre el semforo son Llamadas al
Sistema y, por lo tanto, desde el punto de vista del usuario, se realizan de forma
DWyPLFD, es decir, que las instrucciones sobre la estructura de datos que compone
el semforo se ejecutan siempre en exclusin mutua. La forma de conseguir la
exclusin mutua (no incluida en la Figura 24) depende de la implementacin
concreta de cada sistema operativo.
Ya tenemos un mecanismo de sincronizacin que nos ha resuelto el gran problema
de la espera activa, pues ya no se desperdicia el tiempo de la CPU. No obstante, se
sigue manteniendo uno de los problemas de los cerrojos, esto es, sigue siendo
responsabilidad del programador el uso adecuado de las primitivas de
sincronizacin, o sea, %DMDU para entrar en la regin crtica, y 6XELU para salir de ella.
Si inadvertidamente no se sigue estrictamente el protocolo de entrada y salida de la
regin, o no inicializa adecuadamente el semforo, el sistema falla.
0RQLWRUHV
Para evitar el problema de los descuidos del programador a la hora de seguir el
protocolo estipulado para acceder y salir de una regin crtica, Hoare propuso en
1974 una primitiva de sincronizacin de ms alto nivel denominada PRQLWRU. Brinch
Hansen propuso otra versin del monitor en 1975, y posteriormente ha habido otras
ms, as como tambin hay diversas polticas de planificacin para los procesos que
intervienen en un monitor.
Bsicamente, un monitor es una coleccin de procedimientos y datos, agrupados en
una especie de mdulo muy especial conocido como mdulo monitor. Los procesos
pueden llamar a los procedimientos del monitor siempre que lo deseen, pero no
pueden acceder directamente a las estructuras de datos internas del monitor desde
procedimientos declarados fuera del monitor. Las estructuras de datos escondidas
en el monitor solamente estn accesibles por los procedimientos del monitor.
En la Figura 25 se muestra un monitor llamado Control_Eventos que esconde
una variable interna: Num_Eventos, y que exporta dos procedimientos de acceso a
la variable: Incrementa e Imprime. En la parte inferior tenemos una versin de
nuestro ejemplo en la que se utiliza el monitor.
Los monitores tienen una propiedad especial para conseguir la exclusin mutua:
6RODPHQWHXQSURFHVRSXHGHHVWDUDFWLYRDODYH]GHQWURGHXQPRQLWRU. Dicho de
otra forma, dado un proceso A que ha llamado a un procedimiento de un monitor, y
mientras se est ejecutando dicho procedimiento, toma el control de la CPU otro
proceso B, si este proceso B llama a cualquier procedimiento del monitor, el proceso
B quedar detenido en la entrada (en estado de Espera) hasta que el proceso A
abandone el monitor.
$SXQWHVGH62,



*HVWLyQGH3URFHVRV

6HPiIRURV

,PSOHPHQWDFLyQ

type SEMAFOROS is private;

procedure ,QLFLDOL]DU(S
: SEMAFOROS;
Valor : INTEGER);
procedure %DMDU (S : SEMAFOROS);
procedure 6XELU (S : SEMAFOROS);
private -- Inaccesible al usuario
type SEMAFOROS is
record
Contador : INTEGER;
Cola
: COLA_PROCESOS;
end;
-procedure ,QLFLDOL]DU (S
: SEMAFOROS;
Valor : INTEGER) is
begin
S.Contador := Valor;
end Inicializar;
procedure %DMDU (S : SEMAFOROS) is
begin
if S.Contador < 1 then
Encolar (Este_Proceso, S.Cola);
Suspender; -- Implica llamada al Planificador
else
S.Contador := S.Contador - 1;
endif;
end Bajar;
procedure 6XELU (S : SEMAFOROS) is
Proceso : ID_PROCESO;
begin
if s.Cola.Primero /= 0 then -- Si algun proc. Esperando
Desencolar (Proceso, S.Cola);
Preparar (Proceso); -- Llamada al Planificador
else
S.Contador := S.Contador + 1;
endif;
end Subir;

6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

0RQLWRU

([FOXVLyQ0XWXD

/RVVHPiIRURVVRQXQEXHQPHFDQLVPR
SDUDVLQFURQL]DFLyQGHSURFHVRVSHUR
6LQRVHXVDQDGHFXDGDPHQWH
RUGHQQ~PHURYDORULQLFLDO

3$FFHVR&RQFXUUHQWH
3,QWHUEORTXHRV

8Q0RQLWRUHVXQFRQMXQWRGDWRVFRQVXVSURFHGLPLHQWRVGH
DFFHVRHQFHUUDGRVHQXQPyGXORHVSHFLDO0RQLWRU
6RODPHQWHXQSURFHVRSXHGHHVWDUDFWLYR
HQXQPRQLWRUHQXQPRPHQWRGDGR

(;&/86,1
0878$

Module Monitor Control_Eventos;

Num_Eventos : INTEGER;
procedure ,QFUHPHQWD is
Num_Eventos := Num_Eventos + 1;
end Incrementa;
procedure ,PSULPH is
Imprimir (Num_Eventos);
Num_Eventos := 0;
end Imprime;
process Observador;
repeat
Esperar_Evento;
&RQWUROB(YHQWRV,QFUHPHQWD
forever;
end Observador;
process Reportero;
repeat
&RQWUROB(YHQWRV,PSULPH
Hacer_Otras_Cosas;
forever;
end Reportero;
6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

Los monitores son una construccin de los lenguajes de programacin, de tal forma
que los compiladores saben que las llamadas a los procedimientos de un monitor se
manejan de forma distinta a las llamadas a los procedimientos convencionales.
Normalmente, en la llamada de un proceso a un procedimiento de un monitor, las
primeras instrucciones del procedimiento son para comprobar si algn otro proceso
se encuentra dentro del monitor; si es as, el proceso llamante queda bloqueado
hasta que el otro proceso salga del monitor. Si no hay ningn proceso dentro del
monitor, el proceso llamante puede entrar y continuar la ejecucin.
La implementacin de la exclusin mutua en las entradas del monitor es labor del
compilador. Normalmente suele realizarse con ayuda de un semforo binario, de tal
forma que en el prlogo de un procedimiento de monitor, se incluye una llamada a
Bajar(S), y a la terminacin del procedimiento se llama a Subir(S), siendo S un
semforo asociado a cada monitor.
Ya que es el compilador, no el programador, el que se ocupa de cumplir el protocolo
de acceso a la regin crtica, es mucho ms difcil que algo se haga mal o que se
produzca algn olvido. En cualquier caso, la persona que escribe un monitor no
tiene por qu saber cmo implementa la exclusin mutua el compilador. Le basta
con saber que metiendo las regiones crticas en monitores, nunca habr ms de un
proceso dentro de la misma regin crtica al mismo tiempo.
Puesto que cuando un proceso se encuentra dentro de un monitor, no puede entrar
otro proceso, debe evitarse que el proceso que est dentro pueda quedarse
bloqueado en estado de Espera, o sea, que no debe ejecutar llamadas al sistema
que lo pasen a tal estado. Sin embargo hay situaciones en las que se requiere pasar
a Espera. Para ello, existen otras construcciones, para que cuando un proceso
dentro de un monitor deba pasar a espera, se permita la entrada a algn otro
proceso que est esperando para entrar. Aunque estas construcciones (las YDULDEOHV
FRQGLFLyQ), no vamos a tratarlas en estos apuntes, puede obtenerse una descripcin
detallada consultando la bibliografa de referencia.

 3DVRGH0HQVDMHV
Aunque los semforos y los monitores son buenos mecanismos para la
sincronizacin de procesos todava tienen algunas pegas: los semforos son de
demasiado bajo nivel, y los monitores solamente estn disponibles en unos pocos
lenguajes de programacin.
Otro problema con los monitores y los semforos es que estn diseados para
resolver el problema de la exclusin mutua en sistemas con una o ms CPUs que
comparten una memoria comn. Pero cuando se trata de un sistema distribuido,
formado por mltiples procesadores, cada uno con su propia memoria particular y
conectados por una red de rea local, estas primitivas se vuelven inservibles, pues
ya no hay variables compartidas, y ninguno de estos mecanismos proporciona
intercambio de informacin entre mquinas. Se necesita algo ms.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

3DVRGH0HQVDMHV

&RPXQLFDFLyQGH3URFHVRV

&RPXQLFDFLyQ
HQWUH3URFHVRV

0HPRULD&RPSDUWLGD

3DVRGH0HQVDMHV

(OSURJUDPDGRUUHVXHOYHORV
SUREOHPDVGHFRQFXUHQFLD

1RKD\YDULDEOHV
FRPSDUWLGDV

(QYLDU0HQVDMH

5HFLELU0HQVDMH

3URF


3URF


5HFLELU0HQVDMH

(QYLDU0HQVDMH

$/*81$6&8(67,21(6
8QLGLUHFFLRQDO 0HPRULD&RPSDUWLGD
(O(QODFH
%XV+DUGZDUH
3XHGH6HU
%LGLUHFFLRQDO
5HGGH&RPXQLFDFLRQHV

+ 0RGHORV
/yJLFRV

&RPXQLFDFLyQ',5(&7$R,1',5(&7$
&RPXQLFDFLyQ6,0e75,&$2$6,0e75,&$

+ &DSDFLGDGGHO%X]yQ
+

7DPDxRGHO0HQVDMH

6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

)LMR
9DULDEOH
*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

Ese algo ms es el SDVRGHPHQVDMHV. La funcin del paso de mensajes es permitir

que dos procesos se comuniquen sin necesidad de utilizar variables compartidas.
Este mtodo de comunicacin entre procesos ofrece, al menos, dos primitivas:
(QYLDU y 5HFLELU, que, a diferencia de los monitores, no son construcciones del
lenguaje de programacin, sino Llamadas al Sistema, por lo que para utilizarlas
basta con llamar a los correspondientes procedimientos de biblioteca.
Mediante (QYLDU se expide un mensaje a un proceso destino, mientras que con
5HFLELU se indica el deseo de recibir un mensaje de algn proceso fuente. Si no hay
ningn mensaje disponible, el proceso receptor puede quedarse bloqueado hasta
que llegue uno.
El paso de mensajes no es de uso exclusivo de sistemas con mltiples
procesadores (con o sin memoria comn), sino que es vlido para cualquier sistema
multiproceso, ya sea con una o ms CPUs, o con memoria compartida o local a
cada procesador, pues su semntica solamente indica el paso de informacin de un
proceso a otro. Esta independencia del hardware subyacente hace que los
programas que utilizan paso de mensajes como mecanismo de sincronizacin y
comunicacin sean ms portables entre distintas mquinas, pues slo requieren que
dispongan del mismo sistema operativo. (Obsrvese que esto no quiere decir que
para que dos procesos que se ejecutan en mquinas distintas puedan comunicarse,
tengan que ejecutarse sobre el mismo sistema operativo; simplemente tienen que
utilizar el mismo protocolo de comunicacin).
Si dos procesos $ y % quieren comunicarse, deben enviarse y recibir mensajes, por
lo que debe establecerse un HQODFH GH FRPXQLFDFLyQ entre ellos. Este enlace
puede implementase de distintas maneras. Aqu no vamos a tratar la
implementacin fsica del enlace (memoria compartida, un bus o una red), que es
ms propia de los cursos de comunicacin de datos, sino que vamos a
preocuparnos de los aspectos lgicos de la implementacin. As, estudiaremos
cuestiones relacionadas con los siguientes puntos:
Cul es el tamao de los mensajes? El tamao es fijo o puede ser variable?
Un enlace puede ser unidireccional o bidireccional? Es decir los mensajes
solamente pueden viajar en un sentido, o en ambos?
Modelos de comunicacin: comunicacin directa o indirecta, simtrica o
asimtrica.
La informacin se puede enviar por copia o por referencia.
En cuanto al tamao de los mensajes que se envan los procesos, pueden ser de
longitud fija o variable. Si slo se permiten mensajes de longitud fija, la
implementacin del sistema es ms fcil, pero tal restriccin dificulta la tarea del
programador.
Veamos el resto de las cuestiones enumeradas en los siguientes apartados.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

 0RGHORVGH&RPXQLFDFLyQ
Primero debemos decir que los procesos reciben mensajes en EX]RQHV. Es decir,
que cuando un proceso enva mensajes, estos van a parar a buzones, y los
procesos que quieren recibirlos tendrn que sacarlos de esos buzones.
Los procesos que desean comunicarse deben disponer de una manera explcita de
indicar el destino del mensaje que se enva, o el remitente del mensaje que se
quiere recibir, y esto depende de que la comunicacin sea 'LUHFWD o ,QGLUHFWD.
&RPXQLFDFLyQ'LUHFWD
En la comunicacin directa de envo de mensajes, tanto el emisor como el receptor
deben indicar explcitamente el proceso destino o remitente del mensaje. As, las
primitivas de envo y recepcin tendrn el siguiente aspecto:
(QYLDU3URFHVRB'HVWLQR0HQVDMH
5HFLELU3URFHVRB2ULJHQ0HQVDMH
Como se puede apreciar en el esquema superior de la Figura 27, cada proceso tiene
su propio buzn de recepcin de mensajes.
Una comunicacin de este tipo tiene las siguientes caractersticas:
Automticamente se establece un enlace entre cada par de procesos que se
quieren comunicar.
Cada uno de ellos necesita saber la identidad del otro proceso con el que se
quiere comunicar.
Un enlace asocia nicamente a dos procesos.
Entre cada par de procesos solamente existe un enlace.
El enlace o comunicacin puede ser unidireccional o bidireccional.
En la Figura 27 tambin tenemos a nuestros dos procesos, el Observador y el
Reportero, comunicndose por mensajes. Tal comunicacin es directa,
unidireccional (el Observador slo enva, y el Reportero solamente recibe) y
VLPpWULFD, pues tanto el emisor como el receptor necesita conocer el nombre del
otro proceso.
Una variante dentro de esta comunicacin directa, es que el modelo sea DVLPpWULFR
(esquema inferior de la Figura 27), es decir, que puede haber mltiples procesos
enviando mensajes a un nico receptor, en cuyo caso el proceso receptor no tiene
que indicar de qu proceso quiere recibir mensajes. En la comunicacin asimtrica,
la llamada al sistema para enviar mensajes permanece invariable, mientras que la
de recepcin, queda as:
5HFLELU,GB3URFHVR0HQVDMH
Donde ambos parmetros son de salida. ,GB3URFHVR contendr el identificador del
proceso que envi el 0HQVDMH recibido.
$SXQWHVGH62,



*HVWLyQGH3URFHVRV

&RPXQLFDFLyQ'LUHFWD

3DVRGH0HQVDMHV

3&DGDSURFHVRWLHQHVXSURSLREX]yQ
3&DGDSURFHVRLPSOLFDGRGHEHLQGLFDU
H[SOtFLWDPHQWHHOQRPEUHGHOUHFHSWRURHPLVRU
(QYLDU30HQVDMH

5HFLELU30HQVDMH

3URF


3URF


5HFLELU30HQVDMH

(QYLDU30HQVDMH

(VTXHPD6,0e75,&2

2EVHUYDGRU

5HSRUWHUR

repeat
. . .
Esperar_Evento
. . .
(QYLDU5HSRUWHUR0HQVDMH
forever

repeat
. . .
5HFLELU2EVHUYDGRU0HQVDMH
. . .
Imprimir_Evento
forever

2EV


(QYLDU5HSRUWHUR0HQVDMH

2EV


(QYLDU5HSRUWHUR0HQVDMH

2EV


5HS
5HFLELU5HPLWHQWH0HQVDMH

(QYLDU5HSRUWHUR0HQVDMH

(VTXHPD$6,0e75,&2
3HJDGHOD
&RPXQLFDFLyQ
'LUHFWD
6LVWHPDV2SHUDWLYRV,



6LFDPELDHOQRPEUHGHXQSURFHVR
KD\TXHUHYLVDUWRGDVODVUHIHUHQFLDVDpO
*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

La desventaja que presenta este modelo de comunicacin directa (tanto el simtrico

como el asimtrico), es el problema que se plantea con el mantenimiento de los
nombres de proceso. Es decir, en un programa, que puede estar formado por
muchos mdulos, si se cambia el identificador de un proceso hay que revisar todos
los mdulos para comprobar y modificar todas las referencias a tal proceso, para
que indiquen el nuevo identificador.
&RPXQLFDFLyQ,QGLUHFWD
Con la comunicacin indirecta, los mensajes se envan a buzones, no a procesos, y,
anlogamente, el receptor debe indicar el buzn del que quiere recibir un mensaje,
no de qu proceso. Vase el croquis superior de la Figura 28.
Un buzn se puede ver como un objeto en el que se pueden poner y retirar
mensajes. Cada buzn tiene un identificador nico. Segn este esquema, un
proceso puede comunicarse con otros procesos mediante distintos buzones. Las
primitivas de envo y recepcin de mensajes quedan as:
(QYLDU%X]yQ0HQVDMH
5HFLELU%X]yQ0HQVDMH
siendo %X]yQ el identificador del buzn al que se enva o del que se desea recibir un
mensaje.
Observando el citado croquis de la Figura 28, puede verse que, ahora, un enlace de
comunicaciones tiene las siguientes propiedades:
Dos procesos solamente pueden comunicarse entre ellos si comparten un
buzn.
Un enlace de comunicaciones puede estar asociado a ms de dos procesos.
Entre cada pareja de procesos comunicantes puede haber varios enlaces,
donde cada enlace corresponde a un buzn.
Un enlace puede ser unidireccional o bidireccional.
Este modelo de comunicacin indirecta ya no adolece del problema del
mantenimiento de los nombres o identificadores de procesos que se produca en la
comunicacin directa, pues ahora nunca se nombra el proceso destino u origen, sino
un buzn comn. Este esquema de comunicaciones es similar al servicio de
$SDUWDGRV GH &RUUHRV que ofrecen las compaas postales. La comunicacin
mediante un apartado de correos, es independiente de la direccin o domicilio real
de la persona o entidad a quien se dirige la correspondencia, ya que sta se le enva
indirectamente, va un apartado de correos, y aunque el destinatario cambie de
domicilio, basta con que siga yendo a recoger la correspondencia al cajetn del
apartado de correos para que la comunicacin siga siendo efectiva. Obviamente, la
comunicacin se mantiene en tanto en cuanto se mantenga invariable el nombre del
buzn o apartado de correos comn. Pero mientras que los cambios de domicilio

$SXQWHVGH62,



*HVWLyQGH3URFHVRV

&RPXQLFDFLyQ,QGLUHFWD

3DVRGH0HQVDMHV

/RV%X]RQHV6RQ&RPSDUWLGRV

2EV


%X]yQB

Enviar (Buzn_1, Mensaje)

2EV


Recibir (Buzn_1, Mensaje);

5HS


%X]yQB

Enviar (Buzn_1, Mensaje)

Enviar (Buzn_2, Mensaje)

Recibir (Buzn_2, Mensaje);

2EV


5HS

Recibir (Buzn_2, Mensaje);

Enviar (Buzn_2, Mensaje)

/RVPHQVDMHVVHHQYtDQ\UHFLEHQDGHEX]RQHVQRDSURFHVRV
5HSB\5HSBHMHFXWDQRecibir (Buzn_2, Mensaje)
2EVBHQYtDXQPHQVDMHDO%X]yQB
+4XpSURFHVRUHFLEHHOPHQVDMHGH2EVB"
(O6LVWHPD2SHUDWLYRRIUHFHVHUYLFLRVSDUD
Procedure &UHDUB%X]RQ (Nombre : in
Buzon

Nombres;

: out Buzones);

procedure &RQHFWDUB%X]RQ (Nombre : in

Buzon
procedure (QYLDU (Buzon

Nombres;

: out Buzones);

: in Buzones;

Mensaje : in Mensajes);
procedure 5HFLELU (Buzon
: in Buzones;
Mensaje : out Mensajes);
procedure 'HVWUXLUB%X]RQ (Buzon : in out Buzones);
6LVWHPDV2SHUDWLYRV,



*HVWLyQGH3URFHVRV

$SXQWHVGH62,

*HVWLyQGH3URFHVRV

son previsibles, no hay razn para no seguir manteniendo el mismo apartado de

correos, y as nadie se ve afectado por el cambio de direccin.
Cuando la comunicacin es indirecta, se pueden tener varios buzones de
comunicacin entre dos procesos, con lo que se puede enviar mensajes a uno u otro
buzn, dependiendo del motivo o importancia de cada mensaje.
Obsrvese que, debido a la flexibilidad que ofrece este esquema, se puede tener
cualquier combinacin numrica de procesos productores y consumidores de
mensajes:
Un productor- un consumidor
Varios productores - un consumidor
Un productor - varios consumidores
Varios productores - varios consumidores
Las primitivas de gestin de buzones y mensajes varan segn el sistema operativo.
No obstante, en el cuadro inferior de la Figura 28 podemos ver las primitivas que se
suelen ofrecer para estos servicios:

Crear un buzn.
Conectarse a un buzn.
Enviar y recibir mensajes de un buzn.
Destruir un buzn.

Para crear un buzn, se llama a la primitiva correspondiente, indicando como

parmetro de entrada el nombre del buzn, esto es, una tira preestablecida de
caracteres (al igual que los nombres de ficheros), y el sistema crea el buzn
devolviendo como parmetro de salida el LGHQWLILFDGRU GHO EX]yQ creado. Este
identificador es el que se debe utilizar en el resto de las operaciones que se realicen
con ese buzn.
Cuando varios procesos vayan a comunicarse mediante un buzn, uno de ellos (el
propietario) lo debe crear y, posteriormente, el resto debe conectarse a l, pues
conocen de antemano el nombre del buzn a compartir. Seguidamente ya pueden
realizar las operaciones de envo y recepcin de mensajes utilizando el identificador
de buzn.
El proceso propietario del buzn debe ocuparse de destruir el buzn cuando no se
requieran ms sus servicios, para liberar la memoria y recursos del sistema que se
utilizan en la gestin del buzn.

 &DSDFLGDGGHO%X]yQ
Un buzn tiene una capacidad que determina el nmero de mensajes que puede
tener almacenados temporalmente. Este almacn se puede ver como una cola de
mensajes asociada al buzn. Bsicamente hay tres posibilidades sobre el tamao
del buzn:
$SXQWHVGH62,



*HVWLyQGH3URFHVRV

&DSDFLGDG/LPLWDGD
La cola tiene una longitud mxima finita (Q mensajes), lo que quiere decir que,
como mucho, podr haber Q mensajes en el buzn esperando a ser recibidos por
uno o varios procesos. As, si la cola no est llena, cuando un proceso enva un
mensaje, ste se encola en el buzn, y el emisor puede continuar la ejecucin sin
ninguna espera. El proceso receptor podra estar esperando a recibir un mensaje,
con lo que ahora ya podra recibirlo y continuar tambin la ejecucin; pero
tambin es posible que no hubiera todava ningn proceso esperando por el
mensaje, en cuyo caso, el mensaje simplemente queda encolado en el buzn
hasta que un proceso quiera recibirlo. No obstante, ya que el tamao del buzn
es limitado, si al enviar un mensaje a un buzn, ste est lleno, entonces hay dos
alternativas:
- El proceso emisor queda bloqueado en espera de que haya espacio libre en
el buzn.
- Como parmetro de salida en la llamada a (QYLDU, se le indica un VWDWXV de
error indicativo del llenado del buzn. En este caso, el proceso emisor no se
bloquea, y se deja en sus manos la decisin de reenvo o no del mensaje.
La tcnica habitual de implementar estos buzones es mediante un buffer
circular.
6LQ/tPLWHGH&DSDFLGDG
La cola de mensajes tiene una longitud potencialmente infinita, por lo que puede
albergar cualquier nmero de mensajes, y por lo tanto, el emisor nunca queda
bloqueado.
Los buzones de capacidad ilimitada suelen implementarse como una lista
encadenada de mensajes, por lo que la limitacin slo est en la cantidad de
memoria que el proceso tiene disponible.
&DSDFLGDG1XOD
La longitud mxima de la cola de mensajes es cero, por lo que no puede haber
mensajes en el buzn esperando a ser recibidos. En este caso, el emisor o
remitente que quiera enviar un mensaje debe esperar hasta que el destinatario
reciba el mensaje. As, los dos procesos deben ponerse de acuerdo en el
momento de realizar el envo/recepcin del mensaje para que la transferencia
tenga lugar. En este caso se dice que la comunicacin es VtQFURQD. A esta
comunicacin sncrona tambin se le conoce con el nombre de UHQGH]YRXV (cita).
Se debe hacer notar que cuando la capacidad del buzn no es cero, el proceso
emisor no sabe cundo un mensaje enviado ha llegado a su destino, pues no tiene
que esperar a que el proceso destino lo reciba (comunicacin DVtQFURQD), y esto
puede ser crucial para el normal desarrollo del programa. En este caso, el receptor
debera comunicarse explcitamente con el emisor para hacerle saber que ha
recibido el mensaje.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

3DVRGH0HQVDMHV

&DSDFLGDGGHO%X]yQ

+&DSDFLGDG/LPLWDGDQPHQVDMHV
6LKD\HVSDFLR(OHPLVRUFRQWLQ~DODHMHFXFLyQ
GHVSXpVGHOHQYtR
6LHVWiOOHQR3(OHPLVRUTXHGDEORTXHDGRKDVWDTXH
KD\DHVSDFLRHQHOEX]yQSDUDGHMDU
XQPHQVDMH
36HGHYXHOYHXQVWDWXV OOHQR

+&DSDFLGDG,OLPLWDGD
(OHPLVRUQXQFDVHEORTXHDHQHOHQYtRGHPHQVDMHV

+&DSDFLGDG1XOD
(OHPLVRUTXHGDEORTXHDGRKDVWDTXHHOUHFHSWRUHVWi
OLVWRSDUDUHFLELUHOPHQVDMH
&RPXQLFDFLyQ
6tQFURQD

5(1'(=9286

(QORVEX]RQHVFRQFDSDFLGDG!
&yPRVDEHHOHPLVRUTXHHOPHQVDMHKDOOHJDGRDVXGHVWLQR"
PROCESO P1:
Enviar (P2, Mensaje);
Recibir (P2, Mensaje);
PROCESO P2:
Recibir (P1, Mensaje);
Enviar (P1, Mensaje);

6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

+D\TXHIRU]DUHO
VLQFURQLVPR

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

7KUHDGV
Vamos a comentar ahora un nuevo tipo de procesos que en los ltimos aos a
surgido con fuerza entre los sistemas operativos y que se adapta especialmente
bien a la estructura de los sistemas con mltiples procesadores: los WKUHDGV o
procesos ligeros.
Para que un programa pueda ejecutarse (convertirse en proceso) se requieren dos
elementos:
Un procesador.
Un entorno de ejecucin.
El entorno de ejecucin se refiere al resto de los recursos (adems del procesador)
que necesita un programa para ejecutarse. As, por ejemplo, sabemos que se
necesita un rea de memoria para acoger el cdigo del programa, un rea de
memoria para ubicar las variables globales, otro rea de memoria, denominado
KHDS, de donde se sirven las peticiones dinmicas de memoria, y por ltimo tambin
se necesita un rea de memoria para albergar la pila de trabajo. Una vez que el
proceso est cargado en memoria puede comenzar su ejecucin. Con memoria
virtual, el comienzo de la ejecucin va a implicar que todas las primeras referencias
a memoria generen una falta de pgina, tanto en la cach como en memoria
principal, por lo que se deber dedicar un tiempo a la carga de pginas iniciales
hasta que se consiga el conjunto de trabajo estable. Tambin es normal que un
proceso haga operaciones de E/S con ficheros, por lo que ser necesario abrir los
ficheros con los que se vaya a trabajar, y durante la ejecucin se tendrn EXIIHUV de
E/S asociados con cada dispositivo o fichero. Como nos podemos imaginar se
requiere cierto tiempo para conseguir un entorno de ejecucin estable.
Los procesos tradicionales (como los de Unix) se crean de tal forma que comparten
el procesador (en un entorno monoprocesador) y a cada uno se le asigna un entorno
de ejecucin diferente, es decir, cada uno tiene sus reas de memoria, sus tablas de
pginas, sus descriptores de los ficheros que maneja, sus EXIIHUV de E/S,
semforos, etc. Y esto, que parece razonable, se hace para todos los procesos del
sistema, es decir, se trata a todos los procesos del sistema como si fueran
totalmente disjuntos y que lo nico que comparten es el procesador.
Ahora bien, hay situaciones en las que un trabajo laborioso, puede descomponerse
en varias subtareas o subprocesos, de tal forma que todos ellos cooperan en la
consecucin de un mismo fin. En estos trabajos es normal que haya mucha
comunicacin y compartimiento de datos entre los subprocesos componentes. El
mecanismo normal de comunicacin en estos casos son los mensajes, que no deja
de ser un mecanismo costoso en tiempo. La comunicacin entre procesos por
memoria compartida, aunque rpida, es peligrosa, pues un proceso malintencionado
podra machacar reas de memoria de otro proceso con el que comparte memoria,
sin embargo esto no es normal en procesos cooperantes.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

7KUHDGV
3DUDHMHFXWDUXQSURJUDPDVHUHTXLHUH
0&

(QWRUQRGH(MHFXFLyQ
(VSDFLRGHGLUHFFLRQHV
9DULDEOHVJOREDOHV
)LFKHURVDELHUWRV
7HPSRUL]DGRUHV
3URFHVRVKLMRV
6HxDOHV
6HPiIRURV
&RQWDELOLGDG

&RQWDGRUGHSURJUDPD
3XQWHURGHSLOD
5HJLVWURGHHVWDGR
5HJLVWURVJHQHUDOHV


&DPELRGH
FRQWH[WR

3&DPELRHQHOSURFHVDGRU
3&DPELRGHHQWRUQRGHHMHFXFLyQ
)DOWDVGHSiJLQD
)DOWDVGHFDFKp
$EULUILFKHURV
/OHQDUEXIIHUVGH(6

1HFHVDULRFRQ3URFHVRV
'LVMXQWRV
3(52
SLOD
3URFHVRV&RRSHUDQWHV
38('(1&203$57,5
5(&85626

SLOD

GDWRV
FRG

FRG

3

3

SLOD

SLOD

GDWRV
FyGLJR
3

3

3&UHDFLyQ5iSLGDGH3URFHVRV
3&DPELR5iSLGRGH&RQWH[WR

6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

Hemos visto que la creacin de un proceso puede ser un tanto costosa, pues crea
un entorno de trabajo totalmente diferente para cada uno. Sin embargo, para
procesos cooperantes parece que no se requieren entornos totalmente distintos,
pues es muy posible que prefieran reas de memoria comunes para compartir datos
(a su propio riesgo) y comunicarse rpidamente. Es ms, seguramente prefieren
compartir las memorias cach, y los EXIIHUV de E/S, pues parte de los datos que
manejan van dirigidos o provienen de las mismas fuentes. Dos o ms procesos
gemelos cooperantes podran compartir incluso el rea de cdigo. Segn esto, la
creacin de procesos cooperantes requerira un entorno de trabajo muy reducido: la
pila de trabajo y, en caso de procesos no gemelos, un rea de memoria para el
cdigo. Esto traera ventajas por dos vertientes:

Creacin rpida de procesos

Cambio rpido de contexto

Debemos darnos cuenta de que, en este escenario, la conmutacin del entorno de

trabajo entre dos procesos cooperantes puede ser muy rpida, pues solamente hay
que cambiar los registros del procesador (lo cual implica un cambio de pila de
trabajo y de contador de programa). El proceso que asume la posesin del
procesador va a seguir utilizando las mismas reas de memoria para datos
estticos, cdigo (si los procesos son gemelos), ficheros, EXIIHUV de E/S. El
compartimiento de memoria va a implicar, adems, que al cambiar de contexto no
se van a vaciar las cachs y no se van a producir faltas de pgina en las primeras
referencias a memoria, con lo que se evitan ms prdidas de tiempo.
Por lo visto hasta ahora, parece que sera interesante que los sistemas operativos
ofrecieran dos tipos de procesos (cooperantes y no cooperantes), con sus
correspondientes primitivas de creacin, gestin, comunicacin y sincronizacin.
Prcticamente todos los ncleos de sistemas operativos para sistemas distribuidos
ofrecen los dos tipos de procesos, y estos son los nombres que les han dado:
.HUQHOGH62SURFHVRVFRRSHUDQWHV3URFHVRVQRFRRSHUDQWHV
$PRHED
7KUHDG
Proceso
&KRUXV
7KUHDG
Actor
0DFK
7KUHDG
Tarea
96\VWHP
Proceso
Equipo (7HDP)
Aunque los distintos sistemas operativos no se han puesto totalmente de acuerdo,
los nombres ms extendidos son los proceso, tarea o proceso pesado para los
procesos tradicionales (los que tienen un entorno de trabajo totalmente diferente de
los dems procesos), y WKUHDG o SURFHVROLJHUR para los procesos cooperantes que
quieren compartir el entorno de trabajo.
Windows/NT, OS/2 y Solaris (Unix de Sun) son algunos ejemplos de sistemas
operativos comerciales que disponen de WKUHDGV.



$SXQWHVGH62,

*HVWLyQGH3URFHVRV

7KUHDGV
.HUQHOGH62

3URF&RRSHUDQWHV

3URF1R&RRSHUDQWHV

7KUHDG
7KUHDG
7KUHDG
3URFHVR

3URFHVR
$FWRU
7DUHD
(TXLSR7HDP

7KUHDG
R
3URFHVR/LJHUR

3URFHVR
R
3URFHVR3HVDGR

$PRHED
&KRUXV
0DFK
96\VWHP

0D\RU
1~PHURGH
3URFHVRV
&RRSHUDQWHV

0HMRUDSURYHFKDPLHQWR
GHORV7KUHDGV
WKUHDG
UHSDUWLGRU

5$0FRPSDUWLGD

/RV6'VHSUHVWDQD
WHQHUDSOLFDFLRQHV
IRUPDGDVSRUPXFKRV
SURFHVRVFRRSHUDQWHV

WKUHDGV
GHVHUYLFLR

FDFKp

SHWLFLyQ
62

&UHDUSURFHVRWKUHDG

8QL[
7RSD]

EX]yQ

&DPELRFRQWH[WR

PV

PV

PV

PV

6REUHXQSURFHVDGRU&9$;GH',*,7$/
6LVWHPDV2SHUDWLYRV,

$SXQWHVGH62,

*HVWLyQGH3URFHVRV



*HVWLyQGH3URFHVRV

A los programas con WKUHDGV se les saca ms provecho en aplicaciones compuestas

de mltiples procesos cooperantes, y esto es algo que se suele dar mucho en los
sistemas distribuidos, en los que por su filosofa cliente-servidor se prestan mucho a
este tipo de aplicaciones. Debido a la premura de tiempo no vamos a profundizar en
esta justificacin, no obstante, se recomienda echar un vistazo a los captulos
dedicados a WKUHDGV de los textos indicados en la bibliografa, en los cuales pueden
encontrarse numerosos ejemplos de situaciones de programas en las que se
muestran beneficios de los WKUHDGV frente a los procesos convencionales.
Algunos datos sobre los tiempos creacin de procesos nos pueden ayudar a
convencernos de las ventajas de los WKUHDGV. La creacin de un proceso Unix sobre
un procesador CVAX de DIGITAL requiere 11 milisegundos, mientras que la
creacin de un WKUHDG en un kernel llamado Topaz, sobre el mismo procesador
solamente necesita 1 milisegundo. Los tiempos de cambio de contexto entre
procesos Unix oscilan alrededor de 1,8 milisegundos, siendo solamente 0,4 ( y en
algunos casos 0,004) entre WKUHDGV de Topaz. A estos datos habra que aadir los
beneficios que se ganan a largo plazo, es decir, el tiempo que no se pierde en
cargar de nuevo las pginas de memoria virtual, de la cach, creacin de
semforos, apertura y cierre de ficheros, llenado de EXIIHUV de E/S, etc.



$SXQWHVGH62,