Indi

e General
1 Introdu ion a los Sistemas Operativos

1.1 Evolu ion de los S.O. . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.1 Sistemas Bat h . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Opera ion O-line . . . . . . . . . . . . . . . . . . . . . .
1.1.3 Buering . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Simultaneous Peripheral Operation On-Line : Spooling . .
1.1.5 Sistemas de Multiprograma ion . . . . . . . . . . . . . . .
1.1.6 Maquinas o pro esadores virtuales . . . . . . . . . . . . .
1.1.7 Sistemas de Tiempo Compartido . . . . . . . . . . . . . .
1.1.8 Computadores Personales . . . . . . . . . . . . . . . . . .
1.1.9 Redes de omputadores personales . . . . . . . . . . . . .
1.1.10 Sistemas distribuidos o redes de esta iones de trabajo . .
1.1.11 Sistemas multipro esadores . . . . . . . . . . . . . . . . .
1.1.12 El presente . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Pro esos

2.1 Clasi a ion de pro esos . . . . . . . . . . . . . .

2.1.1 Pro esos pesados versus pro esos livianos
2.1.2 Preemption versus non-preemption . . . .
2.2 El nano System . . . . . . . . . . . . . . . . . . .
2.2.1 Gestion de tareas en nSystem . . . . . . .
2.2.2 El problema de la se ion rti a . . . . .
2.2.3 Comuni a ion entre tareas en nSystem . .
2.2.4 Otros pro edimientos de nSystem . . . . .
2.2.5 Buering usando tareas . . . . . . . . . .
2.3 Semaforos . . . . . . . . . . . . . . . . . . . . . .
2.3.1 El problema del produ tor/ onsumidor .
2.3.2 El problema de los losofos pensantes . .
2.4 Monitores . . . . . . . . . . . . . . . . . . . . . .
2.4.1 El problema de los es ritores y le tores . .
2.5 Sistemas de mensajes . . . . . . . . . . . . . . . .

3 Estru tura del Computador

3.1 Arquite tura Logi a del Computador . .

3.1.1 Espa io de Dire iones Reales . .
3.1.2 Estrategias de E/S . . . . . . . .
3.1.3 Modo Dual . . . . . . . . . . . .
3.1.4 Espa io de Dire iones Virtuales
3.1.5 Cronometro regresivo . . . . . .
3.2 Arquite tura del Sistema Operativo . .
3.2.1 El nu leo . . . . . . . . . . . . .
3.2.2 Los drivers para dispositivos . .

..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
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

3.2.3 El sistema de ar hivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.4 El interprete de omandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.5 Ejemplos de Sistemas Operativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Administra ion de Pro esos

4.1 S heduling de Pro esos . . . . . . . . . . . . . . . . . . .

4.1.1 Estados de un pro eso . . . . . . . . . . . . . . .
4.1.2 El des riptor de pro eso . . . . . . . . . . . . . .
4.1.3 Colas de S heduling . . . . . . . . . . . . . . . .
4.1.4 Cambio de ontexto . . . . . . . . . . . . . . . .
4.1.5 Rafagas de CPU . . . . . . . . . . . . . . . . . .
4.2 Estrategias de s heduling de pro esos . . . . . . . . . . .
4.2.1 First Come First Served o FCFS . . . . . . . . .
4.2.2 Shortest Job First o SJF . . . . . . . . . . . . . .
4.2.3 Colas on prioridad . . . . . . . . . . . . . . . .
4.2.4 Round-Robin . . . . . . . . . . . . . . . . . . . .
4.3 Jerarquas de S heduling . . . . . . . . . . . . . . . . . .
4.4 Administra ion de pro esos en nSystem . . . . . . . . .
4.4.1 La pila . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 El ambio de ontexto . . . . . . . . . . . . . . .
4.4.3 S heduling en nSystem . . . . . . . . . . . . . . .
4.4.4 Entrada/Salida no bloqueante . . . . . . . . . . .
4.4.5 Implementa ion de se iones rti as en nSystem
4.4.6 Implementa ion de semaforos en nSystem . . . .
4.5 Implementa ion de pro esos en Unix . . . . . . . . . . .
4.5.1 Unix en monopro esadores . . . . . . . . . . . .
4.5.2 Unix en multipro esadores . . . . . . . . . . . . .

5 Administra ion de Memoria

5.1 Segmenta ion . . . . . . . . . . . . . . . . . . . . . .

5.1.1 La tabla de segmentos del pro esador . . . .
5.1.2 Tradu ion de dire iones virtuales . . . . . .
5.1.3 Administra ion de la memoria de segmentos .
5.1.4 Compa ta ion en el nu leo . . . . . . . . . .
5.1.5 El poten ial de la segmenta ion . . . . . . . .
5.1.6 Problemas de la segmenta ion . . . . . . . . .
5.2 Paginamiento . . . . . . . . . . . . . . . . . . . . . .
5.2.1 La tabla de paginas . . . . . . . . . . . . . .
5.2.2 Tradu ion de dire iones virtuales . . . . . .
5.2.3 El poten ial del paginamiento . . . . . . . . .
5.2.4 Ejemplos de sistemas de paginamiento . . . .
5.3 Memoria Virtual : Paginamiento en Demanda . . . .
5.3.1 Estrategias de reemplazo de paginas . . . . .
5.3.2 La estrategia ideal . . . . . . . . . . . . . . .
5.3.3 La estrategia FIFO . . . . . . . . . . . . . . .
5.3.4 La estrategia LRU . . . . . . . . . . . . . . .
5.3.5 La estrategia del reloj . . . . . . . . . . . . .
5.3.6 La estrategia del Working-Set . . . . . . . . .
5.3.7 Carga de binarios en demanda . . . . . . . .
5.3.8 Lo alidad de los a esos a la memoria . . . .

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..

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

Figura 1.1: Componentes de un sistema omputa ional.

Un Sistema Operativo es un programa que a tua

omo intermediario entre el usuario y la maquina. El
proposito de un sistema operativo es proveer un ambiente en que el usuario puede eje utar sus apli a iones. Las apli a iones son todos aquellos programas
que el usuario eje uta para mejorar su produ tividad Programa
o para divertirse.
El primer objetivo de un sistema operativo es que el I. Introdu ion
Historia del desarrollo de los sistemas operati omputador sea omodo de usar. El segundo objetivo
vos: sistemas bat h, job, dump, monitor rees que la maquina sea usada e ientemente.
sidente, opera ion o-line, buering, spooling,
Las omponentes de un sistema operativo se obmulti-programa i
on, job s heduling, maquinas
servan en la gura 1.1. La prin ipal omponente del
virtuales,
pro esos,
omputadores personales, resistema operativo es el nu leo (kernel). El nu leo se
des,
sistemas
distribuidos.
en arga de eje utar y dar servi ios a los pro esos.
Un pro eso puede ser una apli a ion o un utili- II. Pro esos
tario. Las apli a iones son los programas del usuario que le ayudan a mejorar su produ tividad. Las
{ Pro esos pesados vs. pro esos livianos o thapli a iones no son parte del sistema operativo. Los
reads.
utilitarios son programas que pertene en al sistema
{ Preemption vs. non-preemption.
operativo y que ayudan al usuario a: administrar sus
ar hivos, imprimir programas y resultados, intera { Un sistema de pro esos livianos: nSystem.
3

 A LOS SISTEMAS OPERATIVOS

CAPITULO 1. INTRODUCCION

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.
{

III. Estru tura del Computador

Arquite tura logi a del Hardware: espa io
de dire iones reales, E/S mapeada en el espa io de dire iones reales, interrup iones,
polling, ve tor de interrup iones, anales de
E/S, modo dual, seguridad y prote ion,
espa io de dire iones virtuales, segmenta ion, timer.
{ Estru tura del Software: nu leo, drivers,
API, servi ios del nu leo/sistema operativo.

IV. Administra ion de Pro esos.

S heduling de pro esos, indenti ador de pro eso, des riptor de pro eso, olas de s heduling, estados de un pro eso, ambio de ontexto, rafagas
de CPU, estrategias de s heduling, First Come
First Served, Shortest Job First, Colas de Prioridad, Round Robin, s heduling en varios niveles,
s heduling en nSystem.
V. Administra ion de Memoria Primaria.
Segmenta ion, Paginamiento, Memoria Virtual,
Swapping, Demand Paging, page fault, lo alidad
de los a esos a memoria, estrategias de reemplazo de paginas, First Come First Served, Least
Re ently Used, la estrategia del reloj, la estrategia del working set, opy-on-write, demand loading, paginamiento en x86, Translation Lookaside Buer.
VI. Administra ion de Memoria Se undaria.
El sistema de ar hivos de unix, s heduling de
dis o.
VII. Estru tura de Redes
Topologa de redes, lo aliza ion de hosts, estrategias de onexion, estrategias de ruteo, proto olos de omuni a ion de datos.

Evalua ion :

 2 ontroles + examen (70%).

 2 o 3 tareas omputa ionales (no habra alumnos

pendientes).

Bibliografa :

A. Silbers hatz, \Operating System Con epts", 1991

Addison-Wesley

1.1 Evolu ion de los S.O.

Al omienzo solo haba Hardware y apli a iones. Un
programa en ROM lee el binario de una apli a ion a
partir de algun dispositivo.
La apli a ion debe in luir todo, in luso debe saber omo manejar ada dispositivo. Es de ir no hay
read ni write, sino que la apli a ion debe omandar
dire tamente el dis o a traves de puertas de E/S en
el espa io de dire iones. El dis o se ve omo una
se uen ia nita de bloques de bytes sin ninguna estru tura en ar hivos y dire torios. La apli a ion es
responsable de dar alguna estru tura al dis o.
Si se desea lanzar otra apli a ion hay que presionar
el boton reset en la onsola del omputador.
Durante el desarrollo de una apli a ion la depura ion se lleva a abo observando las lu es de la onsola del omputador. Dado que solo un programador
puede usar el omputador en un instante, los programadores deben reservar hora.
Problema : Bajo prove ho de un omputador
ostoso

 El omputador pasa la mayor parte del tiem-

po o ioso, esperando instru iones del programador.

 El tiempo de omputador es mu ho mas aro que
los programadores.
>Como mejorar el rendimiento del omputador?

1.1.1 Sistemas Bat h

En un sistema bat h el pro esamiento se ha e en lotes de tarjetas perforadas o jobs. El programador no

intera tua dire tamente on el omputador. Un job
es un lote de tarjetas perforadas por el programador mediante maquinas perforadoras. Estas tarjetas
ontienen el programa y los datos delimitados por
tarjetas de ontrol.

 DE LOS S.O.
1.1. EVOLUCION

Un operador del omputador se en arga de re ibir

los jobs de varios programadores e introdu irlos en
una le tora de tarjetas para que sean pro esados.
Un programa denominado monitor residente se en arga de leer las tarjetas, interpretar las tarjetas de
ontrol y lanzar los programas. Si el programa termina en un error, el monitor residente imprime un
dump, que onsiste en una imagen hexade imal de la
memoria del omputador al momento de o urrir el
error. El operador entrega el dump al programador
para que este determine la ausa del error y solu ione
el problema reha iendo algunas de las tarjetas.
Ventajas

 Mientras el programador piensa, el omputador

A.
Procesador
Satelite

Perforadora

B.
Computador
Principal

C.
Procesador
Satelite

Figura 1.2: Opera ion O-Line de periferi os

E

...

puede pro esar otros jobs.

 El omputador pasa asi el 100% del tiempo o u- Figura 1.3: Alternan ia entre le tura, pro eso y espado, puesto que el operador es mu ho mas dies- ritura de un job tpi o.
tro en el manejo de las tarjetas que los programadores.
del pro esador prin ipal aso iando varios satelites de
Problema : Baja utiliza ion de un pro esador le tura y varios satelites de impresion.
En efe to, el osto de los pro esadores satelites es
ostoso
marginal frente al osto del pro esador prin ipal. CaAunque el omputador esta o upado, su omponente da vez que se agrega un pro esador satelite se aumenmas ostosa, el pro esador o CPU pasa gran parte ta la apa idad de pro eso sin omprar un nuevo prodel tiempo o ioso porque la le tura de las tarjetas y esador prin ipal, solo se aumenta el por entaje de
la impresion de los resultados son muy lentas.
tiempo de utiliza ion del pro esador prin ipal. Por
supuesto esto tiene un lmite, puesto que llega un
momento
en que el omputador prin ipal no es apaz
1.1.2 Opera ion O-line
de leer mas intas. Por lo tanto se agregan pro esaEl termino o-line signi a fuera de la lnea de pro- dores satelites mientras exista apa idad o iosa en el
du ion. Apli ado a los sistemas bat h, opera ion omputador prin ipal.
o-line signi a que la le tura de las tarjetas y la im- Las te ni as que veremos a ontinua ion apuntan
presion de los resultados no las realiza el omputador. ha ia ese mismo objetivo: aumentar el por entaje de
Estas a tividades se realizan a abo en pro esadores tiempo de utiliza ion del pro esador prin ipal agresatelites de bajo osto y espe ializados en una sola gando otros pro esadores dedi ados de bajo osto.
a tividad (ver gura 1.2).
Las tarjetas de varios jobs son ledas por un pro esador satelite, el que genera una inta (parte A en la Problema : Busy-waiting
gura) que el operador transporta ha ia la unidad de Mientras se lee o es ribe una lnea (equivalente a una
intas del omputador prin ipal. El omputador lee tarjeta),
CPU debe ha er busy-waiting, es de ir
estas intas mu ho mas rapidamente que las tarjetas no realizalaning
un trabajo util. En la gura 1.3 se
(parte B en la gura).
observa
el
t

pi o
job que alterna entre le tura de una
De igual forma, el resultado de los jobs se graba en lnea de datos, pro esamiento
esa lnea y es ritura
una o mas intas que son desmontadas por el opera- del resultado. En ella se observadeque
dor y llevadas a un pro esador satelite dedi ado a la E y S el pro esador esta o ioso. durante las fases
impresion (parte C en la gura).
Ventajas

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

 A LOS SISTEMAS OPERATIVOS

CAPITULO 1. INTRODUCCION
Unidad
trabajando
Canal 1

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 nmo 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)

Figura 1.6: Spooling

job nun a lee sus datos dire tamente de la le tora de
tarjetas o imprime dire tamente sus resultados. Un
job obtiene su entrada de un ar hivo en dis o y graba su salida en un ar hivo tambien en dis o. Es el
monitor residente el que se en arga de leer las tarjetas (dejandolas en el dis o) e imprimir los resultados.
Para mejorar el grado de utiliza ion del pro esador
prin ipal, el monitor residente superpone las siguientes a tividades:
 Pro esamiento del job que orresponde pro esar,
 Le tura de las tarjetas de uno o mas jobs que
esperan ser pro esados.
 Impresion de los resultados de uno o mas jobs
que ya fueron pro esados.
Este esquema se muestra en gura 1.6. En ella se
observa que la uni a restri ion para pro esar el iesimo job es que este haya sido ledo por algun anal.
Del mismo modo, la uni a restri ion para imprimir
el resultado de un job es que ya se haya on luido su
pro eso.
Ventantas

Spool). En un sistema de multiprograma ion (nes

de los '60) el monitor residente aprove ha los intervalos de espera de E/S para ha er avanzar otros jobs.
Es en esta epo a en que el monitor residente puede
omenzar a llamarse un Sistema Operativo. El sistema operativo debe de idir que jobs ha e avanzar y
uales no, tratando de maximizar el rendimiento del
omputador. Esto se llama Job s heduling.
Problema : Ausen ia de prote ion entre jobs

Si se lanza un programa defe tuoso, su ada provo a

la ada de todo el omputador. Surge la ne esidad
de tener un me anismo de prote ion entre jobs.

1.1.6 Maquinas o pro esadores virtuales

Apare en las arquite turas de omputadores que son

apa es de emular varias maquinas o pro esadores
virtuales a partir de un solo pro esador real. Cada
pro esador virtual posee:
 Un espa io de dire iones independiente.
 Dispositivos de E/S independientes.
 Espa ios de alma enamiento de informa ion

ompartidos.
 Interrup iones.
 Tiempo de CPU obtenido en forma de tajadas
de tiempo del pro esador real.

Al desapare er los pro esadores satelites (o-line) se

disminuye la labor del operador en lo que respe ta
a transportar intas. Esto disminuye el tiempo de En los sistemas de multiprograma ion se al anza el
despa ho de un job, espe ialmente uando la ola de mayor rendimiento de un omputador.
jobs esperando pro eso se mantiene peque~na.
Problema : Aun queda tiempo de pro esador Problema : Baja produ tividad de los programadores
disponible

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.

Los dis os {aunque mas rapidos que las intas{ siguen

siendo mas lentos que la CPU. En pro esos intensivos
en E/S, la utiliza ion de la CPU sigue siendo baja.
Por lo tanto el proximo adelanto sigue apuntando a
o upar esa apa idad o iosa evitando la ompra de
una nueva CPU.

 A LOS SISTEMAS OPERATIVOS

CAPITULO 1. INTRODUCCION

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

ompartido para 10 usuarios.

Problema : Di ultad para ompartir informa ion

Cada omputador personal tiene que tener su propia

impresora y dis o. Estos re ursos ontinuan siendo
aros, pero no pueden ser ompartidos. Por otra parte los programadores y usuarios no pueden ompartir
informa ion, algo que s pueden ha er en los sistemas
de tiempo ompartido para desarrollar un proye to
en grupo.
1.1.9 Redes de omputadores personales

Es as omo a mediados de los '80 surgen las redes de

omputadores personales ( omo Novell). La idea es
mantener la vision que tiene un usuario de un omputador personal, pero la red le permite ompartir el
espa io en dis o y la impresora on el n de e onomizar re ursos.
El esquema fun iona dedi ando uno de los omputadores personales a la fun ion de servidor de dis o
e impresora. Los demas omputadores se one tan
va una red al servidor. Una apa en el monitor residente ha e ver el dis o del servidor omo si fuese un
dis o lo al en ada omputador personal de la red.
Lo mismo o urre on la impresora.
Aunque poten ialmente un usuario tambien podra
usar el servidor para sus propios nes, esto no es onveniente, ya que el monitor residente no tiene me anismo de prote ion. Si el usuario lanza una apli a ion defe tuosa, la ada de esta apli a ion signi ara
la ada de todos los omputadores personales, puesto que el servidor dejara de responder las peti iones
de dis o o impresion.
La desventaja de este tipo de redes es que no resuelve el problema de ompartir informa ion. En efe to,
las primeras redes permiten ompartir dire torios de
programas en modo le tura, pero no permiten ompartir dire torios en modo es ritura lo que impide el
desarrollo en grupo.
1.1.10 Sistemas distribuidos o redes
de esta iones de trabajo

La otra solu ion surge omo respuesta al problema de

ompartir informa ion. En las esta iones de trabajo
se trata de emular un sistema de tiempo ompartido, ya que este tipo de sistemas s permite ompartir

 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.

Esto signi a que el modelo on eptual del pro eso

no ambia. Un pro eso sigue siendo un solo pro esador virtual on su propia memoria no ompartida.
Sin embargo existen sistemas operativos que permiten que dos o mas pro esos ompartan parte de sus
espa ios de dire iones, es apandose de la deni ion
original de pro eso.
El problema de los sistemas multipro esadores es
doble. Por el lado del software es dif il implementar sistemas operativos que aprove hen e ientemente todos los pro esadores disponibles. Y por lado del
hardware, el aumento del osto de un multipro esador es exponen ial on respe to al numero de pro esadores que omparten la misma memoria. Hoy en
da existe una barrera de 20 pro esadores.
1.1.12 El presente

Los omputadores personales estan en el mismo rango

de velo idades de las esta iones de trabajo y ambos
terminos se onfunden. Las nuevas implementa iones de los sistemas de tiempo ompartido de los '80
han sido ampliamente superadas en rapidez por las
esta iones y omputadores personales. Sin embargo,
estos sistemas de tiempo ompartido siguen existiendo debido a la amplia base de apli a iones que aun
ne esitan estos omputadores para poder orrer.
Los omputadores personales mas velo es se onvierten en servidores de dis o o bases de datos. Las
esta iones de trabajo mas velo es se onvieten en servidores de dis o o apli a ion en donde los usuarios
pueden orrer aquellos programas que ne esitan mu ha memoria. En algunas instala iones se usan para
ambos nes ha iendo que los programas vora es en
CPU y memoria degraden el servi io de dis o degradando el tiempo de respuesta de todas las esta iones
de trabajo.

10

 A LOS SISTEMAS OPERATIVOS

CAPITULO 1. INTRODUCCION

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

2.1 Clasi a ion de pro esos

2.1.1 Pro esos pesados versus pro esos livianos

Procesos Livianos

Los pro esos que implementa un sistema operativo se

lasi an segun el grado en que omparten la memoria (ver gura 2.1):
 Pro esos Pesados (pro eso Unix) : Los pro esos
no omparten ninguna por ion de la memoria.
Cada pro eso se eje uta en su propio pro esador
virtual on CPU y memoria. Todos los pro esos
s omparten el mismo espa io de alma enamiento permanente (el dis o).
 Pro esos Livianos o threads: Los threads omparten toda la memoria y el espa io de alma enamiento permanente.
El primer tipo de pro esos se di e pesado porque el
osto de implementa ion en tiempo de CPU y memoria es mu ho mas elevado que el de los pro esos livianos. Ademas la implementa ion de pro esos pesados
requiere de una MMU o Unidad de Manejo de la Memoria. Esta omponente de hardware del pro esador
se en arga de la tradu ion de dire iones virtuales

Figura 2.1: Pro esos pesados y livianos

a reales. La implementa ion en software de esta tradu ion sera demasiado ostosa en tiempo de CPU,
puesto que para garantizar una verdadera prote ion
habra que re urrir a un interprete del lenguaje de
maquina.
Unix estandar solo ofre e pro esos pesados, pero
omo veremos existen extensiones que implementan
pro esos livianos para Unix. Un ejemplo de sistema
de pro esos livianos es el que implementaba el sistema
operativo de los omputadores Commodore Amiga,
que no tena la MMU ne esaria para implementar
pro esos pesados.
La ventaja de los pro esos pesados es que garantizan prote ion. Si un pro eso falla, los demas pro esos ontinuan sin problemas. En ambio si un thread
falla, esto ausa la falla de todos los demas threads
que omparten el mismo pro esador.
La ventaja de los threads es que pueden omuni arse e ientemente a traves de la memoria que om-

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

Los pro esos tambien se pueden lasi ar segun quien

tiene el ontrol para transferir el pro esador multiplexado de un pro eso a otro:
 Pro esos preemptive : Es el nu leo el que de ide
en que instante se transere el pro esador real
de un pro eso al otro. Es de ir un pro eso puede perder el ontrol del pro esador en ualquier
instante.
 Pro esos non-preemptive : Es el pro eso el que
de ide en que instante transere el pro esador
real a otro pro eso.
Los pro esos de Unix son preemptive mientras que
los pro esos de Windows 3.X o Ma intosh Sistema 7.X son non-preemptive. En Windows si una
apli a ion entra en un i lo innito, no hay forma
de quitarle el pro esador real, la uni a salida es el
relanzamiento del sistema. Lo mismo o urre en un
Ma intosh. Por esta misma razon, la tenden ia a
futuro es que todos los sistemas ofre eran pro esos
preemptive.

2.2 El nano System

Dado que en Unix un pro eso pesado orre en un
pro esador virtual es posible implementar un sistema
de threads que omparten el mismo espa io de dire iones virtuales en un pro eso Unix. Un ejemplo de
estos sistemas es el nano System (nSystem de ahora
en adelante).
En vez de usar la palabra thread {que es dif il de
pronun iar en astellano{ usaremos omo sinonimo la
palabra tarea. Las tareas de nSystem se implementan
multiplexando el tiempo de CPU del pro eso Unix
en tajadas de tiempo que se otorgan por turnos a
ada tarea, de la misma forma en que Unix multiplexa
el tiempo del pro esador real para otorgarlo a ada
pro eso pesado.
De esta forma varios pro esos Unix puede tener ada uno un enjambre de tareas que omparten el mis-

mo espa io de dire iones, pero tareas pertene ientes

a pro esos distintos no omparten la memoria.
2.2.1 Gestion de tareas en nSystem

Los siguientes pro edimientos de nSystem permiten

rear, terminar y esperar tareas:


nTask nEmitTask( int (*pro )(),

parametro1 ... parametro6) : Emite

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

2.2. EL NANO SYSTEM

Tarea A

Tarea B
Count == 2

Load count, Reg

Reg==2

t=nEmitTask(P)

Add Reg, 1, Reg

Load count, Reg

Store Reg, count

Add Reg, 1, Reg

Reg==2
Count==3

Store Reg, count

Count==3

rc=nWaitTask(t)

Count=3 !
nExitTask(rc)

B
t=nEmitTask(P)

nExitTask(rc)
rc=nWaitTask(t)

Figura 2.2: Crea ion, espera y termino de tareas en

nSystem
gestion de un numero exponen ial de tareas es olosal. Para que esta solu ion sea e iente se ne esitara
una implementa ion de nSystem que usara pro esadores reales para ada tarea reada, pero en la a tualidad esto no es posible en ningun multi-pro esador
de memoria ompartida.
2.2.2 El problema de la se ion rti a

Supongamos que en el problema anterior se desea

ontar el numero de tareas que se rean. La solu ion natural que se viene en mente es introdu ir una
variable global ount que se in rementa en ada llamada de pfib :
int ount=0;
int pfib(int n)
{
ount++;
if (...) ...
else ...
}

Figura 2.3: Eje u ion on urrente de una misma se ion rti a

En la gura 2.3 se apre ia omo la eje u ion en
paralelo de dos de estas se uen ias puede terminar
in rementando ount solo en 1. Esta situa ion es un
error porque no se ontabiliza una de las invo a iones
de pfib.
En el ejemplo hemos supuesto que ambas tareas
se eje utan en dos pro esadores reales. Sin embargo,
hemos di ho que nSystem no implementa paralelismo
real sino que emula varios pro esadores a partir de un
solo pro eso multiplexando en tajadas el tiempo de
CPU. Esta forma de eje utar pro esos tambien puede
resultar en un numero errado para ount, uando una
tajada de tiempo de CPU se a aba justo uando un
pro eso esta en medio del in remento de ount 1.
Este tipo de problemas es muy omun en los pro esos que omparten algun re urso, en este aso la
variable ount. El problema es que la utiliza ion del
re urso no es atomi a, se ne esita una se uen ia de
instru iones para ompletar una opera ion sobre el
re urso, en el ejemplo, la ontabiliza ion de una invo a ion de pfib. El problema es que la eje u ion
de esta opera ion no debe llevarse a abo on urrentemente en mas de una tarea en un instante dado,
porque el resultado sera impredes ible.
Una se ion rti a es una por ion de odigo que
solo puede ser eje utada por una tarea a la vez para
que fun ione orre tamente. En el ejemplo la instru ion ount++ (es de ir su tradu ion a instru iones
de maquina) es un a se ion rti a.
2.2.3 Comuni a ion entre tareas en
nSystem

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

1 Mas adelante veremos que nSystem puede eje utar las

tareas en modo non-preemptive. En este aso, omo no
hay tajadas de tiempo, los in rementos de ount no pueden
entremez larse.

14


CAPITULO 2. PROCESOS

int nSend(nTask task, void *msg) : Enva {

el mensaje msg a la tarea task. Un mensaje int end= FALSE;
onsiste en un puntero a un area de datos de int ount=0;

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);

void *nRe eive(nTask

*ptask, int max delay) :

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
indenidamente 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;

/* Cal ula Con urrentemente Fibona i(n) */

int pfib2(int n, nTask ounttask)
{
int end= FALSE;
nSend( ounttask, (void*)&end);
if (n<=1) return 1;
else
{
nTask task1=nEmitTask(pfib,n-1, ounttask);
nTask task2=nEmitTask(pfib,n-2, ounttask);
return nWaitTask(task1)+nWaitTask(task2);
} }

Esta solu ion resuelve efe tivamente el problema de

la se ion rti a, puesto que la uni a tarea que in rementa el ontador es ounttask, y esta se eje uta
estri tamente en se uen ia. En el fondo, la solu ion
fun iona porque el ontador ya no es una variable de
a eso ompartido. Aunque todas las tareas tienen
a eso a este ontador, solo una tarea lo a esa verdaderamente.
Es importante desta ar que el siguiente odigo
podra no fun ionar.

/* Crea la tarea para el onteo y la tarea

* que al ula on urrentemente Fibona i(n)
*/
int pfib(int n, int *p ount)
int *msg= (int*)nRe eive(&sender, -1);
{
nReply(sender, 0);
nTask ounttask= nEmitTask(CountPro );
end= *msg;
int ret= pfib2(n, ounttask);
En efe to, al ha er nReply el emisor puede ontiint end= TRUE;
nuar y retornar de pfib2 y por lo tanto destruir la
nSend( ounttask, (void*)&end);
variable end que ontiene el mensaje, antes de que
*p ount= nWaitTask( ounttask);
se eje ute end=*msg;. Esto entregara resultados imreturn ret;
predes ibles.
}
/* Realiza el onteo de tareas */
int CountPro ()

El paradigma que hay detras de esta solu ion es

el de liente/servidor. Se rea una tarea servidor
( ounttask) que da el servi io de onteo, mientras

15

2.2. EL NANO SYSTEM

que fibtask y las demas tareas que se rean para

al ular Fibona i son los lientes.
Notese que al introdu ir este servidor, ni siquiera
on innitos pro esadores la solu ion sera e iente
puesto que se estable e un uello de botella en el servidor. En efe to el servidor de onteo es estri tamente
se uen ial. Las dos tareas que se rean on urrentemente tienen que ser atendidas se uen ialmente por
el servidor.
Bibliote as de Unix y nSystem

Mu hos pro edimientos de bibliote a de Unix pueden

ontinuar usandose en nSystem, sin embargo gran
antidad de pro edimientos de bibliote a usan variables globales uyo a eso se onvierte en una se ion
rti a en nSystem. El odigo original de Unix no implementa ningun me anismo de ontrol que garanti e
que una sola tarea esta invo ando ese pro edimiento,
puesto que Unix estandar no ofre e threads. Por lo
tanto los pro edimientos de bibliote a de Unix que
usan y modi an variables globales no pueden ser invo ados dire tamente desde nSystem. Para llamar estos pro edimientos en nSystem hay que implementar
un me anismo de ontrol de a eso entre tareas.
2.2.4 Otros pro edimientos de nSystem

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) : Dene
el tama~no de la pila para las tareas que se emitan
a ontinua ion.

void nSetTimeSli e(int sli e) :

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.

void nSetTaskName( har *format,

<args> ... ) : Asigna el nombre de

int nOpen( har *path, int flags, int

mode) : Abre un ar hivo.




int nClose(int fd)

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:

: Entrega el identi ador de la tarea que la invo a.

 int nGetTime(void) : Entrega la \hora" en
miliseg.
 void *nMallo (int size) : Es un mallo nonpreemptive.
 void nFree(void *ptr) : Es un free nonpreemptive.


nTask nCurrentTask(void)

void nFatalError( har *pro name,

har *format, ... ) : Es ribe salida

formateada en la salida estandar de errores y termina

la eje u ion (del pro eso Unix). El formato y
los parametros que re ibe son analogos a los de
printf.

2 Round{Robin y FCFS seran vistos en el aptulo de administra ion de pro esos.

16

CAPITULO 2. PROCESOS

un remos a partir de esta se ion, algunos radi almente

in- distintos, otros tambien basados en mensaje pero on
vo a.
una semanti a distinta, es de ir el fun ionamiento de
mensajes es distinto.
 void nFprintf(int fd, har *format, ... losUn
semaforo es un distribuidor de ti kets y sirve
) : Es \ omo" un fprintf, solo bloqueante para
para
a otar
numero de tareas que pasan por una
la tarea que lo invo a, pero re ibe un fd, no un determinadaelinstru i
on. Para ello un semaforo S
FILE *.
dispone de una ierta antidad de ti kets a repartir.
Las opera iones que a epta un semaforo son :
2.2.5 Buering usando tareas
S ) : Pide un ti ket al semaforo. Si el
Veamos omo se resuelve el problema del buering  Wait(
sem
a
foro
no tiene ti kets disponibles, el pro eso
usando tareas. Este mismo problema se resolvera en
se
bloquea
hasta que otro pro eso aporte ti kets
el proximo aptulo usando interrup iones y anales.
a ese mismo semaforo.
nTask bufftask= nEmitTask(BuffServ);
 Signal(S ): Aporta un ti ket al semaforo. Si
haba algun pro eso esperando un ti ket, se desvoid ReadBuff(int *pbuff)
bloquea. Si haba mas pro esos esperando ti {
kets, se desbloquea el primero que llego pidiendo
nSend(bufftask, (void*)pbuff);
ti kets.
}
En nSystem los semaforos se rean on :


void nPrintf( har *format, ... ) : Es

printf solo bloqueante para la tarea que lo

void BuffServ()
{
har pbuff2[512;

for(;;)
{
nTask lienttask;
har *pbuff;

} }

nRead(0, pbuff2, 512);

pbuff= ( har*)nRe eive(& lienttask,-1);
b opy(pbuff, pbuff2, 512);
nReply( lienttask, 0);

nSem sem= nMakeSem(initti kets);

En donde initti kets es la antidad ini ial de

ti kets. Las opera iones Wait y Signal se llaman
nWaitSem y nSignalSem respe tivamente. Ademas
un semaforo se destruye on nDestroySem.
Uno de los usos de los semaforos es la implementa ion de se iones rti as. Por ejemplo el problema
del onteo de pfib se puede resolver on:
int ount= 0;
nSem sem= nMakeSem(1);
int pfib(int n)
{
nWaitSem(sem);
ount++;
nSignalSem(sem);
...
}

Esta solu ion permite efe tivamente superponer la

le tura de un dispositivo (por el des riptor Unix
numero 0). En efe to, una vez que el servidor
BuffServ entrega un bloque de datos, el liente (la
apli a ion) pro esa este bloque al mismo tiempo que
el servidor ya esta leyendo el proximo bloque. Con
suerte uando el servidor vuelva a re ibir un mensaje pidiendo un nuevo bloque, ese bloque ya estara
disponible.
Observe que esta solu ion tambien ne esita interrup iones para poder implementarse, solo que esta
vez la gestion de las interrup iones la realiza nSystem
y no el programador de la apli a ion.

El semaforo ontiene ini ialmente un solo ti ket.

La primera tarea que llega a la se ion rti a pide el
uni o ti ket, de modo que ninguna otra tarea puede
entrar a la se ion rti a. Al salir la tarea devuelve
el ti ket para que otra tarea pueda entrar a la se ion
rti a.

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

Figura 2.4: El problema del produ tor/ onsumidor

un pro eso onsumidor. El buer puede ontener hasta un maximo de N temes. El produ tor y onsumidor trabajan on urrentemente.
El buer se mantiene en un arreglo de N temes de
tipo Item. La variable nexempty indi a elndi e en el
arreglo en donde hay que depositar el proximo tem
produ ido. La variable nextfull indi a el ndi e en
el arreglo de donde hay que extraer el proximo tem
por onsumir. Esta estru tura se apre ia en la gura
2.4.
El problema esta en lograr que uando el onsumidor trata de extraer un tem uando el buer esta
va o, el onsumidor se bloquee hasta que el produ tor deposite un tem. Del mismo modo, uando el
produ tor intenta depositar un tem uando el buer
ya tiene el maximo de N temes, el produ tor se debe
bloquear hasta que el onsumidor extraiga un tem.
Veamos una solu ion de este problema usando dos
semaforos. Un semaforo mantendra el numero de posi iones disponibles para depositartemes en el buer.
Cuando el produ tor deposita un tem resta un ti ket
on Wait, dado que hay un posi ion menos en el buffer. Si el buer esta lleno, el produ tor se bloqueara
ya que no hay mas ti kets en el semaforo. Cuando el
onsumidor extrae un elemento agrega un ti ket on
Signal, porque ahora hay una nueva posi ion disponible.
El segundo semaforo sirve para mantener el numero
de temes dispobibles en el buer. El produ tor agrega ti kets on Signal y el onsumidor quita ti kets {si
hay disponibles{ on Wait.
La siguiente es una implementa ion del produ tor
y onsumidor.
Ini ialmente se tiene :
empty un semaforo on N ti kets
full un semaforo on 0 ti kets
buffer un arreglo de N Item
nextempty=0
nextfull=0

void Produ tor()

{
for(;;) /* Ci lo infinito */
{

Figura 2.5: El problema de los losofos omiendo.

Item x= Produ e();
/* Listo, ya tenemos un item */

} }

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 */
} }

Observe que las modi a iones de las variables

y nextfull no son se iones rti as,
puesto que ada variable es modi ada por un solo
pro eso. Sin embargo si generalizamos el problema
a varios produ tores y onsumidores, las modi a iones s seran se iones rti as.
Ejer i io: Modique esta solu ion para que fun ione en el aso de varios produ tores y onsumidores.

nextempty

2.3.2 El problema de los losofos pensantes

5 losofos pasan sus das pensando y omiendo. Cada

losofo tiene su puesto asignado en una mesa on 5
sillas. En la mesa hay 5 tenedores omo se muestra
en la gura 2.5.
Cuando un losofo piensa no intera tua on el resto de sus olegas. Pero de vez en uando ne esita
omer y por lo tanto se sienta en su silla. Para poder

18

CAPITULO 2. PROCESOS

omer ne esita los dos tenedores que estan a ambos

lados de su plato. Enton es debe intentar tomar un
tenedor primero y despues el otro. Si alguno de estos
tenedores esta en poder de su ve ino, el losofo no
puede omer. Debe esperar a que los dos tenedores
esten libres. Si logro tomar uno de los tenedores, el
losofo puede mantenerlo mientras espera el otro, omo tambien puede soltarlo para que su otro ve ino
pueda omer.
Este es el mas lasi o de los problemas de sin roniza ion debido a que es muy usual en ontrar problemas equivalentes en los sistemas on urrentes y distribuidos. Lamentablemente no siempre es sen illo
dete tar su presen ia, por lo que tambien se le atribuye mu has de las adas de este tipo de sistemas.

menor ndi e en el arreglo de semaforos. El odigo

para tomar los tenedores queda :

Solu ion erronea

Segunda solu ion

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

otro, puesto que el ultimo tenedor (ndi e 4) siempre

se pide en segundo lugar. Por lo tanto se garantiza
que al menos uno de los losofos podra tomar este
tenedor y omer. En el peor de los asos tendran que
omer se uen ialmente.

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();
} }

Observe que en esta solu ion, uando un losofo

tomo un tenedor no lo suelta a pesar de que tiene
que esperar por el proximo tenedor.
Esta solu ion es erronea porque los losofos pueden llegar a una situa ion de bloqueo eterno, o en
ingles dead-lo k. Esta situa ion se produ e uando
ada losofo esta en poder de un tenedor y espera a
que el otro se deso upe, lo que nun a o urrira. En
estas ondi iones los losofos moriran de hambre.
Primera solu ion

Se tiene espe ial uidado al tomar los tenedores, de

modo que siempre se tome primero el tenedor on

} }

Wait(tenedor[(i+1)%5);
Comer();
Signal(tenedor[i);
Signal(tenedor[(i+1)%5);
Signal(sala);
Pensar();

Con esta restri ion tambien se garantiza que al

menos un losofo podra omer. Al resto tarde o temprano le llegara su turno.

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

Las opera iones son <pro 1>, <pro 2>, ... El

odigo aso iado a todas estas opera iones es una se ion rti a y por lo tanto nun a hay dos instan ias
en eje u ion. Sin embargo el monitor puede suspender la eje u ion de una opera ion para eventualmente
eje utar otra y mas tarde retomar la opera ion suspendida. Esto se logra mediante variables de tipo
ondition.
De lara ion: var x: ontition
Las siguientes a iones sobre variables ondi ionales deben ser invo adas dentro de una de las opera iones del monitor.
 x.wait : El pro eso que llega a eje utar esta a ion se suspende hasta que otro pro eso invoque
x.signal dentro del mismo monitor. El pro eso
queda en una ola FIFO que forma parte de x.
 x.signal : Si no hay pro esos en olados en esta variable, la a ion se ignora (no onfundir on
semaforos). Si x tiene pro esos en olados, el pro eso que invo a x.signal ede el monitor al primer pro eso que quedo en espera. El pro eso que
ha edido el monitor podra re uperarlo uando
el pro eso que lo re ibio salga del monitor, salvo que este ultimo lo eda on otro signal a un
ter er pro eso.
Resolvamos el problema del produ tor/ onsumidor
on monitores. Ini ialmente :
Var buffer: BUFFER;

Para depositar un tem x, un produ tor eje uta

buffer.Put(x); mientras que para extraer un tem,
un onsumidor eje uta buffer.Get(x); donde x se

pasa por referen ia.

El tipo BUFFER se dene omo un monitor en el
siguiente odigo:
type BUFFER= monitor
var pool: array[0..N-1 of Item;
in, out, ount: Integer;
noempty, nofull: ondition;
Pro edure entry Put(x: Item);

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;

2.4.1 El problema de los es ritores y

le tores

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 denen 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

(readers>0) onsultando la estru tura, los es ritores

seran bloqueados para siempre.
El problema de la hambruna de los es ritores se
puede resolver ha iendo que no entren mas le tores
uando hay es ritores esperando. Esto se puede lograr on peque~nas modi a iones a la solu ion presentada. Sin embargo ahora el problema es que los
es ritores pueden ausar hambruna a los le tores.
Cuando una solu ion no provo a hambruna a ninguna tarea se di e que esta solu ion es equitativa (en
ingles fair). Una solu ion equitativa del problema de
los le tores y es ritores es que estos sean atendidos en
orden FIFO, pero atendiendo on urrentemente todos los le tores que lleguen durante un lapso en que
no llegan es ritores. Lamentablemente, no es sen illo implementar esta solu ion on monitores. Luego
implementaremos esta solu ion usando mensajes y tareas en nSystem.

2.5 Sistemas de mensajes

Como men ionamos antes, los mensajes se inventaron
para ha er que pro esos que no omparten memoria
puedan omuni arse, pero tambien pueden usarse para sin ronizar pro esos que omparten la memoria.
En todo sistema de mensajes existe una opera ion
para enviar un mensaje y otra para re ibir un mensaje. En algunos sistemas tambien existe una opera ion
para responder un mensaje. Sin embargo la semanti a
de estos sistemas vara ampliamente, y por lo tanto la
programa ion tambien vara. A ontinua ion lasi aremos los sistemas de mensajes segun sus aspe tos
semanti os.
Comuni a ion dire ta

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)

2.5. SISTEMAS DE MENSAJES

Si es otro el pro eso emisor, el mensaje queda en olado hasta que se espe ique 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 identiLa 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);

iii. buer ilimitado : Como el aso anterior, solo que

el buer es de tama~no innito. Esta lasi a ion
solo sirve para nes teori os, pues en la pra ti a
no existe.

Cap
tulo 3

Estru tura del Computador

En este aptulo veremos la organiza ion de un
omputador tanto del punto de vista arquite toni o
del hardware omo del software.

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.

3.1.2 Estrategias de E/S

Busy-waiting

Cuando el programador ne esita ser informado de la

o urren ia de un evento, entra en un i lo de onsulta
onstante del dispositivo, leyendo la puerta de ontrol
del dispositivo que le informa si tal evento o urrio o
no. En esta estrategia, este i lo de onsulta o upa
el 100% de tiempo de CPU y de ah el nombre de
busy-waiting.
A modo de ejemplo supongamos que tenemos un
dispositivo de entrada que se lee en bloques de 512
bytes. El dispositivo tiene una puerta de ontrol en
la dire ion 0xe0000 que indi a si hay un byte para
leer y una puerta de datos en la dire ion 0xe0001
por donde se re iben los datos. Un programa lee un
bloque llamando a la rutina ReadBlo k suministran3.1.1 Espa io de Dire iones Reales do la dire ion de un area de 512 bytes en donde se
debe dejar el resultado. La siguiente es una impleEl programador debe ser apaz de dire ionar ada menta ion de ReadBlo k.
palabra en memoria real, ada puerta de dispositivo
que posea el omputador, ada pixel de la memoria void ReadBlo k( har *pbuff)
de video y ada palabra de la memoria ROM para el {
bootstrap del sistema. El onjunto de dire iones que
har* puerta_ ontrol= ( har*)0xe0000;
se pueden usar para estos nes se denomina el espa io har* puerta_datos=puerta_ ontrol+1;
de dire iones reales del omputador (ver gura 3.1). int nbytes=512;
Un programador omanda o examina un dispositivo es ribiendo o leyendo en la dire ion asignada a while (nbytes--)
este dispositivo en el espa io de dire iones. Esto es {
/* Ci lo de busy-waiting */
lo que se denomina Entrada/Salida mapeada en la
while (*puerta_ ontrol==0)
memoria (lo que se debe interpretar omo el espa io
/* todavia no llega un byte */ ;
de dire iones reales).
23

24

} }

CAPITULO 3. ESTRUCTURA DEL COMPUTADOR

/* Ahora si llego un byte */

/* Leemos el byte y lo olo amos
en el area suministrada */
*pbuff++= *puerta_datos;

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

Para ubi ar el dispositivo que interrumpio existen las

te ni as de polling y ve tor de interrup iones.
En la te ni a de polling el sistema operativo no
sabe ual dispositivo interrumpio y por lo tanto tiene
que onsultar se uen ialmente todos los dispositivos
hasta dar on aquel o aquellos que interrumpen. Este
me anismo tiene aso iado un tiempo prolongado de
rea ion a las interrup iones.
El segundo me anismo se basa en que ada fuente
de interrup ion tiene aso iado un ndi e. Este ndi e

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

Figura 3.2: Ve tor de interrup iones.

se usa para subindi ar una tabla de rutinas de aten ion (ver gura 3.2). Por lo tanto ada fuente de
interrup ion tiene aso iada una uni a rutina de aten ion. Esta tabla se denomina ve tor de interrup iones y se ubi a en algun lugar de la memoria real del
omputador.
Tambien existen esquemas mixtos en donde varios
dispositivos tienen aso iado una misma posi ion en el
ve tor de interrup iones (debido a que usan la misma
lnea de interrup ion). En ese aso el sistema operativo debe re urrir a la te ni a de polling para ubi ar
entre estos dispositivos ual fue el que interrumpio.
Adaptemos
el
ejemplo
anterior
modi ando ReadBlo k de modo que la le tura del
proximo bloque se reali e en paralelo on el bloque
que ya se leyo. Para esto despues de terminar la le tura de un bloque habilitamos las interrup iones del
dispositivo. Los bytes que se vayan re ibiendo se a umulan en un area es ondida (pbuff2). Con suerte se
re iben los 512 bytes de un bloque antes del proximo
llamado a ReadBlo k. De esta forma en la proxima
llamada el i lo de busy-waiting no se eje utara y se
opiara de inmediato el area es ondida ha ia el area
del llamador.
/* Puertas del dispositivos */
har* puerta_ ontrol=( har*)0xe0000;
har* puerta_datos= puerta_ ontrol+1;
/* El buffer de bytes */
int nbytes=0;
har pbuff2[512;
void RutinaAten ionDispositivoX()
{
pbuff2[nbytes++= *puerta_datos;
if (nbytes==512)
InhibirIntDispositivoX();
}


3.1. ARQUITECTURA LOGICA
DEL COMPUTADOR

void ReadBlo k( har *pbuff)

{
if (nbytes==0)
HabilitarIntDispositivoX();
while (nbytes<512)
/* busy-waiting */;
b opy(pbuff,pbuff2,nbytes);
nbytes=0;
HabilitarIntDispositivoX();
}

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

Un programa que orre en un sistema mono-usuario

omo un PC/DOS puede leer o es ribir ualquier dire ion en la memoria. Por lo tando puede alterar el
odigo de DOS, modi ar el ve tor de interrup iones
o la memoria de video y omandar ualquiera de los
dispositivos.
En ambio en un sistema multiprogramado un programa de un usuario no puede in uir en el programa de otro usuario. Para implementar esto todos
los mi ro-pro esadores modernos (Motorola 68000 e
Intel 286 en adelante) in orporan un modo dual :
 Modo sistema : Todas las instru iones son
validas. Este modo tambien se llama modo privilegiado, monitor o supervisor.

26

CAPITULO 3. ESTRUCTURA DEL COMPUTADOR

Z V S C I

O
1

Accesibles
desde un
proceso

Modo Usuario
Modo Sistema

2 GB

System
Segment

No accesible

0
1

Interrupciones Inhibidas
Interrupciones Activadas

Figura 3.3: Palabra de estado del pro esador

Text
Data
Segment Segment
(codigo) (datos)

4 GB

Stack
Segment
(pila)

Nucleo
del S.O.

Figura 3.4: Espa io de dire iones virtuales de un

programa
en Unix
 Modo usuario : Se inhiben iertas instru iones
onsideradas peligrosas porque pueden in uir en
los programas de otros usuarios. Se di e que es- El Hardware del omputador se en arga de tradu ir
tas instru iones son privilegiadas, porque solo e ientemente las dire iones virtuales a dire iones
pueden eje utarse en el modo privilegiado (mo- reales en todo a eso a la memoria o dispositivos.
do sistema).
Para ello, el nu leo le suministra los parametros sobre
omo realizar esa tradu ion.
El nu leo de un sistema operativo siempre orre El espa io de dire iones tpi o de un programa
en el modo sistema mientras que los programas del en Unix es el que se muestra en la gura 3.4. Las
usuario orren en modo usuario. Si un programa del ara tersti as de este espa io son:
usuario intenta eje utar una de estas instru iones se
produ e una interrup ion (trap) que ausa la invo a-  No hay ve tor de interrup iones.
ion de una rutina de aten ion provista por el nu leo.
Esta rutina de aten ion se eje uta en modo sistema  No existen puertas de dispositivos en este espa io.
y tiene el poder omo para abortar el programa que
intento eje utar la instru ion inhibida.
distinguen 3 zonas a esibles por un programa
El registro de estado del pro esador indi a el modo  Se
en
eje u ion: estas son el segmento de odigo, el
en que se trabaja (ver gura 3.3).
segmento
de datos y el segmento de pila.
Ejemplos de instru iones privilegiadas son la instru ion que inhibe las interrup iones y la instru ion  El segmento de odigo solo puede ser ledo (no
que ambia el registro de estado.
es rito).
Observe que este me anismo no es su iente para
prohibir el a eso a los dispositivos puesto que estos  Estos segmentos son ina esibles a partir de otros
se omandan on las mismas instru iones de le tura
programas que orren en el mismo pro esador.
y es ritura en memoria.
 Los segmentos de datos y pila estan separados
por una zona ina esible. Esta zona esta reser3.1.4 Espa io de Dire iones Virtuavada para la extension de estos segmentos.
les
programa puede ha er re er el area de datos
Cada programa del usuario orre en su propio espa io  Un
utilizando
la primitiva sbrk.
de dire iones virtuales independiente. Es el nu leo {
on ayuda del Hardware{ el que se en arga de emular  La pila re e ha ia las dire iones inferiores y se
varios espa ios de dire iones en un solo espa io de
extiende automati amente si se desborda.
dire iones real del pro esador.
Esto signi a que ada vez que un programa es-  Existe una area invisible para el programador
llamada segmento del sistema que solo el nu leo
pe i a una dire ion en donde leer o es ribir una
puede a esar en modo sistema.
palabra, esa dire ion esta referida al espa io de dire iones virtuales de ese programa. Esa dire ion
no orresponde a la dire ion real que o upa la pa- De esta forma los programas del usuario no puelabra en la memoria real del omputador. Ademas den ver los dispositivos, el ve tor de interrup iones,
la palabra de dire ion virtual 100 de un programa o las estru turas de datos que maneje internamente
en eje u ion tiene una dire ion real distinta de la el nu leo. Este es el me anismo de prote ion mas
palabra de dire ion virtual 100 en otro programa. importante que debe poseer un sistema operativo.

3.2. ARQUITECTURA DEL SISTEMA OPERATIVO

3.1.5 Cronometro regresivo

27
 Manejo de Pro esos: rea ion (fork), des-

tru ion (kill), termino (exit), sin roniza ion

(wait), arga de un binario (exe ).
 Manejo de memoria: extension de la memoria
de datos (sbrk).
 Manejo de ar hivos y dispositivos: open, read,
write y lose.
Estas llamadas se implementan usualmente on
una
instru ion de maquina que provo a una inte3.2 Arquite tura del Sistema rrup i
on. Esta interrup ion ha e que el pro esador
Operativo
real pase a modo sistema e invoque una rutina de
aten ion pertene iente al nu leo y que eje uta la llaLa organiza ion de los sistemas operativos ha evo- mada al sistema. Los argumentos de la llamada se
lu ionado desde los monitores residentes omo DOS pasan a traves de los registros del pro esador.
hasta los modernos sistemas multipro eso omo Solaris. A ontinua ion revisamos algunas de las ompo- 3.2.2 Los drivers para dispositivos
nentes que debe in luir todo sistema operativo moderno.
La opera ion de los dispositivos es altamente dependiente de su implementa ion. Es as omo un dis o
SCSI se opera de una forma distinta de un dis o IDE.
3.2.1 El nu leo
Para independizar el odigo del nu leo de los variados me anismos de intera ion on los dispositivos, el
El nu leo es la omponente del sistema operativo que n
dene lases de dispositivos. Ejemplos de lasiempre esta residente en la memoria real del ompu- sesu leo
son
inta, puerta de omuni a ion, interfaz
tador. La fun ion primordial del nu leo es transfor- de red, dis o,
et .
Para
ada lase se dene una interfaz
mar los re ursos reales del omputador en re ursos estandar para intera tuar
on ualquier dispositivo
estandares y omodos de usar.
que
pertenez a
a
la
lase.
Esta
orresponde
Es as omo el nu leo transforma un pro esa- a las de lara iones de un onjuntointerfaz
de
pro edimientos
dor real on su memoria nita en un numero no implementados.
pra ti amente ilimitado de pro esadores virtuales o
driver es el odigo que implementa una interpro esos. Cada pro eso dispone de su propio tiem- fazUn
est
para intera tuar on un dispositivo espo de CPU, una memoria extensible y me anismos pe  o,andar
omo
ejemplo un dis o SCSI. Este odigo
estandares para intera tuar on los dispositivos, sin es por lo tantoporaltamente
dependiente de los dis os
importar los detalles fsi os de su implementa ion. SCSI y no fun ionara on dis os
IDE. Sin embargo, el
nu leo intera tua on este driver para dis os SCSI de
la misma forma que lo ha e on el driver para dis os
La API del nu leo
IDE, es de ir a traves de la misma interfaz.
Una API (Interfaz de Programa ion de Apli a iones) La vision que tiene el nu leo de un dis o a traves
es el onjunto de servi ios que ofre e un sistema a las de un driver es la de un arreglo de bloques de 512
apli a iones usuarias de ese sistema. Las apli a iones o 1024 bytes de tama~no jo. El nu leo puede leer
invo an estos servi ios a traves de llamadas a pro e- o es ribir dire tamente ualquiera de estos bloques
dimientos. La API queda denida por lo tanto por ha iendo uso de la interfaz estandar de la lase dis o.
los nombres de estos pro edimientos, sus argumentos Por otra parte, la vision que tiene el nu leo de una
y el signi ado de ada uno de ellos.
inta es la de un onjunto de bloques de tama~no vaEl onjunto de servi ios que ofre e el nu leo a los riable que solo pueden leerse o grabarse en se uenpro esos se denomina la API del nu leo. Esta forma- ia. Tambien puede rebobinar esta inta para volver
da por pro edimientos pertene ientes al nu leo, pero a leerla o grabarla. Todo esto a traves de la interfaz
que se invo an desde un pro eso ualquiera. La invo- estandar de la lase inta.
a ion de uno de estos pro edimientos es una llamada En Unix una apli a ion puede a esar una partial sistema.
ion de un dis o en su formato nativo abriendo por
Ejemplos de llamadas al sistema en Unix son:
ejemplo /dev/sd0a.
El hardware del omputador debe in luir un
ronometro regresivo o timer. E ste es un dispositivo que el nu leo puede omandar para que invoque
una interrup ion despues de trans urrido un ierto
tiempo. De esta forma el nu leo uenta on un me anismo para entregar el pro esador a una apli a ion
por un tiempo a otado.

28

CAPITULO 3. ESTRUCTURA DEL COMPUTADOR

Es usual que los drivers esten siempre residentes

en la memoria real y por lo tanto son parte del
nu leo. Sin embargo la tenden ia es que los drivers
son modulos que se argan dinami amente si es ne esario. Tambien existen drivers que orren omo un
pro eso { omo ualquier apli a ion{ y por lo tanto
orren en modo usuario (por ejemplo el servidor X
de X-windows).
3.2.3 El sistema de ar hivos

El sistema de ar hivos es la omponente del sistema

operativo que estru tura un dis o en una jerarqua de
dire torios y ar hivos. Con eptualmente multiplexa
un dis o de tama~no jo en una jerarqua de dis os de
tama~no variable o ar hivos.
Dada esta equivalen ia on eptual entre dis os y
ar hivos no es raro que ambos se manipulen on las
mismas llamadas al sistema: open, read, write,
lose y lseek (esta u
ltima mueve la abeza del dis o
ha ia un bloque determinado).
Es usual que el sistema de ar hivos sea parte del
nu leo. Por lo demas la motiva ion ini ial de mu hos
sistemas operativos omo Unix era el de ofre er un
sistema de ar hivos a un uni o pro eso. Por algo
DOS signi a Disk Operating System y por ello es
natural que forme parte del nu leo. Sin embargo hay
sistemas operativos que ofre en el sistema de ar hivos
omo parte de un pro eso que no es parte del nu leo.
3.2.4 El interprete de omandos

El interprete de omando (o shell) se en arga de leer

las ordenes intera tivas del usuario y eje utar los programas que el usuario indique.
Usualmente el interprete de omandos es un pro eso mas del sistema operativo y no forma parte del
nu leo. Por ejemplo Unix ofre e varios interpretes de
omandos (sh, sh y sus variantes). El interprete de
omandos de DOS se en uentra en COMMAND.COM.
3.2.5 Ejemplos de Sistemas Operativos

Una aplicacion
Nucleo (DOS)
Drivers
(BIOS en ROM)
Hardware
(PC)

Figura 3.5: Organiza ion del Software en un PC

El nu leo de DOS implementaba un sistema de ar hivos jerarqui o y da a eso a puertas seriales y paralelas. El sistema es estri tamente mono-pro eso y
la memoria se limita a los primeros 640 KBytes de la
memoria des ontando lo que o upa el mismo DOS.
Un programa puede llamar a la API de DOS a traves
de la instru ion de maquina INT que provo a una
interrup ion.
Dado que la Intel 8088 no ofre a modo dual ni
me anismos para implementar espa ios de dire iones
virtuales, tanto DOS omo el pro eso en eje u ion
orren en el mismo modo y espa io de dire iones.
Esto no es un problema en un sistema mono-usuario
y mono-pro eso y que por lo tanto no ne esita un
me anismo de prote ion.
Los drivers no son parte de DOS, sino que vienen
en la memoria ROM de un PC. Esta omponente se
llama BIOS (Basi Input Output System) y puede ser
invo ada dire tamente por la apli a ion sin pasar por
DOS. Lamentablemente la BIOS no in luye los drivers su ientemente generales para manejar apropiadamente los distintos dispositivos. Esto obliga a que
las apli a iones deban a esar dire tamente el hardware para opera iones tan simples omo dibujar una
lnea en la pantalla.
Hoy en da DOS s implementa en una forma rudimentaria multiples pro esos, ada uno en su propio
espa io de dire iones. Sin embargo DOS debe permitir que estos manipulen dire tamente los dispositivos (sin ha erlo a traves de DOS) para garantizar
la ompatibilidad on las antiguas apli a iones. Por
ello DOS no puede ofre er verdadera prote ion entre
pro esos.

A ontinua ion revisamos la estru tura de algunos

sistemas operativos.
Linux, Berkeley Unix y Unix System V release
DOS

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

3.2. ARQUITECTURA DEL SISTEMA OPERATIVO

Procesador

Procesos

(CPU y memoria)

Apl2

Util2
Sistema
Operativo
Driver1

Apl1

Util1
Nucleo
Driver2

Driver3

Dispositivos

Figura 3.6: Estru tura de un Sistema Unix tradi ional.

estan orriendo. Entre estos se uentan los servi ios
de spooling, mail, news, www, et .
Chorus y Ma h

El nu leo de estos sistemas operativos esta dise~nado

on el enfoque minimalista: solo ofre e el servi io de
manejo de pro esos e inter omuni a ion entre pro esos a traves de una API no estandar. El sistema de
ar hivos, los drivers y ualquier otro servi io queda
fuera del nu leo y son ofre idos por medio de pro esos.
Ambos sistemas son ompatibles on Unix System V gra ias a un pro eso que implementa la API
estandar de Unix. Las llamadas de sistema de un
pro eso Unix se implementan enviando mensajes al
pro eso de la API que eje uta la llamada y devuelve
el resultado en otro mensaje.
El interes de este tipo de sistemas es que pueden
implementar varias APIs no solo la de Unix, sino que
tambien la de Windows o la de Ma intosh, et ., ada
una de estas APIs se implementan en pro esos independientes.

29

30

CAPITULO 3. ESTRUCTURA DEL COMPUTADOR

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

4.1 S heduling de Pro esos

En la mayora de los sistemas omputa ionales existe

un solo pro esador real. Por lo tanto el nu leo debe asignar el pro esador por turnos a los numerosos
pro esos que pueden estar a tivos. Hay distintas estrategias para asignar estos turnos, dependiendo del
objetivo que se persiga.
Por ejemplo en un sistema de multiprograma ion
se bus a maximizar el tiempo de uso del pro esador,
mientras que en un sistema de tiempo ompartido se
bus a atender en forma expedita a mu hos usuarios
que trabajan intera tivamente.
La asigna ion estrategi a del pro esador a los pro esos es lo que se denomina s heduling de pro esos.
Es estrategi a porque se intenta lograr algun objetivo parti ular omo alguno de los que se men iono
mas arriba y para ello se usan estrategias que pueden
fun ionar muy bien en determinados sistemas, pero
muy mal en otros. La omponente del nu leo que
se en arga de esta labor se denomina s heduler del
pro esador.
Ademas de s heduling de pro esos, tambien se realiza s heduling de los a esos a dis o y para ello existe
un s heduler aso iado a ada dis o. Este s heduler
ordena estrategi amente los mutiples a esos a dis o
de varios pro esos on el n de minimizar el tiempo

Read

4.1.1 Estados de un pro eso

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

El des riptor de pro eso es la estru tura de datos que

utiliza el nu leo para mantener toda la informa ion
aso iada a un pro eso. Ella ontiene :
 El estado del pro eso: En rea ion, listo, orriendo, et .
 Registros del pro esador: Aqu se guardan los
valores del ontador de programa, del puntero a
la pila y de los registros del pro esador real uando el pro eso abandono el estado orriendo.
 Informa ion para el s heduler: Por ejemplo la
prioridad del pro eso, punteros de enla e uando
el des riptor se en uentra en alguna ola, et .
 Asigna ion de re ursos: Memoria asignada, ar hivos abiertos, espa io de swapping, et .
 Contabiliza ion de uso de re urso: Tiempo de
pro esador onsumido y otros.

Exit

4.1.2 El des riptor de pro eso

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

Figura 4.3: Transito de un pro eso por distintas olas

El nu leo posee algun me anismo para obtener el
des riptor de pro eso a partir del identi ador del
pro eso, que es el que ono en los pro esos.
La gura 4.2 muestra el des riptor que usa nSystem. En nSystem el identi ador de tarea es un puntero a este des riptor. Sin embargo, por razones de
en apsula ion este puntero se de lara del tipo void
* en nSystem.h.
4.1.3 Colas de S heduling

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

Cambio de ontexto ( ontext swit h, task swit h o

pro ess swit h) es la a ion que efe tua el s heduler
uando transere el pro esador de un pro eso a otro.

33

4.1. SCHEDULING DE PROCESOS

typedef stru t Task /* Des riptor de una tarea */
{
int status;
/* Estado de la tarea (READY, ZOMBIE ...) */
har *taskname;
/* Util para ha er debugging */
SP sp;
SP sta k;

/* El sta k pointer uando esta suspendida */

/* El sta k */

stru t Task *next_task;

void *queue;

/* Se usa uando esta en una ola */

/* Debugging */

/* Para el nExitTask y nWaitTask */

int r ;
/* odigo de retorno de la tarea */
stru t Task *wait_task;
/* La tarea que espera un nExitTask */

/* Para nSend, nRe eive y nReply */

stru t Queue *send_queue; /* ola de emisores en espera de esta tarea */
union { void *msg; int r ; } send; /* sirve para inter ambio de info */
int wake_time;
/* Tiempo maximo de espera de un nRe eive */
int in_wait_squeue;
/* 1 si esta tarea se en uentra en wait_squeue */
*nTask;

Figura 4.2: El des riptor de pro eso en nSystem

Para realizar el ambio de ontexto, el s heduler debe
realizar diversas labores que detallamos a ontinua ion:
i. Resguardar/restaurar Registros.
Cuando un pro eso esta orriendo, se utiliza el
ontador de programa, el puntero a la pila y los
registros del pro esador real. Al ha er el ambio
de ontexto, el nuevo pro eso que toma el ontrol del pro esador usara esos mismos registros.
Por ello es ne esario resguardar los registros del
pro eso saliente en su des riptor de pro eso. De
igual forma, el des riptor del pro eso entrante
mantiene los valores que ontenan los registros
en el momento en que perdio el pro esador. Estos valores deben ser restaurados en los registros
reales para que el pro eso fun ione orre tamente.
ii. Cambiar espa io de dire iones virtuales.
El espa io de dire iones del pro eso saliente no
es el mismo del espa io de dire iones del pro eso
entrante. En el aptulo sobre administra ion
de memoria veremos omo se logra el ambio de
espa io de dire iones virtuales.
iii. Contabiliza ion de uso de pro esador.
Usualmente, el nu leo se en arga de ontabilizar
el tiempo de pro esador que utiliza ada pro eso.

Una variable en el des riptor de pro eso indi a el

tiempo a umulado. En ada ambio de ontexto
el nu leo onsulta un ronometro que ofre e el
hardware de ada omputador. El s heduler suma el tiempo trans urrido desde el ultimo ambio ontexto al tiempo a umulado del pro eso
saliente.
Estas labores del s heduler onsumen algo de tiempo de pro esador y por lo tanto son sobre osto puro.
Cada ambio de ontexto puede signi ar de 1 mi rosegundo a un milisegundo segun el sistema operativo
y la ayuda que ofrez a el hardware para realizar e ientemente el ambio de ontexto.
Normalmente la omponente mas ara en tiempo
de pro esador es la del ambio de espa io de dire iones virtuales. Ah radi a el origen del nombre de
pro esos livianos. Como los pro esos livianos omparten el mismo espa io de dire iones no es ne esario ambiarlo durante un ambio de ontexto. Por lo
tanto pueden ser implementados mas e ientemente.
En este aso el peso de un pro eso orresponde al
tiempo de pro esador que se onsume al realizar un
ambio de ontexto. A mayor tiempo, mayor peso.
Interrup iones vs. ambio de ontexto

Es importante ha er notar que uando se produ e una

interrup ion, el he ho de invo ar la rutina de aten ion

34

 DE PROCESOS
CAPITULO 4. ADMINISTRACION
Frecuencia

200

100

s heduler tratara de evitar los ambios de ontexto

en medio de una rafaga orta y solo introdu ira ambios de ontexto en rafagas prolongadas, que son las
menos.

4.2 Estrategias de s heduling

de pro esos

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

de la interrup ion no es un ambio de ontexto. Esto

se debe a que el odigo de la rutina de aten ion es
parte del nu leo y por lo tanto no pertene e a ningun
pro eso en parti ular. Para que haya un ambio de
ontexto es ne esario que se pase de la eje u ion del
odigo de un pro eso a la eje u ion del odigo de otro
pro eso.
Sin embargo mu hos ambios de ontexto o urren
durante una interrup ion, por ejemplo uando interrumpe el reloj regresivo. En otros asos, la interrup ion no se tradu e en un ambio de ontexto. Por
ejemplo si un dis o interrumpe, esto puede signi ar que el pro eso que esperaba esta interrup ion se
olo a en la ola del s heduler pero no se le transere
de inmediato el pro esador, se ontinua eje utando el
pro eso interrumpido.
4.1.5 Rafagas de CPU

Una rafaga de CPU es una se uen ia de instru iones

que puede eje utar un pro eso sin pasar a un estado
de espera. Es de ir el pro eso no espera un a eso al
dis o, la re ep ion de un mensaje, el termino de un
pro eso, et .
La eje u ion de un pro eso onsta de innumerables
rafagas de CPU. Empri amente se ha determinado
que la mayora de las rafagas toman po as instru iones. Esto se observa gra amente en la gura 4.4.
El s heduler puede aprove harse de este he ho
empri o para disminuir el sobre osto de los ambios
de ontexto. En efe to, al nal de una rafaga el ambio de ontexto es inevitable porque el pro eso en
urso pasa a un modo de espera. Al ontrario, los
ambios de ontexto en medio de una rafaga son evitables y por lo tanto son sobre osto puro. Un buen

4.2.1 First Come First Served o FCFS

E sta es una estrategia para pro esos non-preemptive.

En ella se atiende las rafagas en forma ininterrumpida
en el mismo orden en que llegan a la ola de pro esos,
es de ir en orden FIFO.
Esta estrategia tiene la ventaja de ser muy simple
de implementar. Sin embargo tiene varias desventajas:
i. Pesimo omportamiento en sistemas de tiempo
ompartido. Por lo tanto solo se usa en sistemas
bat h.
ii. El tiempo de despa ho depende del orden de llegada.
Por ejemplo supongamos que llegan 3 rafagas de
dura ion 24, 3 y 3.
Si el orden de llegada es 24, 3 y 3, el tiempo
promedio de despa ho
es :
24+27+30 = 27
3
Si el orden de llegada es 3, 3 y 24, el promedio
es:
3+6+30 = 13
3
iii. Los pro esos intensivos en tiempo de CPU tienden a pro esarse antes que los intensivos en E/S.
Por lo tanto, al omienzo el uello de botella es
la CPU mientras que al nal son los anales de
E/S y la CPU se utiliza po o. Es de ir esta estrategia no maximiza el tiempo de utiliza ion de
la CPU.
Observe que aun uando esta estrategia es nonpreemptive esto no impide que en medio de una
rafaga de CPU pueda o urrir una interrup ion de E/S
que implique que un pro eso en espera pase al estado
listo para orrer.

35

4.2. ESTRATEGIAS DE SCHEDULING DE PROCESOS

4.2.2 Shortest Job First o SJF

En prin ipio si se atiende primero las rafagas mas

breves se minimiza el tiempo promedio de despa ho.
Por ejemplo si en la ola de pro esos hay rafagas que
van a durar 5, 2, 20 y 1, estas rafagas deberan ser
atendidas en el orden 1, 2, 5 y 20. El tiempo promedio
de despa ho sera: 1+3+8+29
= 10
4
Se demuestra que este promedio es inferior a ualquier otra permuta ion en el orden de aten ion de las
rafagas. Pero desde luego el problema es que el s heduler no puede prede ir el tiempo que tomara una
rafaga de CPU.
Sin embargo es posible al ular un predi tor del
tiempo de dura ion de una rafaga a partir de la dura ion de las rafagas anteriores. En efe to, se ha omprobado empri amente que la dura ion de las rafagas
tiende a repetirse. El predi tor que se utiliza usualmente es:
nP+1 = tPn + (1 )nP
En donde :
nP+1 :
tPn :
nP :
:

El predi tor de la pr

oxima r
afaga
Dura i
on de la r
afaga anterior
Predi tor de la r
afaga anterior
Ponderador para la u
ltima r
afaga

Tpi amente  = 0:5. Con esta formula se pondera

espe ialmente la dura ion de las ultimas rafagas, ya
que al expandir esta formula se obtiene:
nP+1 = tPn + (1 )tPn 1 + (1 )2 tPn 2 + :::
De este modo uando hay varios pro esos en la ola
de pro esos listos para orrer, se es oge aquel que
tenga el menor predi tor.
SJF puede ser non-preemptive y preemptive. En el
aso non-preemptive una rafaga se eje uta ompletamente, aun uando dure mu ho mas que su predi tor.
Desde luego, la variante non-preemptive se usa solo
en sistemas bat h.
En el aso preemptive se estable e una ota al tiempo de asigna ion del pro esador. Por ejemplo la ota
podra ser el segundo predi tor mas bajo entre los
pro esos listos para orrer. Tambien hay que onsiderar el aso en que mientras se eje uta una rafaga,
llega una nueva rafaga on un predi tor menor. En
este aso, la rafaga que llega debera tomar el pro esador.

P1

P1 P2 P3 P4 P1 ...
P4

P2

corriendo

P3

Cambio de
contexto

Figura 4.5: Round-Robin

la mayor prioridad entre los pro esos que estan listos para orrer. La prioridad puede ser ja o puede
ser al ulada. Por ejemplo SJF es un aso parti ular
de s heduling on prioridad en donde la prioridad se
al ula omo p = n+1 .
El problema de esta estrategia es que puede provo ar hambruna (starvation), ya que lo pro esos on
baja prioridad podran nun a llegar a eje utarse porque siempre hay un pro eso listo on mayor prioridad.
Aging

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

Es una estrategia muy usada en sistemas de tiempo

ompartido. En Round-Robin los pro esos listos para
orrer se organizan en una lista ir ular. El s heduler
se pasea por la ola dando tajadas peque~nas de tiempo de CPU (time sli ing) : de 10 a 100 milisegundos.
Esta estrategia se apre ia en la gura 4.5.
Esta estrategia minimiza el tiempo de respuesta en
los
sistemas intera tivos. El tiempo de respuesta es
4.2.3 Colas on prioridad
el tiempo que trans urre entre que un usuario ingresa
En esta estrategia se aso ia a ada pro eso una priori- un omando intera tivo hasta el momento en que el
dad. El s heduler debe velar porque en todo momen- omando despliega su primer resultado. No se onsito el pro eso que esta orriendo es aquel que tiene dera el tiempo de despliegue del resultado ompleto.

36

 DE PROCESOS
CAPITULO 4. ADMINISTRACION

Esto se debe a que para un usuario intera tivo es

mu ho mas molesto que un omando no de ninguna
se~nal de avan e que un omando que es lento para
desplegar sus resultados. Por esta razon el tiempo
de respuesta solo onsidera el tiempo que demora un
omando en dar su primer se~nal de avan e.

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

El segundo problema que hay que resolver es donde

olo ar los pro esos que pasan de un estado de espera

P3

llega Q

Implementa ion

Esta estrategia se implementa usando una ola FIFO

on todos los pro esos que estan listos para orrer.
Al nal de ada tajada el s heduler olo a el pro eso
que se eje utaba al nal de la ola y extrae el que
se en uentra en primer lugar. El pro eso extrado
re ibe una nueva tajada de CPU. Para implementar
la tajada, el s heduler programa una interrup ion del
reloj regresivo de modo que se invoque una rutina
de aten ion (que pertene e al s heduler) dentro del
tiempo que dura la tajada.
Si un pro eso termina su rafaga sin agotar su tajada (porque pasa a un modo de espera), el s heduler
extrae el proximo pro eso de la ola y le da una nueva
tajada ompleta. El pro eso que termino su rafaga
no se olo a al nal de la ola del s heduler. Este pro eso queda en alguna estru tura de datos esperando
algun evento.

P2

P4

P4

P2
corriendo
llega Q

P1

P3

P4

P2
corriendo

P3
Q
Despues

Figura 4.6: Inser ion de pro esos en Round-Robin

al estado listo para orrer. Es de ir en que lugar
agregar estos pro esos en la lista ir ular de RoundRobin (ver gura 4.6).
Cuando un pro eso llega, las dos uni as posibilidades son agregarlo antes del pro eso en eje u ion o
agregarlo despues.
La primera posibilidad se implementa agregando el
pro eso que llega al nal de la ola del s heduler. Este pro eso debera esperar una vuelta ompleta antes
de que lo toque su tajada. Esto tendera a desfavore er a los pro esos intensivos en E/S debido a que sus
rafagas terminan mu ho antes que la tajada, teniendo que esperar la vuelta ompleta despues de ada
opera ion de E/S. En ambio, los pro esos intensivos
en CPU agotaran ompletamente su tajada antes de
tener que esperar la vuelta ompleta.
En la segunda posibilidad el pro eso que llega se
agrega en primer lugar en la ola del s heduler (es
de ir la ola ya no es siempre FIFO). Esta variante
tiene un omportamiento mas errati o. Veamos que
su ede en los siguientes asos:
 Hay dos pro esos, uno intensivo en CPU que

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

 Hay mu hos pro esos intensivos en E/S y mu-

nMain

call R

nMain

Return

nMain

hos pro esos intensivos en CPU. En este aso

Apilar
Desapilar
los pro esos de E/S pueden ausar hambruna a sp
sp
los pro esos de CPU, pues los pro esos de E/S
sp
Registro de
terminan su rafaga antes que su tajada y desactivacion
de R
pues de un eventualmente orto perodo de espera quedan en primer lugar en la ola. Si hay
su ientes pro esos de E/S omo para o upar el Figura 4.8: Llamado y retorno de pro edimientos
100% de la CPU, los pro esos intensivos en CPU usando una pila
nun a re ibiran su tajada.
Una vez que un job fue lanzado, este se administra solo en los niveles de orto y mediano plazo.
4.3 Jerarquas de S heduling
Es de ir que el s heduler de largo plazo no tiene
ninguna in iden ia sobre los jobs ya lanzados.
Normalmente los sistemas operativos implementan
una jerarqua de s heduling de pro esos. Esto se debe
a que, primero, la CPU no es el uni o re urso que hay
que administrar, la memoria tambien es es asa y hay 4.4 Administra ion de pro esos
que administrarla; y segundo, no todos los pro esos
en nSystem
tienen la misma urgen ia, por lo que es onveniente
que los pro esos no urgentes se pospongan hasta que El nSystem es un sistema de pro esos livianos o nano
el omputador se en uentre mas deso upado.
tareas que orren en un solo pro eso pesado de Unix.
Es as omo el s heduling se podra organizar en 3 Las tareas de nSystem se implementan multiplexando
niveles:
el tiempo de CPU del pro eso Unix en tajadas. Esto
se puede ha er gra ias a que un pro eso Unix tiene
 S heduling de orto plazo.
aso iado su propio reloj regresivo, un me anismo de
En este nivel se administra solo la CPU usando interrup iones (se~nales), E/S no bloqueante y todas
las estrategias vistas en la se ion anterior. Esta las ara tersti as del hardware que se ne esitan para
implementar multiprograma ion en un solo pro esaadministra ion la realiza el nu leo.
dor, on la salvedad de que este hardware es emulado
en software por Unix.
 S heduling de mediano plazo.
4.7 muestra la organiza ion de nSystem
En este nivel se administra la memoria. Cuando enLamogura
dulos.
es una bibliote a de pro edila memoria disponible no es su iente se llevan mientos que senSystem
sit
u
a
entre
apli a ion (el odigo del
pro esos a dis o. Esta transferen ia a dis o toma programador) y la API de laUnix.
mu ho mas tiempo que un traspaso de la CPU Los pro edimientos superiores orresponden a la
(0.1 a 1 segundo vs. menos de un milisegundo). API de nSystem y son por lo tanto invo ados por
Por lo tanto las transferen ias a dis o deben ser la apli a ion. Los pro edimientos de mas abajo son
mu ho menos fre uentes que los ambios de on- pro edimientos internos que se requieren en la impletexto. Por esta razon se habla de mediano plazo. menta ion de la API. El nombre que apare e vertiEste nivel de s heduling tambien se realiza en el almente
es el ar hivo en donde se implementa un
nu leo.
modulo en parti ular. Las e has indi an que el pro edimiento desde donde se origina la e ha ne esita
 S heduling de largo plazo.
Este nivel esta orientado al pro esamiento bat h. invo ar el pro edimiento de destino de la e ha.
Los pro esos bat h o jobs no son urgentes, por
lo que su lanzamiento puede ser postergado si el 4.4.1 La pila
omputador esta sobre argado. No todos los sis- Cada nano tarea tiene su propia pila. Los registros
temas operativos implementan este nivel de s he- de a tiva ion de los pro edimientos que se invo an
duling y si lo ha en, lo realizan fuera del nu leo en una tarea se apilan y desapilan en esta estru tura
a traves de pro esos \demonios".
de datos (ver gura 4.8). Un registro del pro esador,
En este nivel hay una ola de jobs esperando ser denominado sp, apunta ha ia el tope de la pila.
lanzados. El s heduler lanza jobs solo en la medi- La pila es de tama~no jo, por lo que una re ursion
da que el pro esador tiene apa idad disponible. demasiado profunda puede desbordarla. El nSystem
P

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

Figura 4.7: Organiza ion de nSystem

hequea el posible desborde de la pila en ada ambio
de ontexto. De o urrir un desborde el nSystem termina on un mensaje expli ativo. Sin embargo si no
hay ambios de ontexto no puede dete tar el desborde. En este aso, el nSystem podra terminar en un
segmentation fault o bus error, sin mayor expli a ion
de la ausa de la ada.
4.4.2 El ambio de ontexto

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

Figura 4.10: Cambio de ontexto en nSystem.

Llegada
Fin tajada
Salida
Salida
Salida
Fin tajada

Figura 4.11: S heduling en nSystem

en el pro eso Unix en donde orre el nSystem.
4.4.3 S heduling en nSystem

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 indenidamente 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

Unix, es de ir el tiempo de uso del pro esador real

por parte del pro eso Unix sin ontar el tiempo en
que el pro esador estaba en pose ion de otro pro eso
Unix. En efe to, ambiar de tarea ada t milisegundos de tiempo real no tendra sentido, pues durante
ese intervalo podra haber su edido que el pro eso
Unix en donde orre nSystem no hubiese tenido el
pro esador real y por lo tanto la tarea en eje u ion
no pudo avanzar tampo o.
S heduling simpli ado

La siguiente es una version simpli ada del odigo

del s heduler. En ella no se onsideran iertas ondi iones de borde que obs ure en inne esariamente el
odigo. Estas ondi iones son el aso en que no hay
tareas listas para orrer y el aso en que el s heduling
es non-preemptive.
El s heduler mantiene las siguientes variables:
nTask
Queue
int

urrent task
ready queue
urrent sli e

La tarea en eje u i
on
La ola dual
El intervalo entre interrup iones

El s heduler retoma una tarea on el siguiente pro edimiento:

ResumeNextReadyTask()
{
nTask this_task= urrent_task;
nTask next_task= GetTask(ready_queue);
ChangeContext(this_task, next_task);
urrent_task= this_task; /* (1) */
}

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();

Para implementar SetAlarm se usaron las llamadas

al sistema setitimer y siga tion.
Note que la tarea que re ibe el pro esador estaba bloqueada en el llamado a ChangeContext de
ResumeNextReadyTask y por lo tanto es ella la que
a tualizara la variable urrent task on su propio
identi ador. En nSystem todos los ambios de ontexto se realizan a traves de ResumeNextReadyTask.
La uni a ex ep ion es el ambio de ontexto que se
realiza al rear una tarea.

... por ada tarea task que puede

avanzar:
PushTask(task, ready_queue);
...
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 */

int r = read(fd, buf, nbyte);

while (r <0 && errno==EAGAIN)
{ /* No hay nada disponible */
AddWaitingTask(fd, urrent_task);
urrent_task->status= WAIT_READ;
/* Pasamos a la proxima tarea ready */
ResumeNextReadyTask();
/* Ahora si que deberia fun ionar */
r = read(fd, buf, nbyte);
}
return r ;

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(...);

int nRead(int fd, ...)

{
START_CRITICAL();
... omo antes ...
END_CRITICAL();
}

El pro edimiento START CRITICAL inhibe las

se~nales de Unix usando la llamada al sistema
sigpro mask.
La misma llamada se usa en
END CRITICAL para rea tivar las se~nales.
No es ne esario inhibir las se~nales en
VtimerHandler o SigioHandler porque estos pro edimientos son para atender se~nales de Unix, y en
este aso Unix los invo a desde ya on las se~nales inhibidas. De igual forma uando estos pro edimientos
retornan, se rea tivan automati amente las se~nales.
4.4.6 Implementa ion de semaforos en
nSystem

Un semaforo se representa mediante una estru tura

de datos que tiene la siguiente informa ion:

 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();

4.5.1 Unix en monopro esadores

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

Las llamadas al sistema siempre las eje uta el nu leo

en el modo sistema. La uni a forma de pasar desde
una apli a ion al modo sistema es por medio de una
interrup ion. Por lo tanto las llamadas al sistema se
implementan pre isamente a traves de una interrup ion.
Cuando se ha e una llamada al sistema omo read,
}
write, et ., se invo a un pro edimiento de bibliote a
uya uni a labor es olo ar los argumentos en regisdel pro esador y luego eje utar una instru ion
Es importante desta ar que uando en nSignalSem tros
de
m
aquina ilegal (instru ion trap). Esta instru se inhiben las se~nales de Unix y se retoma otra tarea ion ausa
la interrup ion que el nu leo re ono e ollamando a ResumeNextReadyTask, es esta otra tarea mo una llamada
al sistema.
la que rea tivara las se~nales en el END CRITICAL del
nal de nWaitSem.
El END CRITICAL que se en uentra al nal de El segmento sistema
nSignalSem solo se invo ara uando se retome nue- Al pasar a modo sistema, omienza a eje utarse
vamente la tarea que invo o este pro edimiento. Y odigo del nu leo. El espa io de dire iones que se ve
enton es se rea tivaran las se~nales que fueron inhibi- desde el nu leo ontiene los mismos segmentos que se
das por otra tarea, aquella que perdio el pro esador. ven desde una apli a ion: odigo, datos y pila. Pero

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

Figura 4.12: El espa io de dire iones en modo sistema.

ademas se agrega un nuevo segmento: el segmento
sistema. Este segmento se apre ia en la gura 4.12.
El segmento sistema es ompartido por todos los
pro esos. Es de ir no existe un segmento sistema por
pro eso, sino que todos los pro esos ven los mismos
datos en este segmento. Si un pro eso realiza una
modi a ion en este segmento, los demas pro esos
veran la modi a ion.
El segmento sistema ontiene el odigo del nu leo,
el ve tor de interrup iones, los des riptores de pro eso, la ola de pro esos ready, las olas de E/S de
ada dispositivo, los buers del sistema de ar hivos,
las puertas de a eso a los dispositivos, la memoria
de video, et . Enfn, todos los datos que los pro esos
ne esitan ompartir.
Por simpli idad, es usual que las implementa iones
de Unix ubiquen los segmentos de la apli a ion por
debajo de los 2 gigabytes (la mitad del espa io dire ionable) y el segmento sistema por arriba de los 2
gigabytes. Ademas en el segmento sistema se olo a
toda la memoria real del omputador. De esta forma
el nu leo no solo puede ver la memoria del pro eso interrumpido, sino que tambien pueden ver la memoria
de los demas pro esos.
Pro esos ligeros en el nu leo

Cada pro eso pesado tiene aso iado en el nu leo un

pro eso ligero en argado de atender sus interrup iones (ver gura 4.13). Este pro eso ligero tiene su pila
en el segmento sistema y omparte sus datos y odigo
on el resto de los pro esos ligeros que orren en el
nu leo.
Es en este pro eso ligero en donde orre la rutina
de aten ion de ualquier interrup ion que se produz a
mientras orre una apli a ion en el modo usuario, sea
esta interrup ion una llamada al sistema, un evento

Interrupcion

Retorno de una
interrupcion

Figura 4.13: Pro esos ligeros en el nu leo

de E/S rela ionado on otro pro eso, una division por
ero, et .
Con eptualmente, una llamada al sistema es un
mensaje sn rono que enva el pro eso pesado al pro eso ligero en el nu leo. De igual forma el retorno
de la rutina de aten ion orresponde a la respuesta a
ese mensaje que permite que el pro eso pesado pueda
ontinuar.
Los pro esos del nu leo se eje utan on las interrup iones inhibidas y por lo tanto no pueden haber
ambios de ontexto no deseados. De esta forma se
logra la ex lusion en las se iones rti as del nu leo.
Los ambios de ontexto solo o urren expl itamente.
Para implementar este esquema, el hardware de los
mi ropro esadores modernos ofre e dos punteros a la
pila, uno para el modo usuario y otro para el modo
sistema y su inter ambio se realiza automati amente
uando o urre una interrup ion. Desde luego, en el
modo usuario, el puntero a la pila del modo sistema
no es visible, mientras que en el modo sistema s se
puede modi ar el puntero a la pila del modo usuario.
Rela ion on nSystem

Cuando un pro eso Unix pasa al modo sistema, le

entrega el ontrol a su respe tivo pro eso ligero en el
nu leo. Este ultimo orre on las interrup iones inhibidas, omparte el segmento sistema y tiene a eso
a toda la maquina. Por lo tanto on eptualmente
es similar a una nano tarea en nSystem que inhibe
las interrup iones on START CRITICAL(), omparte
el espa io de dire iones on otras nano tareas y tiene
a eso a todo el pro esador virtual.

 DE PROCESOS EN UNIX
4.5. IMPLEMENTACION

Es de ir, un pro eso pesado en Unix que llama al

sistema o es interrumpido se onvierte en un pro eso
ligero ininterrumpible en el nu leo. Luego, los algorit-

mos y estrategias que se vieron para nSystem pueden

ser usados para implementar mensajes, semaforos,
E/S, et . en un monopro esador bajo Unix.
El esquema presentado tiene la ventaja de ser simple de implementar. Sin embargo tiene la desventaja
de que el sistema permane e largos perodos on las
interrup iones inhibidas, lo que puede ser ina eptable
para sistemas de ontrol automati o. Este tipo de sistemas requieren a ve es respuestas rapidas a eventos,
en el rango de unos po os mi ro-segundos.
Ejemplos de sistemas que usan este esquema son
Unix SCO, Berkeley Unix y Linux.
4.5.2 Unix en multipro esadores

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.

Un multipro esador puede orrer varios pro esos

Unix en paralelo. Todos los pro esadores omparten la memoria real del omputador, pero la vision
on eptual de un pro eso Unix sigue siendo la misma : un solo pro esador en donde orre un programa.
Es de ir que los multiples pro esos Unix que orren Ex lusion a traves de andados
en un multipro esador no omparten sus espa ios de Para impedir que dos pro esadores pasen al modo
dire iones.
sistema simultaneamente por medio de una llamada
al sistema, se olo a un andado (lo k) a la entrada
del nu leo. Cuando un pro esador entra al nu leo
S heduling
ierra el andado. Si otro pro esador intenta entrar al
En este esquema hay un reloj regresivo por pro esa- nu leo tendra que esperar hasta que el primer pro eso
dor. De modo que el tiempo de ada pro esador se abra el andado al salir del nu leo.
puede multiplexar en tajadas de tiempo que se otor- El andado es una estru tura de datos que posee
gan por turnos a los distintos pro esos que esten listos dos opera iones:
para orrer. Cada vez que o urre una interrup ion
del reloj regresivo, la rutina de aten ion debe olo ar  Lo k(&lo k) : Si el andado esta errado espera
hasta que este abierto. Cuando el andado esta
el pro eso en eje u ion en la ola global de pro esos
abierto, ierra el andado y retorna de inmediaready, extraer un nuevo pro eso y eje utarlo.
to.
El problema se presenta uando la interrup ion se
produ e simultaneamente en dos pro esadores. En-  Unlo k(&lo k) : Abre el andado y retorna de
ton es los dos pro esadores modi aran paralelameninmediato.
te la ola global de pro esos, on el peligro de dejar
la ola en un estado in onsistente.
El andado se ierra al prin ipio de la rutina de
aten ion de las interrup iones por llamadas al sistePrimera solu ion : un solo pro esador en el ma. Es de ir uando el pro esador ya se en uentra
en el modo sistema, pero todava no ha realizado ninnu leo
guna a ion peligrosa. Si el pro esador en uentra eCuando todos los pro esadores eje utan instru iones rrado el andado, se queda bloqueado hasta que el
en el modo usuario, no hay se iones rti as puesto andado sea abierto por el pro esador que se en uenque los pro esos que orren en ada pro esador no tra en el modo sistema. Mientras tanto el pro esador
omparten sus espa ios de dire iones. De igual for- bloqueado no puede eje utar otros pro esos, pues dama si solo uno de los pro esadores se en uentra en el do que la ola ready es una estru tura de datos ommodo sistema, no hay peligro de modi a ion on u- partida, no puede tener a eso a ella para extraer y
rrente de una estru tura de datos ompartida.
retomar un pro eso.

44

 DE PROCESOS
CAPITULO 4. ADMINISTRACION

El andado se abre en la rutina de aten ion justo

antes de retornar a la apli a ion.
Observe que no es razonable implementar el andado antes de que la apli a ion pase al modo sistema,
puesto que nadie puede obligar a una apli a ion a veri ar que el andado esta abierto antes de ha er una
llamada al sistema.

}
void Unlo k(int *plo k)
{
*plo k= OPEN;
}

Observe que si un pro esador en uentra el andado

errado, la opera ion swap se realiza de todas forImplementa ion de andados
mas, pero el resultado es que el andado permane e
La siguiente implementa ion es erronea. El anda- errado. En ingles, un andado implementado de esta
do se representa mediante un entero que puede estar forma se llama spin-lo k.
OPEN o CLOSED.
Si el andado se en uentra errado, antes de volver
a onsultar por el andado se eje uta un peque~no
void Lo k(int *plo k)
i lo
que dure algunos mi ro-segundos. Esto se ha{
e on el objeto de disminuir el tra o en el bus de
while (*plo k==CLOSED)
datos que es ompartido por todos los pro esadores
;
para llegar a la memoria. Para poder entender esto
*plo k=CLOSED;
es ne esario ono er la implementa ion del sistema
}
de memoria de un multipro esador que in luye un
void Unlo k(int *plo k)
a he por pro esador y un proto olo de oheren ia
{
de
a hes.
*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

Nu leos Multi-threaded

Para resolver denitivamente 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.

5.1 Segmenta ion

Area de
Dispositivos

La segmenta ion es un esquema para implementar

espa ios de dire iones virtuales que se usaba en los
primeros omputadores de tiempo ompartido. Pese
a que hoy en da se en uentra en desuso, es interesante
estudiar la segmenta ion por su simpli idad.
Como se vio en aptulos anteriores, ada pro eso
tiene su propio espa io de dire iones virtuales, independiente del resto de los pro esos. Este espa io de
dire iones virtuales se des ompone en uatro areas
llamadas segmentos (ver gura 5.1):
 Un segmento de odigo.
 Un segmento de datos.
 Un segmento de pila.
 Un segmento de sistema, invisible para la apli a ion, en donde reside el nu leo.
Figura 5.2: Ejemplo de ubi a ion de los segmentos
En una organiza ion segmentada, los segmentos re- de dos pro esos en la memoria real.
siden en un area ontigua de la memoria real del omputador. La gura 5.2 muestra un posible estado de
la memoria de un omputador on los distintos segmentos de varios pro esos.
En la gura se observa que el segmento sistema
ontiene una imagen de toda la memoria real del
omputador. Esta es una te ni a muy usada en la
implementa ion de Unix.
4G

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

5.1.2 Tradu ion de dire iones virtuales

En ada a eso a la memoria un pro eso espe i a

una dire ion virtual. El hardware del pro esador
tradu e esta dire ion virtual a una dire ion real utilizando un onjunto de registros del pro esador que
alma enan la tabla de segmentos del pro eso en eje u ion.
Esta tradu ion se lleva a abo de la siguiente forma : el hardware del pro esador ompara la dire ion
virtual espe i ada on la base y el lmite de ada uno
de los segmentos:
baseseg  dire ion virtual < lmiteseg

5.1.3 Administra ion de la memoria

de segmentos

El nu leo rea y destruye segmentos uando se rea

o termina un pro eso o uando se arga un nuevo
binario (llamadas al sistema fork, exit y exe en
Unix). El nu leo administra la memoria para estos
segmentos en un area de la memoria denominada heap
(monton). Esta estru tura es similar al heap que utiliza mallo y free para administrar la memoria de
un pro eso.
Por onvenien ia, el nu leo separa en dos heaps
independientes la administra ion de la memoria para
segmentos y la administra ion de la memoria para sus
propias estru turas de datos omo los des riptores de
pro eso, olas de s heduling, olas de E/S, et .
En un heap hay trozos de memoria o upada y trozos libres. Los trozos libres se enlazan en una lista que
es re orrida, de a uerdo a alguna estrategia, uando
se soli ita un nuevo trozo de memoria. Cuando se

49


5.1. SEGMENTACION

libera un trozo, se agrega a la lista. Esto ha e que el

heap se fragmente progresivamente, es de ir se onvierte en un sin numero de trozos libres de peque~no
tama~no.
Para disminuir la fragmenta ion, al liberar un trozo
se revisan los trozos adya entes en el heap para ver si
estan libres. Si alguno de ellos esta libre (o los dos),
enton es los trozos se on atenan.
Las estrategias mas ono idas para realizar la
busqueda en la lista de trozos libres son :
 First-t : Se re orre se uen ialmente la lista de
trozos libres hasta en ontrar el primer trozo que
sea de tama~no mayor o igual al tama~no del trozo
soli itado. El trozo en ontrado se parte en dos
para entregar solo el tama~no soli itado.
 Best-t : Se re orre toda lista para en ontrar el
trozo que se a erque mas en tama~no al trozo soli itado. El mejor trozo se parte en dos omo en
First-t.
 Worst-t : Se re orre toda la lista para en ontrar
el trozo mas grande. Este trozo se parte en dos
omo First-t. Solo existe por ompletitud.
La estrategia best-t tiene mal desempe~no debido
a que al partir el mejor trozo, el trozo que queda libre
es demasiado peque~no. Sera muy dif il que se pueda
entregar ese peque~no trozo en un pedido subse uente.
Esto ha e que la lista de trozos libres se va poblando
de trozos demasiado peque~nos que aumentan el osto
de re orrer la lista.
De estas estrategias, rst-t es la que mejor fun iona, pero organizando los trozos libres en una lista
ir ular. La idea es evitar que se busque siempre
a partir del mismo trozo, puesto que esto tiende a
poblar el omienzo de la lista on trozos peque~nos,
alargando el tiempo de busqueda. En esta variante,
al ha er una busqueda se memoriza el ultimo trozo visitado en la lista ir ular. Al ha er una nueva
busqueda se omienza por el trozo siguiente al trozo
memorizado.
5.1.4 Compa ta ion en el nu leo

A medida que se soli itan y liberan trozos de memoria

en un heap, inevitablemente el heap se va fragmentando. La mejores estrategias omo rst-t disminuyen la rapidez de fragmenta ion, pero no la evitan.
En un heap omo el que utiliza mallo y free para
administrar la memoria de un pro eso, el problema
de la fragmenta ion no tiene solu ion. Pero no se
trata de un problema grave, puesto que un pro eso

Compactacion

Figura 5.3: Compa ta ion de la memoria real.

Unix puede ha er re er su espa io de datos, uando ninguno de los trozos disponibles es del tama~no
soli itado.
En el nu leo sin embargo, uando se trata de administrar la memoria de segmentos, no existe la posibilidad de ha er re er la memoria real del omputador. En ambio, el nu leo s puede ompa tar el heap
dedi ado a los segmentos (ver gura 5.3). Para ello
basta desplazar los segmentos hasta que o upen un
area de memoria ontigua en el heap. As la lista de
trozos libres se redu e a uno solo que ontiene toda
la memoria disponible en el heap.
Al desplazar los segmentos de un pro eso, las dire iones reales ambian, por lo que hay que modi ar
sus desplazamientos en la tabla de segmentos del pro eso, pero las dire iones virtuales manejadas por el
pro eso no ambian. Esto signi a que si un objeto o upaba una dire ion virtual ualquiera, despues
de desplazar los segmentos del pro eso, su dire ion
virtual sigue siendo la misma, a pesar de que su dire ion real ambio. Esto garantiza que los punteros
que maneja el pro eso ontinuaran apuntando a los
mismos objetos.
Compa ta ion en un pro eso

Observe que la solu ion anterior no fun iona para

un pro eso Unix, s se alteran las dire iones virtuales de los objetos. Despues de ompa tar habra que
entrar a orregir los punteros, lo que es muy dif il de
ha er en C, puesto que ni siquiera se puede distinguir
en la memoria un entero de un puntero.
Por esta misma razon es onveniente separar en el
nu leo la administra ion de los segmentos del resto
de las estru turas que pueda requerir el nu leo. Si
se desplazan segmentos, es simple determinar uales
son los desplazamientos que hay que modi ar en los
mallo y free, puesto que si se ompa ta el heap de

50

 DE MEMORIA
CAPITULO 5. ADMINISTRACION

des riptores de pro eso. En ambio si se desplazan

estru turas omo olas o des ritores de pro eso, es
muy ompli ado determinar desde que punteros son
apuntadas estas estru turas.
Existen lenguajes de programa ion, omo Lisp, Java y Smalltalk, que s permiten implementar ompa ta ion. Estos lenguajes se implementan ha iendo
que ada objeto en el heap tenga una etiqueta que
Figura 5.4: Implementa ion de fork.
di e que tipo de objeto es, por lo que un ompa tador puede determinar si el objeto tiene punteros que
deberan orregirse. En todo aso, esta ompa ta ion Con este me anismo la memoria que ne esita un
es responsabilidad del pro eso y no del nu leo, por la pro eso para su pila se asigna en demanda: la memisma razon que en C mallo y free son parte del moria se asigna a medida que el pro eso la ne esita.
pro eso.
Mem. real

proceso
padre

Mem. real

fork

proceso
padre

proceso
hijo
(el clone)

Pila

Datos

Codigo

Extension expl ita de los datos

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.

de datos. Sin embargo, en el aso de los datos, no

es fa il distinguir un desborde del area de datos de
la utiliza ion de un puntero mal ini ializado y que
ontiene basura.
Por esta razon en Unix \se preere" que un pro eso
soli ite expl itamente la extension de su segmento
de datos usando la primitiva sbrk(size), en donde
size es la antidad de bytes a agregar a su segmento
de datos. Observe sin embargo que el nu leo no esta
obligado a entregar exa tamente esa antidad. Por
restri iones de implementa ion, el segmento podra
re er en mas de lo que se soli ita.
El me anismo de implementa ion de esta extension
es esen ialmente analogo al me anismo de extension
de la pila.
Implementa ion de fork

En Unix la llamada al sistema fork rea un lone de

un pro eso. El lone es independiente del primero,
pero se rea on una opia del odigo, de los datos y
de la pila de pro eso que ha e fork. Ambos pro esos
omparten los mismos des riptores de ar hivo abiertos al momento de invo ar fork. Solo se diferen ian
por que el fork del pro eso original retorna el identi ador del pro eso lone reado, mientras que el fork
del lone retorna 0.
Esta llamada al sistema se implementa dupli ando los segmentos de datos y pila (ver gura 5.4). El
segmento de odigo puede ompartirse entre ambos
pro esos, pues normalmente un pro eso no debera
modi ar su odigo. Por lo tanto el segmento de
odigo se mar a on el atributo de solo le tura. Si
un pro eso intenta modi ar sus datos, se produ ira
una interrup ion que abortara el pro eso que falla.
Lamentablemente esta implementa ion es muy ine iente para el uso tpi o de fork. Esta llamada

51


5.1. SEGMENTACION

se usa prin ipalmente en el interprete de omandos

uando el usuario ingresa un nuevo omando. El
interprete ha e un fork para rear un lone de s
mismo, desde donde de inmediato llama a exe on
el nombre del omando. El fork ne esita dupli ar
los segmentos de datos y pila para rear el lone, pero estos segmentos seran inmediatamente destruidos
on la llamada a exe que reara otros 3 segmentos.
Es importante ha er notar que los primeros mi ro omputadores basados en la Z80 y luego la 68000 no
ofre an hardware para segmenta ion, por lo que en
ellos era imposible implementar fork, y por lo tanto
Unix. La 8088 ofre e un esquema de segmentos de
tama~no jo en 64 KB y sin prote ion, por lo que era
posible implementar Unix en el PC original, siempre y
uando los usuarios se onformaran on pro esos de
no mas de 3*64 KB (despues de todo, los primeros
Unix orran en 64 KB) y a eptaran que pro esos
mali iosos pudiesen botar el sistema ompleto.
Swapping

Si al rear un nuevo segmento, el nu leo no en uentra

un trozo del tama~no soli itado, el nu leo ompa ta
el heap de segmentos. Si aun as no hay memoria
su iente, el nu leo puede llevar pro esos ompletos
al dis o. Esto se denomina swapping de pro esos.
Para llevar un pro eso a dis o, el nu leo es ribe
una opia al bit de ada segmento en una area denominada area de swap. Luego, la memoria o upada
por esos segmentos se libera para que pueda se o upada para rear otros segmentos. El des riptor de
pro eso ontinua en memoria real, pero se reemplaza
el ampo desplazamiento en la tabla de segmentos del
pro eso por una dire ion que indi a la ubi a ion de
ada segmento en el area de swap. Ademas el pro eso
pasa a un estado espe ial que indi a que se ubi a en
dis o y por lo tanto no puede eje utarse.
El s heduler de mediano plazo de ide que pro eso se va a dis o y que pro eso puede regresar a la
memoria del omputador, de a uerdo a alguna estrategia. Esta estrategia tiene que onsiderar que llevar
un pro eso a dis o y traerlo uesta al menos un segundo. Por esto no onviene llevar pro esos a dis o
por po o tiempo. Se llevan por al menos 10 segundos.
En un sistema omputa ional hay mu hos pro esos
demonios que pasan ina tivos por largos perodos, omo por ejemplo el spooler para la impresion si nadie
imprime. Este tipo de pro esos son los primeros andidatos para irse a dis o.
Cuando todos los pro esos en memoria estan a tivos (sus perodos de espera son muy ortos), la medida de llevar pro esos a dis o es de emergen ia. Si un
pro eso intera tivo (un editor por ejemplo) se lleva a

2G

2G
Pilas independientes

Datos compartidos
0

Codigo compartido

Figura 5.5: Pro esos semi-ligeros.

dis o por 10 segundos, la pausa introdu ida sera tan
molesta para el usuario afe tado que in luso llegara
a temer una ada del sistema. Pero de todas formas, omo alternativa es mejor que botar el sistema
o destruir pro esos al azar.
Implementa ion de pro esos semi-ligeros

Los pro esos ligeros omparten un mismo espa io de

dire iones. El problema es que su pila se ubi a en
el heap del pro eso y por ende es de tama~no jo e
inextensible. Si un pro eso ligero desborda su pila,
se aen todos los pro esos que omparten ese mismo
espa io de dire iones.
En un esquema segmentado el nu leo puede ofre er
pro esos semi-ligeros en donde se omparte el area de
odigo y de datos ( omo los pro esos ligeros) pero no
se omparte la por ion del espa io de dire iones que
orresponde a la pila (ver gura 5.5).
Cada pro eso semi-ligero tiene un segmento de pila asignado en el mismo rango de dire iones. Si un
pro eso semi-ligero desborda su pila, el nu leo puede extender automati amente su pila, omo si fuesen
pro esos pesados.
Los pro esos semi-ligeros tienen dos in onvenientes
on respe to a los pro esos ligeros:
 Su implementa ion debe ser responsabilidad del

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.

 El ambio de ontexto es tan aro omo el de los

pro esos pesados.

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.7: La tabla de paginas de un pro eso.

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

Pra ti amente el uni o me anismo que se usa hoy en

da para implementar espa ios de dire iones virtuales es paginamiento. En este me anismo una pagina
es un bloque de memoria de tama~no jo y poten ia
de 2 (tpi amente 4 KB u 8 KB). La idea es que el
espa io de dire iones virtuales y el espa io de dire iones reales se parti ionan en paginas del mismo
tama~no (ver gura 5.6).
Una pagina siempre se pro esa omo un todo, si se
otorga a un pro eso, se otorga la pagina ompleta, en
ningun aso una fra ion de la pagina. Cada pagina

5.2.1 La tabla de paginas

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

Los atributos de una pagina son un onjunto de bits

que indi an que opera iones es valido realizar en ada
pagina del pro eso. Estos bits son:
 Bit V : En 1 indi a que es valido leer esta 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
innito 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

Tama~no de la tabla de paginas

Si las dire iones son de 32 bits y las paginas son de

2k bits, signi a que la tabla de paginas debe poseer
232 k las. Esto da 512 K-las, si las paginas son
de 8 KB. Por lo tanto se requeriran 2 MB solo para
alma enar la tabla si se destinan 4 bytes por ada
la, lo que es obviamente ex esivo.
Este problema lo resolveremos temporalmente restringiendo el espa io de dire iones virtuales a 1024
paginas u otra antidad razonable. Por ende el tama~no de la tabla de paginas ne esita solo 1024 las
o 4 KB. Los a esos a la pagina 1024 o una pagina
superior ausan una interrup ion.
5.2.2 Tradu ion de dire iones virtuales

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 prejo 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

que solo dupli ar la tabla de pagina del pro eso que

invo a fork (ver gure 5.9). Ini ialmente los pro esos padre e hijo omparten todas sus paginas, pero se
protegen ontra es ritura.
Al retomar estos pro esos ualquier es ritura del
padre o del hijo genera una interrup ion. El nu leo
dupli a enton es la pagina que se modi a y se le
olo a permiso de es ritura. De esta forma se retoma
el pro eso interrumpido en forma transparente, sin
que se de uenta del ambio de pagina.
La ganan ia se obtiene uando el fork va seguido
prontamente por un exe , puesto que sera ne esario
dupli ar solo unas 2 o 3 paginas, lo que resulta ser
mu ho mas e onomi o que dupli ar todas las paginas.
Implementa ion de pro esos semi-pesados

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 .

Es el interprete de omandos el que tpi amente llama

a fork para rear una opia de s mismo. Esta opia
invo a de inmediato exe del binario de un omando
ingresado por el usuario. En un esquema segmentado
esto requiere dupli ar los segmentos de datos y de pila
del interprete de omandos, para que luego se destruyan de inmediato. Esto es un uso muy ine iente del
tiempo de pro esador.
En un esquema de paginamiento, fork se puede implementar e ientemente ha iendo uso de la te ni a Paginamiento en demanda
opy-on-write ( opia al es ribir). La idea es no dupli- Por ultimo, el paginamiento permite realizar una op ar de inmediato las paginas de datos y de pila, sino timiza ion sobre el uso de la memoria que no se pue-

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

Figura 5.9: Optimiza ion de fork a traves de opy-on-write.

pila

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

Observe que on eptualmente, ada vez que se realiza

un a eso a la memoria, es ne esario realizar un a eso a memoria adi ional para realizar la tradu ion.
De implementarse de esta forma, estaramos doblando el tiempo de eje u ion de ualquier programa, lo
que sera ina eptable para los usuarios. A ontinua ion examinamos omo se resuelve este problema en
asos reales.
Paginamiento en una Sun 3/50

En una Sun 3/50 las paginas son de 8 KB (k = 13) y

la tabla de paginas posee 1024 las por lo que el espa io de dire iones virtuales se restringe a 8 MB. Es

interesante estudiar este esquema de paginamiento,

pues permite apre iar las restri iones de los esquemas primitivos.
La tabla de paginas del pro eso en eje u ion se
guarda en una memoria estati a de tiempo de a eso
mu hsimo mas rapido que la memoria dinami a en
donde se alma enan datos y programas (la Sun 3/50
no posea memoria a he). De esta forma la penaliza ion en tiempo de eje u ion al realizar la tradu ion
de la dire ion virtual es razonable (del orden de un
10% de tiempo adi ional en ada a eso a la memoria).
Este me anismo presenta los siguientes in onvenientes:
 La memoria rapida destinada a la tabla de
paginas puede alma enar solo la tabla del pro eso en eje u ion. Cada vez se ha e un ambio de
ontexto hay que modi ar las 1024 las en esta
memoria. Por esta razon los ambios de ontexto entre pro esos pesados en una Sun 3/50 son
aros en tiempo de CPU (son \pesados").
 El espa io de dire iones virtuales es demasiado
estre ho. Este espa io era su iente en la epo a
de esta esta ion (a~nos 86-89), pero insu iente
hoy en da.

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

Figura 5.11: Tradu ion de dire iones virtuales en

un pro esador Intel 386/486/Pentium.
Paginamiento en un Intel 386/486/Pentium

En esta familia de pro esadores, las paginas son de

4 KB (k = 12) y el espa io de dire iones virtuales
es de 4 GB (232 bytes). Una tabla de paginas esta
restringida a 1024 las, pero un pro eso puede tener
hasta 1024 tablas distintas. Cada tabla de paginas
sirve para tradu ir las dire iones de un bloque ontiguo de 4 MB de memoria en el espa io de dire iones
virtuales.
Ademas de las tablas de paginas, existe un dire torio que indi a que tablas posee el pro eso en eje u ion
y ual es su dire ion real en la memoria del omputador. El dire torio y las tablas de paginas o upan
ada uno una pagina ompleta.
El pro eso de tradu ion se observa en la gura
5.11. La organiza ion del dire torio es similar a la de
una tabla de paginas, solo que en vez de indi ar la
tradu ion de una pagina, indi a la dire ion de una
tabla de paginas para tradu ir la paginas que pertene en a un bloque de 4 MB (una espe ie de super
pagina). Ademas en ada la del dire torio hay atributos similares a los de una tabla de paginas. Por
ejemplo si el bit V esta en 0, quiere de ir que todo un
bloque de 4 MB en el espa io virtual no esta asignado
en la memoria real.
El gasto en paginas de memoria para implementar
los pro esos de un sistema operativo omo Unix son
los siguientes:
 Una pagina que ontiene el dire torio del pro eso
en eje u ion. En ada ambio de ontexto es ne-

esario ambiar par ialmente este dire torio para

re ejar el ambio en el espa io de dire iones.
 Por ada pro eso lanzado, se requiere al menos
una pagina para alma enar la tabla de paginas
orrespondiente al area de odigo y datos, ubi ada en las dire iones bajas de la memoria. Si
esta area requiere mas de 4 MB se ne esita una
nueva pagina por ada 4 MB adi ional.
 Por ada pro eso lanzado, se requiere una pagina
para alma enar la tabla de paginas orrespondiente al area de la pila, ubi ada en las dire iones medias del espa io de dire iones (inferiores
a 2 GB). Es pra ti amente imposible que un programa requiera mas de 4 MB para pila, por lo que
es razonable prohibir pilas de mayor tama~no.
 Para que en modo sistema se vea por ompleto la
memoria real del omputador en las dire iones
superiores a 2 GB, se requiere una pagina por
ada 4 MB de memoria real.
El a elerador de la tradu ion de dire iones :
TLB

El dire torio y las tablas de paginas se alma enan en

memoria real en una Intel 386. Con esto, se redu e
el tiempo para realizar un ambio de ontexto, pero
se multipli a por 3 el osto del a eso a la memoria
virtual. En efe to ada a eso a la memoria virtual
requiere un a eso real en el dire torio para determinar la tabla de paginas, otro a eso real en la tabla
de paginas y nalmente el a eso real de la palabra
soli itada por el pro eso. Este nuevo sobre osto es
es andalosamente ina eptable.
Para a elerar los a esos a la memoria, el hardware
del omputador posee una TLB (de translation lookaside buer). La TLB es una peque~na memoria aso iativa (similar a una memoria a he) de muy rapido
a eso que alma ena la tradu ion y los atributos de
32 a 128 paginas virtuales a esadas re ientemente
(ver gura 5.12).
Cuando se a esa una pagina uya tradu ion se
en uentra en la TLB, el sobre osto es bajsimo. En
ambio si la tradu ion no se en uentra en la TLB,
solo enton es se visitan el dire torio y la tabla de
paginas en la memoria real, on un sobre osto de 2
a esos adi ionales a la memoria. La tradu ion de
esta pagina se olo a en la TLB para que los futuros
a esos a esta pagina sean e ientes. Sin embargo,
eventualmente sera ne esario suprimir una tradu ion
previamente existente en la TLB, debido a su tama~no
limitado.

5.3. MEMORIA VIRTUAL : PAGINAMIENTO EN DEMANDA

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 denirlo 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

5.3. MEMORIA VIRTUAL : PAGINAMIENTO EN DEMANDA

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

...

Tabla 5.1: Reemplazo de paginas para la estrategia ideal

a
b

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

...

Tabla 5.2: Reemplazo de paginas para la estrategia FIFO

Paginas reales
Puntero a la proxima
pagina a revisar

Figura 5.13: Ordenamiento de las paginas en la estrategia del reloj.

Cuando o urre un page-fault se eje uta el siguiente
pro edimiento:
i. Mientras el bit R de la pagina apuntada sea 1 :
(a) Colo ar el bit R en 0.
(b) Avanzar el puntero en una pagina.
ii. La pagina apuntada tiene su bit R en 0. Elegir
esa pagina para ser reemplazada, es de ir que esa
pagina virtual se lleva a dis o, lo que libera una
pagina real. Esa pagina real se usa para argar
la pagina que auso el page-fault.
iii. Avanzar el puntero en una pagina2.
La idea es que la pagina elegida para ser reemplazada no ha sido a esada por una vuelta ompleta
del reloj. La estrategia onsidera que este tiempo es
su iente omo para suponer que la pagina no sera
a esada en el futuro inmediato.
El tiempo que demora el puntero en dar una vuelta
depende de la tasa de page-faults. Mientras mayor

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.

sea esta tasa, menor sera el tiempo en dar la vuelta

y por lo tanto el s heduler reemplazara paginas que
llevan menos tiempo sin ser a esadas. Al ontrario,
si la lo alidad de los a esos a memoria es buena,
la tasa de page-faults sera baja y el tiempo de una
revolu ion del puntero aumentara. Esto quiere de ir
que el s heduler tendra que reemplazar paginas que
llevan mas tiempo sin ser a esadas.
Una situa ion anomala se produ e uando todas
las paginas tienen el bit R en 1 y por lo tanto el puntero avanza una vuelta ompleta antes de en ontrar
el primer bit R en 0. Esto o urre uando trans urre
mu ho tiempo sin que o urran page-faults y todas
las paginas al anzan a ser a esadas. Esto no es realmente un problema, puesto que o urre pre isamente
uando la tasa de page-faults es muy baja. Una mala
de ision en uanto a la pagina reemplazada, ausara
un impa to mnimo en el desempe~no del pro eso.
Esta estrategia es fa il de implementar e ientemente on el hardware disponible y fun iona muy
bien on un solo pro eso. En aso de varios pro esos, la estrategia se omporta razonablemente en
ondi iones de arga moderada, pero veremos que se
omporta desastrosamente uando la arga es alta.
Trashing

El problema de la estrategia del reloj es que puede

provo ar el fenomeno de trashing. Este fenomeno se
ara teriza por una tasa elevadsima de page-faults
que ha e que ningun pro eso pueda avanzar. De he ho, la CPU pasa mas del 90% del tiempo en espera
de opera iones de le tura o es ritura de paginas en el
dis o de paginamiento.
Una vez que un sistema ae en el fenomeno de trashing, es muy dif il que se re upere. La uni a solu ion
es que el operador logre detener algunos pro esos. Es-

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

...

Tabla 5.3: Reemplazo de paginas para la estrategia LRU

to podra realizarse on mu ha di ultad porque in luso los pro esos del operador avanzaran \a paso de
tortuga".
La expli a ion de este fenomeno esta en la ombina ion de la estrategia del reloj on un s heduling de
pro esos del tipo Round-Robin. Las paginas del pro eso que se retoma han permane ido largo tiempo sin
ser a esadas y por lo tanto es muy probable que el
s heduler de paginas las haya llevado a dis o. Por lo
tanto, uando un pro eso re ibe una tajada de tiempo, al anza a avanzar muy po o antes de que o urra
un page-fault.
El fenomeno de trashing se produ e exa tamente
uando el puntero del s heduler de paginas omienza
a dar vueltas mas rapidas que las vueltas que da el
puntero del s heduler Round-Robin de los pro esos.
5.3.6 La estrategia del Working-Set

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 dene 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 :

 Si el bit R de q esta en 1, la pagina esta en el

working-set y se olo a el bit en 0.

 Sino, la pagina no ha sido a esada desde ha e
t segundos y por lo tanto no pertene e al
working-set de P . La pagina se agrega al onjunto C que agrupa las paginas andidatas a ser
reemplazadas, de todos lo pro esos.
Cuando o urre un page-fault se eje uta :
i. Mientras C no este va o:
(a) Sea q una pagina en C .
(b) Extraer q de C .
( ) Si el bit R de q esta en 0, se retorna q omo
la pagina elegida para ser reemplazada.
(d) Si el bit R esta en 1, quiere de ir que esa
pagina fue a esada a pesar de no estar en
el working-set de un pro eso, por lo que se
des arta y se ontnua la busqueda on otra
pagina.
ii. El onjunto C esta va o por lo que hay que ha er
swapping.
Observe que en esta estrategia si una pagina pasa
al onjunto C , el tiempo trans urrido desde su ultimo
a eso esta omprendido entre
t y 2
t.
Ademas para que un pro eso tenga la oportunidad de orrer e ientemente se debe umplir que su
working-set sea inferior al tama~no de la memoria real.
A ontinua ion veremos que esta estrategia se puede optimizar de diversas formas.
Transferen ia de paginas a dis o

Cuando o urre un page-fault la estrategia elige una

pagina a reemplazar. La pausa que se introdu e en
el pro eso que auso el page-fault es doble, porque
primero es ne esario llevar a dis o la pagina elegida
y luego argar de dis o la pagina del page-fault.
Sin embargo, no es ne esario llevar a dis o las
paginas que ya hayan sido llevadas una vez a dis o
y no han sido modi adas desde enton es. Esto o urre espe ialmente on las paginas de odigo.

5.3. MEMORIA VIRTUAL : PAGINAMIENTO EN DEMANDA

61

Para evitar llevar nuevamente estas paginas a dis o

y por lo tanto mayor sera el working-set. De
se realiza lo siguiente:
he ho, el tama~no del working-set re e monotamente junto on
t.
i. Al traer una pagina q de dis o, se mar a on el
Este fa tor s debe ser ontrolado por el s heduler
bit D en 0. D es el bit Dirty.
de paginas del sistema operativo.
ii. El hardware olo a el bit D en 1 si el pro eso
iii. El tama~no de la pagina.
modi a esa pagina.
En la pra ti a, el tama~no de una pagina es jo
iii. Al reemplazar q, la pagina se lleva a dis o solo
para
una arquite tura dada y no se puede modisi su bit D esta en 1, si no la antigua opia de
ar
(4
KB en una Intel x86). Pero si fuese posible
q en dis o es la misma que esta a tualmente en
redu irlo
a la mitad, intuitivamente se puede dememoria real.
du ir que el tama~no del working-set en numero
de paginas re era a un po o menos del doble.
Esto resuelve el problema de las paginas de odigo.
Sin embargo, resta un onjunto elevado de paginas
Esto se debe a que el pro eso a esa fre uentemente solo una de las mitades de una pagina.
que todava hay que llevarlas a dis o antes de reemplazarlas. Este tiempo se puede suprimir ha iendo
Ahora si se onsidera el tama~no en bytes del
que las paginas que se agregan a C (el onjunto de
working-set ( al ulado omo numero de paginas
paginas andidatas a ser reemplazadas) se es riban
multipli ado
por el tama~no de la pagina), a measin roni amente en dis o. Con suerte, uando pronor
tama~
n
o
de
pagina, menor es el tama~no del
du to de un page-fault se es oja esa pagina para ser
working-set.
Esto
signi a que el pro eso ne esireemplazada, ya se tendra una opia en dis o.
ta
menos
memoria
real para orrer e ientemenAun as, si el onjunto C es peque~no y la tasa de
te.
Sin
embargo,
por otra parte, al disminuir
page-faults es alta, es po o probable que una pagina
el
tama~
n
o
de
p
a
gina
aumenta el numero de las
al an e a ser es rita en dis o. Por esta razon los sisp
a
ginas
y
por
lo
tanto
aumenta el sobre osto asotemas operativos tratan de mantener en el onjunto
iado
al

a
l ulo
de
los
working-set, lo que resulta
C un 20% de las paginas de la memoria real. Esto
negativo
en
t
e
rminos
de
desempe~no.
garantiza que siempre habran paginas listas para ser
Por lo tanto no es trivial determinar el tama~no
reemplazadas sin que sea ne esario llevarlas primero
ade uado para las paginas. Pero esta no es una
a dis o.
de ision que efrenta el on eptor del sistema opeSi el tama~no de C esta muy por debajo de ese 20%,
rativo. Es el dise~nador de la arquite tura el que
enton es se omienza a ha er swapping de pro esos.
ja este valor.
Es de ir se llevan pro esos ompletos a dis o. Al ontrario, si se supera ese 20%, se pueden argar aquellos
Es de ir que el uni o fa tor que puede ontrolar el
pro esos que esten en el dis o.
s heduler de paginas es el valor de
t. Este valor se
ha e variar en forma independiente para ada pro eso
Perodo entre al ulos del working-set
en fun ion del sobre osto maximo tolerado para el
El tama~no del working-set de un pro eso depende de paginamiento en demanda. El prin ipio es que este
tres fa tores:
sobre osto depende de la tasa de page-faults, y esta
u
depende a su vez de
t.
i. La lo alidad de los a esos que haga el pro eso ltima
Por
ejemplo
si ada page-fault uesta una pausa de
a la memoria.
10 milisegundos y la tasa de page-faults de un pro eMientras mejor sea la lo alidad menor sera el so es de 50 paginas por segundo, enton es por ada
tama~no del working-set y por lo tanto menos segundo de tiempo de uso del pro esador se perdera
memoria real ne esitara el pro eso para orrer medio segundo en pausas de page-faults. Es de ir
e ientemente.
el sobre osto de la memoria virtual para el pro eso
Este es un fa tor que depende uni amente de las sera de un 50%. Esto muestra que el sobre osto de
ara tersti as del pro eso. El sistema operativo la memoria virtual depende de la tasa de page-faults.
La idea es enton es aumentar o disminuir el valor
no puede ontrolar este fa tor.
de

t para ajustar la tasa de page-faults a un nivel
ii. El tiempo
t entre al ulos del working-set.
jado omo parametro del sistema. Si se aumenta
Mientras mayor sea esta ifra, mayor sera la pro-
t, aumenta el tama~no del working-set y enton es
babilidad de que una pagina haya sido a esada disminuye la tasa de page-faults.

62
5.3.7 Carga de binarios en demanda

Al lanzar un pro eso no es ne esario argar su binario

de inmediato en la memoria real. La arga de binarios en demanda (demand loading) onsiste en argar
progresivamente las paginas de un binario a medida
que el pro eso las visita.
Esto se implementa de la siguiente forma:
i. Ini ialmente se onstruye la tabla de paginas del
pro eso on todas sus paginas invalidas, es de ir
on el bit V en 0.
ii. Se destina un bit de los atributos de ada pagina
para indi ar que todas las paginas se en uentran
en el binario. Ademas en el des riptor de pro eso
se reserva un ampo para el ar hivo que ontiene
el binario.
iii. A medida que el pro eso se eje uta, se produ en page-faults debido a que se visitan paginas
que todava estan en el binario. El s heduler
de paginas debe onsultar enton es los atributos para determinar en que lugar se en uentra
esa pagina. En el aso de estar en el binario, la
pagina se arga del ar hivo binario.
El objetivo de esta te ni a es mejorar el tiempo de
respuesta al argar binarios de gran tama~no. Si se
arga un binario de 3 MB, probablemente se requiere
solo un 10% de sus paginas para entregar los primeros
resultados. Para disminuir el tiempo de respuesta, la
arga en demanda lee de dis o solo este 10%, lo que
resulta mas rapido que argar los 3 MB ompletamente.

 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.

5.3.8 Lo alidad de los a esos a la memoria

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 innidad de objetos de peque~no tama~no que se reparten uniformemente en el
heap del area de datos del pro eso. Si bien existe

3 Como el tama~no de la lneas de la memoria a he.