62 IN T R OD U C C IN C A PT U L O 1

1.7 E ST RUC T UR A DE UN SIST E M A OPE R AT IVO

A hora que hemos visto la apariencia exterior de los sistemas operativos (es decir, la interfaz del pro-
gramador), es tiempo de dar un vistazo a su interior. E n las siguientes secciones analizaremos seis
estructuras distintas que se han probado, para poder darnos una idea del espectro de posibilidades.
D e ninguna manera quiere esto decir que sean exhaustivas, pero nos dan una idea de algunos dise-
os que se han probado en la prctica. L os seis diseos son: sistemas monolticos, sistemas de ca-
pas, microkernels, sistemas cliente-servidor, mquinas virtuales y exokernels.

1.7.1 Sistemas monolticos

E n este diseo, que hasta ahora se considera como la organizacin ms comn, todo el sistema ope-
rativo se ejecuta como un solo programa en modo kernel. E l sistema operativo se escribe como una
coleccin de procedimientos, enlazados entre s en un solo programa binario ejecutable extenso.
C uando se utiliza esta tcnica, cada procedimiento en el sistema tiene la libertad de llamar a cual-
quier otro, si ste proporciona cierto cmputo til que el primero necesita. A l tener miles de proce-
dimientos que se pueden llamar entre s sin restriccin, con frecuencia se produce un sistema poco
manejable y difcil de comprender.
Para construir el programa objeto actual del sistema operativo cuando se utiliza este diseo, pri-
mero se compilan todos los procedimientos individuales (o los archivos que contienen los procedi-
mientos) y luego se vinculan en conjunto para formar un solo archivo ejecutable, usando el
enlazador del sistema. E n trminos de ocultamiento de informacin, en esencia no hay nada: todos
los procedimientos son visibles para cualquier otro procedimiento (en contraste a una estructura que
contenga mdulos o paquetes, en donde la mayor parte de la informacin se oculta dentro de m-
dulos y slo los puntos de entrada designados de manera oficial se pueden llamar desde el exterior
del mdulo).
Sin embargo, hasta en los sistemas monolticos es posible tener cierta estructura. Para solicitar
los servicios (llamadas al sistema) que proporciona el sistema operativo, los parmetros se colocan
en un lugar bien definido (por ejemplo, en la pila) y luego se ejecuta una instruccin de trap. E sta
instruccin cambia la mquina del modo usuario al modo kernel y transfiere el control al sistema
operativo, lo cual se muestra como el paso 6 en la figura 1-17. D espus el sistema operativo obtie-
ne los parmetros y determina cul es la llamada al sistema que se va a llevar a cabo. D espus la
indiza en una tabla que contiene en la ranura k un apuntador al procedimiento que lleva a cabo
la llamada al sistema k (paso 7 en la figura 1-17).
E sta organizacin sugiere una estructura bsica para el sistema operativo:

1. U n programa principal que invoca el procedimiento de servicio solicitado.

2. U n conjunto de procedimientos de servicio que llevan a cabo las llamadas al sistema.
3. U n conjunto de procedimientos utilitarios que ayudan a los procedimientos de servicio.

E n este modelo, para cada llamada al sistema hay un procedimiento de servicio que se encarga de
la llamada y la ejecuta. L os procedimientos utilitarios hacen cosas que necesitan varios procedi-
SE C C IN 1.7 E ST R U C T U R A D E U N SIST E M A OPE R AT IV O 63

mientos de servicio, como obtener datos de los programas de usuario. E sta divisin de los proce-
dimientos en tres niveles se muestra en la figura 1-24.

P rocedimiento
principal

P rocedimientos
de servicio

P rocedimientos
utilitarios

Figura 1-24. U n modelo de estructuracin simple para un sistema monoltico.

A dems del ncleo del sistema operativo que se carga al arrancar la computadora, muchos sis-
temas operativos soportan extensiones que se pueden cargar, como los drivers de dispositivos de
E /S y sistemas de archivos. E stos componentes se cargan por demanda.

1.7.2 Sistemas de capas

U na generalizacin del diseo de la figura 1-24 es organizar el sistema operativo como una jerar-
qua de capas, cada una construida encima de la que tiene abajo. E l primer sistema construido de
esta forma fue el sistema T H E , construido en Technische H ogeschool E indhoven en H olanda por E .
W. D ijkstra (1968) y sus estudiantes. E l sistema T H E era un sistema simple de procesamiento por
lotes para una computadora holandesa, la E lectrologica X 8, que tena 32K de palabras de 27 bits
(los bits eran costosos en aquel entonces).
E l sistema tena seis capas, como se muestra en la figura 1-25. E l nivel 0 se encargaba de la
asignacin del procesador, de cambiar entre un proceso y otro cuando ocurran interrupciones o ex-
piraban los temporizadores. Por encima del nivel 0, el sistema consista en procesos secuenciales,
cada uno de los cuales e poda programar sin necesidad de preocuparse por el hecho de que haba
varios procesos en ejecucin en un solo procesador. E n otras palabras, el nivel 0 proporcionaba la
multiprogramacin bsica de la C PU .
L a capa 1 se encargaba de la administracin de la memoria. A signaba espacio para los proce-
sos en la memoria principal y en un tambor de palabras de 512 K que se utilizaba para contener par-
tes de procesos (pginas), para los que no haba espacio en la memoria principal. Por encima de la
capa 1, los procesos no tenan que preocuparse acerca de si estaban en memoria o en el tambor; el
software de la capa 1 se encargaba de asegurar que las pginas se llevaran a memoria cuando se re-
queran.
64 IN T R OD U C C IN C A PT U L O 1

Capa Funcin
5 E l operador
4 P rogramas de usuario
3 Administracin de la entrada/salida
2 C omunicacin operador-proceso
1 Administracin de memoria y tambor
0 Asignacin del procesador y multiprogramacin

Figura 1-25. E structura del sistema operativo T H E .

L a capa 2 se encargaba de la comunicacin entre cada proceso y la consola del operador (es de-
cir, el usuario). E ncima de esta capa, cada proceso tena en efecto su propia consola de operador.
L a capa 3 se encargaba de administrar los dispositivos de E /S y de guardar en bferes los flujos de
informacin dirigidos para y desde ellos. E ncima de la capa 3, cada proceso poda trabajar con los
dispositivos abstractos de E /S con excelentes propiedades, en vez de los dispositivos reales con mu-
chas peculiaridades. L a capa 4 era en donde se encontraban los programas de usuario. N o tenan
que preocuparse por la administracin de los procesos, la memoria, la consola o la E /S. E l proceso
operador del sistema se encontraba en el nivel 5.
U na mayor generalizacin del concepto de capas estaba presente en el sistema M U LT IC S. E n
vez de capa, M U LT IC S se describi como una serie de anillos concntricos, en donde los interio-
res tenan ms privilegios que los exteriores (que en efecto viene siendo lo mismo). C uando un pro-
cedimiento en un anillo exterior quera llamar a un procedimiento en un anillo interior, tena que
hacer el equivalente de una llamada al sistema; es decir, una instruccin TRAP cuyos parmetros
se comprobara cuidadosamente que fueran vlidos antes de permitir que continuara la llamada.
A unque todo el sistema operativo era parte del espacio de direcciones de cada proceso de usuario
en M U LT IC S, el hardware hizo posible que se designaran procedimientos individuales (en realidad,
segmentos de memoria) como protegidos contra lectura, escritura o ejecucin.
M ientras que en realidad el esquema de capas de T H E era slo una ayuda de diseo, debido a
que todas las partes del sistema estaban enlazadas entre s en un solo programa ejecutable, en M U L -
T IC S el mecanismo de los anillos estaba muy presente en tiempo de ejecucin y el hardware se en-
cargaba de implementarlo. L a ventaja del mecanismo de los anillos es que se puede extender
fcilmente para estructurar los subsistemas de usuario. Por ejemplo, un profesor podra escribir un
programa para evaluar y calificar los programas de los estudiantes, ejecutando este programa en el
anillo n, mientras que los programas de los estudiantes se ejecutaban en el anillo n 1 y por ende
no podan cambiar sus calificaciones.

1.7.3 M icrokernels

C on el diseo de capas, los diseadores podan elegir en dnde dibujar el lmite entre kernel y usua-
rio. Tradicionalmente todos las capas iban al kernel, pero eso no es necesario. D e hecho, puede te-
ner mucho sentido poner lo menos que sea posible en modo kernel, debido a que los errores en el
SE C C IN 1.7 E ST R U C T U R A D E U N SIST E M A OPE R AT IV O 65

kernel pueden paralizar el sistema de inmediato. E n contraste, los procesos de usuario se pueden
configurar para que tengan menos poder, por lo que un error en ellos tal vez no sera fatal.
Varios investigadores han estudiado el nmero de errores por cada 1000 lneas de cdigo (por
ejemplo, B asilli y Perricone, 1984; y Ostrand y Weyuker, 2002). L a densidad de los errores depen-
de del tamao del mdulo, su tiempo de vida y ms, pero una cifra aproximada para los sistemas
industriales formales es de diez errores por cada mil lneas de cdigo. E sto significa que es proba-
ble que un sistema operativo monoltico de cinco millones de lneas de cdigo contenga cerca de
50,000 errores en el kernel. D esde luego que no todos estos son fatales, ya que algunos errores
pueden ser cosas tales como emitir un mensaje de error incorrecto en una situacin que ocurre ra-
ras veces. Sin embargo, los sistemas operativos tienen tantos errores que los fabricantes de compu-
tadoras colocan botones de reinicio en ellas (a menudo en el panel frontal), algo que los fabricantes
de televisiones, estreos y autos no hacen, a pesar de la gran cantidad de software en estos dispo-
sitivos.
L a idea bsica detrs del diseo de microkernel es lograr una alta confiabilidad al dividir el sis-
tema operativo en mdulos pequeos y bien definidos, slo uno de los cuales (el microkernel) se
ejecuta en modo kernel y el resto se ejecuta como procesos de usuario ordinarios, sin poder relati-
vamente. E n especial, al ejecutar cada driver de dispositivo y sistema de archivos como un proce-
so de usuario separado, un error en alguno de estos procesos puede hacer que falle ese componente,
pero no puede hacer que falle todo el sistema. A s, un error en el driver del dispositivo de audio ha-
r que el sonido sea confuso o se detenga, pero la computadora no fallar. E n contraste, en un
sistema monoltico con todos los drivers en el kernel, un driver de audio con errores puede hacer
fcilmente referencia a una direccin de memoria invlida y llevar a todo el sistema a un alto ro-
tundo en un instante.
Se han implementado y desplegado muchos microkernels (A ccetta y colaboradores, 1986; H aer-
tig y colaboradores, 1997; H eiser y colaboradores, 2006; H erder y colaboradores, 2006; H ildebrand,
1992; K irsch y colaboradores, 2005; L iedtke, 1993, 1995, 1996; Pike y colaboradores, 1992; y
Zuberi y colaboradores, 1999). Son en especial comunes en las aplicaciones en tiempo real, indus-
triales, aeronuticas y militares que son de misin crtica y tienen requerimientos de confiabilidad
muy altos. A lgunos de los microkernels mejor conocidos son Integrity, K 42, L 4, PikeOS, QN X ,
Symbian y M IN IX 3. A hora veremos en forma breve las generalidades acerca de M IN IX 3, que ha
llevado la idea de la modularidad hasta el lmite, dividiendo la mayor parte del sistema operativo en
varios procesos independientes en modo usuario. M IN IX 3 es un sistema de cdigo fuente abierto
en conformidad con POSIX , disponible sin costo en www.minix3.org (H erder y colaboradores,
2006a; H erder y colaboradores, 2006b).
E l microkernel M I N I X 3 slo tiene cerca de 3200 lneas de C y 800 lneas de ensamblador pa-
ra las funciones de muy bajo nivel, como las que se usan para atrapar interrupciones y conmutar
proceso. E l cdigo de C administra y planifica los procesos, se encarga de la comunicacin en-
tre procesos (al pasar mensajes entre procesos) y ofrece un conjunto de aproximadamente 35 lla-
madas al kernel para permitir que el resto del sistema operativo realice su trabajo. E stas llamadas
realizan funciones tales como asociar los drivers a las interrupciones, desplazar datos entre espa-
cios de direcciones e instalar nuevos mapas de memoria para los procesos recin creados. L a es-
tructura de procesos de M I N I X 3 se muestra en la figura 1-26, en donde los manejadores de las
llamadas al kernel se etiquetan como Sys. E l manejador de dispositivo para el reloj tambin est
66 IN T R OD U C C IN C A PT U L O 1

en el kernel, debido a que el planificador interacta de cerca con l. Todos los dems dispositivos
controladores se ejecutan como procesos de usuario separados.

P roceso

S hell Make O tro P rogramas

... de usuario
Modo
usuario FS P roc. R einc. O tro S ervidores
...

Disk TTY Netw P rint O tro Drivers

...

E l microkernel maneja interrupciones, C lock S ys

procesos, planificacin, IP C

Figura 1-26. E structura del sistema M IN IX 3.

Fuera del kernel, el sistema se estructura como tres capas de procesos, todos se ejecutan en mo-
do usuario. L a capa ms inferior contiene los drivers de dispositivos. C omo todos se ejecutan en
modo usuario, no tienen acceso fsico al espacio de puertos de E /S y no pueden emitir comandos de
E /S directamente. E n vez de ello, para programar un dispositivo de E /S el driver crea una estructu-
ra para indicarle qu valores debe escribir en cules puertos de E /S y realiza una llamada al kernel
para indicarle que realice la escritura. E sta metodologa permite que el kernel compruebe que el dri-
ver est escribiendo (o leyendo) de la E /S que est autorizado a utilizar. E n consecuencia (y a dife-
rencia de un diseo monoltico), un driver de audio defectuoso no puede escribir accidentalmente
en el disco.
E ncima de los drivers hay otra capa en modo usuario que contiene los servidores, que realizan
la mayor parte del trabajo del sistema operativo. U no o ms servidores de archivos administran el
(los) sistema(s) de archivos, el administrador de procesos crea, destruye y administra los procesos
y as sucesivamente. L os programas de usuario obtienen servicios del sistema operativo mediante
el envo de mensajes cortos a los servidores, pidindoles las llamadas al sistema POSIX . Por ejem-
plo, un proceso que necesite realizar una llamada read enva un mensaje a uno de los servidores de
archivos para indicarle qu debe leer.
U n servidor interesante es el servidor de reencarnacin, cuyo trabajo es comprobar si otros
servidores y drivers estn funcionando en forma correcta. E n caso de que se detecte uno defectuo-
so, se reemplaza automticamente sin intervencin del usuario. D e esta forma, el sistema es auto-
corregible y puede lograr una alta confiabilidad.
E l sistema tiene muchas restricciones que limitan el poder de cada proceso. C omo dijimos an-
tes, los drivers slo pueden utilizar los puertos de E /S autorizados, pero el acceso a las llamadas al
kernel tambin est controlado dependiendo del proceso, al igual que la habilidad de enviar mensa-
jes a otros procesos. A dems, los procesos pueden otorgar un permiso limitado a otros procesos pa-
ra hacer que el kernel acceda a sus espacios de direcciones. C omo ejemplo, un sistema de archivos
SE C C IN 1.7 E ST R U C T U R A D E U N SIST E M A OPE R AT IV O 67

puede otorgar permiso al dispositivo controlador de disco para dejar que el kernel coloque un blo-
que de disco recin ledo en una direccin especfica dentro del espacio de direcciones del sistema
de archivos. E l resultado de todas estas restricciones es que cada driver y servidor tiene el poder
exacto para realizar su trabajo y no ms, con lo cual se limita en forma considerable el dao que
puede ocasionar un componente defectuoso.
U na idea que est en parte relacionada con tener un kernel mnimo es colocar el mecanismo pa-
ra hacer algo en el kernel, pero no la directiva. Para aclarar mejor este punto, considere la planifica-
cin de los proceso. U n algoritmo de planificacin relativamente simple sera asignar una prioridad
a cada proceso y despus hacer que el kernel ejecute el proceso de mayor prioridad que sea ejecuta-
ble. E l mecanismo, en el kernel, es buscar el proceso de mayor prioridad y ejecutarlo. L a directiva,
asignar prioridades a los procesos, puede realizarse mediante los procesos en modo usuario. D e esta
forma, la directiva y el mecanismo se pueden desacoplar y el kernel puede reducir su tamao.

1.7.4 M odelo cliente-servidor

U na ligera variacin de la idea del microkernel es diferenciar dos clases de procesos: los servido-
res, cada uno de los cuales proporciona cierto servicio, y los clientes, que utilizan estos servicios.
E ste modelo se conoce como cliente-servidor. A menudo la capa inferior es un microkernel, pero
eso no es requerido. L a esencia es la presencia de procesos cliente y procesos servidor.
L a comunicacin entre clientes y servidores se lleva a cabo comnmente mediante el paso de
mensajes. Para obtener un servicio, un proceso cliente construye un mensaje indicando lo que
desea y lo enva al servicio apropiado. D espus el servicio hace el trabajo y enva de vuelta la res-
puesta. Si el cliente y el servidor se ejecutan en el mismo equipo se pueden hacer ciertas optimiza-
ciones, pero en concepto estamos hablando sobre el paso de mensajes.
U na generalizacin obvia de esta idea es hacer que los clientes y los servidores se ejecuten en
distintas computadoras, conectadas mediante una red de rea local o amplia, como se describe
en la figura 1-27. C omo los clientes se comunican con los servidores mediante el envo de mensa-
jes, no necesitan saber si los mensajes se manejan en forma local en sus propios equipos o si se en-
van a travs de una red a servidores en un equipo remoto. E n cuanto a lo que al cliente concierne,
lo mismo ocurre en ambos casos: se envan las peticiones y se regresan las respuestas. Por ende, el
modelo cliente-servidor es una abstraccin que se puede utilizar para un solo equipo o para una red
de equipos.
C ada vez hay ms sistemas que involucran a los usuarios en sus PC s domsticas como clientes
y equipos ms grandes que operan en algn otro lado como servidores. D e hecho, la mayor parte
de la Web opera de esta forma. U na PC enva una peticin de una pgina Web al servidor y la p-
gina Web se enva de vuelta. ste es un uso comn del modelo cliente-servidor en una red.

1.7.5 M quinas virtuales

L as versiones iniciales del OS/360 eran, en sentido estricto, sistemas de procesamiento por lotes.
Sin embargo, muchos usuarios del 360 queran la capacidad de trabajar de manera interactiva en
una terminal, por lo que varios grupos, tanto dentro como fuera de IB M , decidieron escribir siste-
68 IN T R OD U C C IN C A PT U L O 1

Mquina 1 Mquina 2 Mquina 3 Mquina 4

C liente S ervidor de S ervidor de S ervidor de
archivos procesos terminales
K ernel K ernel K ernel K ernel

R ed
Mensaje del cliente
al servidor

Figura 1-27. E l modelo cliente-servidor sobre una red.

mas de tiempo compartido para este sistema. E l sistema de tiempo compartido oficial de IB M , co-
nocido como T SS/360, se liber despus de tiempo y cuando por fin lleg era tan grande y lento
que pocos sitios cambiaron a este sistema. E n cierto momento fue abandonado, una vez que su de-
sarrollo haba consumido cerca de 50 millones de dlares (G raham, 1970). Pero un grupo en el
Scientific C enter de IB M en C ambridge, M assachusetts, produjo un sistema radicalmente distinto
que IB M acept eventualmente como producto. U n descendiente lineal de este sistema, conocido
como z/V M , se utiliza ampliamente en la actualidad, en las mainframes de IB M (zSeries) que se
utilizan mucho en centros de datos corporativos extensos, por ejemplo, como servidores de comer-
cio electrnico que manejan cientos o miles de transacciones por segundo y utilizan bases de datos
cuyos tamaos llegan a ser hasta de varios millones de gigabytes.

V M /370

Este sistema, que en un principio se llam CP/CM S y posteriormente cambi su nombre a V M /370
(Seawright y M acK innon, 1979), estaba basado en una astuta observacin: un sistema de tiempo com-
partido proporciona (1) multiprogramacin y (2) una mquina extendida con una interfaz ms conve-
niente que el hardware por s solo. L a esencia de V M /370 es separar por completo estas dos funciones.
E l corazn del sistema, que se conoce como monitor de mquina virtual, se ejecuta en el
hardware solamente y realiza la multiprogramacin, proporcionando no una, sino varias mqui-
nas virtuales a la siguiente capa hacia arriba, como se muestra en la figura 1-28. Sin embargo, a
diferencia de otros sistemas operativos, estas mquinas virtuales no son mquinas extendidas,
con archivos y otras caractersticas adecuadas. E n vez de ello, son copias exactas del hardware,
incluyendo el modo kernel/ usuario, la E /S, las interrupciones y todo lo dems que tiene la m-
quina real.
C omo cada mquina virtual es idntica al verdadero hardware, cada una puede ejecutar cual-
quier sistema operativo que se ejecute directamente slo en el hardware. D istintas mquinas virtua-
les pueden (y con frecuencia lo hacen) ejecutar distintos sistemas operativos. E n el sistema V M /370
original, algunas ejecutaban OS/360 o uno de los otros sistemas operativos extensos de procesa-
miento por lotes o de procesamiento de transacciones, mientras que otros ejecutaban un sistema in-
teractivo de un solo usuario llamado C M S (C onversational M onitor System; Sistema monitor
conversacional) para los usuarios interactivos de tiempo compartido. E ste ltimo fue popular entre
los programadores.
SE C C IN 1.7 E ST R U C T U R A D E U N SIST E M A OPE R AT IV O 69

370s virtuales

Llamadas al sistema aqu

Instrucciones de E /S aqu C MS C MS C MS Traps aqu
Traps aqu VM/370
Hardware del 370

Figura 1-28. L a estructura de V M /370 con C M S.

C uando un programa de C M S ejecutaba una llamada al sistema, sta quedaba atrapada para el
sistema operativo en su propia mquina virtual, no para V M /370, de igual forma que si se ejecuta-
ra en una mquina real, en vez de una virtual. D espus, C M S emita las instrucciones normales de
E /S de hardware para leer su disco virtual o lo que fuera necesario para llevar a cabo la llamada.
E stas instrucciones de E /S eran atrapadas por la V M /370, que a su vez las ejecutaba como parte de
su simulacin del hardware real. A l separar por completo las funciones de multiprogramacin y pro-
porcionar una mquina extendida, cada una de las piezas podan ser ms simples, ms flexibles y
mucho ms fciles de mantener.
E n su encarnacin moderna, z/V M se utiliza por lo general para ejecutar varios sistemas ope-
rativos completos, en vez de sistemas simplificados de un solo usuario como C M S. Por ejemplo, la
serie zSeries es capaz de ejecutar una o ms mquinas virtuales de L inux junto con los sistemas ope-
rativos tradicionales de IB M .

R edescubrimiento de las mquinas virtuales

M ientras que IB M ha tenido un producto de mquina virtual disponible durante cuatro dcadas, y
unas cuantas compaas ms como Sun M icrosystems y H ewlett-Packard han agregado reciente-
mente el soporte de mquinas virtuales a sus servidores empresariales de alto rendimiento, la idea
de la virtualizacin se haba ignorado por mucho tiempo en el mundo de la PC , hasta hace poco.
Pero en los ltimos aos, se han combinado nuevas necesidades, nuevo software y nuevas tecnolo-
gas para convertirla en un tema de moda.
Primero hablaremos sobre las necesidades. M uchas compaas han ejecutado tradicionalmen-
te sus servidores de correo, servidores Web, servidores FT P y otros servidores en computadoras se-
paradas, algunas veces con distintos sistemas operativos. C onsideran la virtualizacin como una
forma de ejecutarlos todos en la misma mquina, sin que una falla de un servidor haga que falle el
resto.
L a virtualizacin tambin es popular en el mundo del hospedaje Web. Sin ella, los clientes de
hospedaje Web se ven obligados a elegir entre el hospedaje compartido (que les ofrece slo una
cuenta de inicio de sesin en un servidor Web, pero ningn control sobre el software de servidor) y
hospedaje dedicado (que les ofrece su propia mquina, lo cual es muy flexible pero no es costeable
para los sitios Web de pequeos a medianos). C uando una compaa de hospedaje Web ofrece la
renta de mquinas virtuales, una sola mquina fsica puede ejecutar muchas mquinas virtuales,
70 IN T R OD U C C IN C A PT U L O 1

cada una de las cuales parece ser una mquina completa. L os clientes que rentan una mquina vir-
tual pueden ejecutar cualesquier sistema operativo y software que deseen, pero a una fraccin del
costo de un servidor dedicado (debido a que la misma mquina fsica soporta muchas mquinas vir-
tuales al mismo tiempo).
Otro uso de la virtualizacin es para los usuarios finales que desean poder ejecutar dos o ms
sistemas operativos al mismo tiempo, por decir W indows y L inux, debido a que algunos de sus pa-
quetes de aplicaciones favoritos se ejecutan en el primero y algunos otros en el segundo. E sta situa-
cin se ilustra en la figura 1-29(a), en donde el trmino monitor de mquinas virtuales ha
cambiado su nombre por el de hipervisor de tipo 1 en aos recientes.

P roceso husped del S O

P roceso
E xcel Word Mplayer Apollon anfitrin
del S O

S O husped

Windows Linux ... Hipervisor de tipo 2

Hipervisor de tipo 1 S istema operativo anfitrin

(a) (b)

Figura 1-29. (a) U n hipervisor de tipo 1. (b) U n hipervisor de tipo 2.

A hora pasemos al software. A unque nadie disputa lo atractivo de las mquinas virtuales, el pro-
blema est en su implementacin. Para poder ejecutar software de mquina virtual en una compu-
tadora, su C PU debe ser virtualizable (Popek y G oldberg, 1974). E n sntesis, he aqu el proble-
ma. C uando un sistema operativo que opera en una mquina virtual (en modo usuario) ejecuta una
instruccin privilegiada, tal como para modificar el PSW o realizar una operacin de E /S, es esen-
cial que el hardware la atrape para el monitor de la mquina virtual, de manera que la instruccin
se pueda emular en el software. E n algunas C PU s (como el Pentium, sus predecesores y sus clo-
nes) los intentos de ejecutar instrucciones privilegiadas en modo de usuario simplemente se igno-
ran. E sta propiedad haca que fuera imposible tener mquinas virtuales en este hardware, lo cual
explica la falta de inters en el mundo de la PC . D esde luego que haba intrpretes para el Pentium
que se ejecutaban en el Pentium, pero con una prdida de rendimiento de por lo general 5x a 10x,
no eran tiles para un trabajo serio.
E sta situacin cambi como resultado de varios proyectos de investigacin acadmicos en la
dcada de 1990, como D isco en Stanford (B ugnion y colaboradores, 1997), que ocasionaron el sur-
gimiento de productos comerciales (por ejemplo, V M ware Workstation) y que reviviera el inters
en las mquinas virtuales. V M ware Workstation es un hipervisor de tipo 2, el cual se muestra en la
figura 1-29(b). E n contraste con los hipervisores de tipo 1, que se ejecutaban en el hardware direc-
to, los hipervisores de tipo 2 se ejecutan como programas de aplicacin encima de W indows, L inux
o algn otro sistema operativo, conocido como sistema operativo anfitrin. U na vez que se inicia
un hipervisor de tipo 2, lee el C D -R OM de instalacin para el sistema operativo husped elegido
SE C C IN 1.7 E ST R U C T U R A D E U N SIST E M A OPE R AT IV O 71

y lo instala en un disco virtual, que es tan slo un gran archivo en el sistema de archivos del siste-
ma operativo anfitrin.
C uando se arrancar el sistema operativo husped, realiza lo mismo que en el hardware real; por
lo general inicia algunos procesos en segundo plano y despus una G U I. A lgunos hipervisores tra-
ducen los programas binarios del sistema operativo husped bloque por bloque, reemplazando cier-
tas instrucciones de control con llamadas al hipervisor. D espus, los bloques traducidos se ejecutan
y se colocan en cach para su uso posterior.
U n enfoque distinto en cuanto al manejo de las instrucciones de control es el de modificar el
sistema operativo para eliminarlas. E ste enfoque no es una verdadera virtualizacin, sino paravir-
tualizacin. E n el captulo 8 hablaremos sobre la virtualizacin con ms detalle.

L a mquina virtual de J ava

Otra rea en donde se utilizan mquinas virtuales, pero de una manera algo distinta, es para ejecu-
tar programas de J ava. C uando Sun M icrosystems invent el lenguaje de programacin J ava, tam-
bin invent una mquina virtual (es decir, una arquitectura de computadora) llamada J V M (J ava
Virtual M achine, M quina virtual de J ava). E l compilador de J ava produce cdigo para la J V M ,
que a su vez tpicamente se ejecuta mediante un software intrprete de J V M . L a ventaja de este m-
todo es que el cdigo de la J V M se puede enviar a travs de Internet, a cualquier computadora que
tenga un intrprete de J V M y se ejecuta all. Por ejemplo, si el compilador hubiera producido pro-
gramas binarios para SPA R C o Pentium, no se podran haber enviado y ejecutado en cualquier par-
te con la misma facilidad. (D esde luego que Sun podra haber producido un compilador que
produjera binarios de SPA R C y despus distribuir un intrprete de SPA R C , pero J V M es una arqui-
tectura mucho ms simple de interpretar.) Otra ventaja del uso de la J V M es que, si el intrprete se
implementa de manera apropiada, que no es algo completamente trivial, se puede comprobar que
los programas de J V M entrantes sean seguros para despus ejecutarlos en un entorno protegido, de
manera que no puedan robar datos ni realizar algn otro dao.

1.7.6 E xokernels

E n vez de clonar la mquina actual, como se hace con las mquinas virtuales, otra estrategia es par-
ticionarla; en otras palabras, a cada usuario se le proporciona un subconjunto de los recursos. A s,
una mquina virtual podra obtener los bloques de disco del 0 al 1023, la siguiente podra obtener
los bloques de disco del 1024 al 2047 y as sucesivamente.
E n la capa inferior, que se ejecuta en el modo kernel, hay un programa llamado exokernel (E n-
gler y colaboradores, 1995). Su trabajo es asignar recursos a las mquinas virtuales y despus com-
probar los intentos de utilizarlos, para asegurar que ninguna mquina trate de usar los recursos de
otra. C ada mquina virtual de nivel de usuario puede ejecutar su propio sistema operativo, al igual
que en la V M /370 y las Pentium 8086 virtuales, con la excepcin de que cada una est restringida
a utilizar slo los recursos que ha pedido y que le han sido asignados.
L a ventaja del esquema del exokernel es que ahorra una capa de asignacin. E n los otros dise-
os, cada mquina virtual piensa que tiene su propio disco, con bloques que van desde 0 hasta cier-
72 IN T R OD U C C IN C A PT U L O 1

to valor mximo, por lo que el monitor de la mquina virtual debe mantener tablas para reasignar
las direcciones del disco (y todos los dems recursos). C on el exokernel, esta reasignacin no es ne-
cesaria. E l exokernel slo necesita llevar el registro para saber a cul mquina virtual se le ha asig-
nado cierto recurso. E ste mtodo sigue teniendo la ventaja de separar la multiprogramacin (en el
exokernel) del cdigo del sistema operativo del usuario (en espacio de usuario), pero con menos so-
brecarga, ya que todo lo que tiene que hacer el exokernel es mantener las mquinas virtuales sepa-
radas unas de las otras.

1.8 E L M UNDO SE G N C
Por lo general los sistemas operativos son extensos programas en C (o algunas veces C ) que
consisten de muchas piezas escritas por muchos programadores. E l entorno que se utiliza para de-
sarrollar sistemas operativos es muy distinto a lo que estn acostumbrados los individuos (como los
estudiantes) al escribir pequeos programas en J ava. E sta seccin es un intento de proporcionar una
muy breve introduccin al mundo de la escritura de sistemas operativos para los programadores
inexpertos de J ava.

1.8.1 E l lenguaje C

sta no es una gua para el uso de C , sino un breve resumen de algunas de las diferencias clave en-
tre C y J ava. J ava est basado en C , por lo que existen muchas similitudes entre los dos. A mbos son
lenguajes imperativos con tipos de datos, variables e instrucciones de control, por ejemplo. L os ti-
pos de datos primitivos en C son enteros (incluyendo cortos y largos), caracteres y nmeros de pun-
to flotante. L os tipos de datos compuestos se pueden construir mediante el uso de arreglos,
estructuras y uniones. L as instrucciones de control en C son similares a las de J ava, incluyendo las
instrucciones if, switch, for y while. L as funciones y los parmetros son aproximadamente iguales
en ambos lenguajes.
U na caracterstica de C que J ava no tiene son los apuntadores explcitos. U n apuntador es una
variable que apunta a (es decir, contiene la direccin de) una variable o estructura de datos. C onsi-
dere las siguientes instrucciones:

char c1, c2, *p;

c1 = x;
p = &c1;
c2 = *p;

que declaran a c1 y c2 como variables de tipo carcter y a p como una variable que apunta a (es de-
cir, contiene la direccin de) un carcter. L a primera asignacin almacena el cdigo A SC II para
el carcter c en la variable c1. L a segunda asigna la direccin de c1 a la variable apuntador p. L a
tercera asigna el contenido de la variable a la que apunta p, a la variable c2, por lo que despus de
ejecutar estas instrucciones, c2 tambin contiene el cdigo A SC II para c. E n teora, los apuntado-
res estn tipificados, por lo que no se debe asignar la direccin de un nmero de punto flotante a un
SE C C IN 1.8 E L M U N D O SE G N C 73

apuntador tipo carcter, pero en la prctica los compiladores aceptan dichas asignaciones, aunque
algunas veces con una advertencia. L os apuntadores son una construccin muy potente, pero tam-
bin una gran fuente de errores cuando se utilizan sin precaucin.
A lgunas cosas que C no tiene son: cadenas integradas, hilos, paquetes, clases, objetos, seguri-
dad de tipos y recoleccin de basura. L a ltima es un gran obstculo para los sistemas operativos.
Todo el almacenamiento en C es esttico o el programador lo asigna y libera de manera explcita,
por lo general con las funciones de biblioteca malloc y free. E sta ltima propiedad (control total del
programador sobre la memoria) junto con los apuntadores explcitos que hacen de C un lenguaje
atractivo para escribir sistemas operativos. E n esencia, los sistemas operativos son sistemas en tiem-
po real hasta cierto punto, incluso los de propsito general. C uando ocurre una interrupcin, el sis-
tema operativo slo puede tener unos cuantos microsegundos para realizar cierta accin o de lo
contrario, puede perder informacin crtica. E s intolerable que el recolector de basura entre en ac-
cin en un momento arbitrario.

1.8.2 A rchivos de encabezado

Por lo general, un proyecto de sistema operativo consiste en cierto nmero de directorios, cada uno
de los cuales contiene muchos archivos .c que contienen el cdigo para cierta parte del sistema, jun-
to con varios archivos de encabezado .h que contienen declaraciones y definiciones utilizadas por
uno o ms archivos de cdigo. L os archivos de encabezado tambin pueden incluir macros simples,
tales como:
#define TAM_ BUF E R 4096
las cuales permiten que el programador nombre constantes, de manera que cuando TA M _ BU F E R se
utilice en el cdigo, se reemplace durante la compilacin por el nmero 4096. U na buena prctica
de programacin de C es nombrar cada constante excepto 0, 1 y 1, y algunas veces tambin stas
se nombran. L as macros pueden tener parmetros, tales como:
#define max(a, b) (a > b ? a : b)
con lo cual el programador puede escribir:
i = max(j, k+1)
y obtener:
i = (j > k+1 ? j : k + 1)
para almacenar el mayor de j y k 1 en i. L os encabezados tambin pueden contener compilacin
condicional, por ejemplo:
#ifdef P E NTIUM
intel_ int_ ack();
#endif
lo cual se compila en una llamada a la funcin intel_ int_ ack si la macro P E N T I U M est definida y
no hace nada en caso contrario. L a compilacin condicional se utiliza con mucha frecuencia para
74 IN T R OD U C C IN C A PT U L O 1

aislar el cdigo dependiente de la arquitectura, de manera que cierto cdigo se inserte slo cuando
se compile el sistema en el Pentium, que se inserte otro cdigo slo cuando el sistema se compile
en una SPA R C y as sucesivamente. U n archivo .c puede incluir fsicamente cero o ms archivos de
encabezado mediante la directiva #include. Tambin hay muchos archivos de encabezado comunes
para casi cualquier archivo .c, y se almacenan en un directorio central.

1.8.3 Proyectos de programacin extensos

Para generar el sistema operativo, el compilador de C compila cada archivo .c en un archivo de c-

digo objeto. E stos archivos, que tienen el sufijo .o, contienen instrucciones binarias para el equipo
de destino. Posteriormente la C PU los ejecutar directamente. N o hay nada como el cdigo byte de
J ava en el mundo de C .
L a primera pasada del compilador de C se conoce como preprocesador de C . A medida que
lee cada archivo .c, cada vez que llega a una directiva #include va y obtiene el archivo de encabe-
zado cuyo nombre contiene y lo procesa, expandiendo las macros, manejando la compilacin con-
dicional (y varias otras cosas) y pasando los resultados a la siguiente pasada del compilador, como
si se incluyeran fsicamente.
C omo los sistemas operativos son muy extensos (es comn que tengan cerca de cinco millo-
nes de lneas de cdigo), sera imposible tener que recompilar todo cada vez que se modifica
un archivo. Por otro lado, para cambiar un archivo de encabezado clave que se incluye en miles
de otros archivos, hay que volver a compilar esos archivos. L levar la cuenta de qu archivos de
cdigo objeto depende de cules archivos de encabezado es algo que no se puede manejar sin
ayuda.
Por fortuna, las computadoras son muy buenas precisamente en este tipo de cosas. E n los sis-
temas U N IX hay un programa llamado make (con numerosas variantes tales como gmake, pmake,
etctera) que lee el M akefile, un archivo que indica qu archivos son dependientes de cules otros
archivos. L o que hace make es ver qu archivos de cdigo objeto se necesitan para generar el archi-
vo binario del sistema operativo que se necesita en un momento dado y para cada uno comprueba
si alguno de los archivos de los que depende (el cdigo y los encabezados) se ha modificado des-
pus de la ltima vez que se cre el archivo de cdigo objeto. D e ser as, ese archivo de cdigo ob-
jeto se tiene que volver a compilar. C uando make ha determinado qu archivos .c se tienen que
volver a compilar, invoca al compilador de C para que los recompile, con lo cual se reduce el n-
mero de compilaciones al mnimo. E n los proyectos extensos, la creacin del M akefile est propen-
sa a errores, por lo que hay herramientas que lo hacen de manera automtica.
U na vez que estn listos todos los archivos .o, se pasan a un programa conocido como enlaza-
dor para combinarlos en un solo archivo binario ejecutable. C ualquier funcin de biblioteca que sea
llamada tambin se incluye en este punto, se resuelven las referencias dentro de las funciones y se
reasignan las direcciones de la mquina segn sea necesario. C uando el enlazador termina, el resul-
tado es un programa ejecutable, que por tradicin se llama a.out en los sistemas U N IX . L os diver-
sos componentes de este proceso se ilustran en la figura 1-30 para un programa con tres archivos
de C y dos archivos de encabezado. A unque hemos hablado aqu sobre el desarrollo de sistemas
operativos, todo esto se aplica al desarrollo de cualquier programa extenso.
SE C C IN 1.8 E L M U N D O SE G N C 75

defs.h mac.h main.c ayuda.c otro.c

P reprocesador
de C

C ompilador
de C

main.o ayuda.o otro.o

libc.a enlazador

P rograma binario
ejecutable
a.out

Figura 1-30. E l proceso de compilar archivos de C y de encabezado para crear un ar-

chivo ejecutable.

1.8.4 E l modelo del tiempo de ejecucin

U na vez que se ha enlazado el archivo binario del sistema operativo, la computadora puede reini-
ciarse con el nuevo sistema operativo. U na vez en ejecucin, puede cargar piezas en forma dinmi-
ca que no se hayan incluido de manera esttica en el binario, como los drivers de dispositivos y los
sistemas de archivos. E n tiempo de ejecucin, el sistema operativo puede consistir de varios seg-
mentos, para el texto (el cdigo del programa), los datos y la pila. Por lo general, el segmento de
texto es inmutable y no cambia durante la ejecucin. E l segmento de datos empieza con cierto ta-
mao y se inicializa con ciertos valores, pero puede cambiar y crecer segn lo necesite. A l princi-
pio la pila est vaca, pero crece y se reduce a medida que se hacen llamadas a funciones y se
regresa de ellas. A menudo el segmento de texto se coloca cerca de la parte final de la memoria, el
segmento de datos justo encima de ste, con la habilidad de crecer hacia arriba y el segmento de pi-
la en una direccin virtual superior, con la habilidad de crecer hacia abajo, pero los distintos siste-
mas trabajan de manera diferente.
E n todos los casos, el cdigo del sistema operativo es ejecutado directamente por el hardware,
sin intrprete y sin compilacin justo-a-tiempo, como se da el caso con J ava.
76 IN T R OD U C C IN C A PT U L O 1

1.9 INV E ST IG AC IN AC E R C A DE L OS
SIST E M A S OPE R AT IVOS
L a ciencia computacional es un campo que avanza con rapidez y es difcil predecir hacia dnde va.
L os investigadores en universidades y los laboratorios de investigacin industrial estn desarrollan-
do constantemente nuevas ideas, algunas de las cuales no van a ningn lado, pero otras se convier-
ten en la piedra angular de futuros productos y tienen un impacto masivo en la industria y en los
usuarios. Saber qu ideas tendrn xito es ms fcil en retrospeccin que en tiempo real. Separar el
trigo de la paja es en especial difcil, debido a que a menudo se requieren de 20 a 30 aos para que
una idea haga impacto.
Por ejemplo, cuando el presidente E isenhower estableci la A gencia de Proyectos A vanzados
de Investigacin (A R PA ) del D epartamento de D efensa en 1958, trataba de evitar que el E jrcito
predominara sobre la M arina y la Fuerza A rea en relacin con el presupuesto de investigacin. N o
estaba tratando de inventar Internet. Pero una de las cosas que hizo A R PA fue patrocinar cierta in-
vestigacin universitaria sobre el entonces oscuro tema de la conmutacin de paquetes, lo cual con-
dujo a la primera red experimental de conmutacin de paquetes, A R PA N ET. Entr en funcionamiento
en 1969. Poco tiempo despus, otras redes de investigacin patrocinadas por A R PA estaban conecta-
das a A R PA N E T,y naci Internet, que en ese entonces era utilizada felizmente por los investigado-
res acadmicos para enviarse correo electrnico unos con otros durante 20 aos. A principios de la
dcada de 1990, Tim B erners-L ee invent la World W ide Web en el laboratorio de investigacin
C E R N en G inebra y M arc A ndreesen escribi el cdigo de un navegador grfico para esta red en la
U niversidad de Illinois. D e repente, Internet estaba llena de adolescentes conversando entre s. Pro-
bablemente el presidente E isenhower est revolcndose en su tumba.
L a investigacin en los sistemas operativos tambin ha producido cambios dramticos en los
sistemas prcticos. C omo vimos antes, los primeros sistemas computacionales comerciales eran to-
dos sistemas de procesamiento por lotes, hasta que el M .I.T. invent el tiempo compartido interac-
tivo a principios de la dcada de 1960. Todas las computadoras eran basadas en texto, hasta que
D oug E ngelbart invent el ratn y la interfaz grfica de usuario en el Stanford R esearch Institute a
finales de la dcada de 1960. Quin sabe lo que vendr a continuacin?
E n esta seccin y en otras secciones equivalentes en el resto de este libro, daremos un breve
vistazo a una parte de la investigacin sobre los sistemas operativos que se ha llevado a cabo du-
rante los ltimos 5 a 10 aos, slo para tener una idea de lo que podra haber en el horizonte. E n
definitiva, esta introduccin no es exhaustiva y se basa en gran parte en los artculos que se han pu-
blicado en los principales diarios de investigacin y conferencias, debido a que estas ideas han so-
brevivido por lo menos a un proceso de revisin personal riguroso para poder publicarse. L a
mayora de los artculos citados en las secciones de investigacin fueron publicados por la A C M , la
IE E E C omputer Society o U SE N IX , que estn disponibles por Internet para los miembros (estu-
diantes) de estas organizaciones. Para obtener ms informacin acerca de estas organizaciones y sus
bibliotecas digitales, consulte los siguientes sitios Web:

AC M http://www.acm.org
IE E E C omputer S ociety http://www.computer.org
US E NIX http://www.usenix.org
SE C C IN 1.10 D E SC R IPC IN G E N E R A L SOB R E E L R E ST O D E E ST E L IB R O 77

C asi todos los investigadores de sistemas operativos consideran que los sistemas operativos ac-
tuales son masivos, inflexibles, no muy confiables, inseguros y estn cargados de errores, eviden-
temente algunos ms que otros (no divulgamos los nombres para no daar a los aludidos). E n
consecuencia, hay mucha investigacin acerca de cmo construir mejores sistemas operativos.
E n fechas recientes se ha publicado trabajo acerca de los nuevos sistemas operativos (K rieger y co-
laboradores, 2006), la estructura del sistema operativo (Fassino y colaboradores, 2002), la rectitud
del sistema operativo (E lphinstone y colaboradores, 2007; K umar y L i, 2002; y Y ang y colaborado-
res, 2006), la confiabilidad del sistema operativo (Swift y colaboradores, 2006; y L eVasseur y co-
laboradores, 2004), las mquinas virtuales (B arham y colaboradores, 2003; Garfinkel y colaborado-
res, 2003; K ing y colaboradores, 2003; y W hitaker y colaboradores, 2002), los virus y gusanos
(C osta y colaboradores, 2005; Portokalidis y colaboradores, 2006; Tucek y colaboradores, 2007; y
V rable y colaboradores, 2005), los errores y la depuracin (C hou y colaboradores, 2001; y K ing
y colaboradores, 2005), el hiperhilamiento y el multihilamiento (Fedorova, 2005; y B ulpin y Pratt,
2005), y el comportamiento de los usuarios (Y u y colaboradores, 2006), entre muchos otros temas.

1.10 DE SC R IPC IN G E NE R A L SOBR E E L R E ST O

DE E ST E L IBRO
A hora hemos completado nuestra introduccin y un breve visin del sistema operativo. E s tiempo
de entrar en detalles. C omo dijimos antes, desde el punto de vista del programador, el propsito
principal de un sistema operativo es proveer ciertas abstracciones clave, siendo las ms importan-
tes los procesos y hilos, los espacios de direcciones y los archivos. D e manera acorde, los siguien-
tes tres captulos estn dedicados a estos temas cruciales.
El captulo 2 trata acerca de los procesos y hilos. Describe sus propiedades y la manera en que se
comunican entre s. Tambin proporciona varios ejemplos detallados acerca de la forma en que fun-
ciona la comunicacin entre procesos y cmo se pueden evitar algunos obstculos.
E n el captulo 3 estudiaremos los espacios de direcciones y su administracin adjunta de me-
moria con detalle. E xaminaremos el importante tema de la memoria virtual, junto con los concep-
tos estrechamente relacionados, como la paginacin y la segmentacin.
D espus, en el captulo 4 llegaremos al importantsimo tema de los sistemas de archivos. H as-
ta cierto punto, lo que el usuario ve es en gran parte el sistema de archivos. A nalizaremos la inter-
faz del sistema de archivos y su implementacin.
E n el captulo 5 se cubre el tema de las operaciones de entrada/salida. H ablaremos sobre los
conceptos de independencia de dispositivos y dependencia de dispositivos. U tilizaremos como
ejemplos varios dispositivos importantes, como los discos, teclados y pantallas.
E l captulo 6 trata acerca de los interbloqueos. A nteriormente en este captulo mostramos en
forma breve qu son los interbloqueos, pero hay mucho ms por decir. H ablaremos tambin sobre
las formas de prevenirlos o evitarlos.
E n este punto habremos completado nuestro estudio acerca de los principios bsicos de los sis-
temas operativos con una sola C PU . Sin embargo, hay ms por decir, en especial acerca de los te-
mas avanzados. E n el captulo 7 examinaremos los sistemas de multimedia, que tienen varias
78 IN T R OD U C C IN C A PT U L O 1

propiedades y requerimientos distintos de los sistemas operativos convencionales. E ntre otros ele-
mentos, la planificacin de tareas y el sistema de archivos se ven afectados por la naturaleza de
la multimedia. Otro tema avanzado es el de los sistemas con mltiples procesadores, incluyendo los
multiprocesadores, las computadoras en paralelo y los sistemas distribuidos. C ubriremos estos te-
mas en el captulo 8.
U n tema de enorme importancia es la seguridad de los sistemas operativos, que se cubre en el
captulo 9. E ntre los temas descritos en este captulo estn las amenazas (es decir, los virus y gusa-
nos), los mecanismos de proteccin y los modelos de seguridad.
A continuacin veremos algunos ejemplos prcticos de sistemas operativos reales. stos son
L inux (captulo 10), W indows V ista (captulo 11) y Symbian (captulo 12). E l libro concluye con
ciertos consejos y pensamientos acerca del diseo de sistemas operativos en el captulo 13.

1.11 UNIDA DE S M T R IC A S
Para evitar cualquier confusin, vale la pena declarar en forma explcita que en este libro, como en
la ciencia computacional en general, se utilizan unidades mtricas en vez de las tradicionales uni-
dades del sistema ingls. L os principales prefijos mtricos se listan en la figura 1-31. Por lo gene-
ral, estos prefijos se abrevian con sus primeras letras y las unidades mayores de 1 estn en
maysculas. A s, una base de datos de 1 T B ocupa 1012 bytes de almacenamiento, y un reloj de 100
pseg (o 100 ps) emite un pulso cada 10-10 segundos. C omo mili y micro empiezan con la letra m,
se tuvo que hacer una eleccin. Por lo general, m es para mili y (la letra griega mu) es para
micro.

Exp. Explcito Prefijo Exp. Explcito Prefijo

103 0 .0 0 1 mili 10 3 1,000 K ilo
106 0 .0 0 0 0 0 1 mic ro 10 6 1,000,000 Mega
109 0 .0 0 0 0 0 0 0 0 1 na no 10 9 1,000,000,000 G iga
1012 0.000000000001 pico 1012 1,000,000,000,000 Tera
1015 0.000000000000001 femto 1015 1,000,000,000,000,000 P eta
1018 0.0000000000000000001 atto 10 18 1,000,000,000,000,000,000 E xa
1021 0.0000000000000000000001 zepto 10 21 1,000,000,000,000,000,000,000 Zetta
1024 0.0000000000000000000000001 yocto 10 24 1,000,000,000,000,000,000,000,000 Yotta

Figura 1-31. L os principales prefijos mtricos.

Tambin vale la pena recalcar que para medir los tamaos de las memorias, en la prctica co-
mn de la industria, las unidades tienen significados ligeramente diferentes. A h, K ilo significa 2 10
(1024) en vez de 103 (1000), debido a que las memorias siempre utilizan una potencia de dos. Por
ende, una memoria de 1 K B contiene 1024 bytes, no 1000 bytes. D e manera similar, una memoria
de 1 M B contiene 220 (1,048,576) bytes y una memoria de 1 G B contiene 230 (1,073,741,824) by-
tes. Sin embargo, una lnea de comunicacin de 1 K bps transmite 1000 bits por segundo y una L A N
de 10 M bps opera a 10,000,000 bits/seg, debido a que estas velocidades no son potencias de dos.
Por desgracia, muchas personas tienden a mezclar estos dos sistemas, en especial para los tamaos
SE C C IN 1.12 R E SU M E N 79

de los discos. Para evitar ambigedades, en este libro utilizaremos los smbolos K B , M B y G B pa-
ra 210, 220 y 230 bytes, respectivamente y los smbolos K bps, M bps y G bps para 103, 106 y 109 bits-
/seg, respectivamente.

1.12 R E SUM E N
L os sistemas operativos se pueden ver desde dos puntos de vista: como administradores de recursos
y como mquinas extendidas. E n el punto de vista correspondiente al administrador de recursos, la
funcin del sistema operativo es administrar las distintas partes del sistema en forma eficiente. E n el
punto de vista correspondiente a la mquina extendida, la funcin del sistema operativo es proveer a
los usuarios abstracciones que sean ms convenientes de usar que la mquina actual. E stas abstrac-
ciones incluyen los procesos, espacios de direcciones y archivos.
L os sistemas operativos tienen una larga historia, empezando desde los das en que reemplaza-
ron al operador, hasta los sistemas modernos de multiprogramacin. E ntre los puntos importantes
tenemos a los primeros sistemas de procesamiento por lotes, los sistemas de multiprogramacin y
los sistemas de computadora personal.
C omo los sistemas operativos interactan de cerca con el hardware, es til tener cierto conoci-
miento del hardware de computadora parea comprenderlos. L as computadoras estn compuestas de
procesadores, memorias y dispositivos de E /S. E stas partes se conectan mediante buses.
L os conceptos bsicos en los que se basan todos los sistemas operativos son los procesos, la
administracin de memoria, la administracin de E /S, el sistema de archivos y la seguridad. C ada
uno de estos conceptos se tratar con detalle en un captulo posterior.
E l corazn de cualquier sistema operativo es el conjunto de llamadas al sistema que puede ma-
nejar. E stas llamadas indican lo que realmente hace el sistema operativo. Para U N IX , hemos visto
cuatro grupos de llamadas al sistema. E l primer grupo de llamadas se relaciona con la creacin y
terminacin de procesos. E l segundo grupo es para leer y escribir en archivos. E l tercer grupo es pa-
ra administrar directorios. E l cuarto grupo contiene una miscelnea de llamadas.
L os sistemas operativos se pueden estructurar en varias formas. L as ms comunes son como
un sistema monoltico, una jerarqua de capas, microkernel, cliente-servidor, mquina virtual o
exokernel.

PROBL E M A S

1. Qu es la multiprogramacin?
2. Qu es spooling? C ree usted que las computadoras personales avanzadas tendrn spooling como
caracterstica estndar en el futuro?
3. E n las primeras computadoras, cada byte de datos ledos o escritos se manejaba mediante la C PU
(es decir, no haba D M A ). Qu implicaciones tiene esto para la multiprogramacin?
80 IN T R OD U C C IN C A PT U L O 1

4. L a idea de una familia de computadoras fue introducida en la dcada de 1960 con las mainframes
IB M System/360. E st muerta ahora esta idea o sigue en pie?
5. U na razn por la cual las G U I no se adoptaron con rapidez en un principio fue el costo del hardwa-
re necesario para darles soporte. C unta R A M de video se necesita para dar soporte a una pantalla
de texto monocromtico de 25 lneas x 80 caracteres? C unta se necesita para un mapa de bits de
1024 768 pxeles y colores 24 bits? C ul fue el costo de esta R A M con precios de 1980
(5 dlares/K B )? C unto vale ahora?
6. H ay varias metas de diseo a la hora de crear un sistema operativo, por ejemplo: la utilizacin de
recursos, puntualidad, que sea robusto, etctera. D e un ejemplo de dos metas de diseo que puedan
contradecirse entre s.
7. C ul de las siguientes instrucciones debe permitirse slo en modo kernel?
a) D eshabilitar todas las interrupciones.
b) L eer el reloj de la hora del da.
c) E stablecer el reloj de la hora del da.
d) C ambiar el mapa de memoria.
8. C onsidere un sistema con dos C PU s y que cada C PU tiene dos hilos (hiperhilamiento). Suponga que
se inician tres programas P 0, P 1 y P 2 con tiempos de ejecucin de 5, 10 y 20 mseg, respectivamen-
te. C unto se tardar en completar la ejecucin de estos programas? Suponga que los tres progra-
mas estn 100% ligados a la C PU , que no se bloquean durante la ejecucin y no cambian de C PU
una vez que se les asigna.
9. U na computadora tiene una canalizacin con cuatro etapas. Cada etapa requiere el mismo tiempo pa-
ra hacer su trabajo, a saber, 1 nseg. Cuntas instrucciones por segundo puede ejecutar esta mquina?
10. C onsidere un sistema de cmputo con memoria cach, memoria principal (R A M ) y disco, y que el
sistema operativo utiliza memoria virtual. Se requieren 2 nseg para acceder a una palabra desde la
cach, 10 nseg para acceder a una palabra desde la R A M y 10 ms para acceder a una palabra desde
el disco. Si la proporcin de aciertos de cach es de 95% y la proporcin de aciertos de memoria
(despus de un fallo de cach) es de 99%, cul es el tiempo promedio para acceder a una palabra?
11. U n revisor alerta observa un error de ortografa consistente en el manuscrito del libro de texto de
sistemas operativos que est a punto de ser impreso. E l libro tiene cerca de 700 pginas, cada una
con 50 lneas de 80 caracteres. C unto tiempo se requerir para digitalizar en forma electrnica el
texto, para el caso en que la copia maestra se encuentre en cada uno de los niveles de memoria de
la figura 1-9? Para los mtodos de almacenamiento interno, considere que el tiempo de acceso da-
do es por carcter, para los discos suponga que el tiempo es por bloque de 1024 caracteres y para la
cinta suponga que el tiempo dado es para el inicio de los datos, con un acceso posterior a la misma
velocidad que el acceso al disco.
12. C uando un programa de usuario realiza una llamada al sistema para leer o escribir en un archivo en
disco, proporciona una indicacin de qu archivo desea, un apuntador al bfer de datos y la cuenta.
D espus, el control se transfiere al sistema operativo, el cual llama al driver apropiado. Suponga que
el driver inicia el disco y termina hasta que ocurre una interrupcin. E n el caso de leer del disco, es
obvio que el procedimiento que hizo la llamada tiene que ser bloqueado (debido a que no hay datos
para leer). Qu hay sobre el caso de escribir en el disco? N ecesita ser bloqueado el procedimien-
to llamador, para esperar a que se complete la transferencia del disco?
C A PT U L O 1 PR OB L E M A S 81

13. Qu es una instruccin de trap? E xplique su uso en los sistemas operativos.

14. C ul es la diferencia clave entre un trap y una interrupcin?
15. Por qu se necesita la tabla de procesos en un sistema de tiempo compartido? Se necesita tambin
en los sistemas de computadora personal en los que slo existe un proceso, y ese proceso ocupa to-
da la mquina hasta que termina?
16. E xiste alguna razn por la que sera conveniente montar un sistema de archivos en un directorio no
vaco? D e ser as, cul es?
17. C ul es el propsito de una llamada al sistema en un sistema operativo?
18. Para cada una de las siguientes llamadas al sistema, proporcione una condicin que haga que falle:
fork, exec y unlink.

19. Podra la llamada

cuenta = write(fd, bufer, nbytes);
devolver algn valor en cuenta distinto de nbytes? Si es as, por qu?
20. U n archivo cuyo descriptor es fd contiene la siguiente secuencia de bytes: 3, 1, 4, 1, 5, 9, 2, 6, 5, 3,
5. Se realizan las siguientes llamadas al sistema:
lseek(fd, 3, S E E K _ S E T);
read(fd, &bufer, 4);
en donde la llamada lseek realiza una bsqueda en el byte 3 del archivo. Qu contiene bufer des-
pus de completar la operacin de lectura?
21. Suponga que un archivo de 10 M B se almacena en un disco, en la misma pista (pista #: 50) en sec-
tores consecutivos. E l brazo del disco se encuentra actualmente situado en la pista nmero 100.
C unto tardar en recuperar este archivo del disco? Suponga que para desplazar el brazo de un ci-
lindro al siguiente se requiere aproximadamente 1 ms y se requieren aproximadamente 5 ms para que
el sector en el que est almacenado el inicio del archivo gire bajo la cabeza. Suponga adems que la
lectura ocurre a una velocidad de 100 M B /s.
22. C ul es la diferencia esencial entre un archivo especial de bloque y un archivo especial de carcter?
23. E n el ejemplo que se da en la figura 1-17, el procedimiento de biblioteca se llama read y la misma
llamada al sistema se llama read. E s esencial que ambos tengan el mismo nombre? Si no es as,
cul es ms importante?
24. E l modelo cliente-servidor es popular en los sistemas distribuidos. Puede utilizarse tambin en un
sistema de una sola computadora?
25. Para un programador, una llamada al sistema se ve igual que cualquier otra llamada a un procedi-
miento de biblioteca. E s importante que un programador sepa cules procedimientos de biblioteca
resultan en llamadas al sistema? B ajo qu circunstancias y por qu?
26. L a figura 1-23 muestra que varias llamadas al sistema de U N IX no tienen equivalentes en la A PI
W in32. Para cada una de las llamadas que se listan y no tienen un equivalente en W in32, cules
son las consecuencias de que un programador convierta un programa de U N IX para que se ejecute
en W indows?
82 IN T R OD U C C IN C A PT U L O 1

27. U n sistema operativo porttil se puede portar de la arquitectura de un sistema a otro, sin ninguna
modificacin. E xplique por qu no es factible construir un sistema operativo que sea completamen-
te porttil. D escriba dos capas de alto nivel que tendr al disear un sistema operativo que sea alta-
mente porttil.
28. E xplique cmo la separacin de la directiva y el mecanismo ayuda a construir sistemas operativos
basados en microkernel.
29. H e aqu algunas preguntas para practicar las conversiones de unidades:
(a) A cuntos segundos equivale un microao?
(b) A los micrmetros se les conoce comnmente como micrones. Qu tan largo es un gigamicron?
(c) C untos bytes hay en una memoria de 1 T B ?
(d) L a masa de la Tierra es de 6000 yottagramos. C unto es eso en kilogramos?
30. E scriba un shell que sea similar a la figura 1-19, pero que contenga suficiente cdigo como para que
pueda funcionar y lo pueda probar. Tambin podra agregar algunas caractersticas como la redirec-
cin de la entrada y la salida, los canales y los trabajos en segundo plano.
31. Si tiene un sistema personal parecido a U N IX (L inux, M IN IX , FreeB SD , etctera) disponible que
pueda hacer fallar con seguridad y reiniciar, escriba una secuencia de comandos de shell que inten-
te crear un nmero ilimitado de procesos hijos y observe lo que ocurre. A ntes de ejecutar el experi-
mento, escriba sync en el shell para vaciar los bferes del sistema de archivos al disco y evitar
arruinar el sistema de archivos. Nota: N o intente esto en un sistema compartido sin obtener prime-
ro permiso del administrador del sistema. L as consecuencias sern obvias de inmediato, por lo que
es probable que lo atrapen y sancionen.
32. E xamine y trate de interpretar el contenido de un directorio tipo U N IX o W indows con una herra-
mienta como el programa od de U N IX o el programa D E BU G de M S-D OS. Sugerencia: L a forma
en que haga esto depender de lo que permita el SO. U n truco que puede funcionar es crear un di-
rectorio en un disco flexible con un sistema operativo y despus leer los datos puros del disco usan-
do un sistema operativo distinto que permita dicho acceso.