Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Sistemas Operativos
Sistemas Operativos
e General
1 Introdu
ion a los Sistemas Operativos
2 Pro esos
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
1
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
4
4
5
5
6
7
7
8
8
8
8
9
9
11
11
11
12
12
12
13
13
15
16
16
16
17
18
19
20
23
23
23
23
25
26
27
27
27
27
INDICE GENERAL
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
31
31
31
32
32
32
34
34
34
35
35
35
37
37
37
38
39
40
40
40
41
41
43
47
47
48
48
48
49
50
52
52
52
53
53
55
57
57
58
58
58
58
60
62
62
Cap
tulo 1
Introdu
i
on a los Sistemas
Operativos
tuar
on la maquina a traves de una interfaz gra
a
o un interprete de
omandos, et
.
Lo pro
esos intera
tuan ne
esariamente
on el
nu
leo para
rear otros pro
esos,
omuni
arse entre
s y obtener memoria para sus datos. Usualmente
(aunque no ne
esariamente) los pro
esos tambien intera
tuan
on el nu
leo para manejar ar
hivos. El
usuario nun
a intera
tua dire
tamente
on el nu
leo.
El usuario intera
tua
on los pro
esos.
Por razones de e
ien
ia y simpli
idad de implementa
ion el nu
leo es la
omponente del sistema
operativo que esta siempre residente en memoria.
En
ambio las apli
a
iones y los utilitarios se
argan
uando se ne
esitan, y por lo tanto no siempre estan
residentes en la memoria
En este
urso se estudiara en profundidad el dise~no del nu
leo de los sistemas operativos. Ademas
el
urso
ontempla a
tividades pra
ti
as en donde se
modi
aran
omponentes del pseudo sistema operativo nSystem.
Procesador
(CPU y memoria)
Apl2
procesos
Apl1
Util2
Sistema
Operativo
Util1
Nucleo
Dispositivos
El problema de la sin
roniza
ion de pro
esos: produ
tor/
onsumidor, losofos
omiendo, le
tores/es
ritores.
{ Sin
roniza
ion entre pro
esos mediante mensajes:
omuni
a
ion sn
rona y
asn
rona.
{ Otros me
anismos de sin
roniza
ion entre
pro
esos: semaforos, regiones
rti
as, monitores.
{
Evalua ion :
pendientes).
Bibliografa :
DE LOS S.O.
1.1. EVOLUCION
A.
Procesador
Satelite
Perforadora
B.
Computador
Principal
C.
Procesador
Satelite
...
1.1.3 Buering
Como la le
tura de
intas es mu
ho mas rapida que Normalmente se entiende por buering una te
ni
a
la de tarjetas, se puede lograr un mejor rendimiento que
onsiste en leer/es
ribir bloques de varias lneas
E1
E2
E3
Cinta
E4
(cinta de
entrada)
P1
Procesador
P2
P3
Impresora
Lectora
Canal 2
S1
S2
S3
S4
Disco
(cinta de
salida)
Fase
Unidad ociosa
Procesador
Principal
Canal
Canal
Canal
Figura 1.4: Uso de
anales para leer, grabar y pro
esar en paralelo
Figura 1.5: Utiliza
ion de
anales para la
onexion
de dispositivos
en una sola opera
ion de entrada/salida. Esto disminuye el tiempo total requerido para la entrada/salida, Jobs intensivos en E/S: En este tipo de jobs
ya que leer/es
ribir 10 lneas toma en la pra
ti
a
asi
el tiempo de pro
eso de un bloque es nmo y
el mismo tiempo que leer/es
ribir una lnea.
por lo tanto muy inferior a su tiempo de le
tuPor ejemplo si en el esquema original el tiempo de
ra/es
ritura. En este tipo de jobs el tiempo de
pro
eso estaba dominado por 10000 le
turas de una
utiliza
ion de la CPU puede ser muy bajo.
lnea
ada una,
on buering fa
tor 10 el tiempo se redu
ira drasti
amente ya que se realizaran solo 1000
opera
iones de le
tura de a 10 lneas que tomaran Ventantas
po
o mas de un de
imo del tiempo sin buering.
Con la te
ni
a de buering se logra un mejor rendiLa te
ni
a de buering es un po
o mas
ompleja miento del pro
esador, ya que ahora aumenta su porque lo des
rito anteriormente, puesto que tambien se
entaje de utiliza
ion. El aumento del
osto es marusan
anales para realizar las opera
iones de le
tu- ginal, ya que los
anales son mu
ho mas e
onomi
os
ra/es
ritura de bloques en paralelo
on el pro
eso del que el pro
esador.
job. Los
anales son pro
esadores espe
ializados en
el movimiento de datos entre memoria y dispositi- Problema : Tiempo de despa
ho prolongado
vos. Son ellos los que intera
tuan
on las
intas
on
mnima interven
ion de la CPU. La CPU solo ne
e- El in
onveniente
on los sistemas o-line es que aumenta el tiempo mnimo trans
urrido desde la ensita intervenir al nal de
ada opera
ion de E/S.
La gura 1.4 muestra la te
ni
a de buering. En trega del job en ventanilla hasta la obten
ion de los
ella se observa que en la fase i se superponen las si- resultados (tiempo de despa
ho). Este aumento se
debe a la demora que signi
a todo el transporte de
guientes a
tividades:
intas entre pro
esadores satelites y pro
esador prin Le
tura del bloque Ei+1 .
ipal. Esta demora se paga aun
uando la
ola de
Pro
eso del bloque que tiene
omo entrada Ei y jobs esperando pro
eso es peque~na.
salida Si.
1.1.4 Simultaneous Peripheral Opera Es
ritura del bloque de salida Si 1
tion On-Line : Spooling
Observe que la fase i +1 solo puede
omenzar
uan- El termino On-Line signi
a que la le
tura de tarjetas e impresion de resultados ya no se realizan en
do todas las partes de la fase i han
on
luido.
El rendimiento de esta te
ni
a depende de la natu- pro
esadores satelites. Las le
toras e impresoras se
one
tan dire
tamente al
omputador aprove
hando
raleza del job que se pro
esa.
los
anales de E/S que este posee (ver gura 1.5). La
Jobs que usan intensivamente la CPU: En este apari
ion de los sistemas On-Line o
urre gra
ias a la
tipo de jobs el tiempo de pro
eso de un bloque apari
ion de dis
os de
osto relativamente bajo.
de datos es muy superior al tiempo de le
tura y Al igual que los sistemas O-Line, los sistemas Ones
ritura de un bloque. En este tipo de jobs se Line tambien permiten lograr un mejor grado de utial
anza un 100% de utiliza
ion de la CPU.
liza
ion del pro
esador prin
ipal. La idea es que un
DE LOS S.O.
1.1. EVOLUCION
Canal 1
Lect.
Job1
Lect. Lect.
Job 2 Job 3
(lectora de
tarjetas)
Procesador
Cinta 2
Proceso
Job 1
Proceso
Job 2
Impresion
Job 1
Proceso
Job 3
Impresion
Job 2
Impresion
Job 3
(impresora)
ompartidos.
Interrup
iones.
Tiempo de CPU obtenido en forma de tajadas
de tiempo del pro
esador real.
Desde la apari
ion de los sistemas bat
h los programadores tienen mu
has di
ultades para depurar sus
programas. El tiempo de despa
ho de
ada prueba
que realizan es bastante prolongado, aun en los sistemas de multiprograma
ion. A medida que los
ostos
de los
omputadores bajan, el
osto de los programadores y el tiempo de desarrollo se
onvierten en
omponente importante para el usuario. Es de1.1.5 Sistemas de Multiprograma
ion una
ir, por primera vez el problema se
entra en mejorar
En un sistema On-Line en un instante dado pueden la produ
tividad de los programadores y no la del
haber varios pro
esos listos para eje
utarse (en el
omputador.
1.1.7 Sistemas de Tiempo Comparti- de bajo
osto. Es de
ir 10
omputadores personales son mu
ho mas baratos que un sistema de tiempo
do
A prin
ipio de los '70 apare
en los primeros sistemas de tiempo
ompartido. En estos sistemas varios
programadores o usuarios pueden trabajar intera
tivamente
on el
omputador a traves de terminales.
Es de
ir re
uperan aquella
apa
idad de trabajar dire
tamente
on el
omputador,
apa
idad que haban
perdido
on la apari
ion de los sistemas bat
h.
Ahora
ada programador tiene su propia
onsola
en donde puede realizar una depura
ion mas
omoda.
Ademas los usuarios disponen de un sistema de ar
hivos en lnea que pueden
ompartir. Ya no se habla
de tiempo de despa
ho de un job, sino que mas bien
tiempo de respuesta de un
omando, el que se redu
e
drasti
amente.
En los sistemas de tiempo
ompartido los usuarios
omparten re
ursos e informa
ion {abaratando
el
osto del sistema{ pero manteniendo una relativa
independen
ia entre programadores o usuarios {sin
que se molesten entre ellos.
Problema : El pro
esador es un
uello de botella
A medida que
re
e el numero de usuarios, el desempe~no del sistema se degrada, ya sea por es
asez de
CPU o es
asez de memoria.
1.1.8 Computadores Personales
A nes de los '70, gra
ias al progreso en la miniaturiza
ion es posible in
luir todas las fun
iones de una
CPU en un solo
hip, el que se llamo un mi
ropro
esador. Con ellos se puede
onstruir
omputadores no
muy rapidos (
omparados
on los sistemas de tiempo
ompartido de esa epo
a), pero que por su bajo
osto
es posible destinar a un solo programador o usuario,
sin ne
esidad de
ompartirlo. De ah su nombre de
omputador personal.
Los
omputadores personales no tienen ne
esidad
de in
orporar las
ara
tersti
as de los sistemas bat
h
o de tiempo
ompartido. Por ello, en un
omienzo
solo in
orporan un monitor residente (
omo CP/M80 o su su
esor MS-DOS) y no un verdadero sistema
operativo que soporte multiprograma
ion o maquinas
virtuales. Tampo
o ne
esita
anales de E/S (sin embargo los
omputadores personales de hoy en da s
in
orporan todas estas
ara
tersti
as).
La atra
ion que ejer
en en esa epo
a los
omputadores personales se debe a que son sistemas intera
tivos
on un tiempo de respuesta prede
ible y son
DE LOS S.O.
1.1. EVOLUCION
fa
ilmente la informa
ion. La idea es que el usuario se
one
te a un terminal inteligente (esta
ion o
puesto de trabajo), es de
ir que
ontiene un pro
esador en donde
orren sus programas. Pero la vision
que el usuario tiene es la de un sistema de tiempo
ompartido. El
omputador es la red, los dis
os que
se ven en este
omputador pueden estar fsi
amente
en
ualquiera de las esta
iones de trabajo, es de
ir
el sistema
omputa
ional de tiempo
ompartido esta
fsi
amente distribuido en varias esta
iones de trabajo. De ah la apela
ion de sistemas distribuidos.
Este esquema se implementa inter
one
tando
omputadores de
osto mediano a traves de una red. Estos
omputadores son de
osto medio porque in
orporan todas las
ara
tersti
as de un sistema de tiempo
ompartido (sistema operativo,
anales, pro
esadores virtuales), aunque no son tan rapidos
omo los
omputadores de tiempo
ompartido avanzados de la
epo
a.
La desventaja de los sistemas distribuidos y de las
redes de PCs esta en su alto
osto de administra
ion. En efe
to, estos sistemas requieren aten
ion
ontinua de operadores que intervienen
uando hay
momentos de des
onexion de la red. Esto se debe
a que en la pra
ti
a los sistemas distribuidos se implementan en base a par
hes al sistema operativo de
tiempo
ompartido que
orre en
ada esta
ion. Por
lo tanto la mayor parte del software no esta dise~nado
para tolerar des
onexiones de la red aunque sean momentaneas.
Del mismo modo, las redes de PCs se implementan
omo par
hes al monitor residente de los PCs y
por lo tanto adole
en del mismo problema. Hoy en
da se realiza una amplia investiga
ion para dise~nar
sistemas operativos distribuidos tolerantes a fallas.
1.1.11 Sistemas multipro
esadores
La ter
era forma de resolver el problema de los sistemas de tiempo
ompartido es agregar mas pro
esadores al
omputador
entral. Un sistema multipro
esador posee de 2 a 20 pro
esadores de alto desempe~no
que
omparten una misma memoria real (al menos
128 MB).
El sistema multipro
esador se
omporta
omo un
sistema de tiempo
ompartido pero que es
apaz de
eje
utar efe
tivamente varios pro
esos en paralelo,
uno en
ada pro
esador. Sin embargo, un pro
eso
nun
a se eje
uta al mismo tiempo en mas de un pro
esador. Cuando la
antidad de pro
esos en eje
u
ion
supera al numero de pro
esadores reales, se re
urre a
la reparti
ion del tiempo de CPU en tajadas, al igual
que en los sistemas de tiempo
ompartido.
10
Cap
tulo 2
Pro
esos
Un pro
eso es un programa en eje
u
ion. Este programa se eje
uta en un pro
esador, tiene su
odigo,
datos, pila, un
ontador de programa y un puntero a
la pila.
Cuando el sistema operativo ofre
e multiples pro
esos, los pro
esadores son virtuales y el nu
leo multiplexa el pro
esador real disponible en tajadas de
tiempo que otorga por turnos a los distintos pro
esos.
Cuando el
omputador es multipro
esador y el sistema operativo esta dise~nado para explotar todos
los pro
esadores disponibles, enton
es los pro
esos se
pueden eje
utar efe
tivamente en paralelo.
1 proceso
MEM
MEM
MEM
CPU
CPU
CPU
Procesos Pesados
MEM
1 thread
CPU
CPU
CPU
Procesos Livianos
11
12
CAPITULO 2. PROCESOS
parten. Si se ne
esita que un thread
omunique informa
ion a otro thread basta que le enve un puntero
a esa informa
ion. En
ambio los pro
esos pesados
ne
esitan enviar toda la informa
ion a otro pro
esos
pesado usando pipes, mensajes o ar
hivos en dis
o,
lo que resulta ser mas
ostoso que enviar tan solo un
puntero.
2.1.2 Preemption
non-preemption
versus
o lanza una nueva tarea que eje
uta el pro
edimiento pro
. A
epta un m'aximo de 6 par'ametros
(enteros o punteros) que son traspasados dire
tamente a pro
. Retorna un des
riptor de la tarea
lanzada.
void nExitTask(int r
) : Termina la eje
u
ion de la tarea que lo invo
a, r
es el
'odigo de
retorno de la tarea.
int nWaitTask(nTask task) : Espera a que
una tarea termine, entrega el
'odigo de retorno dado a nExitTask.
void nExitSystem(int r
) : Termina la eje
u
ion de todas las tareas. Es de
ir, termina el
pro
eso Unix
on
odigo de retorno r
.
En la gura 2.2 se observa que si una tarea A espera otra tarea B antes de que B haya terminado,
A se bloquea hasta que B invoque nExitTask. De
la misma forma, si B termina antes de que otra tarea invoque nWaitTask, B no termina {permane
e
bloqueada{ hasta que alguna tarea lo haga.
Como ejemplo veamos
omo se
al
ula un numero
de Fibona
i usando las tareas de nSystem :
int pfib(int n)
{
if (n<=1) return 1;
else
{
nTask task1= nEmitTask(pfib, n-1);
nTask task2= nEmitTask(pfib, n-2);
return nWaitTask(task1)+nWaitTask(task2);
} }
La eje
u
ion de pfib(6)
rea dos tareas que
al
ulan
on
urrentemente pfib(5) y pfib(4). Como a
su vez estos dos pro
edimientos
rean nuevas tareas,
al nal se
rea un arbol de tareas.
Observe que esta solu
ion se introdu
e solo
on motivos pedagogi
os. Ella es sumamente ine
iente
omo me
anismo para
al
ular un numero de Fibona
i, puesto que el sobre
osto natural introdu
ido por la
13
Tarea B
Count == 2
t=nEmitTask(P)
Reg==2
Count==3
rc=nWaitTask(t)
Count=3 !
nExitTask(rc)
B
t=nEmitTask(P)
nExitTask(rc)
rc=nWaitTask(t)
Esta solu
ion es errada. En efe
to, la instru
ion En nSystem se pueden implementar se
iones
rti
as
en C
ount++ se tradu
e por una se
uen
ia de ins- mediante mensajes. El envo de mensajes en nSystem
tru
iones de maquina del tipo :
se logra
on los siguientes pro
edimientos:
Load
ount, Reg ; Reg=
ount
Add Reg, 1, Reg ; Reg= Reg+1
Store Reg,
ount ;
ount= Reg
14
CAPITULO 2. PROCESOS
ualquier tama~no. El emisor se queda bloqueado hasta que se le haga nReply. nSend retorna
un entero espe
i
ado en nReply.
do
{
nTask sender;
int *msg= (int*)nRe
eive(&sender, -1);
end= *msg;
ount++;
nReply(sender, 0);
}
while (end==FALSE);
Re
ibe un mensaje
proveniente de
ualquier tarea. La identi
a
ion
del emisor queda en *ptask. El mensaje retornado por nRe
eive es un puntero a un area que
ha sido posiblemente
reada en la pila del emisor. Dado que el emisor
ontinua bloqueado hasta que se haga nReply, el re
eptor puede a
esar
libremente esta area sin peligro de que sea destruida por el emisor.
La tarea que lo invo
a queda bloqueada por
max delay miliseg, esperando un mensaje. Si el
perodo naliza sin que llegue alguno, se retorna
NULL y *ptask queda en NULL. Si max delay es
0, la tarea no se bloquea (nRe
eive retorna de
inmediato). Si max delay es -1, la tarea espera
indenidamente la llegada de un mensaje.
void nReply(nTask task, int r
) : Responde un mensaje enviado por task usando nSend.
Desde ese instante, el re
eptor no puede a
esar
la informa
ion
ontenida en el mensaje que haba
sido enviado, ya que el emisor podra destruirlo.
El valor r
es el
odigo de retorno para el emisor.
nReply no se bloquea.
Con estos pro
edimientos el problema de la se
ion
rti
a se puede resolver
reando una tarea que realiza
el
onteo de tareas.
int
ount=0; /* Contador de tareas */
return ount-1;
15
Durante el lanzamiento de nSystem se realizan algunas ini
ializa
iones y luego se invo
a el pro
edimiento
nMain, el que debe ser suministrado por el programador. E ste pro
edimiento
ontiene el
odigo
orrespondiente a la primera tarea del programador. Desde
ah se pueden
rear todas las tareas que sean ne
esarias para realizar el trabajo. El en
abezado para este
pro
edimiento debe ser:
int nMain(int arg
,
har *argv[)
{
...
}
El retorno de nMain ha
e que todas las tareas pendientes terminen y por lo tanto es equivalente a llamar nExitSystem. Es importante por lo tanto evitar
que nMain se termine antes de tiempo.
Los siguientes pro
edimientos son parte de nSystem y pueden ser invo
ados desde
ualquier tarea de
nSystem.
Par'ametros para las tareas:
void nSetSta
kSize(int new size) : Dene
el tama~no de la pila para las tareas que se emitan
a
ontinua
ion.
Tama~no de
la tajada de tiempo para la administra
ion
Round{Robin2 (preemptive) (sli
e esta en miliseg). Degenera en FCFS (non{preemptive) si
sli
e es
ero, lo que es muy u
til para depurar
programas. El valor por omision de la tajada de
tiempo es
ero.
la tarea
que la invo
a. El formato y los parametros que
re
ibe son analogos a los de printf.
Entrada y Salida:
Los siguientes pro
edimientos son equivalentes a
open,
lose, read y write en UNIX. Sus parametros
son los mismos. Los \nano" pro
edimientos solo bloquean la tarea que los invo
a, el resto de las tareas
puede
ontinuar.
: Cierra un ar
hivo.
int nRead(int
fd,
har *buf, int nbyte)
: Lee de un ar-
int nWrite(int
fd,
har *buf, int nbyte)
: Es ribe en un
hivo.
ar
hivo.
Servi
ios Mis
elaneos:
nTask nCurrentTask(void)
16
CAPITULO 2. PROCESOS
void BuffServ()
{
har pbuff2[512;
for(;;)
{
nTask
lienttask;
har *pbuff;
} }
2.3 Semaforos
2.3.1 El
problema
produ
tor/
onsumidor
del
Los mensajes de nSystem son un me
anismo para sin- Un pro
eso produ
tor produ
e temes depositandolos
ronizar pro
esos. Existen otros me
anismos que ve- en un buer. Los temes son extrados del buer por
17
2.3. SEMAFOROS
nextempty
Consumidor
Productor
nextfull
} }
Wait(empty);
buff[nextempty= x;
nextempty= (nextempty+1)%N;
Signal(full);
Consumidor()
{
for(;;) /* Ci
lo infinito */
{
Item x;
Wait(full);
x= buff[nextfull;
nextfull=(nextfull+1)%N;
Signal(empty);
Consume(x);
/* Listo, ya
onsumimos el item */
} }
nextempty
18
CAPITULO 2. PROCESOS
j=min(i,(i+1)%5);
k=max(i,(i+1)%5);
Wait(tenedor[j);
Wait(tenedor[k);
Con este orden es imposible la situa ion de deadlo k en que ada pro eso tenga un tenedor y espere el
Cada losofo es un pro
eso. El uso de
ada tenedor Permitir un maximo de 4 losofos en la mesa. Para
es una se
ion
rti
a, ya que dos losofos no pueden lograr esto se ne
esita un nuevo semaforo (sala) que
estar usando el mismo tenedor en un instante dado. parte ini
ialmente
on 4 ti
kets.
El a
eso a los tenedores se
ontrola en un arreglo
i)
de 5 semaforos
on un ti
ket
ada uno. Para poder Folosofo(int
{
omer, el losofo i debe pedir el ti
ket del semaforo for(;;)
i y el del semaforo (i+1)%5.
{
Ini
ialmente se tiene :
Wait(sala);
tenedor es un arreglo de 5 semaforos,
Wait(tenedor[i);
ada uno
on un solo ti
ket.
Folosofo(int i)
{
for(;;)
{
Wait(tenedor[i);
Wait(tenedor[(i+1)%5);
Comer();
Signal(tenedor[i);
Signal(tenedor[(i+1)%5);
Pensar();
} }
} }
Wait(tenedor[(i+1)%5);
Comer();
Signal(tenedor[i);
Signal(tenedor[(i+1)%5);
Signal(sala);
Pensar();
2.4 Monitores
Un monitor es la version
on
urrente de una estru
tura de datos: posee un estado interno mas un
onjunto de opera
iones. A pesar de que las opera
iones
se invo
an
on
urrentemente, el monitor las eje
uta
se
uen
ialmente.
Los monitores fueron inventados por Hoare para
un diale
to de Pas
al, de ah su sintaxis a la Pas
al.
Sintaxis:
type <nombre> = monitor
<variables>
pro
edure entry <pro
1>( <argumentos1> );
19
2.4. MONITORES
<
uerpo>
pro
edure entry <pro
2>( <argumentos2> );
<
uerpo>
...
begin
<ini
ializa
iones>
end
begin
if (
ount=n) then nofull.wait;
pool[in:= x;
in:= (in+1) mod N;
ount:=
ount+1;
noempty.signal;
end
Pro
edure entry Get(var x: Item);
begin
if (
ount=0) then noempty.wait;
x:= pool[out;
out:= (out+1) mod N;
ount:=
ount+1;
nofull.signal;
end;
En este problema varios pro
esos
on
urrentes
omparten una misma estru
tura de datos y ne
esitan
onsultarla o a
tualizarla (modi
arla). Un pro
eso
le
tor es aquel que esta
onsultando la estru
tura y
un pro
eso es
ritor es aquel que la esta modi
ando.
Las
ara
tersti
as de este problema son las siguientes:
Se permite varios pro
esos le
tores al mismo
tiempo.
Solo se permite un es
ritor en un instante dado. Mientras el es
ritor modi
a la estru
tura
no puede haber pro
esos le
tores ni otros pro
esos es
ritores.
Veamos una solu
ion usando monitores. El monitor M
ontrolara el a
eso a la estru
tura de datos.
Se denen enton
es las siguientes opera
iones en el
monitor:
M.EnterRead : Un pro
eso anun
ia que entra en
un trozo de
odigo en que va a
onsultar la estru
tura de datos. Es de
ir el pro
eso se
onvierte en le
tor.
M.ExitRead : El le
tor anun
ia que sale del
odigo de
onsulta.
M.EnterWrite : Un pro
eso anun
ia que entra
a un segmento de
odigo en que va a a
tualizar
la estru
tura de datos. Es de
ir el pro
eso se
onvierte en un es
ritor.
M.ExitWrite : El es
ritor anun
ia que sale del
odigo de a
tualiza
ion.
20
Solu
ion
Var M: Monitor
var readers: integer;
writing: boolean;
anread:
ondition;
anwrite:
ondition;
Pro
edure Entry EnterRead
begin
if (writing) then
anread.wait;
In
r(readers);
anread.signal
end;
Pro
edure Entry ExitRead
begin
De
r(readers);
if (readers=0) then
anwrite.signal
end;
Pro
edure Entry EnterWrite
begin
if ((readers>0)
or writing) then
anwrite.wait; { (1) }
writing:= true
end;
Pro
edure Entry ExitWrite
begin
writing:= false;
anwrite.signal; { (2) }
if (not writing) then
anread.signal { (3) }
end
begin
writing:= false;
readers:= 0
end
CAPITULO 2. PROCESOS
En este tipo de sistemas los mensajes se envan dire
tamente al pro
eso que debe re
ibirlo. Para ello,
al enviar el mensaje se espe
i
a la identi
a
ion del
Observe que en (2) se presentan dos posibilidades. pro
eso
re
eptor (pro
ess identi
ation o pid).
En la primera hay es
ritores esperando por lo que el
pro
eso
ede el monitor al es
ritor bloqueado en (1)
send(dest_pid, msg)
y solo lo re
uperara
uando el es
ritor salga del monitor. Al re
uperar el monitor writing sera verdadera. Ejemplos de este tipo de mensajes son los que imLa segunda posibilidad es que no hayan es
ritores en plementan
nSystem y el lenguaje ADA.
espera. En este
aso el pro
eso no
ede el
ontrol y Los sistemas
de
omuni
a
ion dire
ta se presentan
writing sera falso, por lo tanto si hay le
tores espeen
varios
sabores:
rando, estos seran desbloqueados en (3).
Esta solu
ion tiene in
onvenientes, puesto que los
on de un solo pro
eso: El sistema peres
ritores pueden sufrir hambruna (starvation). Un i. Re
ep
i
mite
sele
ionar
el pro
eso emisor del mensaje.
pro
eso sufre hambruna
uando otros pro
esos pueden
on
ertarse para ha
er que nun
a logre obtener
un re
urso. En este
aso, si siempre hay le
tores
msg= Re
eive(sender_pid)
Si es otro el pro
eso emisor, el mensaje queda en
olado hasta que se espe
ique la identi
a
ion
de ese pro
eso.
ii. Re
ep
ion de
ualquier pro
eso: El sistema obliga a re
ibir los mensajes provenientes de
ualquier pro
eso.
msg= Re
eive(&sender_pid)
21
i. Punto a punto unidire
ional: Solo un pro
eso
puede enviar mensajes por un
anal y solo un
pro
eso puede re
ibir mensajes de ese
anal. En
el lenguaje OCCAM los
anales son de este tipo.
ii. Punto a punto bidire
ional: Un par de pro
esos
usa el
anal para
omuni
arse en ambos sentidos.
Los streams de Unix pertene
en a esta
lase de
anales.
iii. Puerta o port : Cualquier pro
eso puede enviar
mensajes por ese
anal. El emisor espe
i
a otro
anal por donde re
ibir la respuesta.
Los
anales pueden estar orientados ha
ia el envo
de mensajes
omo es el
aso del lenguaje OCCAM.
En otros sistemas los
anales estan orientados ha
ia
el envo de se
uen
ias de
ara
teres
omo es el
aso
de los streams de Unix.
Esto signi
a que el re
eptor debe estar siempre preparado para re
ibir mensajes de
ualquier
pro
eso. Este es el
aso de nSystem y ADA.
iii. Re
ep
ion de algunos pro
esos: Se puede espe
i
ar un
onjunto de los identi
adores de pro
esos de donde se a
epta la re
ep
ion de mensajes
de inmediato. Los mensajes de otros pro
esos
quedan en
olados.
iv. Broad
ast o envo a todos los pro
esos: Se enva Buering
un mensaje que es re
ibido por todos los pro
eLos sistemas de mensajes se agrupan segun la
ansos.
tidad de mensajes que se pueden enviar sin que el
emisor se quede bloqueado.
Broad
ast(msg)
i. 0-buering : Al enviar un mensaje, el emisor se
El mensaje se re
ibe en
ada pro
eso mediante
queda bloqueado hasta que :
Re
eive.
El re
eptor re
iba el mensaje (
on
v. Multi
ast o envo a varios pro
esos: Se enva un
Re
eive).
mismo mensaje a varios pro
esos. Esto es equi El re
eptor responda el mensaje (
on
valente a usar varias ve
es Send
on el mismo
Reply).
mensaje pero
on distintos destinatarios.
Al segundo tipo de mensajes
orresponde el
Comuni
a
ion indire
ta
nSystem y los sistemas de RPC o Remote Pro
edure Call.
Los mensajes se enva a traves de
anales de
omuni
a
ion. Al enviar un mensaje se espe
i
a la identiLa
omuni
a
ion del tipo 0-buering tambien se
a
ion del
anal.
denomina sn
rona.
send(
han_id, msg)
ii. buer a
otado: Los mensajes se
opian en un
buer de tama~no nito de modo que el emisor
Por ejemplo los streams o pipes de Unix
orresponpuede
ontinuar y enviar nuevos mensajes. Si el
den a este tipo de mensajes.
buer esta lleno, el emisor se bloquea hasta que
En algunos sistemas de
omuni
a
ion indire
ta
algun pro
eso re
eptor deso
upe parte del buer.
tambien se puede espe
i
ar un
onjunto de
anales
Este
tipo
de
omuni
a
ion
de donde re
ibir mensajes. Por ejemplo en Unix se
se
denomina
as
n
rona
.
Al
enviar
un mensaje,
usa sele
t para sele
ionar un
onjunto de streams
el
solo
he
ho
de
que
Send
retorne
no
impli
a que
por lo
uales se desea re
ibir datos. Esto es muy util
el
mensaje
fue
re
ibido.
Si
el
emisor
ne
esita
o
uando se desea leer
omandos ingresados a traves de
no
er
uando
un
mensaje
fue
re
ibido,
debe
esvarios terminales. En Unix System V se puede ha
er
perar
un
mensaje
de
vuelta
(un
re
ono
imiento)
lo mismo
on poll.
del re
eptor.
Los
anales de
omuni
a
ion pueden ser del siguiente tipo :
Emisor:
22
CAPITULO 2. PROCESOS
Send(dest_pid, msg);
a
k= Re
eive(dest_pid);
Re
eptor:
msg= Re
eive(&dest_pid);
Send(dest_pid, a
k);
Cap
tulo 3
espacio
libre
memoria
real
4
Gigabytes
memoria
de video
puertas de
dispositivos
memoria
ROM
3.1 Arquite
tura Logi
a del Figura 3.1: Espa
io de dire
iones de un
omputador.
Computador
La arquite
tura logi
a del
omputador es la vision
que tiene un programador de la maquina sobre la
ual
se pretende programar el nu
leo de un sistema operativo. En esta vision no interesa si el
omputador
tiene memoria
a
he o si el pro
esador usa pipeline
para eje
utar las instru
iones de maquina, puesto
que estas son
ara
tersti
as que no in
uyen en el
omo se programa la maquina (salvo si se
onsidera
la e
ien
ia).
En
ambio en la arquite
tura logi
a de un
omputador s interesa
ual es su lenguaje de maquina,
omo se
omanda/examinan los dispositivos,
omo se
re
iben las interrup
iones, et
. Un programador del
sistema operativo s ne
esita
ono
er esta informa
ion
para saber
omo programarlo.
24
} }
Interrup iones
En esta estrategia, se programa el dispositivo y el
ontrolador de interrup
iones para que produz
an una
interrup
ion en el momento de o
urrir el evento esperado en este dispositivo. Luego, el sistema operativo puede desligarse
ompletamente del dispositivo y
dedi
arse a otras a
tividades.
Cuando se produ
e la interrup
ion, el programa en
eje
u
ion se suspende y se eje
uta una rutina de aten
ion en
argada de realizar las a
iones que requiere
el dispositivo que interrumpe. Cuando esta rutina de
aten
ion retorna, se retoma el programa interrumpido.
A pesar que una interrup
ion es
ompletamente
transparente para el programa interrumpido (si la rutina de aten
ion esta bien programada) desde el punto de vista fun
ional, un usuario s puede per
ibir una
degrada
ion en la rapidez de pro
eso si el numero de
interrup
iones es muy elevado.
En este me
anismo
ada byte o palabra transferidos entre el pro
esador y un dispositivo provo
a una
interrup
ion. Dado que un pro
esador de hoy en da
no puede atender mas de 100.000 interrup
iones por
segundo la velo
idad de transferen
ia entre pro
esador y dispositivos usando interrup
iones esta limitada
a no mas de 100.000 bytes/palabras por segundo. Esta velo
idad lmite es inferior a la del me
anismo de
busy-waiting.
El sistema operativo tambien puede inhibir las interrup
iones por
ortos perodos
uando ne
esita eje
utar trozos de
odigo que no puede ser interrupidos.
Para ello un bit en la palabra de estado del pro
esador indi
a si las interrup
iones estan inhibidas o
no.
Lo
aliza
ion de un dispositivo
Codigo
RutinaAtencionDispX:
save R1
save R2
...
load [R1],R2
...
restore R1
restore R2
reti
DispX
DispY
.
.
.
Vector de Interrupciones
RutinaAtencionDispY:
save R2
save R5
...
load [R2],R5
...
restore R2
restore R5
reti
3.1. ARQUITECTURA LOGICA
DEL COMPUTADOR
har pbuff2[512;
int RutinaAten
ionCanalX()
{
leido= TRUE;
}
void ReadBlo
k(
har *pbuff)
{
if (!programado)
ProgramarCanalX();
Canales de E/S
Cuando se requiere transferir grandes bloques de datos entre memoria y dispositivos existen
opro
esadores espe
ializados para estos nes llamados
anales
de E/S o
anales DMA (de Dire
t Memory A
ess).
Para ini
iar este tipo de transferen
ias el sistema
operativo indi
a a algun
anal {a traves de puertas
en el espa
io de dire
iones{ la dire
ion de memoria en donde
omienza el bloque de datos, el tama~no
del bloque, el sentido de la transferen
ia (memoria
a dispositivo o vi
eversa) y la lnea por la
ual el
dispositivo anun
iara que hay un byte/palabra para
transferir. Luego se
omanda al
anal para que ini
ie
la transferen
ia.
De esta forma, el sistema operativo puede desligarse
ompletamente de la transferen
ia, la que se realiza
on mnima degrada
ion del pro
esador al eje
utar
los programas. Al terminar la transferen
ia, el
anal
interrumpe al sistema operativo para que determine
las a
iones a seguir.
La velo
idad de transferen
ia entre memoria y dispositivos esta limitada uni
amente por la velo
idad
del bus que los separa (tpi
amente de 3 a 100 MBytes por segundo).
El siguiente
odigo es una implementa
ion de
ReadBlo
k que usa la te
ni
a de buering (vista en
la introdu
ion).
/* Puertas del dispositivo */
har* puerta_
ontrol=(
har*)0xe0000;
har* puerta_datos= puerta_
ontrol+1;
/* Puertas del
anal */
har**puerta_
analX_ini
io= ...;
int* puerta_
analX_nbytes= ...;
int* puerta_
analX_disp= ...;
har* puerta_
analX_
ontrol= ...;
/* El buffer de bytes */
int leido= FALSE;
int programado= FALSE;
25
while (!leido)
/* busy-waiting */ ;
b
opy(pbuff, pbuff2, 512);
leido= FALSE;
ProgramarCanalX();
void ProgramarCanalX()
{
*puerta_CanalX_ini
io= pbuff2;
*puerta_CanalX_nbytes= 512;
*puerta_CanalX_disp=
<nro. linea DRQ del dispositivo>;
*puerta_CanalX_
ontrol= LEER;
HabilitarIntCanalX();
programado= TRUE;
}
Observe que la rutina de aten
ion atiende las interrup
iones del
anal y no las del dispositivo. Del
mismo modo, son las interrup
iones del
anal las que
se habilitan, no las del dispositivo. Esto se ha
e para
que efe
tivamente se re
iba una sola interrup
ion al
nal del bloque y no una interrup
ion por
ada byte
transferido.
3.1.3 Modo Dual
26
O
1
Accesibles
desde un
proceso
Modo Usuario
Modo Sistema
2 GB
System
Segment
No accesible
0
1
Interrupciones Inhibidas
Interrupciones Activadas
Text
Data
Segment Segment
(codigo) (datos)
4 GB
Stack
Segment
(pila)
Nucleo
del S.O.
27
Manejo de Pro
esos:
rea
ion (fork), des-
28
Una aplicacion
Nucleo (DOS)
Drivers
(BIOS en ROM)
Hardware
(PC)
3.X
Todas estas variantes de Unix tienen estru
tura simiEn sus primeras 3 versiones, DOS era realmente un lar (ver gura 3.6). El nu
leo in
luye los drivers y el
monitor residente que se situaba entre una apli
a
ion sistema de ar
hivos.
y el Hardware/ROM de un PC (ver gura 3.5). Los Ademas de los servi
ios de la API del nu
leo, Unix
objetivos del sistema no eran ambi
iosos puesto que ofre
e mu
hsimos otros servi
ios a traves de pro
esos
deba
orrer en
omputadores
on po
a memoria. demonios, que
orresponden a pro
esos que siempre
Procesos
(CPU y memoria)
Apl2
Util2
Sistema
Operativo
Driver1
Apl1
Util1
Nucleo
Driver2
Driver3
Dispositivos
29
30
Cap
tulo 4
Administra
i
on de Pro
esos
En
Una de las a
tividades fundamentales del nu
leo
Terminado
Creacion
del sistema operativo es implementar pro
esos. Cada
pro
eso es un pro
esador virtual en donde se eje
uta
Listo
Corriendo
una apli
a
ion o una herramienta del sistema operativo. El nu
leo debe en
argarse enton
es de adminisEsperando
trar los re
ursos del hardware del
omputador para
que sean asignados
onvenientemente a los pro
esos.
Figura 4.1: Estados de un pro
esos
En este
aptulo examinaremos
omo el nu
leo asigna el o los pro
esadores reales a los pro
esos. En una
primera etapa supondremos que el hardware solo ofre- de a
eso.
e un pro
esador real. Mas tarde generalizaremos a Para abreviar la nota
ion,
uando se hable de \el
varios pro
esadores.
s
heduler" se subentendera que se trata del s
heduler
del pro
esador.
Exit
Interrupt
Read
Mientras un pro
eso se eje
uta puede pasar por distintos estados. Estos estados se apre
ian en la gura
4.1.
En
rea
ion : el nu
leo esta obteniendo los re
ursos que ne
esita el pro
eso para poder
orrer,
omo por ejemplo memoria o dis
o.
Corriendo : El pro
eso esta en pose
ion del pro
esador, el que eje
uta sus instru
iones.
Esperando : El pro
eso espera que se lea un
se
tor del dis
o, que llegue un mensaje de otro
pro
eso, que trans
urra un intervalo de tiempo,
que termine otro pro
eso, et
.
Listo : El pro
eso esta a
tivo pero no esta en
pose
ion del pro
esador.
Terminado : El pro
eso termino su eje
u
ion,
pero sigue existiendo para que otros pro
esos
puedan determinar que termino.
Un pro
eso pasa de un estado a otro
onstantemente y varias ve
es por segundo. Por ejemplo
uando
31
32
DE PROCESOS
CAPITULO 4. ADMINISTRACION
Exit
Cola
Ready
CP
un pro
eso esta
orriendo el s
heduler puede quitarle el pro
esador para entregarselo a otro pro
eso. En
este
aso el primer pro
eso queda listo para eje
utarse. Es de
ir en
ualquier momento, el pro
esador
puede entregarle nuevamente el pro
esador y quedar
orriendo. De este estado el pro
eso puede leer un
omando del terminal y por lo tando quedar en espera de que el usuario invoque alguna a
ion.
Desde luego el numero exa
to de estados depende del sistema. Por ejemplo en nSystem un pro
eso
puede pasar por los siguientes estados:
READY : Elegible por el s
heduler o
orriendo.
ZOMBIE: La tarea llamo nExitTask y espera
nWaitTask.
WAIT TASK : La tarea espera el nal de otra
tarea.
WAIT REPLY: La tarea hizo nSend y espera
nReply.
WAIT SEND : La tarea hizo nRe
eive y espera
nSend.
WAIT READ : La tarea esta bloqueada en un
read.
WAIT WRITE : La tarea esta bloqueada en un
write.
otros.
fin turno
Cola
Disco 1
read
wait(X)
Descriptor
Proceso X
send(x,...)
Cola nSend
Proceso X
Durante la eje
u
ion, un pro
eso pasa por numerosas
olas a la espera de algun evento. Esto se puede
observar en la gura 4.3.
Mientras un pro
eso espera la obten
ion del pro
esador, este pro
eso permane
e en una
ola del s
heduler del pro
esador. Esta
ola puede estar organizada en una lista enlazada simple (
ada des
riptor de
pro
eso tiene un puntero al proximo des
riptor en la
ola).
Ademas de la
ola del s
heduler del pro
esador
existen la
olas de s
heduling de dis
o. El pro
eso
permane
e en estas
olas
uando realiza E/S.
Cuando un pro
eso enva un mensaje sn
rono a
otro pro
eso que no esta preparado para re
ibirlo, el
primer pro
eso queda en una
ola de re
ep
ion de
mensajes en el des
riptor del pro
eso re
eptor.
Por ultimo el pro
eso puede quedar en una
ola
del reloj regresivo, a la espera de que trans
urra un
instante de tiempo.
4.1.4 Cambio de
ontexto
33
34
DE PROCESOS
CAPITULO 4. ADMINISTRACION
Frecuencia
200
100
Como dijimos anteriormente el s
heduling de pro
esos intenta lograr algun objetivo parti
ular
omo ma123
...
[miliseg]
ximizar la utiliza
ion del pro
esador o atender en forma expedita a usuarios intera
tivos. Para lograr estos
Figura 4.4: Histograma de la dura
ion de la rafagas objetivos
usan diversas estrategias que tienen sus
de CPU. El primer tramo indi
a el numero de rafagas ventajas ysedesventajas.
A
ontinua
ion se expli
an
que duran entre 0 y 1 milisegundo, el segundo tramo las estrategias mas utilizadas.
indi
a las rafagas de 1 a 2 milisegundos, et
.
0
35
P1
P1 P2 P3 P4 P1 ...
P4
P2
corriendo
P3
Cambio de
contexto
Aging es una variante de la estrategia de prioridades que resuelve el problema de la hambruna. Esta
estrategia
onsiste en aumentar
ada
ierto tiempo
la prioridad de todos los pro
esos que se en
uentran
listos para
orrer. Por ejemplo,
ada un segundo se
puede aumentar en un punto la prioridad de los pro
esos que se en
uentran en la
ola ready. Cuando el
s
heduler realiza un
ambio de
ontexto el pro
eso
saliente re
upera su prioridad original (sin las boni
a
iones).
Desde este modo, los pro
esos que han permane
ido mu
ho tiempo en espera del pro
esador, tarde
o temprano ganaran la prioridad su
iente para re
ibirlo.
4.2.4 Round-Robin
36
DE PROCESOS
CAPITULO 4. ADMINISTRACION
Antes
Q
P1
corriendo
P1
Tama~no de tajada
Una primera de
ision que hay que tomar es que tama~no de tajada asignar. Si la tajada es muy grande
la estrategia degenera en FCFS
on todos sus problemas. Al
ontrario si la tajada es muy peque~na el
sobre
osto en
ambios de
ontexto es demasiado alto.
Ademas si la tajada es muy peque~na aumenta el
tiempo promedio de despa
ho. En efe
to, si se tienen dos rafagas de dura
ion t. El tiempo medio de
despa
ho de ambas rafagas
en FCFS
sera :
t
3t
T = t+2
=
2
2
En
ambio en RR
on tajada mu
ho mas peque~na que t, ambas rafagas seran despa
hadas
pra
ti
amente al mismo tiempo en 2t, por lo que el
tiempo medio de despa
ho sera :
T ! 2t
Una regla empri
a que da buenos resultados en
Round-Robin es que se ja el tama~no de la tajada de
modo que el 80% de las rafagas deben durar menos
que la tajada y por lo tanto se eje
utan sin
ambios
de
ontexto de por medio.
Llegada de pro
esos
P3
llega Q
Implementa ion
P2
P4
P4
P2
corriendo
llega Q
P1
P3
P4
P2
corriendo
P3
Q
Despues
siempre esta listo para
orrer y el otro es un pro
eso intensivo en E/S
on rafagas
ortas separadas por peque~nos intervalos de espera. En este
aso el pro
eso de E/S tambien sera desfavore
ido, ya que
uando este pro
eso llega, la
ola
siempre esta va
a y da lo mismo agregarlo al
prin
ipio o al nal. La situa
ion es identi
a a la
de la estrategia anterior.
37
DE PROCESOS EN NSYSTEM
4.4. ADMINISTRACION
nMain
call R
nMain
Return
nMain
38
DE PROCESOS
CAPITULO 4. ADMINISTRACION
Aplicacion
nSystem
nMsg.c
Tareas
nReceive
RtimerHandler
ChangeContext
sigprocmask
Unix
API
nEmitTask
nExitTask
nWaitTask
nSetTimeSlice
VtimerHandler
ResumeNextReadyTask
START_CRITICAL
END_CRITICAL
open select
read
write
close
Mensajes
nSend
nReply
SetAlarm
nDep.c nProcess.c
SigioHandler
nIO.c
Semaforos
nWaitSem
nSignalSem
nSem.c
Monitores
nEnterMonitor
nExitMonitor
nWaitCondtion
nSignalCondition
nMonitor.c
E/S
nOpen
nRead
nWrite
nClose
Implemen
tacion
setitimer
sigaction
T1
T2
P
Q
ChangeContext
T1 > T2
R
S
Q
P
ChangeContext
T2 > T1
En nSystem nun
a hay mas de una nano tarea
o- Figura 4.9: Cambio de pila durante un
ambio de
rriendo realmente. El registro sp del pro
esador
ontexto.
apunta al tope de la pila de la tarea que esta
orriendo.
El
ambio de
ontexto en nSystem lo realiza el s
he- iv. Restaura los registros de la tarea entrante que se
en
uentran en el tope de la pila.
duler llamando al pro
edimiento:
on a partir del llamado a
void ChangeContext(nTask out_task, nTask in_task); v. Retoma la eje
u
i
ChangeContext de la tarea entrante.
Este pro
edimiento realiza las siguientes a
tividaEs de
ir que el llamado a ChangeContext de la
des (ver gura 4.9):
tarea saliente no retorna hasta que se haga un nuevo
i. Resguarda los registros del pro
esador en el tope
ambio ha
ia aquella tarea (ver gura 4.10).
de la pila de la tarea saliente (out task).
Observe que las labores que realiza ChangeContext
no
llevarse a
abo en C y por lo tanto parii. Guarda sp en el des
riptor de esta tarea saliente te depueden
este
pro
edimiento
esta es
rito en assembler y
(out_task->sp).
es
ompletamente dependiente de la arquite
tura del
iii. Res
ata el puntero al tope de la pila de la ta- pro
esador. Sin embargo, este
ambio de
ontexto no
rea entrante a partir de su des
riptor de pro
eso requiere una llamada al sistema, el
ambio de
ontex(in_task->sp).
to se realiza solo
on instru
iones del modo usuario
39
DE PROCESOS EN NSYSTEM
4.4. ADMINISTRACION
T1
T2
T1
T2
regs
sp
sp
ChangeContext
T1 > T2
Q
regs
Descr.
de T1
Descr.
de T2
Descr.
de T1
sp
Descr.
de T2
sp
La estrategia de s
heduling de nSystem podra denominarse
omo preemptive last
ome rst served o
PLCFS. Las rafagas son atendidas en orden LIFO, es
de
ir que las tareas que llegan al s
heduler toman el
ontrol de pro
esador de inmediato y la tarea que se
eje
utaba en ese instante se
olo
a en primer lugar
en la
ola del s
heduler. Para evitar que una tarea
a
apare indenidamente el pro
esador,
ada t milisegundos el s
heduler le quita el pro
esador a la tarea
en eje
u
ion,
ualquiera sea esta tarea, y la
olo
a al
nal de una
ola.
Esta estrategia se implementa usando una
ola
dual, es de
ir en donde se pueden agregar tareas ya
sea al nal
omo al
omienzo. Cuando una tarea que
estaba en estado de espera (por ejemplo a la espera
de una opera
ion de E/S) pasa al modo lista para
eje
utarse (produ
to de una interrup
ion de E/S) el
s
heduler
olo
a la tarea en eje
u
ion al
omienzo de
la
ola dual y retoma de inmediato la tarea que llega
(ver gura 4.11).
El
ambio de tarea
ada t milisegundos se implementa programando una se~nal que se invo
a
ada t
milisegundos de tiempo virtual del pro
eso Unix. En
esta interrup
ion el s
heduler
olo
a la tarea en eje
u
ion al nal de la
ola dual, extrae la tarea que se
en
uentra en primer lugar y la retoma.
Para esta se~nal se usa el tiempo virtual del pro
eso
urrent task
ready queue
urrent sli
e
La tarea en eje
u
i
on
La
ola dual
El intervalo entre interrup
iones
Observe que si T era la tarea que
orra
uando se invo
o ResumeNextReadyTask, el llamado a
ChangeContext no retornara hasta que se retome T . Es de
ir
uando se invoque nuevamente
ResumeNextReadyTask y T aparez
a en primer lugar en la
ola ready queue. Mientras tanto, el nSystem eje
uto otras tareas y realizo eventualmente otros
ambios de
ontexto. Por esta razon en (1) se asigna
T a la tarea a
tual y no next task.
En
ada se~nal periodi
a se invo
a el siguiente pro
edimiento:
VtimerHandler()
{
/* Programa la siguiente interrup
ion */
SetAlarm(VIRTUALTIMER,
urrent_sli
e,
VtimerHandler);
/* Colo
a la tarea a
tual al final
de la
ola */
PutTask(ready_queue,
urrent_task);
/* Retoma la primera tarea en la
ola */
40
}
DE PROCESOS
CAPITULO 4. ADMINISTRACION
ResumeNextReadyTask();
El llamado al sistema sele
t determina que des
riptores de ar
hivo tienen datos para leer o en que
des
riptores se puede es
ribir sin llenar los buers internos de Unix que obligaran a bloquear el pro
eso
Unix. En el
odigo que sigue al sele
t se bus
a si hay
tareas bloqueadas a la espera de alguno de los des
riptores
uya le
tura/es
ritura no
ausara un bloqueo
temporal de nSystem. Estas tareas quedaran antes
4.4.4 Entrada/Salida no bloqueante en la
ola que la tarea en eje
u
ion
uando se invo
o
, porque el s
heduling es preemptive
En Unix se puede
olo
ar un des
riptor de ar
hivo SigioHandler
LCFS.
(fd) en un modo no bloqueante y ha
er que se invoque la se~nal SIGIO
uando haya algo para leer en ese
des
riptor. Esto signi
a que read(fd,...) no se 4.4.5 Implementa
ion de se
iones
rti
as en nSystem
bloquea
uando no hay nada que leer en fd, sino que
retorna 1. Esto se ha
e en Unix
on la llamada al El
odigo de nRead puede fun
ionar mal essistema f
ntl.
poradi
amente
uando se re
iba alguna se~nal en meEsto es importante porque de no programar los des- dio
llamado a AddWaitingTask. Esto se debe a
riptores en modo bloqueante,
uando una tarea in- que del
el
de nRead es una se
ion
rti
a y por
tente leer un des
riptor se bloquearan todas las tareas lo tanto osedigo
debe
evitar que otras tareas invoquen este
hasta que haya algo para leer en ese des
riptor. Esto pro
edimiento
on
urrentemente.
es inadmisible en un sistema multiprogramado.
nSystem implementa las se
iones
rti
as de la forUna primera implementa
ion de nRead es:
ma mas simple posible en un mono-pro
esador: inhibe las interrup
iones. Por lo tanto la version nal
int nRead(int fd,
har *buf, int nbyte)
de
nRead es:
{ /* Intentamos leer */
El valor EAGAIN en errno indi
a que no hay nada para leer y que read debera ser reinvo
ado mas
tarde. Unix informa al pro
eso de nSystem que hay
algo para leer en algun des
riptor invo
ando la se~nal
SIGIO. El pro
edimiento que atiende esta se~nal es:
SigioHandler()
{
PushTask(
urrent_task, ready_queue);
... preparar argumentos para sele
t ...
sele
t(...);
DE PROCESOS EN UNIX
4.5. IMPLEMENTACION
41
El numero de ti
kets
4.5 Implementa
ion de pro
eLos pro
eso que esperan
sos en Unix
El pro
edimiento nWaitSem debe bloquear la tarea
que lo invo
a
uando
ount es 0:
Las implementa
iones
lasi
as de Unix administran
los pro
esos en un esquema similar al de nSystem. La
estrategia de s
heduling de pro
esos es un po
o mas
void nWaitSem(nSem sem)
elaborada
pues implementa pro
esos
on prioridades
{
y
al
mismo
tiempo intenta dar un buen tiempo de
START_CRITICAL();
respuesta
a
los
usuarios intera
tivos, algo que no es
if (sem->
ount>0)
f
a
il
de
lograr
debido
a las restri
iones que impone
sem->
ount--;
la
memoria
del
pro
esador.
else
Mas interesante que la estrategia de s
heduling es
{
estudiar, primero, a partir de que momento los pro
urrent_task->status= WAIT_SEM;
esos
omienzan a
ompartir parte de su espa
io de
PutTask(sem->queue,
urrent_task);
dire
iones, y segundo,
omo se logra la ex
lusion en
/* Retoma otra tarea */
ResumeNextReadyTask();
se
iones
rti
as.
int
Queue
ount
queue
}
END_CRITICAL();
Cuando un pro
eso eje
uta una apli
a
ion el pro
esador se en
uentra en modo usuario, y por lo tanto
El pro
edimiento nSignalSem debe desbloquear algunas
instru
iones estan inhibidas. Si se eje
utan
una tarea
uando
ount es 0 y hay tareas en espera. se produ
e
una interrup
ion que atrapa el nu
leo.
La tarea desbloqueada toma de inmediato el
ontrol Los segmentos
del espa
io de dire
iones que son
del pro
esador (ya que el s
heduling es LCFS).
visibles desde una apli
a
ion son el de
odigo, datos
y pila.
Cuando o
urre una interrup
ion el pro
esador pasa
void nSignalSem(nSem sem)
al
modo sistema e invo
a una rutina de aten
ion de
{
esa
interrup
ion. Esta rutina es provista por el nu
leo
START_CRITICAL();
y
su
dire
ion se res
ata del ve
tor de interrup
iones,
if (EmptyQueue(sem->queue))
el
que
no es visible desde un pro
eso en modo usuario.
sem->
ount++;
else
{
nTask wait_task= GetTask(sem->queue);
wait_task->status= READY;
PushTask(ready_queue,
urrent_task);
PushTask(ready_queue, wait_task);
/* wait_task es la primera en la
ola! */
ResumeNextReadyTask();
}
END_CRITICAL();
Llamadas al sistema
42
DE PROCESOS
CAPITULO 4. ADMINISTRACION
compartido
por los procesos
A B y C
segmento
sistema
Nucleo:
Segmento Sistema
2 GB
proceso A
pila
proceso B
pila
2 GB
proceso
ligero
A
proceso
ligero
B
proceso
ligero
C
proceso
pesado
A
proceso
pesado
B
proceso
pesado
C
proceso C
pila
datos
datos
datos
codigo
codigo
codigo
Interrupcion
Retorno de una
interrupcion
DE PROCESOS EN UNIX
4.5. IMPLEMENTACION
43
El peligro de las se
iones
rti
as se presenta
uando hay 2 o mas pro
esadores reales en el modo sistema
al mismo tiempo, es de
ir en el nu
leo
ompartiendo
el mismo segmento sistema.
Por lo tanto, la forma mas simple de implementar
Unix en un multipro
esador es impedir que dos pro
esadores puedan
orrer simultaneamente en el modo
sistema.
El problema es
omo impedir que dos pro
esadores
eje
uten en paralelo
odigo del nu
leo. La solu
ion
estandar en un monopro
esador que
onsiste en inhibir las interrup
iones no fun
iona en un multipro
esador. En efe
to, solo se pueden inhibir las interrup
iones externas a la CPU, es de
ir las del reloj regresivo
y las de E/S. Un pro
eso en el modo usuario puede realizar llamadas al sistema
on las interrup
iones
externas inhibidas.
Es de
ir que si dos pro
esos que se eje
utan en pro
esadores reales llaman al sistema al mismo tiempo,
ambos entraran al nu
leo y habra dos pro
esadores
orriendo en el modo sistema. Esto originara problemas de se
ion
rti
a.
44
DE PROCESOS
CAPITULO 4. ADMINISTRACION
}
void Unlo
k(int *plo
k)
{
*plo
k= OPEN;
}
El problema es que dos pro
esadores pueden
argar simultaneamente el valor de *plo
k y determinar
que el
andado esta abierto y pasar ambos al modo
sistema.
Para implementar un
andado, la mayora de los
mi
ropro
esadores ofre
en instru
iones de maquina
atomi
as (indivisibles) que permiten implementar un
andado. En spar
esta instru
ion es:
swap dir. en memoria, reg
Esta instru
ion inter
ambia atomi
amente el
ontenido de la dire
ion espe
i
ada
on el
ontenido
del registro. Esta instru
ion es equivalente al pro
edimiento :
Ventajas y desventajas
Se ha presentado una solu
ion simple para implementar Unix en un multipro
esador. La solu
ion
onsiste en impedir que dos pro
esadores puedan eje
utar
simultanemente
odigo del nu
leo, dado que
omparten el mismo segmento sistema.
Este me
anismo se usa en SunOS 4.X ya que es
muy simple de implementar sin realizar modi
a
iones mayores a un nu
leo de Unix dise~nado para monopro
esadores,
omo es el
aso de SunOS 4.X. Este
esquema fun
iona muy bien
uando la
arga del multipro
esador esta
onstituida por pro
esos que requieren mnima aten
ion del sistema.
La desventaja es que en un multipro
esador que
int Swap(int *ptr, int value)
se utiliza
omo servidor de dis
o en una red, la
ar{
ga esta
onstituida sobretodo por mu
hos pro
esos
int ret= *ptr;
\demonios" que atienden los pedidos provenientes de
*ptr= value;
return ret;
la red (servidores NFS o network le system). Estos
}
pro
esos demonios
orren en SunOS solo en modo sisPor lo tanto solo uno de estos pro
esos puede
Solo que por el he
ho de eje
utarse atomi
amente, tema.
estar
eje
ut
andose en un pro
esador en un instante
dos pro
esadores que tratan de eje
utar en paralelo dado. El resto
de los pro
esadores esta eventualmente
esta instru
ion, seran se
uen
ializados.
bloqueado
a
la
Veamos
omo se puede usar este pro
edimiento pa- al modo sistema.espera del
andado para poder entrar
ra implementar un
andado:
Si un pro
esador logra extraer un pro
eso para ha
erlo
orrer, basta que este pro
eso haga una llamada
void Lo
k(int *plo
k)
al sistema para que el pro
esador vuelva a bloquearse
{
en el
andado por
ulpa de que otro pro
esador esta
while (Swap(plo
k, CLOSED)==CLOSED)
mini-loop(); /* busy-waiting */
orriendo un pro
eso NFS en el nu
leo.
45
DE PROCESOS EN UNIX
4.5. IMPLEMENTACION
Para resolver denitivamente el problema de las se
iones
rti
as en el nu
leo de un sistema operativo
para multipro
esadores se debe permitir que varios
pro
esadores puedan eje
utar pro
esos ligeros en el
nu
leo. Ademas estos pro
esos deben ser interrumpibles. Los pro
esos ligeros del nu
leo deben sin
ronizarse a traves de semaforos, mensajes o monitores.
Un semaforo del nu
leo se implementa usando un
spin-lo
k. E ste es un
andado a la estru
tura de datos que representa el semaforo. Las opera
iones sobre
semaforos las llamaremos kWait y kSignal para indi
ar que se llaman en el kernel (nu
leo).
void kWait(kSem sem)
{
Lo
k(&sem->lo
k);
if (sem->
ount>0)
{
sem->
ount--;
Unlo
k(&sem->lo
k);
}
else
{
urrentTask()->status= WAIT_SEM;
PutTask(sem->queue,
urrentTask());
Unlo
k(&sem->lo
k);
/* Retoma otra tarea */
ResumeNextReadyTask();
}
}
El prin
ipio es que el
andado permane
e
errado solo
uando un pro
esador esta manipulando el
semaforo. Si el
ontador esta en 0, el pro
eso se
olo
a en la
ola del semaforo, se abre nuevamente
el
andado y el pro
esador llama al s
heduler para
retomar un nuevo pro
eso. En ningun
aso, el pro
esador espera en un spin-lo
k hasta que el
ontador del
semaforo se haga positivo. De esta forma, el tiempo
que permane
e
errado el
andado es del orden de un
mi
rosegundo, muy inferior al tiempo que puede permane
er
errado el
andado que permite el a
eso al
nu
leo en SunOS 4.X.
Observe que
uando hay varios pro
esadores
orriendo, no se puede tener una variable global que
apunta al pro
eso en eje
u
ion. Ademas, el s
heduler
debe tener otro
andado aso
iado a la
ola de pro
esos ready, para evitar que dos pro
esadores extraigan
o en
olen al mismo tiempo.
El
odigo para kSignal es:
void kSignal(Sem sem)
{
Lo
k(&sem->lo
k);
if (EmptyQueue(sem->queue))
{
sem->
ount++;
Unlo
k(&sem->lo
k);
}
else
{
nTask wait_task= GetTask(sem->queue);
Unlo
k(&sem->lo
k);
wait_task->status= READY;
/* ready_lo
k es el
andado para
la ready_queue */
Lo
k(&ready_lo
k);
PushTask(ready_queue,
urrent_task);
PushTask(ready_queue, wait_task);
Unlo
k(&ready_lo
k);
/* wait_task no ne
esariamente es la
primera en la
ola! Por qu\'e? */
ResumeNextReadyTask();
}
Ejemplos de sistemas operativos que usan este esquema son Solaris 2, Unix System V.4, Window NT
y Ma
h (Next y OSF/1). Se di
e que el nu
leo de estos sistemas es multi-threaded, porque pueden
orrer
en paralelo varios threads en el nu
leo, a diferen
ia
de la implementa
ion
lasi
a en donde
orre un solo
thread en el nu
leo, y ademas es ininterrumpible.
46
DE PROCESOS
CAPITULO 4. ADMINISTRACION
Cap
tulo 5
Administra
i
on de Memoria
Accesibles
desde un
proceso
0
2 GB
System
Segment
No accesible
Text
Data
Segment Segment
(codigo) (datos)
4 GB
Stack
Segment
(pila)
Nucleo
del S.O.
Figura 5.1: Segmentos del espa io de dire iones virtuales de un pro eso.
Area de
Dispositivos
4G
16M
2G
2G
2M
2G
2G4K
2G
2G4K
1M
200K
190K
90K
63K
30K
Proceso A
47
0K
Area de
Memoria
Real
Proceso B
48
DE MEMORIA
CAPITULO 5. ADMINISTRACION
Cuando un pro
eso a
esa la memoria siempre su- Si la dire
ion (virtual)
ae dentro de uno de los
ministra una dire
ion en su espa
io de dire
iones segmentos enton
es la dire
ion real se obtiene
omo:
virtuales. El pro
esador debe tradu
ir esa dire
ion
a su posi
ion efe
tiva en la memoria real del
ompudire
ion real = dire
ion virtual + despseg
tador, es de
ir a su dire
ion real.
Si la dire
ion no
ae dentro de ninguno de los seg5.1.1 La tabla de segmentos del pro- mentos
enton
es se produ
e una interrup
ion. En
esador
Unix usualmente el pro
eso se aborta
on un menPara tradu
ir las dire
iones virtuales a dire
iones saje no muy expli
ativo que di
e segmentation fault.
reales, el pro
esador posee una tabla de segmentos El Hardware es
apaz de realizar e
ientemente esta
on 4 las. Cada una de estas las des
ribe uno de tradu
ion en a lo mas un
i
lo del reloj del mi
rolos 4 segmentos del programa en eje
u
ion. Para
ada pro
esador.
El nu
leo del sistema operativo se en
arga de
olosegmento se indi
a:
ar valores apropiados en la tabla de segmentos, y lo
Base: Dire
ion virtual en donde
omienza (in- ha
e de tal forma que una dire
ion virtual jamas pertene
e a dos segmentos. Sin embargo, es importante
luyendo esta dire
ion).
ha
er notar que una misma dire
ion real s puede
Lmite: Dire
ion virtual en donde naliza (ex- pertene
er a dos segmentos aso
iados a pro
esos dis
luyendo esta dire
ion).
tintos.
Desplazamiento: Desplazamiento que hay que
sumar a una dire
ion virtual para obtener su Cambios de
ontexto
dire
ion real. Se
al
ula
omo la dire
ion de Cada pro
eso tiene su propia tabla de segmentos al
omienzo del segmento en la memoria real menos ma
enada en su des
ritor de pro
eso. El pro
esador
la dire
ion virtual de ini
io del segmento.
mantiene solamente en registros internos la tabla de
segmentos
del pro
eso que esta
orriendo.
Atributos del segmento: le
tura/es
ritura, solo
Cuando
el
nu
leo de
ide efe
tuar un
ambio de
onle
tura e invisible (a
esible solo por el nu
leo).
texto, tiene que
ambiar el espa
io de dire
iones virLa siguiente tabla muestra el
ontenido de la tabla tuales del pro
eso saliente por el del pro
eso entrante.
Para realizar este
ambio, el nu
leo
arga la tabla de
de segmentos para el pro
eso B de la gura 5.1.
segmentos del pro
esador
on la tabla de segmentos
que se en
uentra en el des
riptor del pro
eso entrante.
Ini
io
Fin
DesplaAtributos
Corresvirtual
2G
2G-4K
63K
0
virtual
4G
2G
200K
63K
zamiento
0-2G
2M-2G+4K
1M-63K
30K-0
Invisible
Le
t/Es
r.
Le
t/Es
r.
Le
tura
ponde a
sistema
pila
datos
odigo
49
5.1. SEGMENTACION
Compactacion
50
DE MEMORIA
CAPITULO 5. ADMINISTRACION
proceso
padre
Mem. real
fork
proceso
padre
proceso
hijo
(el clone)
Pila
Datos
Codigo
5.1.5 El poten ial de la segmenta ion La misma estrategia se puede usar para el segmento
La segmenta
ion es un esquema simple para implementar espa
ios de dire
iones virtuales, ne
esarios
para poder garantizar prote
ion entre pro
esos. A
pesar de ser simple, permite implementar una serie
de optimiza
iones que permiten administrar mejor la
memoria del
omputador que hasta el da de hoy es
un re
urso
aro y por lo tanto es
aso. A
ontinua
ion
se des
riben estas optimiza
iones.
Extension automati
a de la pila en
aso de desborde
Cuando se va a
rear un pro
eso, es imposible determinar a priori
uanta memoria se requiere para la
pila. Si se otorga un segmento de pila muy peque~no,
puede o
urrir un desborde de la pila. Por otro lado, si
se otorga memoria en ex
eso se malgasta un re
urso
que podra dedi
arse a otros segmentos.
En un sistema segmentado se puede se puede implementar un me
anismo de extension de la pila en
demanda. Este me
anismo
onsiste en asignar un segmento de pila peque~no y ha
erlo
re
er solo
uando
la pila se desborda. En efe
to, el desborde de la pila
o
urre
uando el puntero a la pila se de
rementa mas
alla de la base del segmento de la pila. Cuando se intente realizar un a
eso por debajo de este segmento
se produ
ira una interrup
ion.
Esta interrup
ion ha
e que se eje
ute una rutina
de aten
ion del nu
leo que diagnosti
a el desborde
de la pila. Enton
es el nu
leo puede soli
itar un segmento mas grande,
opiar la antigua pila al nuevo
segmento, liberar el antiguo segmento, modi
ar el
desplazamiento del segmento pila en la tabla de segmento y retomar el pro
eso interrumpido en forma
transparente, es de
ir sin que este se de
uenta de
que desbordo su pila.
51
5.1. SEGMENTACION
2G
2G
Pilas independientes
Datos compartidos
0
Codigo compartido
nu
leo, porque requiere manejar la tabla de segmentos. En
ambio los pro
esos ligeros pueden
implementarse a nivel de un pro
eso Unix, sin
interven
ion del nu
leo.
A pesar de que el
ambio de
ontexto es
aro, todava se puede de
ir que son pro
esos ligeros debido
a que se pueden
omuni
ar e
ientemente a traves
del envo de punteros al area de datos. Pero observe
que es erroneo enviar punteros a variables lo
ales a
un pro
eso semi-ligero.
52
DE MEMORIA
CAPITULO 5. ADMINISTRACION
proceso
A
proceso
B
Tabla de paginas
Espacio de
del proceso
direcciones del
proceso
0
1
0
0
1
2
.
.
.
v
V,W,R,D
Atributos
Mem. real
Memoria
Real
Traduccion
Figura 5.6: Parti
ionamiento de los espa
ios de didel espa
io de dire
iones virtuales puede residir en
re
iones en paginas.
ualquiera de las paginas del espa
io de dire
iones
reales, siempre y
uando all haya memoria fsi
a.
5.1.6 Problemas de la segmenta
ion
Apesar de que un sistema segmentado aporta solu
iones y optimiza
iones, persisten algunos problemas
que solo se resuelven
on paginamiento. Estos problemas son:
La implementa
ion de fork es ine
iente, pues
opia
ompletamente los segmentos. Con paginamiento, fre
uentemente no es ne
esario
opiar
ompletamente datos y pila.
La
ompa
ta
ion introdu
e una pausa generalizada del sistema que es dif
il distinguir de una
ada del sistema. Con paginamiento no es ne
esario efe
tuar
ompa
ta
ion.
El tama~no de un pro
eso no puede ex
eder el tama~no de la memoria real, puesto que un pro
eso
ne
esita estar
ompletamente residente para poder
orrer. Con paginamiento en demanda, el
que veremos mas adelante, un pro
eso no ne
esita estar
ompletamente residente en memoria
para poder
orrer.
5.2 Paginamiento
En el des
riptor de
ada pro
eso se guarda una tabla de paginas que
onsiste en una arreglo que indi
a en que pagina de la memoria real se ubi
a
ada
pagina del espa
io de dire
iones virtuales (ver gura
5.7). Para ello se enumeran las paginas virtuales y las
paginas reales de 0 en adelante. De esta forma en la
la v de la tabla de paginas se indi
a en que numero
de pagina real se en
uentra la pagina virtual numero
v.
Atributos de una pagina
En 0, la pagina no se puede leer ni es
ribir, simplemente esa pagina no reside en la memoria real.
Si se a
esa esa pagina se produ
e una page fault
(falta de pagina) que invo
a una interrup
ion.
Bit W : En 1 indi
a que la pagina se puede es
ribir, pero solo si ademas V esta en 1. Si esta
en 0 y se es
ribe en la pagina, se produ
e una
interrup
ion.
Bit R : El hardware
olo
a este bit en 1
ada vez
que se lee una palabra de esta pagina. Se usa
para implementar paginamiento en demanda.
Bit D : El hardware
olo
a este bit en 1
ada vez
que se es
ribe en esta pagina.
53
5.2. PAGINAMIENTO
Cambios de ontexto
Direccion virtual
El hardware del pro
esador posee usualmente un registro que indi
a la dire
ion en la memoria real de la
tabla de paginas del pro
eso en eje
u
ion. Este registro ne
esariamente
ontiene una dire
ion real pues
de ser una dire
ion virtual,
aeramos en una
i
lo
innito al tratar de determinar en que lugar de la
memoria real se en
uentra.
Durante un
ambio de
ontexto es ne
esario
ambiar el espa
io de dire
iones virtuales por el del pro
eso entrante, por lo que este registro se modi
a
on
Direccion real
la dire
ion de la tabla de paginas que se en
uentra
en el des
riptor del pro
eso entrante.
Figura 5.8: Tradu
ion de dire
iones virtuales a dire
iones reales por medio de la tabla de paginas.
v
k bits
32k
0
1
2
.
.
.
v,w,r,d
Atributos
El hardware del mi
ropro
esador se en
arga de tradu
ir las dire
iones virtuales que a
esa un pro
eso
a dire
iones reales. Para efe
tuar esta tradu
ion el
hardware determina el numero de la pagina virtual a
partir de la dire
ion virtual a
esada por el pro
eso
y la tradu
e al numero de la pagina real en donde
reside esa pagina virtual.
Si las paginas son de 2k bytes y las dire
iones de
32 bits, es muy fa
il determinar el numero de una
pagina en una dire
ion. Basta observar que todas
las dire
iones que
aen en la misma pagina v tienen
un mismo prejo de 32 k bits que
orresponde pre
isamente a v, los ultimos k bits en la dire
ion son
el desplazamiento de la palabra a
esada dentro de la
pagina.
El me
anismo de tradu
ion de dire
iones se observa en la gura 5.8. De la dire
ion virtual se extraen los bits que
orresponden al numero de pagina
virtual (v). Con ellos se subindi
a la tabla de paginas
y se determina en que pagina real (r) se en
uentra la
Traduccion
palabra a
esada, ademas se veri
a que los atributos presentes en esa posi
ion en la tabla autorizan la
opera
ion soli
itada (le
tura o es
ritura). Finalmente, la dire
ion real se forma a partir del numero de la
pagina real y el desplazamiento o dentro de la pagina
que se extrae de la dire
ion virtual.
5.2.3 El poten
ial del paginamiento
El paginamiento permite implementar espa
ios de dire
iones virtuales y por lo tanto prote
ion entre
pro
esos. Tambien permite realizar todas las optimiza
iones del uso de la memoria que ofre
e la segmenta
ion:
Extension automati
a de la pila en
aso de desborde.
Cuando un pro
eso desborda su pila, el nu
leo
puede asignarle una nueva pagina en forma
transparente para el pro
eso.
Extension expl
ita de los datos.
Cuando el pro
eso soli
ita la extension de los
datos invo
ando la llamada al sistema sbrk, el
nu
leo asigna las paginas ne
esarias segun la memoria pedida.
Swapping.
Cuando la memoria es
asea, el nu
leo puede llevar pro
esos a dis
o: sus datos, su
odigo, su
pila y sus tablas de paginas.
Implementa
ion de pro
esos semi-ligeros.
Los pro
esos semi-ligeros
omparten la por
ion
del espa
io de dire
iones que
orresponde al
odigo y los datos, pero poseen una por
ion no
ompartida en donde se ubi
a la pila. Con esto
54
es posible implementar extension automati
a de
la pila en
aso de desborde.
Pero ademas, el me
anismo de paginamiento permite realizar mejor algunas optimiza
iones que en
segmenta
ion.
No hay framenta
ion externa
Se di
e que la fragmenta
ion aso
iada a la segmenta
ion es una fragmenta
ion externa porque se pierden
trozos de memoria fuera de la memoria asignada a los
pro
esos. Este problema no existe en paginamiento:
se puede otorgar a un pro
eso un
onjunto de paginas
reales que o
uparan una por
ion
ontigua del espa
io de dire
iones virtuales, aun
uando estas paginas
reales no forman un bloque
ontiguo en la memoria
real del
omputador.
La administra
ion de paginas de tama~no jo es
un problema simple de resolver e
ientemente. Las
paginas disponibles se organizan en una lista enlazada simple. La extra
ion y la devolu
ion de paginas
toma tiempo
onstante y requiere unas po
as instru
iones. Cuando un pro
eso soli
ita expl
itamente
o impl
itamente mas memoria, se le otorga tantas
paginas
omo sea ne
esario para
ompletar la memoria requerida, sin importar que las p'aginas disponibles esten diseminadas por toda la memoria.
Aunque no hay fragmenta
ion externa s puede haber fragmenta
ion interna. Este ultimo tipo de fragmenta
ion o
urre
uando a un pro
eso se le otorga
mas memoria de la que el soli
ita. En efe
to, al
otorgar un grupo de paginas, es usual que la ultima
pagina
ontenga un sobrante que el pro
eso no ha soli
itado. Este sobrante existe porque en paginamiento
no se pueden otorgar fra
iones de pagina. En todo
aso, los estudios indi
an que la fragmenta
ion interna signi
a una perdida de memoria inferior a la
fragmenta
ion externa.
Implementa
ion e
iente de fork
DE MEMORIA
CAPITULO 5. ADMINISTRACION
En una esquema de paginamiento se puede implementar todo el rango de \pesos" de los pro
esos (ver
gura 5.10). En esta
ategoriza
ion los pro
esos se
distinguen por la amplitud del espa
io de dire
iones que
omparten. Mientras mas espa
io
omparten,
mas ligeros son.
Los pro
esos semi-pesados se ubi
an a mitad de
amino entre los semi-ligeros y los pesados. Los pro
esos semi-pesados tienen dos por
iones del espa
io
de dire
iones para datos:
Una primera por
ion no
ompartida
orrespondiente a las variables globales y al heap administrado por mallo
/free.
Una segunda por
ion que s es
ompartida y
en donde se
olo
a un heap que se administra
on pro
edimientos espe
iales: shared mallo
y shared free. Estos pro
edimientos deben adquirir un lo
k antes de realizar
ualquier
ambio en el heap, para evitar problemas de se
ion
rti
a.
Los pro
esos semi-pesados mejoran los pro
esos
semi-ligeros porque no es ne
esario rees
ribir los pro
edimientos de bibliote
a que invo
an mallo
y free.
Esto porque los pro
esos semi-pesados no ne
esitan
sin
ronizarse para llamar a mallo
o free.
Observe que un pro
eso semi-pesado puede enviar
a otro pro
eso semi-pesado un puntero a una estru
tura que pidio
on shared mallo
, pero es un error
mandar un puntero a una estru
tura que se pidio
on
mallo
.
55
5.2. PAGINAMIENTO
fork
Tabla de
paginas
del padre
store
Tabla de
paginas
del padre
Tabla de
paginas
del hijo
Tabla de
paginas
del padre
Tabla de
paginas
del hijo
pila
pila
pila
pila
pila
Datos
Compar
tidos
Pila
Pila
Datos
Codigo
Ligeros
Semiligeros
semipesados
pesados
Figura 5.10: Clasi
a
ion de los pro
esos segun la por
ion
ompartida del espa
io de dire
iones.
de realizar en un esquema de segmenta
ion: paginamiento en demanda.
En este esquema el nu
leo lleva a dis
o las paginas
virtuales que no han sido a
esadas por un perodo
prolongado y, a pesar de todo, el pro
eso propietario
de esas paginas puede
ontinuar
orriendo, si no las
a
esa.
El paginamiento en demanda sera estudiado en
profundidad en la siguiente se
ion.
5.2.4 Ejemplos de sistemas de paginamiento
56
DE MEMORIA
CAPITULO 5. ADMINISTRACION
Direccion virtual
10 10 12 bits
desplazamiento dentro de la pagina
b
nro.
de
tabla
nro. de pagina
12
20 bits
12
d
vwrd
20 bits
Directorio
nro. de la pagina
del directorio
vwrd
Tabla de
paginas
r
20
12
Direccion real
57
un pro
eso que tienen po
a probabilidad de ser referen
iadas en el futuro
er
ano. Un pro
eso puede
ontinuar
orriendo
on parte de sus paginas en dis
o,
v
r
pero
on la
ondi
ion de no a
esar esas paginas.
v
r
La realiza
ion de un sistema de memoria virtual se
.
ha
e posible gra
ias al prin
ipio de lo
alidad de las
.
referen
ias
: un pro
eso tiende a
on
entrar el 90%
.
de sus a
esos a la memoria en solo el 10% de sus
paginas. Sin embargo, para que un pro
eso pueda
a
esar una palabra, es ne
esario que la pagina que
Figura 5.12: Estru
tura de la TLB : Translation-
ontiene esa palabra deba estar
ompletamente resiLookaside-Buer.
dente en memoria. Aun as, empri
amente se observa
que un pro
eso puede pasar perodos prolongados en
Empri
amente se ha determinado que mas del 99% los que a
esa solo entre un 20 al 50% de sus paginas.
de los a
esos a memoria
orresponde a paginas
uya El resto de las paginas puede llevarse a dis
o mientras
no son usadas.
tradu
ion y atributos se en
uentran en la TLB.
Una restri
ion usual es que la TLB mantiene solo
la tradu
ion de paginas pertene
ientes al pro
eso en Page-fault
eje
u
ion. Durante un
ambio de
ontexto es ne
esario invalidar la TLB, para que no se en
uentren en Las paginas residentes en dis
o se mar
an en la tala TLB tradu
iones que
orresponden erroneamente bla de paginas del pro
eso
on el bit V en
ero, de
al pro
eso anterior. Este es un
osto es
ondido del modo que si el pro
eso las referen
ia se produ
e una
ambio de
ontexto: el pro
eso que re
ibe el pro
e- interrup
ion. Esta interrup
ion se denomina pagesador en
uentra la TLB va
a, la que se ira poblando fault. En la rutina de aten
ion de un page-fault, el
a medida que el pro
eso a
esa sus paginas virtuales. nu
leo debe
argar en memoria la pagina que
auso
Para
argar 64 las de la TLB se habran requerido el page-fault, por lo que el pro
eso queda suspendido
128 a
esos adi
ionales. De todas formas, este sobre- mientras se realiza la le
tura del dis
o. Cuando es
osto es muy inferior al del
ambio de
ontexto en ta opera
ion
on
luye, el pro
eso se retoma en forma
transparente sin que per
iba la ausen
ia temporal de
una Sun 3/50.
De esta forma se resuelven los dos problemas de esa pagina.
los me
anismos de paginamiento primitivos: el espa- La dura
ion de la suspension del pro
eso es del
io de dire
iones virtuales
re
e a 4 GB y el
osto orden del tiempo de a
eso del dis
o, es de
ir entre 8
del
ambio de
ontexto se redu
e. La mayora de los a 20 milisegundos.
pro
esadores modernos emplean esquemas similares
a la ex
ep
ion de los PowerPC que poseen tablas de 5.3.1 Estrategias de reemplazo de
paginas invertidas, que por problemas de espa
io no
paginas
podemos dis
utir este do
umento.
Toda la di
ultad del paginamiento en demanda esta
en
de
idir que paginas
onviene llevar a dis
o
uando
5.3 Memoria Virtual : Pagina- la memoria
se ha
e es
asa. La idea es que la pagina
que se lleve a dis
o debe
ausar un page-fault lo mas
miento en Demanda
tarde posible. Por lo tanto se puede dedu
ir que el sisCuando la memoria real de un
omputador se ha
e in- tema de paginamiento ideal debe llevar a dis
o aquesu
iente, el nu
leo del sistema operativo puede emu- lla pagina que no sera usada por el perodo de tiempo
lar una memoria de mayor tama~no que la memoria mas largo posible.
real, ha
iendo que parte de los pro
esos se manten- Desde luego, en terminos pra
ti
os el nu
leo no
gan en dis
o. A este tipo de memoria se le denomina puede prede
ir por
uanto tiempo una pagina permemoria virtual, pues es una memoria inexistente, mane
era sin ser referen
iada, por lo que es ne
esario
pero que para
ualquier pro
eso es indistinguible de re
urrir a estrategias que se aproximen al
aso ideal.
Estas estrategias se denominan estrategias de reemla memoria real.
El me
anismo que implementa la memoria virtual plazo de paginas.
se denomina paginamiento en demanda y
onsiste en Las estrategias de reemplazo de paginas son realique el nu
leo lleva a dis
o las paginas virtuales de zadas por el nu
leo del sistema operativos. La
omponumero traduccion
pagina a pagina
virtual
real
vwrd
32 a 128
filas
Atributos
58
DE MEMORIA
CAPITULO 5. ADMINISTRACION
nente de
odigo del nu
leo que se en
arga de esta la- 5.3.3 La estrategia FIFO
bor podramos denirlo
omo el s
heduler de paginas. Entre las paginas virtuales residentes, se elige
omo
Antes de estudiar estas estrategias examinemos el la pagina a reemplazar la primera que fue
argada en
impa
to que tiene una tasa elevada de page-faults en memoria.
el desempe~no de un pro
eso. Para ha
er este analisis En la tabla 5.2 se observa el fun
ionamiento de es
onsideremos los siguientes parametros.
ta estrategia. En total o
urren 15 page-faults. Aun
Parametro Signi
ado
Valor aproximado
esta estrategia es trivial de implementar, la
tM
Tiempo de a
eso a 60 nanosegundos
uando
tasa
de
page-faults es altsima, por lo que ningun
la memoria real
sistema
la
tP
Tiempo de le
tura 12 milisegundosdemanda1.utiliza para implementar paginamiento en
de una pagina
r
Tasa de page-faults
Enton
es el tiempo promedio de a
eso a una pa- 5.3.4 La estrategia LRU
labra en memoria es:
LRU signi
a Least-Re
ently-Used. La estrategia
onsiste en llevar a dis
o la pagina que ha permane
ido
te = (1 r)tM + r tP
por mas tiempo sin ser a
esada. El fundamento de
Si la tasa de page-faults es 1 page-fault
ada 1000 esta estrategia es que estadsti
amente se observa que
a
esos, el tiempo promedio por a
eso es te = 12 mientras mas tiempo permane
e una pagina sin ser
mi
rosegundos, es de
ir 200 ve
es mas lento que el a
esada, menos probable es que se a
ese en el futuro
tiempo de a
eso de una palabra residente en la me- inmediato.
moria. Esta diferen
ia abismante se debe a que el En la tabla 5.3 se observa el fun
ionamiento de esta
tiempo de
arga de una pagina es 200 mil ve
es el estrategia. En total o
urren 12 page-faults. Si bien,
tiempo de a
eso a una palabra en memoria real.
posible implementar esta estrategia, sera ne
esario
Por supuesto no es razonable que en un sistema es
ono
er
en que instante fue a
esada
ada pagina. Se
on memoria virtual una apli
a
ion
orra 200 ve
es podra modi
ar
Hardware para que
oloque esta
mas lento que
uando
orre en un sistema sin memo- informa
ion en laeltabla
paginas en
ada a
eso,
ria virtual. Para que la penaliza
ion de la memoria pero en la pra
ti
a ninguden pro
esador
lo ha
e. Por
virtual no ex
eda mas del 10% del tiempo de a
eso lo demas, si esta informa
ion estuviese disponible,
de
de una palabra es ne
esario que :
todas formas, habra que re
orrer todas la paginas en
ada page-fault, lo que sera demasiado
aro.
1
r<
2; 000; 000
Es de
ir a lo mas un page-fault por
ada 2 millones 5.3.5 La estrategia del reloj
de a
esos a la memoria.
Esta estrategia es una aproxima
ion de LRU. El funA
ontinua
ion des
ribiremos y evaluaremos las damento
es que no es ne
esario es
oger exa
tamendistintas estrategias. Veremos que estas estrategias te la pagina
LRU, sino que es su
iente elegir una
presentan problemas ya sea de implementa
ion o tam- pagina que lleva
harto tiempo sin ser a
esada.
bien de desempe~no.
La estrategia usa el bit R de la tabla de pagina
y que el hardware
olo
a en 1
uando la pagina es
5.3.2 La estrategia ideal
a
esada. El s
heduler de paginas
olo
a en 0 este
y lo
onsulta
uando estima que ha trans
urrido
Consiste en llevar a dis
o aquella pagina que no sera bit
el
tiempo
su
iente
omo para que aquella pagina sea
usada por el perodo de tiempo mas largo. Esta es- reemplazada
trategia es optima, pero desde luego, no se puede im-
ontinua en 0.si no ha sido a
esada, es de
ir si el bit R
plementar. Solo sirve para
omparar
ifras.
La estrategia del reloj ordena las paginas reales
irLa tabla 5.1 muestra el fun
ionamiento de esta es-
ularmente
si fueran los minutos de un reloj (ver
trategia ante una traza de a
esos a memoria. Esta gura 5.13).
omo
Un
puntero
se~nala en
ada instante una
traza es una lista ordenada
on los a
esos que ha
e de las paginas. Ini
ialmente
las paginas parten
un pro
eso a sus paginas virtuales. La tabla muestra
on R en 0. Luego de
ierto todas
tiempo
paginas
por
ada a
eso a la memoria
uales son las paginas han sido a
esadas y por lo tanto su algunas
bit
R
pasa
a 1.
virtuales que se en
uentran en la memoria real. Se
observa que
on esta estrategia o
urren 9 page-faults 1 En
ambio s se usa para implementar estrategias de reemplazo en memorias
a
he o en TLBs.
en total.
59
a
b
7
7
0
7
0
1
7
0
1
2
2
0
1
0
2
0
1
3
2
0
3
0
2
0
3
4
2
4
3
...
7
7
0
7
0
1
7
0
1
2
2
0
1
0
2
0
1
3
2
3
1
0
2
3
1
4
2
3
4
...
2 Esta instru
ion no es ne
esaria para que la estrategia fun
ione. Su presen
ia signi
a que una pagina que a
aba de ser
argada de dis
o, solo puede volver a ser llevada a dis
o despues
de dos vueltas del puntero del reloj.
60
DE MEMORIA
CAPITULO 5. ADMINISTRACION
a
b
7
7
0
7
0
1
7
0
1
2
2
0
1
0
2
0
1
3
2
0
3
0
2
0
3
4
4
0
3
...
Esta estrategia elimina el problema del trashing
ombinando paginamiento en demanda
on swapping. La
idea es mantener para
ada pro
eso un mnimo de
paginas que garanti
e que pueda
orrer razonablemente, es de
ir
on una tasa de page-faults baja. Este
mnimo de paginas se denomina working-set.
Si el s
heduler de paginas no dispone de memoria
su
iente
omo para tener
argados los working-set
de todos los pro
esos, enton
es se
omuni
a
on el
s
heduler de mediano plazo para que este haga swapping de pro
esos. Es de
ir se llevan pro
esos
ompletos a dis
o.
El working-set
Se dene WSP (t)
omo el
onjunto de paginas virtuales del pro
eso P que han sido a
esadas en los
ultimos t segundos de tiempo virtual del pro
eso
P.
La estrategia del working-set
al
ula para un pro
eso P el valor WSP (t)
ada vez que el pro
eso P
ompleta t segundos de uso de la CPU. Este
al
ulo
se realiza de la siguiente forma:
Se
onsulta el bit R de
ada pagina q residente en
memoria real del pro
eso P :
61
62
5.3.7 Carga de binarios en demanda
DE MEMORIA
CAPITULO 5. ADMINISTRACION
una buena lo
alidad en el a
eso a los objetos, fre
uentemente una pagina
ontiene al menos uno de
los objetos que estan siendo a
esados. Por lo tanto,
a la larga son po
as las paginas que no quedan en el
working-set.
El problema de la lo
alidad en OOP se podra resolver utilizando
paginas de tama~no similar al de los
objetos3. Sin embargo aqu
aemos nuevamente en
un sobre
osto desmedido para administrar un numero
elevado de paginas.
Como dijimos anteriormente la lo
alidad de los a
esos a la memoria es un fa
tor que depende uni
amente
del pro
eso. En parti
ular depende de los algoritmos
que utili
e el pro
eso para realizar sus
al
ulos.
Los pro
esos que manipulan matri
es u ordenan
arreglos usando qui
k-sort son ejemplos de pro
esos
que exhiben un alto grado de lo
alidad en sus a
esos.
Al
ontrario, los pro
esos que re
orren aleatoriamente
arreglos de gran tama~no exhiben pesima lo
alidad en
los a
esos.
La programa
ion orientada a objetos (OOP) produ
e programas que tienen mala lo
alidad. Este tipo
de programas
rea una innidad de objetos de peque~no tama~no que se reparten uniformemente en el
heap del area de datos del pro
eso. Si bien existe