Notas de sistemas operativos/Saade Sergio

NOTAS DE
SISTEMAS OPERATIVOS
SERGIO DANIEL SAADE

AA mmiiss ppaaddrreess,, qquuiieenneess mmee eedduuccaarroonn
pprriinncciippaallmmeennttee ccoonn eell eejjeemmpplloo..

PREFACIO
PREFACIO
OBJETIVOS
Estas “Notas en Sistemas Operativos” presentan los aspectos teóricos básicos
encontrados en la mayoría de los Sistemas Operativos actuales. El objetivo
principal de estas notas es proveer a los lectores con una referencia en idioma
Español de tales conceptos básicos y ejemplificar con implementaciones de
sistemas operativos reales dichos conceptos.
El texto está dirigido a estudiantes de un curso introductorio en Sistemas
Operativos en carreras tales como Ingeniería en Computación, Ciencias de la
Computación, Ingeniería Informática, Analista o Ingeniero en Sistemas. Todos los
módulos contienen al final problemas resueltos y propuestos para ayudar a
alumnos, docentes o autodidactas en la consolidación de los conceptos teóricos
tratados en los mismos.
DIAGRAMACIÓN DEL TEXTO
El texto está organizado en 7 módulos, a saber:
Módulo 1: Provee una revisión general sobre las arquitecturas básicas de
computadoras. Se definen a los Sistemas Operativos de acuerdo a distintos
aspectos. Se estudian distintos tipos de estructura de organización interna de los
sistemas operativos como monolítica, kernel, microkernel y otras. A modo de
ejemplo se muestra la arquitectura interna de Microsoft Windows NT.
Módulo 2: Se introduce el concepto de Proceso y se estudian las estructuras de
datos utilizadas por los Sistemas Operativos para su control. También se
introduce el concepto de “thread” o “hilo de ejecución” presente en la mayoría
Prefacio 9

- NOTAS EN SISTEMAS OPERATIVOS -
de los sistemas operativos modernos. Como ejemplo de sistema operativo, se
describe la manipulación de procesos en UNIX System V.
Módulo 3: Se analiza el planificador o “scheduler” de CPU. Se estudian distintos
algoritmos para su implementación. Se describe la planificación de CPU en
sistemas multiprocesados. El sistema operativo seleccionado para ejemplificar, es
el Microsoft Windows NT, analizándose su planificador en sistemas mono-
procesados.
Módulo 4: Se introduce el concepto concurrencia de procesos. Se comienza
tratando el problema de la sección crítica y su resolución mediante herramientas
de software y hardware. También se definen primitivas de sincronización como
semáforos y monitores. Finalmente se introduce el concepto de sistemas
distribuidos y su sincronización mediante primitivas basadas en mensajes. En este
módulo se consideran problemas clásicos de sincronización tales como el
problema de Productor/Consumidor, Escritores/Lectores y otros. Se utiliza a las
primitivas de sincronización de UNIX System V para ejemplificar los aspectos
tratados en el módulo.
Módulo 5: Se introduce el problema de abrazo mortal o “ deadlock” en sistemas
operativos. Se muestran esquemas para la detección, recuperación y prevención
de tal estado. También se estudia el algoritmo del banquero para evitar la
ocurrencia de “deadlock”.
Módulo 6: Se ven los aspectos más importantes de la administración de memoria.
Se introduce el concepto de memoria virtual y su implementación mediante
esquemas paginados y segmentados. Se estudian distintos algoritmos de
reemplazo de página. Se ejemplifican los aspectos cubiertos en el texto con la
descripción del esquema de administración de memoria de Microsoft Windows
NT.
Módulo 7: En este módulo se analiza el subsistema de archivos y de
Entrada/Salida. Se plantea un modelo jerárquico de sistema de archivos,
analizando cada uno de los niveles. Se analiza en detalles el sistemas de archivos
de UNIX System V y se muestra la organización interna de archivos y directorios
de Microsoft Windows NT.
Prefacio 10

CONTENIDO
Tabla de
Contenido
Generalidades de Sistemas Operativos 14
1.1 Introducción 14
1.2 Evolución de los Sistemas Operativos 17
1.3 Limitaciones del Hardware 19
1.4 Principio de Multiprogramas 26
1.5 Definición de Sistema Operativo 27
1.6 Tipos de Sistemas Operativos 29
1.7 Estructura de los Sistemas Operativos 32
1.8 Ejemplo de Estructura Interna de Sistema Operativo: Microsoft Windows NT 43
1.8 Problemas 48
Procesos 54
2.2 Creación y Terminación de Procesos 55
2.3 Estados de un Proceso 57
2.4 Descripción de un Proceso 60
2.5 Cambio de Proceso 64
2.6 Procesos y “Threads” 66
2.7 Ejemplo de Descripción y Control de Procesos: UNIX System V 69
2.8 Problemas 76
Planificación de la CPU 82
3.2 Tipos de Planificadores de CPU 82
3.3 Algoritmos de Planificación de CPU 86
3.4 Comparación de Métodos de Planificación 89
3.5 Planificación en Sistemas Multiprocesados 92
3.6 Ejemplo de Planificación de Procesos y “Threads”: Microsoft Windows NT 96
3.5 Problemas 102
Concurrencia 108
4.2 Procesos Competitivos y Cooperativos 109
Tabla de Contenido 11

4.3 Introducción al Problema de la Sección Crítica 110
4.4 Soluciones al Problema de la Sección Crítica 112
4.5 Primitivas de Semáforo 119
4.6 Métodos de Sincronización de Alto Nivel 128
4.7 Concepto de Sistemas Distribuidos 134
4.8 Problemas Clásicos de Sincronización 144
4.9 Ejemplos de Primitivas de Sincronización: UNIX System V. 151
4.10 Problemas 156
Abrazo Mortal 172
5.2 Tipos de Recursos 172
5.3 Ejemplos de Abrazo Mortal 173
5.4 Detección, Recuperación y Prevención del Abrazo Mortal 176
5.5 Grafo de Asignación de Recursos 176
5.6 Detección de “Deadlock” - Grafos “Wait-For” 180
5.7 Recuperación de “Deadlock” 182
5.8 Condiciones Necesarias para la Existencia de “Deadlock” 183
5.9 Prevención del “Deadlock” 183
5.10 Evitando el “Deadlock” 186
5.10 Problemas 193
Administración de Memoria 200
6.2 Esquemas Simples de Administración de Memoria 202
6.3 Principios de Memoria Virtual 206
6.4 Implementación de Memoria Virtual 208
6.5 Esquemas de Asignación de Memoria 219
6.6 Ejemplo de Administración de Memoria: Microsoft Windows NT 229
6.6 Problemas 242
Sistema de Archivos y Procesamiento de I/O 254
7.2 Organización del Sistema de Archivos y de Entrada/Salida 255
7.3 Administración de Directorio 261
7.4 Sistema Básico de Archivos 264
7.5 Métodos de Organización Física 267
7.6 El Subsistema de I/O 278
7.7 Buffering 284
7.8 Planificación de Disco 285
7.9 Ejemplo de File System: UNIX System V 287

7.10 Problemas 298
Bibliografía 308

MÓDULO 1
GENERALIDADES DE
SISTEMAS OPERATIVOS
1.1 INTRODUCCIÓN
Cuando se escribe un comando como “date” en un terminal conectado a una computadora
y se presiona la tecla <Enter>, se pone en marcha un complejo conjunto de acciones que
involucran a un gran número de recursos de software y hardware que posee dicha compu-
tadora.
Informalmente se puede definir a un sistema operativo como el conjunto de programas
que tiene la finalidad − entre otras − de gestionar los recursos y coordinar los eventos que
toman lugar en un computador. También, el sistema operativo proporciona los servicios
necesarios para que los programas (o procesos) puedan hacer uso de los recursos constitu-
tivos del computador.
Se verá a continuación la secuencia de eventos que deben ocurrir para que un programa
como “date” sea ejecutado, lo cual pondrá en evidencia algunas de las funcionalidades del
sistema operativo. Por empezar, cada vez que se escribe un caracter del comando, el te-
clado transmite el código correspondiente al computador, el cual lo recibe a través de una
placa de comunicación. Dicha placa almacena cada caracter en un área reservada de me-
moria − denominada “buffer” − y emite una señal que interrumpe la unidad central de
proceso (CPU) del computador. Se activa en ese momento un programa denominado con-
trolador de terminal el cual devuelve una copia del caracter al terminal para que éste lo
represente en la pantalla (ver figura 1-1).

- Notas en Sistemas Operativos -
date
"listener"
Directorios
Archivos
Controlador
Terminal
Controlador
de Disco
buffer
buffer
dat
Disco
Reloj
dat
Figura 1-1: Ingreso por Teclado del Comando date
Cuando se recibe el código de la tecla <Enter>, que significa que se ha terminado de es-
cribir el comando, el controlador de terminal activa otro programa, denominado oyente o
“listener”. Dicho programa lee los caracteres d a t e almacenados en la memoria interme-
dia del teclado, y busca dicho programa en disco. Para ello accede a una especie de guía
telefónica − denominada directorio − que se encuentra también almacenado en disco, ha-
ciendo para ello uso del programa controlador de disco quien accede al directorio y lo
almacena en una memoria temporaria (figura 1-2).
date
"listener"
Directorios
Archivos
Controlador
Terminal
Controlador
de Disco
buffer
buffer
Disco
Reloj
Directorio
Figura 1-2: Acceso al Directorio en Disco
A través del directorio, se encuentra la ubicación del comando date en disco y por lo tanto
el programa “listener” instruye al administrador de archivos para que se cargue en memo-
ria el código binario del programa. Para tal fin el administrador de archivos vuelve a utili-
zar el controlador de disco (ver figura 1-3).

date
"listener"
Directorios
Archivos
Controlador
Terminal
Controlador
de Disco
buffer
buffer
Disco
Reloj
date
Figura 1-3: Carga del Programa date en Memoria Primaria
A continuación, el programa “listener” activa el comando date, el cual lee el contenido del
reloj. Este dispositivo está formado por un conjunto de circuitos electrónicos que man-
tiene una cuenta de los milisegundos que han transcurrido desde alguna fecha inicial pre-
fijada, por ejemplo 1 de Enero de 1980. Con esta cuenta el programa date calcula la fecha
actual y la envía para su visualización a la pantalla del terminal como muestra la figura 1-
4.
date
"listener"
Directorios
Archivos
Controlador
Terminal
Controlador
de Disco
buffer
buffer
Disco
Reloj
14/09/199714-9-97
Figura 1-4: Visualización de la Fecha en Pantalla
En realidad, cada uno de estos eventos involucra una mayor cantidad de acciones. Por
ejemplo, para ubicar el directorio o el archivo date (y puesto que el disco está organizado
en pistas concéntricas y éstas en sectores), deben ejecutarse instrucciones que sitúen al
cabezal sobre la pista apropiada y que lean los datos binarios cuando el sector seleccio-
nado pase por debajo del mismo. Los caracteres leídos se almacenan temporariamente en
un buffer de I/O desde donde el programa de gestión de directorio o archivo los procesará.
Más aún, esta secuencia de eventos descripta es mucho más compleja, si se considera que
el computador trabaja con un conjunto de programas en forma simultánea. De esta ma-

nera, un programa puede suspenderse temporalmente mientras el procesador central
atiende a otro. Dicho programa suspendido debe reanudar su ejecución − luego de un
cierto tiempo − en el punto exacto donde quedó bloqueado.
De este simple ejemplo se desprende que el sistema operativo interactúa con todos los
elementos que posee un computador. En efecto, algunas porciones del sistema operativo
interactúan directamente con los circuitos electrónicos y dispositivos magnéticos que
constituyen el hardware, donde las velocidades a las que se realizan las acciones (conmu-
tación de compuertas, activación de “buses”, etc.) son de miles de millones de veces por
segundo. En el otro extremo, el sistema operativo se comunica con el usuario, que envía
comandos a una velocidad infinitamente menor, posiblemente uno cada varios segundos.
1.2 EVOLUCIÓN DE LOS SISTEMAS OPERATIVOS
Los sistemas operativos se crearon para sistemas de computación que comenzaron a apa-
recer a finales de la década del ‘40. Estaban formados por simples rutinas para entrada y
salida, tales como programas para almacenar códigos binarios leídos de una cinta perfo-
rada en posiciones consecutivas de memoria. El sistema operativo completo solo poseía
algunos centenares de instrucciones de máquina. Ejemplo de estos sistemas operativos
primitivos es el EDSAC creado en la Universidad de Cambridge.
A mitad de la década del cincuenta, la mayoría de los computadores trabajaban en moda-
lidad “batch”. En estos computadores, el sistema operativo se limitaba a recoger los pro-
gramas enviados por los múltiples usuarios y los ejecutaba en secuencia, eliminando así
los retrasos que se producían al cargar los programas uno a uno. Además de su función
primaria de carga de programas, el sistema operativo administraba los dispositivos de al-
macenamiento secundario (disco, cintas, etc.), asignaba memoria primaria y realizaba las
entradas y salidas correspondientes. En la mayoría de los casos, poseían también una bi-
blioteca de rutinas − las más frecuentemente utilizadas − a las cuales podían acceder los
programas para su uso.
Los primeros sistemas de tiempo compartido (“time sharing”) fueron diseñado en la dé-
cada del ‘60. En esta modalidad de operación la atención del procesador central conmuta
rápidamente entre los diferentes programas de los usuarios, brindado la sensación de que
se ejecutan simultáneamente. Al construir tales sistemas, se deben resolver los problemas
que se derivan de compartir el procesador, la memoria y los demás recursos físicos y lógi-
cos. La resolución de dichos problemas dio lugar a un número importante de avances con-
ceptuales, entre ellos la sincronización de procesos paralelos, la memoria virtual, la en-
trada y salida independientes del dispositivo, etc.

En la misma medida que se fueron diseñando sistemas operativos más complejos, fueron
creciendo sus tamaños. El sistema operativo CTSS (“Compatible Time Sharing System”)
que se desarrolló en el MIT y se puso en funcionamiento en el año 1.963, constaba de
32.000 palabras de 36 bits. El OS/360, introducido un año más tarde por IBM, poseía más
de un millón de instrucciones de máquina. En el ´75, el Multics (MIT - Bell Labs) poseía
más de 20 millones de instrucciones. La figura 1-5 muestra la evolución de los sistemas
operativos hasta 1985. La misma sugiere una tendencia al crecimiento exponencial de su
tamaño.
1940 1950 1960 1970 1980 1990
1000
10.000
100.000
1.000.000
10.000.000
.
.
.
. . .
.
.
.
.
.
.
. .
.
.
.
EDSAC
Atlas
CTSS
THE
RC4000
Unix(1)
Unix(7.5)
MS-DOS
CP/M
Unix BSD
SCOPE
OS/360 (1)
OS/360 (21)
Multics(Nucleo+Util.)
MVS
VMS
Multics(Núcleo)
Figura 1-5: Evolución de los Sistemas Operativos (Tamaño vs. Año)
Hacia fines de la década del ’80 comenzaron a aparecer sistemas operativos como MACH,
IBM AIX, MS-Windows NT, IBM OS/400, con núcleos superando ampliamente el millón
de Bytes. Estos sistemas operativos − creados para administrar computadores de rango
medio a alto − fueron acompañados por la creación de sistemas operativos para computa-
doras personales1
, que también poseen núcleo de tamaño considerable.
Normalmente el tamaño y la complejidad de los sistemas operativos van asociados a nue-
vas arquitecturas de organización de computadoras. Por ejemplo, la popularización del
multiprocesamiento simétrico − varios procesadores trabajando en paralelo − llevó a la
inclusión de soporte para dicho hardware en los sistemas operativos actuales. Se avanzó
1
Como IBM OS/2, MS-Windows 95, MS-Windows NT Workstation y otros.

también en los sistemas distribuidos, los cuales tienden a reemplazar computador de gran-
des capacidades (“mainframes”) por sistemas interconectados a través de redes de comu-
nicación de alta velocidad. En tales redes de procesamiento distribuido, es responsabilidad
del sistema operativo la coordinación de las acciones entre los diversos computadores
interconectados.
La evolución de los sistemas operativos
aún no ha terminado. Los usuarios continuamente plantean la necesidad de nuevos servi-
cios. Por ejemplo la explosión que tuvo Internet en estos últimos años, requieren de cam-
bios y adaptaciones de los sistemas operativos actuales para ofrecer mayor capacidad de
conectividad, de manejar información distribuida, de aumentar los niveles de seguridad.
1.3 LIMITACIONES DEL HARDWARE
Antes de avanzar con la definición y tipos de sistemas operativos, se introducirán algunos
conceptos básicos de arquitectura de hardware de computadoras.
1.3.1 Modelo de von Neumann
La mayoría de las computadoras actuales implementan el modelo de von Neumann, el
cual se muestra esquemáticamente en la Fig. 1-7
CPU
Memoria
Primaria
Subsistema
de
Comunicación
Memoria
Secundaria
Figura 1-7: Modelo de von Neumann
El corazón de este modelo está compuesto por la memoria principal o primaria y por el
procesador (CPU). La memoria se utiliza para almacenar el programa que es ejecutado por
el procesador. Se incluyen dos componentes extras para hacer a este modelo un poco más
realista: una unidad de almacenamiento secundario (discos, cintas, etc.) que almacenan
programas y datos en forma permanente (no volátil) y un subsistema de comunicación que

permite la interacción entre el usuario y la máquina. Por lo general se referencia al alma-
cenamiento secundario y al subsistema de comunicación como el subsistema de en-
trada/salida (I/O).
1.3.2 Procesadores, Memorias y Dispositivos de I/O
Para cada uno de los componentes del modelo de von Neumann existe una gran diversidad
de elementos, los cuales dependen de la función que se pretende obtener del sistema en su
totalidad. Se describirán someramente dichos componentes.
• CPU: la componente más rápida de una computadora. Su velocidad se especifica
en ciclos de CPU (decenas o milésimas de µseg). El número real de operaciones
que realiza por segundo, depende de la rapidez con que son transferidos los ope-
randos de las instrucciones desde y hacia la memoria principal2
.
• Memoria Principal: también su velocidad se mide en ciclos de memoria (los
cuales varían de 0.05 a 1 µseg). Cuando se compara con la velocidad de CPU, la
memoria es un orden de magnitud más lenta por lo que se necesitan elementos de
hardware (registros rápidos, caches, etc.) para que la memoria pueda responder
rápidamente las acciones ordenadas por el procesador.
• Almacenamiento secundario: los dispositivos de almacenamiento secundarios
más comunes son los discos magnéticos (discos flexibles y fijos). Algunas pro-
piedades importantes de estos dispositivos son:
 Capacidad: usualmente medida en Mega o Giga Bytes.
 Tamaño del registro: mínimo conjunto de bytes contiguos que pueden
ser direccionados.
 Método de acceso: puede ser directo (o aleatorio) o secuencial.
 Razón de transferencia de datos: velocidad a que se transfieren los da-
tos (palabras) desde memoria principal al dispositivo y viceversa. Se ex-
presa en MBytes por segundo.
 Latencia: (solo para discos) tiempo en que la cabeza de un disco está
posicionada justo sobre el registro o sector que se debe leer o escribir.
 Tiempo de Búsqueda (“seek time”): tiempo de movimiento de la cabeza
para que se posicione en el lugar apropiado para la lectura/escritura.
2
Existen otras formas de especificar la CPU, de acuerdo a su rendimiento o performance. Un
parámetro típico suele ser MIPS (Mega Instruction Per Second).

• Dispositivos de comunicación: los tipos más comunes de dispositivos de co-
municaciones con entrada/salida al sistema son los terminales, que están
compuestos de una pantalla y un teclado. Los terminales de salida solamente
más utilizados son las impresoras, que producen resultados legibles en papel.
Para la transferencia de gran cantidad de datos entre computadoras no interconectadas se
utilizan discos removibles o cintas magnéticas. Por lo tanto una unidad de cinta o un disco
puede ser considerado como un dispositivo de almacenamiento o bien como un disposi-
tivo de entrada/salida, de acuerdo al uso que se le brinde.
1.3.2.1 Modos de Ejecución de Procesadores
La mayoría de los procesadores actuales soportan por lo menos dos modos de ejecución:
modo usuario y modo privilegiado o kernel. En el modo usuario, se incluye solo un sub-
conjunto de instrucciones del conjunto completo que ofrece el procesador. Por ejemplo las
instrucciones que permiten alterar un registro de control, o acceder a ciertas porciones de
memoria, no están permitidas en este modo de ejecución. En el modo privilegiado, por el
contrario, está permitido el uso completo del conjunto de instrucciones del procesador.
El uso de estos modos de operación de los procesadores, debería quedar claro luego de
analizar la estructura interna de los sistemas operativos. Brevemente se podría decir, que
esta doble modalidad permite proteger al sistema operativo − y las distintas tablas que el
mantiene − de posibles interferencias provocadas por los programas de los usuarios.
Los procesadores de la familia Intel 80386 (y superiores) proveen cuatro modos de opera-
ción en lugar de los dos mencionados. Estos modos se denominan anillos o “rings”. El
“ring” 0 constituye es modo más privilegiado, mientras que el 3 el menos privilegiado. El
sistema operativo MS Windows NT y MS Windows 95 utilizan solamente el anillo 0 y 3,
mientras que el IBM OS/2 utiliza los anillos 0, 2 y 3, dejando solamente el anillo 1 sin
usar.
1.3.3 La Interface Procesador/Dispositivo
En una computadora existen diversas formas en que interactúan los dispositivos de en-
trada/salida con el procesador central. Ellos son:
1.3.3.1 I/O Programada
En el caso más simple, cada dispositivo está equipado con un controlador conectado di-
rectamente a la CPU a través del bus de datos y de direcciones (ver figura 1-8).

La CPU utiliza el bus de direcciones para seleccionar un dispositivo de I/O particular;
mientras que el bus de datos transfiere datos entre la CPU y el dispositivo (y viceversa).
Los controladores son dispositivos necesarios para transformar los comandos ejecutados
por la CPU en señales eléctricas que realizan la acción requerida. El controlador posee un
registro de “status” donde almacena el estado en que se encuentra el dispositivo. Por
ejemplo, si el dispositivo es un disco y el mismo está leyendo un determinado sector, el
registro de “status” notificará que el dispositivo esta ocupado (“busy”) en una operación
de lectura. Generalmente el controlador también posee un buffer capaz de mantener re-
gistros de datos leídos o enviados al dispositivo.
Disco
CPU
Controlador Controlador
Bus Datos
Bus Direcciones
Subsistema de I/O
Memoria
Primaria
Usuario
Figura 1-8: Esquema Básico de una Computadora
En este esquema básico, la memoria primaria, se encuentra conectada directamente a los
buses de datos y direcciones. En realidad, en las computadoras actuales, existe un bus es-
pecífico para el acceso de la CPU a la memoria.
En las interfaces de I/O programada, la CPU es responsable de la totalidad de la transfe-
rencia de datos desde y hacia los dispositivos y memoria. En el caso de salida de datos, la
CPU copia un registro desde la memoria al buffer del controlador, quien informa al dispo-
sitivo que hay datos disponibles para mostrar. Cuando el dispositivo completa la opera-
ción informa a la CPU (explícita o implícitamente). A continuación la CPU copia los re-
gistros siguientes y así sucesivamente hasta que se completa la salida de datos3
.Para el
ingreso de datos desde el dispositivo hacia el sistema se sigue un protocolo similar.
La figura 1-9 muestra un diagrama temporal en la interacción CPU/Dispositivo para el
caso de I/O programada. En esta figura, las líneas horizontales representan el tiempo en el
3
Este protocolo se denomina informalmente “handshaking”.

que la CPU o el dispositivo están ocupados y las flechas verticales indican los puntos de
interacción entre ambos. La línea horizontal remarcada en la porción de la CPU corres-
ponde a la rutina de I/O (código que copia un registro de datos desde o hacia el buffer del
dispositivo e inicia la operación del mismo).
CPU
Dispositivo
Rutina I/O Rutina I/O
CPU
Dispositivo
test test test test test testrestart restart
(a)
(b)
Figura 1-9: Interacción CPU/Dispositivo: (a) I/O Programada con Espera
(b) I/O Programa con “Polling”
El esquema de I/O programada es el más simple y económico de los métodos de comuni-
cación con los dispositivos externos. Pero también es el más ineficiente en cuanto a utili-
zación de los recursos. Eso se debe principalmente a la diferencia de velocidad entre la
CPU y el resto de los dispositivos de I/O (varios órdenes de magnitud). Por ejemplo el
tiempo de búsqueda promedio de un disco rígido es del orden de los mseg, mientras que
un ciclo de CPU del orden de las centésimas de µseg. Es decir mientras el disco está bus-
cando el registro solicitado por la CPU, la misma está desocupada durante millones de
ciclos.
Una forma de optimizar este método de acceso es realizar operaciones con la CPU en
forma simultánea o concurrente a la de los dispositivos de I/O. La CPU puede simple-
mente iniciar la tarea de búsqueda de un registro en disco (o un carácter en un terminal) y
luego continuar con su tarea – como por ejemplo el cómputo de un cierto cálculo aritmé-
tico.
El problema que se presenta en este caso, es como determinar la finalización de la opera-
ción de I/O. Esta condición normalmente está disponible a través de un “flag” en el con-
trolador del dispositivo. Obviamente la forma más simple − e ineficiente − sería chequear
continuamente el “flag” hasta que se active. Una forma más eficiente sería realizando una

consulta periódica −“polling” − chequeando periódicamente la terminación de la tarea del
dispositivo (ver figura 1-9 (b)). El inconveniente de este método es determinar la frecuen-
cia de la consulta. En efecto, si la frecuencia es muy alta, se pierden ciclos de CPU, mien-
tras que si es muy baja, el dispositivo puede estar desocupado por mucho tiempo hasta que
la CPU detecte su estado, llevando a una baja utilización del mismo.
1.3.3.2 Interrupciones
El método más eficiente de chequear el citado “flag” es con el uso de interrupciones. En
este caso es necesario proveer un mecanismo de hardware para chequear el estado de cada
dispositivo en cada instrucción de la CPU. Si el “flag” está activado, la CPU interrumpe
lo que estaba haciendo y pasa a atender al dispositivo (mediante una rutina conocida como
“interrupt handler”). Cuando se finaliza con la atención del dispositivo, la CPU continúa
con lo que estaba ejecutando en el momento en que fue interrumpida (ver figura 1-10).
CPU
Dispositivo
Interrupción restart restartInterrupción Interrupción
Figura 1-10: Interacción CPU/Dispositivo mediante interrupción
En las computadoras, se provee hardware adicional para distinguir entre distintos tipos de
interrupciones. Dependiendo del tipo de interrupción, el control es transferido a las dis-
tintas rutinas de manejo de interrupciones. Por otra parte, las interrupciones normalmente
tienen asociadas una prioridad, de tal manera que cuando se está ejecutando una cierta
rutina de interrupción, el hardware automáticamente inhibe todas las interrupciones de
igual o menor prioridad. Este esquema − denominado de prioridades múltiples − permite
optimizar la utilización de los recursos.
Generalmente se presentan cuatro clases de interrupciones:
• Interrupciones de programa: generadas por alguna condición que ocurre como
resultado de la ejecución de una instrucción, tal como un “overflow”, división
por cero, intento de ejecutar una instrucción ilegal, intento de ingresar a una zona
de memoria no permitida, etc.
• Interrupciones de “Timer”: generadas automáticamente cada n ciclos del reloj
por el hardware de la computadora. Esto permite al sistema operativo realizar
ciertas acciones en forma periódica, como por ejemplo la actualización de ciertas
estructuras de datos y tablas que el mantiene.

• Interrupciones de I/O: generadas por un controlador de I/O, para señalizar la fi-
nalización de una operación o alguna condición de error.
• Interrupciones de Fallas de Hardware: generadas por una anomalía en algún
dispositivo físico, tal como un error de paridad en la memoria.
1.3.3.3 Acceso Directo a Memoria (DMA).
Cuando se utiliza un esquema de I/O programada o de notificación por intermedio de inte-
rrupción, la CPU dirige la transferencia de datos entre la memoria principal y los buffers
de los dispositivos. Esto es aceptable con dispositivos lentos, como terminales o impreso-
ras, en donde la CPU puede realizar millones de instrucciones hasta que se complete la
transferencia de un caracter. Sin embargo en dispositivos rápidos, como por ejemplo un
disco, la sobrecarga de la CPU en la transferencia de estos datos puede significar una gran
cantidad de ciclos de la misma. Para alivianar al procesador de esta tarea, se puede pro-
veer al sistema con hardware adicional para que la transferencia de datos entre el disposi-
tivo y la memoria sea realizada en forma directa, es decir, sin intervención de la CPU.
Este concepto se denomina acceso directo a memoria o DMA. Con el empleo de DMA, la
CPU solo ordena al dispositivo el comienzo de la transferencia de datos, mientras que la
transferencia propiamente dicha es realizada por el controlador de DMA. Normalmente la
CPU envía un comando al controlador de DMA con los siguientes parámetros:
• Tipo de operación a realizar (lectura o escritura).
• Dirección del dispositivo de I/O.
• Dirección origen en memoria desde donde se debe leer o escribir.
• Número de palabras que se deben leer o escribir.
El procesador luego de enviado el pedido (“request”) continúa procesando, delegando
toda la operación de I/O al módulo de DMA. El mismo transfiere el bloque de datos − una
palabra de por vez − directamente desde o hacia la memoria. Cuando la transferencia se
completa, el módulo de DMA genera una interrupción notificando al procesador la con-
clusión de la operación.
El módulo de DMA necesita tomar control del “bus” para la transferencia de datos. De-
bido a esta competencia por el uso del “bus”, existen instantes en que la CPU necesita el
mismo y debe esperar. El efecto que esto causa en el sistema en forma global, es de una
disminución de la velocidad de ejecución de la CPU durante la transferencia del controla-
dor de DMA. De todas maneras, este método es más eficiente que los otros mencionados.

1.4 PRINCIPIO DE MULTIPROGRAMAS
Con la introducción de interrupciones y controladores de DMA se ha provisto al sistema
con mecanismos que permiten a la CPU y a los dispositivos de entrada/salida estar ope-
rando simultáneamente en una forma eficiente. Sin embargo, un único programa rara-
mente explotará este potencial del hardware. Un programa típico tiene una fase de entrada
de datos, una fase de cómputo y una fase de salida de los resultados computados. Si se
considera por ejemplo un programa que ordena alfabéticamente una lista de alumnos −
“sort” interno − la fase de entrada consistirá en leer los datos (archivos) del disco y po-
nerlos en memoria. En esta primera fase, la CPU estará la mayor parte del tiempo desocu-
pada, mientras que el disco trabajará en forma intensa. Se dice que el sistema está limitado
por I/O (“I/O-bound”). La segunda fase consiste en ordenar los datos que se encuentran
en memoria. Por lo tanto en esta fase, la CPU estará muy ocupada, mientras que el disco
estará libre y se dice que el sistema está limitado por la computación de la CPU (“CPU-
bound”). Finalmente, en la fase de salida de datos, se tiene de nuevo al sistema limitado
por I/O. Se observa que en un sistema con un único programa no se utilizan los recursos
apropiadamente, ya que no aparece la necesidad de la concurrencia de operaciones entre
CPU e I/O.
Sin embargo, si más de un programa estuviese activo, la ocupación de los recursos del
sistema aumentaría como así también el “throughput” 4
global del sistema. Esto lleva al
concepto de multiprogramación, es decir mantener más de un programa independiente en
memoria en forma simultánea. Lo ideal sería superponer un programa limitado en I/O
(modificación de un archivo grande) con un programa limitado en CPU (resolución de un
sistema de ecuaciones diferenciales); de esta forma mientras el primer programa espera
por el I/O, el segundo utiliza plenamente la CPU. La figura 1-11 muestra los diagramas de
tiempo (Gantt) para este ejemplo en un sistema con monoprogramas (a) y con multipro-
gramas (b). Se observa como en un sistema multiprogramada, aumenta el uso de los dis-
positivos como así también el “throughput” del sistema.
Por supuesto que las ventajas de estos sistemas se consiguen teniendo que pagar un cierto
precio. Primero, se debe dotar a la computadora de un hardware apropiado para manejar
más de un programa en forma simultánea. Esto incluye por ejemplo controladores de
DMA, mecanismos de prioridad de interrupciones, etc. Segundo, el sistema operativo se
complica en gran medida ya que debe ocultar a los usuarios el hecho que los recursos del
sistema son compartidos, es decir cada usuario debe tener la ilusión de que posee el sis-
tema enteramente para él mismo. Sin embargo, dicha complejidad es más que justificada
con los beneficios que se obtienen, de allí que la mayoría de los sistemas operativos ac-
4
En este contexto, el “througput” representa el número de programas o procesos finalizados por
unidad de tiempo.

tuales implementan este esquema de multiprogramación o multitarea (como es llamado
más habitualmente).
Programa A Programa B
CPU
I/O
Programa A
Programa B
CPU
CPU
I/O
I/O
A
A
B
B
(a)
(b)
Figura 1-11: Comparación de (a) Monoprogramación
con (b) Multiprogramación
1.5 DEFINICIÓN DE SISTEMA OPERATIVO
No existe una definición general de sistema operativo. Los sistemas operativos existen
porque constituyen un elemento sin el cual no se podría utilizar una computadora. Una
posible definición sería considerar al sistema operativo como un programa de sistema que
está siempre ejecutando en la computadora (kernel) y con programas de aplicación que
corren sobre él, requiriendo de sus servicios.
Posiblemente sea más simple definir el sistema operativo por sus funcionalidades que por
lo que realmente es. El objetivo primario del sistema operativo es establecer un caparazón
al usuario entre el hardware y su entorno de trabajo, de tal forma que dicho entorno sea
amigable y simple de utilizar. En ese sentido, se puede modelar al sistema operativo y el

hardware sobre el que se asienta como un conjunto de capas jerárquicas, cada una de ellas
separada por las funciones que realiza. La tabla 1-1 muestra una posible organización.
Cada nivel gestiona un conjunto de objetos − circuitos electrónicos, estructuras de datos o
procesos − cuya naturaleza varía considerablemente de un nivel a otro. También cada ni-
vel define las operaciones que pueden realizarse sobre dichos objetos. Un nivel N hace
uso de las funciones y servicios implementados en el nivel inferior (N-1), ocultando todos
los detalles internos de sus operaciones a los niveles superiores5
.
Nivel Nombre Objetos Ejemplo de Operaciones
13 Shell Entorno de programación del
usuario
Comandos
12 Procesos de
Usuarios
Procesos de Usuario Abandonar, borrar, sus-
pender, reanudar
11 Directorios Directorios Crear, destruir, asignar,
buscar, listar
10 Dispositivos Dispositivos externos, panta-
llas, teclados, impresoras, ...
Crear, destruir, abrir, ce-
rrar, leer, escribir.
9 Sistema de Ar-
chivos
Archivos Crear, destruir, abrir, ce-
8 Comunicaciones Tuberías o “pipes” Crear, destruir, abrir, ce-
7 Memoria Virtual Segmentos y páginas de memo-
ria
Leer, escribir, extraer.
6 Memoria Se-
cundaria
Bloques de datos, canales peri-
féricos
Leer, escribir, asignar,
liberar.
5 Procesos Primi-
tivos
Procesos primitivos, semáfo-
ros.
Esperar, señalar, suspen-
der, reanudar.
4 Interrupciones Programas de manejo de erro-
res, de atención de dispositivos,
etc.
Llamar, enmascarar, con-
tinuar
3 Procedimientos Segmentos de procedimiento,
Stack
Señalar la pila, llamar,
devolver.
2 Instrucciones Interprete de microprogramas,
datos.
Cargar, almacenar, sumar,
restar
1 Circuitos Elec-
trónicos
Registros, compuertas, “buses” Limpiar, transferir, activar
Tabla 1-1: Modelo Jerárquico de Sistema Operativo
5
Esto se conoce con el nombre de ocultamiento de la información.

Una segunda funcionalidad de los sistemas operativos es la administración eficiente de los
recursos que posee la computadora. Esta función es particularmente importante en siste-
mas multiusuarios, donde los recursos son escasos y de altos costos. En este sentido el
sistema operativo debe evaluar periódicamente el estado general del sistema y cambiar la
asignación de recursos − si es conveniente − con el objeto de maximizar la utilización de
los mismos.
Otra función que cumplen los sistemas operativos del tipo multiprogramados y multiusua-
rios es el establecimiento de una política de protección y seguridad. En efecto, debido a
que el sistema es compartido por más de un usuario, se deben proteger los programas y
archivos de daños intencionales y no intencionales.
También los sistemas operativos deben proveer facilidades de comunicación y sincroniza-
ción. En un sistema de multiprogramas, más de un programa puede competir por un
mismo recurso (por ejemplo un archivo), que necesita leer o modificar. El sistema opera-
tivo debe arbitrar esta operación de tal forma que sea realizada en forma congruente (sin-
cronización). Así también un programa puede necesitar servicios de otros programas que
se están ejecutando en forma concurrente; el sistema operativo debe proveer funciones o
primitivas para permitir tal cooperación en forma ordenada (comunicación entre proce-
sos).
1.6 TIPOS DE SISTEMAS OPERATIVOS
La cantidad de sistemas operativos diseñados y que continúan implementándose hoy en
día es altísima. Una posible clasificación de los sistemas operativos sería de acuerdo a:
1. La arquitectura del hardware que administra.
2. El nivel de compartimiento de recursos.
3. Los tipos de interacción permitidos.
1.6.1 Clasificación de Acuerdo a la Arquitectura del Hardware
Se pueden distinguir los siguientes tipos:
• Sistemas operativos para Microcomputadores: típicamente la CPU de una mi-
crocomputadora consiste de un único procesador el cual está conectado al resto
del hardware a través de “buses”. Por lo general los microcomputadores son ele-
mentos de bajo costo, lo cual implica un número limitado de dispositivos perifé-
ricos: uno o dos discos, un monitor, un teclado y una impresora. En concordancia

con el bajo costo del hardware, el sistema operativo realiza funciones básicas.
Las mismas están restringidas a inicializar el sistema (“boot”), proveer rutinas de
entrada/salida para permitir a los programas transferir datos entre memoria y los
dispositivos de I/O y administrar los recursos de hardware. En los casos en que
estos microcomputadores se comportan como estaciones de trabajo (“worksta-
tion”) dentro de una red, el sistema operativo provee rutinas para la comunica-
ción con la computadora principal (“host”). Ejemplos de sistemas operativos de
este tipo serían el MS-DOS, MS Windows ‘95, IBM OS/2.
• Sistemas operativos para Minicomputadores: hasta hace unos años los minicom-
putadores eran los microcomputadores de hoy en día. En la actualidad los mini-
computadores están dotados de CPU (en algunos casos más de una, modalidad
que se conoce como multiprocesamiento simétrico) con capacidad de direccio-
namiento de 64 bits, memorias del tipo cache, subsistemas de discos especiales,
etc. Los sistemas operativos son diseñados entonces principalmente para una efi-
ciente utilización de recursos. En general realizan la mayoría de las funciones de
los sistemas de multitarea de tiempo compartido. Ejemplos de este tipo de sis-
tema operativo serían MS Windows NT, UNIX, etc.
• Sistemas Operativos para Mainframes: el término “mainframe” fue introducido
al final de la década del '70 para denotar grandes sistemas de computadoras de
propósitos generales. Estos sistemas están diseñados para soportar gran cantidad
de usuarios trabajando en forma interactiva, como así también procesos por lotes
(“batch”) y al mismo tiempo ofrecer a cada usuario un amplio espectro de servi-
cios y facilidades. Por lo general están compuestos por varios CPU’s, gran can-
tidad de memoria principal y subsistemas independientes para la atención de pe-
riféricos de almacenamiento secundario, para manejo de comunicaciones, etc. El
sistema operativo, por su parte, tiene que cumplir globalmente con las mismas
especificaciones que en el caso anterior; la única diferencia es la complejidad
asociada al hardware que debe administrar. Un ejemplo de sistema operativo para
mainframe lo constituye IBM MVS.
1.6.2 Clasificación de Acuerdo al Nivel de Compartimiento de
Recursos
• Sistemas operativos de monoprograma: en este caso el sistema permite que solo
un programa esté activo en cualquier instante de tiempo. Es decir, una vez que el
programa se cargó en memoria, permanece allí hasta que finaliza. En algunos
sistemas más complejos, el sistema operativo utiliza una técnica denominada

“swapping” para utilizar los recursos de una manera más eficiente. Con esta téc-
nica, se mantiene un programa activo en memoria principal y varios programas
también activos − pero sin utilizar los ciclos de CPU − en memoria secundaria
(disco). Cuando el programa que se está ejecutando necesita esperar, por ejemplo
en un acceso a disco, el mismo se aloja temporalmente en memoria secundaria y
uno de los programas que se encontraba en disco es cargado en memoria princi-
pal para a ser ejecutado. Estos sistemas operativos pueden ser considerados en el
límite entre sistemas de monoprogramas y multiprogramas. Vale la pena desta-
car, que con la disminución del costo del hardware, estos sistemas operativos es-
tán desapareciendo en la actualidad. Ejemplos típicos de sistemas operativos de
monoprograma, son los utilizados en microcomputadores como MS-DOS.
• Sistemas operativos de multiprogramas o multitareas: aparecen para mejorar la
utilización de los recursos disponibles. En estos sistemas, se mantiene más de un
programa activo en memoria principal, permitiendo el compartimiento del
tiempo de CPU, memoria principal y en general de todos los recursos comparti-
bles del hardware entre los programas activos. Un ejemplo de este tipo de sis-
tema operativo lo constituyen UNIX y MS Windows NT. Aunque históricamente
los sistemas operativos de multitarea fueron asociados a sistemas compartidos
por más de un usuario, en la actualidad, se poseen sistemas operativos de este
tipo aún en sistemas monousuarios, como por ejemplo MS Windows ‘95 o IBM
OS/2.
1.6.3 Clasificación de Acuerdo al Tipo de Interacción Permitida
• Sistemas Operativos para Procesamiento por Lotes (“batch”): en este caso, los
programas o tareas, son entregados al sistema en lotes secuenciales a los disposi-
tivos de entrada y no existe interacción entre los usuarios y sus programas du-
rante el procesamiento. El usuario está completamente aislado de la ejecución del
programa y por ende, el tiempo de respuesta − denominado tiempo de
“turnaround” − está definido como el tiempo que demora el programa en ejecu-
tarse desde que ingresó al sistema hasta que produce sus salidas. El procesa-
miento por “batch” puede ser realizado en sistemas de mono o multiprogramas.
• Sistemas Operativos Interactivos: en este caso se permite una interacción entre
los usuarios y las computaciones respectivas.
• Sistemas Operativos de Tiempo Real: muchas aplicaciones necesitan atender
procesos externos dentro de intervalos de tiempo muy precisos. Normalmente

estos procesos solicitan su atención mediante interrupciones, las cuales si no son
atendidas en un tiempo limitado − el cual variará de acuerdo al proceso − puede
causar efectos catastróficos. En estos casos, el sistema operativo debe estar capa-
citado para responder a estas interrupciones en un tiempo no determinístico.
Algunos sistemas operativos poseen todos estos tipos de interacción; por lo general, lo
más común es que posea procesamiento por lotes e interactivo. Por ejemplo, UNIX − sis-
tema de naturaleza interactiva por excelencia − permiten el procesamiento por lotes.
1.7 ESTRUCTURA DE LOS SISTEMAS OPERATIVOS
El sistema operativo debe ser visto como el administrador de un amplia gama de recursos
de software y de hardware, ocultando al hardware al usuario, ofreciendo de esta manera
una máquina virtual totalmente diferente de la que realmente es. Ya que el sistema opera-
tivo es una colección grande y compleja de rutinas de software, los diseñadores deben
poner gran énfasis en su organización o arquitectura interna. En ese sentido se pueden
considerar − entre otras − las siguientes estructuras internas de sistemas operativos:
1. Estructura monolítica.
2. Estructura de kernel.
3. Estructura de capas.
4. Estructura de microkernel.
5. Estructura orientada a objetos.
1.7.1 Estructura Monolítica
La estructura de estos sistemas operativos está caracterizada porque no existe tal estruc-
tura. Es decir el sistema operativo está compuesto por una colección de programas que se
ejecutan sobre el hardware. En tales sistemas operativos, los módulos que proveen dife-
rentes servicios, tales como administración del procesador, de memoria, de dispositivos de
I/O, pueden ser perfectamente distinguidos. Sin embargo, la ejecución de cada uno de
estos módulos resulta en un único proceso que se ejecuta y que interactúa con los otros
módulos llamándolos en forma de procedimientos. Incluso los programas de los usuarios
pueden ser vistos como subrutinas que el sistema operativo invoca cuando no está reali-
zando algunas de las funciones citadas arriba.
Cuando el programa del usuario es invocado, continúa su ejecución hasta que ocurre uno
de los siguientes eventos:

1. El programa termina.
2. Una señal de fin de uso de la CPU es generada, señalando que el programa ha
excedido su tiempo máximo asignado en el procesador.
3. El programa solicita alguna acción al sistema operativo, por ejemplo una opera-
ción de I/O.
4. Ocurre una interrupción, indicando que un dispositivo u otro evento requiere la
atención del sistema operativo.
En todos los casos, el control retorna al sistema operativo el cual analiza la causa de su
invocación y luego que realiza las tareas apropiadas, invoca otro proceso de usuario. El
concepto básico de sistema operativo monolítico se muestra en la figura 1-12, donde
p1,..., pn, son los programas de los distintos usuarios del sistema y HW representa el
hardware de la computadora.
Sistema Operativo
Programas de Usuarios
. . .
HW
Return Return
P1 P2
1. 2.
3. 4.
1. 2.
3. 4.
Interrupción
Figura 1-12: Sistema Operativo con Estructura Monolítica
La estructura monolítica se encuentra en los primeros sistemas operativos desarrollados.
Un ejemplo típico de sistema operativo que utiliza esta organización es el sistema opera-
tivo MS-DOS. La estructura básica del mismo se muestra en la figura 1-13.

Se observa en este sistema operativo como los programas de aplicación tienen acceso a las
rutinas básicas de entrada/salida (ROM BIOS) y por ende pueden escribir directamente a
la pantalla, a la memoria o aún al disco. Este exceso de libertad, causa que el sistema más
de una vez deje de funcionar correctamente, teniendo que ser reinicializado.
Programa de Aplicación
Programa Residente Sistema
Drivers de dispositivos
Drivers de Dispositivos "ROM BIOS"
Figura 1-13: Estructura Básica del Sistema Operativo MS-DOS
Debido a diversas funcionalidades que un sistema de cómputos debe ofrecer hoy en día y
a los resultados naturalmente no determinísticos de los eventos simultáneos que se pre-
sentan, los sistemas operativos son cada vez más complejos. Por lo tanto la estructura in-
terna de los mismo juega un rol fundamental en su desarrollo, como así también en sus
modificaciones y mejoras futuras. Debido a esto, la estructura monolítica no es conside-
rada hoy en día como una alternativa para el diseño de sistemas operativos.
1.7.2 Estructura de Kernel
Este tipo de estructura se basa en el diseño de un núcleo o kernel del sistema operativo, el
cual se encarga de las funciones primitivas o de bajo nivel más esenciales. Es decir el ker-
nel, provee un mínimo conjunto de operaciones a partir del cual el resto del sistema ope-
rativo puede ser construido.
Una de las tareas más importantes del kernel es la de ocultar la capa del hardware de tal
forma que cada usuario tenga la ilusión que su programa se está ejecutando en una má-

quina independiente de la de otros usuarios. Es decir el kernel debe crear una máquina
virtual con su propia CPU, espacio de memoria, y demás dispositivos para cada programa
activo dentro del sistema.
Para lograr tal objetivo, los procesos o programas6
de los usuarios deben interactuar con
los del sistema operativo. Esta interacción se hace a través de funciones de comunicación
y sincronización. La figura 1-14 muestra la estructura del sistema operativo basado en
kernel, donde ui representa a los programas de los usuarios y si los programas del sistema
operativo. La línea que une los procesos de los usuarios con los del sistema denota el in-
tercambio de señales de comunicación y sincronización que existe entre ambos tipos de
procesos. Sin embargo el flujo real de información siempre pasa a través del kernel.
Kernel
. . .
HW
Return
Interrupción
Ui Si
Comunicación
Invocación
al kernel
Figura 1-14: Estructura de un Sistema Operativo Basado en Kernel
Un ejemplo típico de arquitectura de kernel lo representa el sistema operativo UNIX7
,
cuyo diagrama en bloques se muestra en la figura 1-15
6
En el módulo siguiente se dará una definición precisa de proceso, denotando la diferencia que existe
con un programa.
7
Algunos sistemas operativos modernos basados en UNIX utilizan arquitectura de microkernel, como
por ejemplo MACH.

De este diagrama se debe destacar que existen dos niveles claramente diferenciados: Nivel
Usuario y Nivel Kernel. En el primero – donde el procesador ejecuta en la modalidad
usuario − se ejecuta la totalidad de los procesos de los usuarios. Cuando uno de tales pro-
cesos necesita acceder a un recurso controlado por el sistema operativo, como por ejemplo
un archivo que reside en disco, se accede a través de una llamada especial al kernel
(“system call”) quien ejecuta en modalidad del procesador privilegiada.
Esta forma de dividir la modalidad de uso del procesador es distintiva de la mayoría de los
sistemas operativos modernos. Con ello se logra obtener una robustez y seguridad integral
que no se conseguiría permitiendo el acceso a los recursos del sistema en forma directa
por parte de los procesos de los usuarios.
Subsistema de Archivos
Buff. Cache
Caracter Bloque
Device Drivers
IPC
Schedule
Adm. Memoria
Subsistema de
Control de
Procesos
Interface de "System Call"
Librerías
Control de Hardware
Hardware
Nivel de Kernel
Nivel de Usuario
Nivel de Hardware
Programas de Usuarios
Figura 1-15: Diagrama Básico del Sistema Operativo UNIX
1.7.3 Estructura de Capas (o de jerarquía de procesos)

La estructura de kernel provee un método mucho más ordenado de organizar el sistema
operativo que la estructura monolítica. Sin embargo divide a los procesos en solo dos ti-
pos: procesos del kernel y procesos de usuarios. Por lo tanto decidir cuales son las funcio-
nes del kernel es muy crítico. Por otra parte, si el kernel es de un tamaño considerable, el
mismo debe ser estructurado de una manera correcta, o de lo contrario podría convertirse
en una estructura monolítica con las desventajas ya mencionadas. Como contrapartida, si
es pequeño, la mayor parte del sistema operativo estará construido fuera de él.
Para evitar la disyuntiva de cuales son las funciones que atañen al kernel, el sistema ope-
rativo puede ser estructurado de acuerdo a una colección de capas jerárquicas. La capa
inferior es generalmente la encargada de crear procesadores virtuales para todos los proce-
sos, tal como lo hace la organización de tipo kernel. La siguiente capa es la encargada de
la administración de memoria. Así se aplican sucesivamente estas abstracciones llegando
finalmente a la capa más alta donde se ejecutan los procesos de los usuarios.
Un ejemplo de sistema operativo que utiliza este tipo de estructura es THE, diseñado por
Dijkstra. La figura 1-16 muestra los niveles jerárquicos para este sistema operativo.
OPERADOR N5: Operador
Usuario 1 Usuario 2 . . . Usuario n
N4: Procesos
independientes
de usuarios
Procesos de
Dispositivos
de Entrada y
Salida
N3: Dispositi-
vos de I/O vir-
tuales
Interpretes de
Mensajes
N2: Consola de
Operadores
Virtuales
Controlador
de Segmen-
tos de Memo-
ria
N1: Memoria
Virtual Seg-
mentada
Planificación
de CPU. Ope-
raciones P y V
N0: Procesado-
res Virtuales
CPU Memoria
Principal y
Secundaria
Consola de
Operadores
Dispositivos
de Entrada /
Salida
Hardware Real
Figura 1-16: Diagrama de un sistema operativo de jerarquía de procesos

Se observa en esta estructura que a medida que se ascienden en los niveles, se tiene un
mayor número de tareas de administración. Así, un proceso en un dado nivel puede asumir
que todas las tareas de administración en niveles inferiores están realizadas y por ende
utilizar los servicios provistos por ellos. Por ejemplo en el sistema operativo THE, el nivel
N0 es el encargado de virtualizar la CPU (además de proveer las primitivas P y V que se
estudiarán más adelante). Por lo tanto los niveles superiores a N0 (N1 a N5) no deben
considerar el número real de procesadores con que consta el sistema. El nivel N1 provee
el proceso de control de memoria primaria y secundaria, por lo que los niveles superiores
al N1, solo trabajan con segmentos de información, sin concernirles si se encuentran en
memoria principal o secundaria. De esta forma se sigue con la abstracción de funciones de
cada nivel, hasta llegar al nivel donde cada usuario tiene a su disposición una máquina
virtual que consta de su procesador, su administrador de memoria, su administrador de
dispositivos de I/O, etc. (El nivel de operador N5 en realidad representa al proceso por el
cual se puede controlar todo el sistema operativo; es decir tal proceso representaría al
proceso del supervisor)8
.
1.7.4 Estructura de Microkernel
Existe una clara tendencia a apartarse de los sistemas operativos monolíticos o de kernel
para adoptar la técnica de utilización de un pequeño kernel. La estructura de kernel y la de
capas, aunque presentan un buen funcionamiento, son consideradas en la actualidad como
estructuras monolíticas porque todo el sistema operativo está vinculado de manera con-
junta en una jerarquía de funciones o capas. El agregado de nuevas funcionalidades o la
modificación de las existentes, requiere un profundo conocimiento del sistema operativo y
una gran cantidad de tiempo y esfuerzo, con una alta probabilidad de aparición de errores
bastante difíciles de encontrar.
El primer sistema operativo que utilizó la estructura de microkernel fue Mach en las com-
putadoras NEXT. En teoría - su pequeño y privilegiado núcleo - rodeado por servicios en
modalidad de usuario, proporcionaba una modularidad y flexibilidad sin precedentes9
.
Luego apareció Windows NT de Microsoft que ofreció no solo modularidad sino también
portabilidad como ventaja adicional que caracterizan a los microkernels10
. Actualmente
Novell/USL, Open Software Foundation (OSF), IBM, Apple - entre otros fabricantes -
8
Esta técnica de estratificación constituye la técnica de modelado denominada “layering”, del cual el
modelo de comunicación de computadoras OSI-ISO es un ejemplo.
9
Sin embargo, el éxito de su estructura fue opacado por el uso del sistema operativo UNIX BSD 4.3,
considerado como cuasi monolítico.
10
NT fue concebido para ejecutarse en sistemas basados en mono y multiprocesadores Intel, Alpha,
Mips. También en su versión 3.5 se portó a plataforma PowerPC. En la versión 4.0 solo está
soportado en plataforma Intel y Alpha.

están anunciando arquitecturas microkernel. Por ejemplo, IBM y OSF han adoptado a
Mach 3.0 para su comercialización11
.
Un microkernel12
implementa las funciones esenciales del núcleo del sistema operativo.
La determinación de cuales son los servicios del sistema no esenciales y que pueden rele-
garse a la periferia es tema de discusión entre los fabricantes de sistemas operativos. En
general, los servicios que tradicionalmente fueron parte integral de un sistema operativo
(sistemas de archivos, interface gráfica, servicios de seguridad, etc.) se están convirtiendo
en módulos periféricos que interactúan con el kernel y entre si. La idea generalizada con-
siste en incluir en el microkernel solo aquellos recursos que imprescindiblemente deben
correrse en modalidad de supervisor y en espacio privilegiado. Esto normalmente signi-
fica codificación dependiente del procesador (incluyendo soporte para multiprocesadores),
algunas funciones de administración de proceso, administración de interrupciones y so-
porte de transferencia de mensajes. Los “drivers” de dispositivos pueden estar incluidos
en el microkernel, fuera del mismo o en algún lugar intermedio.
La estructura de microkernel reemplaza la estratificación vertical de las funciones del sis-
tema operativo por una estratificación horizontal. Los componentes ubicados por encima
del microkernel se comunican directamente entre si, utilizando mensajes que pasan a tra-
vés del microkernel. Este tráfico de mensajes administrado por el microkernel, involucra
la validación y transferencia de los mismos entre los distintos módulos.
Una desventaja del esquema de transferencia de mensajes es que no es tan rápida como las
llamadas de funciones comunes, pero ofrece otras ventajas, como por ejemplo la facilidad
en la implementación de sistemas operativos distribuidos. En efecto cuando un microker-
nel recibe un mensaje de un proceso, puede manejarlo de manera directa o transferir el
mensaje a otro proceso. Debido a que el microkernel no necesita saber si el mensaje pro-
viene de un proceso local o remoto, el esquema de transferencia de mensajes ofrece un
fundamento ordenado para las RPCs (Remote Procedure Call o llamadas a procedimientos
remotos).
Con toda la codificación específica del procesador aislada en el microkernel, las modifi-
caciones necesarias para poder ejecutar un programa en un nuevo procesador son mucho
menores y se agrupan de manera lógica. Con la fragmentación del mercado de procesado-
res, poder ejecutar un sistema operativo en más de un procesador podría resultar un ele-
mento atractivo para que los usuarios aumenten sus inversiones en hardware.
La posibilidad de ampliación es también un objetivo principal en los sistemas operativos
modernos. Si bien el hardware puede quedar obsoleto en pocos años, la vida útil de la ma-
11
Next utiliza Mach 2.5 como la base de NextStep. Las diferencias entre ambos microkernels son
sustanciales.
12
Microkernel no significa necesariamente un sistema pequeño.

yoría de los sistemas operativos se puede medir en décadas. Los fabricantes de sistemas
operativos han aprendido que la ampliación de los mismos puede ser una tarea sumamente
compleja, por lo que ahora construyen sistemas que permiten agregar extensiones de ma-
nera más fácil. El conjunto limitado de interfaces bien-definidas del microkernel hace po-
sible un crecimiento y una evolución ordenados.
Un sistema operativo que implementa en su forma más pura los conceptos de microkernel
es QNX de QNX Software. Su microkernel, en la versión 4.x solo ocupa 12 KB de memo-
ria, pudiendo ser alojado en su totalidad en la memoria cache de la mayoría de los proce-
sadores modernos.
Proc
A
Proc
B
Proc
C
Adm
de
Red
Hardware
IPC
Interfase
Red
Planificador
de
CPURedirector
IRQ
Interrupciones
Red de
Comunicación
Figura 1-17: Diagrama Esquemático del Sistema Operativo QNX
El microkernel de QNX solamente implementa 4 servicios: comunicación entre procesos
(InterProcess Communication o IPC), planificación de procesador (“scheduling”), comu-
nicaciones de red de muy bajo nivel y manejo de interrupciones como se observa en la
figura 1-17 . Existe así mismo, un numero reducido de “system calls”, que permiten el
acceso al microkernel por los procesos de usuarios o los administradores de recursos que
corren en modalidad usuario del procesador.

Las facilidades de mensajes provistas por el microkernel, son implementaciones blo-
queantes de la primitivas Send(), Receive(), y Reply()13
. Todos los servicios del sistema
dentro de QNX son construidos sobre estas primitivas de mensajes.
Un sistema operativo basado en el microkernel de QNX se puede construir agregando un
administrador de procesos. También − para la utilización de almacenamiento secundario −
se debería agregar un sistema de archivos y un administrador de dispositivos. Estos admi-
nistradores corren fuera del espacio del kernel, accediendo a él solo a través de las
“system calls” provistas.
Todos los servicios de QNX, excepto los provistos por el microkernel, son manejados con
procesos estándar de QNX. Un configuración típica de QNX tiene los siguientes procesos
del sistemas:
• Process Manager (Proc): Administrador de procesos
• Filesystem Manager (Fsys): Administrador del Sistema de Archivo
• Device Manager (Dev): Administrador de Dispositivos
• Network Manager (Net): Administrador de Red.
Vale la pena destacar, que las primitivas de planificación de procesos de QNX, cumplen
con las especificaciones POSIX 1003.1b de tiempo real. QNX provee planificación total-
mente “preemptive” a través de manejo de distintos algoritmos de planificación (Round-
robin, FIFO y adaptativo).
1.7.5 Estructura Orientada a Objetos
En lugar de visualizar al sistema operativo como una colección de procesos concurrentes,
se puede tomar una visión más general considerándolo como una colección de objetos. De
esta forma se pueden asociar con objetos a un proceso, una página de memoria, a las pri-
mitivas de sincronización, a los distintos dispositivos de hardware, etc. Las interacciones
entre objetos están determinadas por las capacidades, que pueden ser consideradas como
punteros a los objetos. Estas capacidades también contienen un conjunto de derechos que
definen las operaciones aplicables al objeto.
El kernel es responsable de mantener las definiciones de los tipos de objetos y de contro-
lar los privilegios de acceso a cada objeto. Esto normalmente se realiza permitiendo ac-
ceso directo del kernel al manejo de capacidades. Cuando un proceso desea realizar al-
13
Las primitivas de comunicación entre procesos basadas en mensajes, se estudiarán en detalle en
el módulo 4.

guna operación en otro objeto, debe ejecutar una llamada al kernel, incluyendo la capaci-
dad para tal objeto y la operación a ser realizada. El kernel valida la solicitud y si es co-
rrecta, permite que se realice. La estructura resultante de un sistema operativo orientado a
objetos es una red de objetos conectados por capacidades, como se ilustra en la figura 1-
18.
Kernel
. . .
Return
Oi Oj
Capacidad
Invocación
al kernel
. . .
Figura 1-18: Estructura orientada a objetos
Cada objeto agrupa una abstracción de algún concepto, ocultando la implementación in-
terna de dicho concepto y proveyendo un conjunto de operaciones aplicables al objeto que
implementa. Considérese por ejemplo, un planificador de procesos, cuya función es selec-
cionar procesos y ponerlos en una cola, hasta que puedan utilizar la CPU. En un sistema
operativo orientado a objetos, el planificador puede trabajar con dos tipos de objetos: pro-
cesos y colas. Su función principal es seleccionar procesos de una cola y ubicarlos de
acuerdo a algún algoritmo de planificación en una cola de procesos listos para ser ejecuta-
dos. El planificador puede realizar esta tarea utilizando operaciones de pasaje de mensajes
(primitivas “send” y “receive”), definidas en objetos del tipo cola, que realizan el agre-
gado o quitado del proceso correspondiente en la cola apropiada. Se observa que el plani-
ficador no necesita poseer ningún conocimiento acerca de la representación y funcionali-
dad interna de ninguno de los objetos participantes. Solamente trabaja con objetos proce-
sos y colas, manipulados con las primitivas “send” y “receive”.
Los sistemas operativos basados en objetos, al igual que los de microkernel, también pro-
porcionan bases sólidas para implementar sistemas distribuidos. Puesto que los objetos
son unidades de codificación y datos que se comunican mediante el envío y recepción de
mensajes, la tarea de intercambiar objetos remotos por locales puede convertirse en una
tarea sencilla y como consecuencia de ello extender la comunicación entre objetos a través
de una red.

La mayoría de los sistemas operativos modernos trabajan con el concepto de orientación a
objetos. Por ejemplo Windows NT está basado en objetos, pese a que no está completa-
mente orientado a objetos. Los recursos del sistema, como por ejemplo los procesos, los
“threads” y los archivos se manejan como objetos; cada tipo de objeto expone un conjunto
de atributos y métodos. Los recursos visibles al usuario, incluyendo ventanas, menúes y
archivos también están construidos sobre una base de objetos. Debido a que tienen el es-
tado de objetos, a estos recursos se les puede asignar nombres, se los puede proteger y
eventualmente compartir.
1.8 EJEMPLO DE ESTRUCTURA INTERNA DE SISTEMA
OPERATIVO: MICROSOFT WINDOWS NT
El sistema operativo MS Windows NT14
, utiliza una estructura conocida con el nombre de
microkernel modificado, que estaría comprendida entre una estructura de microkernel
puro y una de kernel. En esta estructura, los ambientes (“environments”)15
del sistema
operativo ejecutan en modo usuario como procesos autónomos (ver figura 1-19). Los sub-
sistemas básicos del sistema operativo, tales como el “Process Manager” o administrador
de procesos y el “Virtual Memory Manager” o administrador de memoria virtual, ejecutan
en modo kernel y son compilados bajo un solo archivo ejecutable (ntoskernel.exe). La
comunicación entre los subsistemas que trabajan en modalidad kernel se realiza utilizando
llamadas a funciones, optimizándose de esta forma la velocidad de comunicación entre
procesos con respecto al método de pasaje de mensajes que se implementa en los sistemas
de microkernel puros.
Estos “environments” que provee NT trabajan sobre servicios que el modo kernel ofrece y
que no podrían ser ejecutados en modo usuario. Estos servicios invocados en modo kernel
son los API’s nativos de NT16
− aproximadamente 250 funciones − accedidos a través de
“system calls” implementadas como excepciones de software. Con este esquema, se pro-
vee un método asistido por hardware para cambiar la modalidad de ejecución de modo
usuario a modo Kernel.
1.8.1 El Ejecutivo de Windows NT (NT “Executive”)
14
Corresponde a la versión 4.0 de MS Windows NT.
15
Los “environments” de Windows NT son interfaces que de cierta manera simulan ambientes de
otros sistemas operativos. De esta manera Windows NT logra el soporte de aplicaciones
implementadas para otros sistemas operativos como IBM OS/2, MS Windows 3.x, MS DOS y Posix.
16
Win32 API.

Las solicitudes de API nativas son ejecutadas por funciones en modo kernel, conocidas
como servicios del sistema (“system services”). Estos servicios del sistema llaman a fun-
ciones implementadas en una o más de las componentes del Ejecutivo de NT (“NT
Executive”) , el cual incluye, entre otros, el Administrador de I/O, Administrador de Ob-
jetos, Monitor de referencia de Seguridad, Administrador de Procesos, Administrador de
Memoria Virtual y Recurso de Llamadas a Procedimientos Locales. Cada uno de estos
componentes tiene una función específica dentro del sistema operativo. Los controladores
de dispositivos o “device drivers” son aquellas componentes de software, que conectan el
sistema operativo con dispositivos específicos de hardware como una placa de red o de
video. Los mismos trabajan muy próximo al administrador de I/O, según se observa en la
figura 1-19.
Proceso
de logon
Subsistema
de seguridad
Cliente
OS/2
Cliente
Win32
Cliente
Posix
OS/2
Subsistema
Win32
Subsistema
Posix
Administrador
de I/O
Sist Arch.
Cache
Drivers
Drivers
de red
Administr.
de Objetos
Monitor de
referencias
de segur.
Administr.
de Proceso
Recurso de
llamadas a
proced.
locales
Administr.
de memoria
virtual
(MICRO)KERNEL
CAPA DE ABSTRACCIÓN DE HARDWARE (HAL)
HARDWARE
NT Executive
Subsistemas
protegidos
Aplicaciones
User
Mode
Mode
Kernel
Transf. de
Trampa de
Manipulación
de Hardware
Sistema
Mensaje
Subsistema
Servicios del Usuario
Figura 1-19: Arquitectura del sistema operativo Microsoft Windows NT
Las funciones básicas de cada uno de los componentes del ejecutivo son:

Administrador de Objectos (“Object Manager”): Se vió que uno de los roles más im-
portantes de cualquier sistema operativo es la administración de recursos físicos y lógicos.
También se mencionó que en NT estos recursos están representados por objetos. Los sub-
sistemas del ejecutivo utilizan al Administrador de Objetos para definir y administrar los
objetos que representan a tales recursos. Por ejemplo, a través del Administrador de Ob-
jetos, el Administrador de Procesos define un objeto proceso para monitorear los procesos
activos que posee el sistema.
Monitor de Referencias de Seguridad (“Security Reference Monitor”): Está
íntimamente relacionado con el Administrador de Objetos. Este último llama al Monitor
de Referencias de Seguridad antes de permitir a una aplicación que realice operaciones
sobre los objetos, tal como la lectura o escritura a él.
Administrador de Memoria Virtual (“Virtual Memory Manager”): Este subsistema
ejecutivo tiene principalmente dos funciones: crear y administrar el mapa de direcciones
para los procesos y controlar la asignación de memoria física a los procesos. NT imple-
menta un espacio de direcciones de 32 bits, es decir son direccionables 4Gbytes, dividido
en 2 Gbytes de espacio para la aplicación en modo usuario (espacio único por procesos) y
2 Gbytes de espacio para el kernel (compartido por todos los procesos)17
. La figura 1-20
muestra el mapa de direcciones virtuales de los distintos procesos en Windows NT.
17
NT 4.0 Service Pack 3 (SP3) y NT Server, Enterprise Edition 4.0, permiten modificar estos límites a
3 Gbytes y un 1Gbytes para modo usuario y kernel respectivamente. La version 5.0 implementará por
defecto esta nueva división del espacio de direcciones.

Modo Usuario
Modo Kernel
OGB
2GB
4GB
Ejecutivo
Kernel
HAL
Drivers
MS SQL Server
Lotus Notes
Norton Antivirus
Figura 1-20: Mapa de direcciones virtuales en NT
El administrador de memoria virtual de NT implementa un esquema de demanda de pági-
nas. En la versión de NT para plataforma Intel, una página tiene un tamaño de 4KB,
mientras que en sistemas Alpha, tiene un tamaño de 8KB18
.
Administrador de I/O (“I/O Manager”): Esta parte del ejecutivo es responsable de la
integración de controladores de dispositivos (“device drivers”) al resto del sistema ope-
rativo. Los controladores de dispositivos, que son componentes dinámicamente cargables,
controlan un tipo específico de componente de hardware, traduciendo los comandos que el
sistema operativo y las aplicaciones dirigen al mismo para ser ejecutadas por tales recur-
sos.
Recurso de Llamada a Procedimientos Locales (“Local Procedure Call Facility”):
Este subsistema del ejecutivo, optimiza la comunicación entre aplicaciones, incluyendo
los ambientes del sistema operativo.
18
En el módulo 6 − Administración de Memoria Virtual − se estudia con más detalle la implementación
del esquema de administración de memoria en Windows NT.

1.8.2 El Kernel
El microkernel de NT, o simplemente kernel, trabaja más cerca del hardware que el eje-
cutivo, por lo que contiene código específico de la CPU. El planificador de CPU (“thread
dispatcher”) reside en el kernel. Este “dispatcher” implementa 32 niveles de prioridad: 0 –
31. El mismo es del tipo “preemptive”: el tiempo de CPU es dividido en porciones llama-
das “quantums”. Cuando un proceso (más correctamente expresado un hilo de ejecución o
“thread”) finaliza en el uso de su quantum sin la CPU, el planificador le quita (o
“preempts”) el uso del mismo al proceso y se lo otorga a otro proceso (o “thread”)19
.
Además del “dispatcher”, el kernel implementa las primitivas de sincronización utilizadas
por el sistema operativo. Windows NT posee un amplio conjunto de primitivas de sincro-
nización como “mutexes”, semáforos, eventos y “spin locks”.
Finalmente, la última de las funciones del kernel de NT, es la del manejo de los vectores
de interrupción. NT define e implementa los niveles de IRQ en el kernel.
1.8.2 El Hardware Abstraction Layer (HAL)
Los “drivers” de dispositivos y el microkernel de NT utilizan el HAL (“Hardware
Abstraction Layer”) para interactuar con el hardware del computador. El HAL es la inter-
face de NT al CPU propiamente dicho. Microsoft quiso hacer a Windows NT tan portable
como sea posible, por lo que aisló la mayor parte de código específico del procesador en
un módulo dinámicamente reemplazable denominado HAL. El HAL exporta un modelo
de procesador común, que enmascara las diferencias entre varios chips de procesadores al
resto del sistema operativo. Los controladores de dispositivos utilizan este procesador
“estándar” en lugar de un tipo de CPU particular.
La portabilidad de NT esta asegurada debido a que el código específico del procesador
está restringido al kernel y al HAL, es decir que si se necesitara migrar NT a una nueva
plataforma de Hardware, solo el kernel y el HAL deberían ser modificados. El resto del
código de NT está escrito en C y C++, pudiendo ser simplemente recompilado para las
instrucciones de otro procesador.
19
El tópico de planificadores de CPU se verá en detalle en el módulo 3, donde se estudia
específicamente la implementación del “dispatcher” de Windows NT.

1.8 PROBLEMAS
1.8.1 Problemas Resueltos
1. Considere los siguientes programas que se ejecutan en forma concurrente dentro de
un sistema que permite multiprogramación.
programa productor
begin
repeat forever
leer k del terminal
computar f = sqrt(k)
esperar hasta que buffer este vacio
llene buffer con f
end
end
programa consumidor
begin
repeat forever
esperar hasta buffer este no-vacio
leer proximo valor f del buffer
escribir f al terminal
end
end
Describa brevemente la secuencia de eventos que toman lugar durante un ciclo de eje-
cución de ambos procesos. Asuma que el buffer se encuentra almacenado en disco y es
de tamaño 1. Los eventos a considerar son: ejecución del programa, bloqueo del pro-
grama, comandos de lectura/escritura, interrupciones de dispositivos, etc. Describa los
eventos en forma tabular.
Solución:
PRODUCTOR CONSUMIDOR
Invocar rutina de lectura del terminal Invocar rutina de lectura de buffer del disco
Bloquearse hasta recibir interrupción del
terminal
Bloquearse hasta que el buffer este no-vacío
Desbloquearse debido a la interrupción del
terminal
. . .
Recibir k del terminal
Computar f

PRODUCTOR CONSUMIDOR
Invocar rutina de escritura del buffer en
disco
Bloquearse hasta que el buffer este vacío
Recibir interrupción del disco
Llenar el buffer con f
Invocar rutina de lectura del terminal Recibir interrupción del disco
Bloquearse hasta recibir interrupción del
terminal
Leer el valor f del buffer
. . . Invocar rutina de escritura al terminal
Recibir k del terminal Bloquearse hasta recibir interrupción del
terminal
Computar f Desbloquearse con interrupción del terminal
Invocar rutina de escritura del buffer en
disco
Escribir f al terminal
Bloquearse hasta que el buffer este vacío . . .
. . .
. . . . . .
Recibir interrupción del disco Escribir f al terminal
2. En el apartado 1.4 se menciona que los sistemas de computadoras que proveen servi-
cios de multiprogramas o multitareas deben poseer hardware adicional necesario para
poder implementar tal funcionalidad del sistema operativo. Se menciona a modo de
ejemplo el hardware de DMA y el mecanismo de interrupciones. Explique porque son
necesarios estos dispositivos de hardware y mencione otros elementos de software y
de hardware que considere necesarios.
Solución:
• Hardware de DMA: con este hardware se libera la CPU de la tarea de transferir
información (palabra por palabra o byte por byte) desde memoria a los dispositi-
vos de I/O (y viceversa). Este hardware es importante en sistemas multitareas ya
que en ellos existen varios programas (esperando) para ejecutar, generando de
esta forma mucha demanda de tiempo de CPU y de entrada/salida de datos.
• Mecanismos de Interrupción Prioritarios: en un sistema multiprogramado exis-
ten diversos tipos de eventos que deben ser atendidos por el sistema operativo.
Por ejemplo: finalización de operaciones de I/O notificadas por los controlado-
res, condiciones de error en el hardware, errores de software generados por pro-
gramas (por ejemplo división por cero), etc. Para manejar esta diversidad de

eventos de una manera eficiente, el mecanismo de interrupciones debe ejecutar
las rutinas de interrupciones de acuerdo a la prioridad de atención de cada una de
ellas. Por ejemplo, algunas interrupciones deben ser atendidas inmediatamente,
como es el caso de una interrupción que notifica un error en el hardware o una
interrupción producida por un dispositivo de adquisición de datos indicando la
presencia de nuevos datos de entrada. A su vez algunas interrupciones pueden ser
diferidas por un cierto tiempo (respecto a otras) como sería el caso de una finali-
zación de la transferencia de datos por parte de una dispositivo de cinta.
• Timer: el hardware debe poseer un “timer” programable para poder controlar el
compartimiento de ciertos recursos entre los diversos programas activos del sis-
tema. El “timer” se inicia en un cierto valor el cual es decrementado periódi-
camente. Cuando alcanza el valor cero, interrumpe a la CPU permitiendo al sis-
tema operativo tomar posesión del procesador. Esto evita que ciertos programas
monopolicen la CPU por un tiempo indefinido y así causar que otros recursos
permanezcan inutilizados.
• Protección de almacenamiento y de instrucciones: para evitar que los programas
destruyan o invadan (errónea o intencionalmente) la privacidad de otros progra-
mas, incluyendo programas del sistema operativo, es importante que el sistema
posea mecanismos de hardware para proteger áreas de memoria y para restringir
el uso de algunas instrucciones de la CPU. Por ejemplo, en general no se debería
dar la posibilidad a un programa de un usuario de deshabilitar las interrupciones
de la CPU. Normalmente las CPU sobre las que se construyen los sistemas mul-
tiprogramados permiten la selección de un conjunto de instrucciones reservados
para el sistema operativo (modo usuario vs. modo kernel).
• Reubicación de memoria dinámica: cuando un programa espera por algún evento
que ocurrirá dentro de un tiempo prolongado, es a veces deseable trasladar tem-
poralmente a memoria secundaria el programa de memoria principal para permi-
tir que otros programas utilicen este recurso. Para aumentar la flexibilidad de este
mecanismo de intercambio (“swapping”) de programas, debería ser posible car-
gar un programa dado en diferentes direcciones de memoria cada vez que el
mismo es eliminado. Es más, un programa debería poder residir solo parcial-
mente en memoria. Para realizar esto en forma eficiente, el sistema debe poseer
hardware para soporte de memoria virtual.

1.8.2 Problemas Propuestos
1. ¿Cuál es la principal dificultad que se presenta en la implementación de un sistema
operativo de tiempo real? ¿Qué soluciones propone para evitar tal problema?
2. En un sistema multiusuario varios usuarios comparten el sistema (y sus recursos) si-
multáneamente. Este hecho puede resultar en varios problemas de seguridad. Enu-
mere por lo menos dos de esos problemas. ¿Se presentan dichos problemas en sistema
dedicados (no compartidos)? Explique.
3. ¿Cuáles son las propiedades más importantes de los siguientes tipos de sistemas ope-
rativos?
a) Batch (lotes)
b) Interactivo
c) Tiempo real
d) Para Mainframes
4. ¿Es muy importante en computadores dedicados el mecanismo de DMA? Explique.
5. Explique claramente porque el esquema de transferencia de datos con el uso de I/O
programada es usado con dispositivos de baja velocidad de transferencia (terminales,
impresoras, etc.), mientras que el esquema de DMA es utilizado con dispositivos de
alta velocidad de transferencia (discos, etc.). ¿Se le ocurre algún otro sistema aún más
eficiente que DMA?
6. Explique claramente como funciona el mecanismo de interrupciones de la CPU. Rea-
lice un esquema en el tiempo que muestre como se ejecutan las rutinas de interrup-
ción, cuando se permite el anidamiento de las mismas.
7. Cuando se utiliza un esquema de transferencia de acceso directo a memoria, tanto la
CPU como el controlador de DMA pueden acceder a memoria primaria en forma si-
multánea. Esto no es posible en la mayoría de las arquitecturas convencionales de
computadoras. ¿Quién debería tener prioridad sobre memoria: la CPU o el controla-
dor de DMA? Explique.
8. Realice una comparación entre las diversas estructuras de los sistemas operativos
mencionadas.

9. Explique la diferencia entre modo de ejecución privilegiado y usuario en un procesa-
dor. Mencione cinco operaciones que solo pueden ser ejecutadas en modo privile-
giado del procesador.
10. El sistema operativo VAX/VMS hace uso de cuatro modos de acceso al procesador
para facilitar la protección y compartimiento de recursos del sistema entre procesos.
Los modos de acceso determinan lo siguiente:
• Privilegios de ejecución de instrucciones: las instrucciones que el procesador
puede ejecutar.
• Privilegios de acceso a memoria: las ubicaciones en memoria virtual que las ins-
trucciones actuales pueden acceder.
Los cuatro modos de acceso son los siguientes:
• Kernel: ejecuta el kernel del SO VMS, el cual incluye administración de memo-
ria, manejo de interrupciones, y operaciones de I/O.
• Executive: ejecuta diversos servicios del sistema operativo, incluyendo rutinas de
administración de archivos (disco y cintas)
• Supervisor: ejecuta otros servicios del sistema operativo, tal como respuestas a
los comandos de los usuarios.
• User: ejecuta programas de usuarios y utilitarios tales como compiladores, edito-
res, “linkers”, “debuggers”.
Un proceso ejecutando en un modo menos privilegiado generalmente necesita llamar
a un procedimiento que ejecuta en un modo más privilegiado; por ejemplo un pro-
grama de usuario requiere un servicio del sistema operativo. Este llamado es reali-
zado utilizando la instrucción CHM que causa una interrupción transfiriendo el
control a una rutina que ejecuta en el nuevo modo de ejecución. El “return” se realiza
ejecutando la instrucción REI (Return from Interruption).
a) Una gran cantidad de sistemas operativos utilizan solo dos modos de acceso:
kernel y user. ¿Cuáles son las ventajas y desventajas de utilizar cuatro mo-
dos?
b) ¿Puede imaginarse un caso de uso de más de cuatro modos?
11. En diversos procesadores (por lo general del tipo utilizados en microcontroladores)
una interrupción causa que los valores de los registros sean almacenados en lugares
fijos de memoria los cuales están asociados con la señal (o nivel) de interrupción.

¿Bajo qué circunstancias esta técnica es útil? Explique porqué en general es inconve-
niente.
12. La figura 1-19 muestra la arquitectura interna del sistema operativo Microsoft
Windows NT. Ayudado por dicha figura conteste las siguientes preguntas:
a) ¿Qué son los “Environment Subsystems”? Mencione por lo menos dos de ellos.
b) ¿Qué son los servicios ejecutivos? ¿Por qué los servicios ejecutivos son genéri-
cos a todo el sistema operativo y no particulares a cada ambiente
(“environment”)?.
c) ¿Los distintos servicios ejecutivos se comunican entre sí a través de mensajes?
Explique.
d) ¿Por qué razón el código de un Sistema Operativo es más portable si es escrito en
un lenguaje de alto nivel? ¿Cuál componente de Windows NT contiene la mayor
parte del código específico del procesador? ¿Por qué?
e) ¿Cómo es posible que diferentes procesos compartan el mismo espacio de direc-
ciones virtuales, como muestra la figura 1-20?

MÓDULO 2
PROCESOS
2.1 INTRODUCCIÓN
En el módulo anterior se ha visto que los sistemas operativos están compuestos por un
conjunto de módulos o programas de alta complejidad, y por lo tanto definir su estructura
es un punto crucial en el diseño del mismo. Consecuentemente, todos los sistemas opera-
tivos son descompuestos en diferentes rutinas o partes que realizan funciones específicas y
que interactúan con otras a través de interfaces perfectamente definidas.
La complejidad en la implementación de los sistemas operativos se presenta principal-
mente por el alto grado de no determinismo que existe en las operaciones del sistema: mu-
chas funciones y servicios son llamados en respuestas a eventos que pueden ocurrir en
tiempos totalmente impredecibles.
Con el objeto de utilizar una metodología ordenada para la implementación de los siste-
mas operativos se introduce el concepto de proceso secuencial o tarea. Informalmente un
proceso secuencial es la actividad que resulta de la ejecución de un programa − con sus
correspondientes datos − en un procesador secuencial.
El concepto de proceso es completamente diferente al de programa. Un proceso debe con-
siderarse como un programa en ejecución, es decir como una entidad activa, que tiene un
estado particular en un dado instante. Un programa es una entidad pasiva, es simplemente
un archivo que cuando es llamado pasa a constituir un proceso.
Virtualmente cada proceso tiene su propio procesador para ejecutar, su espacio en memo-
ria primaria y acceso a los diferentes dispositivos de I/O, aunque en realidad más de un
proceso puede estar compartiendo todos estos recursos físicos. Cada proceso opera casi
independientemente del otro, compartiendo y compitiendo por recursos (de hardware y de
software) y con funciones bien definidas.
Para permitir que un sistema sea visualizado como un conjunto de procesos ejecutando
concurrentemente, este compartimiento de recursos debe ser implementado en forma
transparente (para los procesos). Esto es realizado por la capa más inferior del sistema
Procesos 54

operativo (kernel) cuya tarea es virtualizar el procesador (crear una CPU virtual por cada
proceso) como así también proveer un área de memoria para cada proceso, de tal forma
que el mismo ejecute en forma aislada e interactúe con otros procesos a través de primiti-
vas de comunicación también provistas por el kernel. Finalmente el kernel también debe
permitir acceso a los dispositivos de I/O, los cuales son compartidos por todos los proce-
sos. El sistema operativo se puede considerar entonces como una colección de procesos,
todos ellos ejecutándose en forma concurrente o simultánea y compartiendo o compi-
tiendo por recursos físicos (hardware) o lógicos (software).
2.2 CREACIÓN Y TERMINACIÓN DE PROCESOS
Los procesos tienen vida, por lo tanto deben ser creados y terminados. Cuando se va a
agregar un nuevo proceso a aquellos que ya se encuentran ejecutando en el sistema, el
sistema operativo actualiza estructuras de datos que el posee para administrar dichos pro-
cesos y además asigna un espacio de direcciones dentro del mapa de memoria, que va a
ser ocupado por dicho proceso.
Existen principalmente cuatro eventos que llevan a la creación de un proceso.
1. Nuevo proceso “batch”: en este caso se crea un proceso a ser ejecutado en mo-
dalidad “batch” por el SO20
(si el mismo lo permite).
2. Nuevo proceso interactivo: ídem al caso anterior para SO del tipo interactivo.
Ejemplos de procesos creados en forma interactiva son los programas ejecutados
por los usuarios, procesos de logon, etc.
3. Creados por el sistema operativo: en algunos casos el SO internamente crea pro-
cesos con el objeto de ofrecer servicios a los programas de los usuarios. Por
ejemplo, cuando se envía a imprimir un trabajo, el SO puede crear un proceso
interno para la administración de dicha impresión.
4. Creación de un proceso por un proceso existente: la mayoría de los SO permiten
que un proceso pueda crear otros procesos. Por ejemplo, un proceso del tipo
servidor puede crear un proceso por cada solicitud que recibe de sus clientes21
.
Estos procesos creados se ejecutan en forma concurrente con el proceso que los
creó. El proceso creador se denomina proceso padre (“parent process”), mien-
tras que los procesos creados se denominan procesos hijos (“child process”).
20
De aquí en adelante se abreviará la palabra Sistema Operativo por SO.
21
Pese a que un proceso puede crear diversos procesos, la verdadera creación de todos los
procesos es una tarea exclusiva del sistema operativo. Es decir, un proceso que necesita crear otros
procesos, debe solicitar al sistema operativo su creación.
Procesos 55

Evidentemente estos procesos necesitan comunicación y sincronización de sus
actividades. Este tema se verá en un módulo posterior.
Los procesos tienen una vida limitada. La tabla 2-1 muestra algunas razones por las cuales
un proceso puede terminar. Cualquiera sea la causa por la que un proceso finalice su eje-
cución, el SO debe realizar ciertas tareas, como por ejemplo la eliminación del mapa de
memoria del espacio ocupado por el mismo, modificación de tablas internas, etc.
Terminación Normal El proceso ejecuta un “system call” indicando al sistema ope-
rativo que ha terminado su ejecución.
Tiempo de vida ex-
cedido
El proceso ha corrido por un tiempo mayor que el límite má-
ximo especificado.
Memoria insufi-
ciente
El proceso necesita más memoria (primaria/secundaria) de la
disponible en el sistema.
Error de Protección El proceso intenta utilizar un recurso (por ejemplo un archivo)
que no está autorizado a utilizar.
Error Aritmético El proceso intenta ejecutar una operación aritmética prohibida,
como una división por cero.
Falla de I/O Aparece una falla en algún dispositivo de I/O. Por ejemplo la
imposibilidad de leer o escribir luego de un cierto número de
reintentos en un disco.
Instrucción inválida El proceso intenta ejecutar una instrucción no-válida, como por
ejemplo un salto a un área de memoria a la que no tiene acceso.
Instrucción privile-
giada
El proceso intenta utilizar una instrucción reservada para el SO.
Terminación del
padre
Cuando el proceso padre termina, el SO puede estar diseñado
para que automáticamente termine todos sus procesos hijos.
Terminado por el
padre
Un proceso padre puede terminar cualquiera de sus procesos
hijos.
Intervención del
operador o del Sis-
tema Operativo
Por alguna razón, el operador o el SO termina el proceso.
Tabla 2-1: Algunos Motivos para la Terminación de un Proceso
Procesos 56

2.3 ESTADOS DE UN PROCESO
Un proceso durante su vida cambia de estado de acuerdo a la actividad que se encuentra
realizando en un dado momento. Básicamente se pueden distinguir los siguientes estados
por los que transiciona un proceso:
1. Ejecutando (“Running”): el proceso está haciendo uso de la CPU.
2. Bloqueado (“Blocked”): el proceso está esperando que ocurra un evento deter-
minado, por ejemplo la finalización de una lectura en un dispositivo de I/O.
3. Disponible (“Ready”): el proceso está en condiciones para utilizar la CPU; sin
embargo debe esperar porque otro proceso está haciendo uso de ella.
A estos estados se podrían agregar los estados de nuevo y terminado. El primero repre-
sentaría a aquellos procesos que fueron creados y no fueron admitidos al grupo de proce-
sos disponibles (“ready”) por el sistema operativo. El estado de terminado correspondería
a aquellos procesos que han sido liberado del grupo de procesos ejecutables por el SO por
alguna de las razones expuestas en la tabla 2-1.
La consideración de estos dos últimos estados puede simplificar la administración general
de procesos. Por ejemplo, cuando se crea un nuevo proceso, el SO realiza las tareas co-
rrespondientes a la creación del mismo (asignación de un identificador de proceso, asig-
nación de espacio en memoria, creación de estructuras de datos asociadas al proceso, etc.).
Finalizado este paso, el proceso queda en estado de nuevo y por lo tanto no se lo considera
todavía al proceso como disponible para ejecutar. Si por ejemplo, el SO limita el número
máximo de procesos22
que pueden estar ejecutando en forma simultánea, este proceso en
estado de nuevo será pasado al estado de “ready” cuando algún proceso abandone el sis-
tema.
Similarmente cuando un proceso termina, el SO lo puede retener en el estado de
terminado en lugar de eliminarlo totalmente del sistema. Programas de monitoreo y audi-
toría del SO pueden extraer información útil de estos procesos, como por ejemplo estadís-
ticas de uso de recursos del sistema, razones por la que se terminaron los mismos, etc.
El diagrama básico de estado por los que transcurre un proceso se muestra en la figura 2-
1. Es importante destacar que solo un proceso puede estar en el estado de “running”, ya
que el sistema consta de una única CPU. Sin embargo puede haber varios procesos en el
estado de “blocked” o “ready”.
22
Por ejemplo por razones de performance o de limitaciones de memoria.
Procesos 57

Procesos
Nuevos
"Ready" "Running"
"Blocked"
Procesos
Terminados
"Dispatch"
Timer expirado
Espera
Evento
Ocurrió
Evento
Figura 2-1: Diagrama de Estado de un Proceso
Asociado con este diagrama de estado se puede realizar un modelo de colas23
. La figura 2-
2 representa una primera aproximación.
CPU
Cola "ready"
Cola "blocked"
Espere evento
evento
Ocurrió
"Time-out"
Nuevo
Terminado
"Dispatch"
Figura 2-2: Diagrama Básico de Colas de Procesos
Al admitirse un nuevo proceso al sistema, el mismo es ubicado en la cola “ready”. Cuando
el sistema operativo tiene que seleccionar un proceso para su ejecución, lo toma de esta
cola en particular. El proceso que decide cual es el próximo a utilizar la CPU se denomina
planificador de CPU o “scheduler” tópico que se verá en el próximo módulo. Cuando un
23
Este es uno de los tantos casos en los sistemas de computación donde aparecen colas. De allí que
una de las disciplinas más estudiadas en la ciencia de la computación sea la denominada teoría de
cola o “queuing theory”.
Procesos 58

proceso termina de utilizar el procesador, es eliminado del sistema (en caso que haya
completado su ejecución definitivamente), es puesto en la cola “ready” (cuota de tiempo
de CPU expirada) o en la cola de bloqueados (esperando la ocurrencia de un evento).
Según se observa en este diagrama de colas, cuando ocurre un evento, todos los procesos
que se encuentran en la cola de bloqueados y que esperan la ocurrencia de dicho evento
son desplazados a la cola “ready” 24
. Es decir, el sistema operativo debe recorrer toda la
cola de procesos bloqueados buscando por esos procesos que estaban bloqueados en es-
pera del evento que acaba de ocurrir. En un sistema operativo que soporta multitareas y
multiusuarios, pueden haber cientos o miles de procesos en esta cola, por lo que es más
eficiente poseer una cola por cada tipo de evento (ver figura 2-3).
CPU
Cola "ready"
Cola "blocked" 1
Espere evento
evento 1
Ocurrió
"Time-out"
Nuevo
Terminado
"Dispatch"
Cola "blocked" 2
Espere evento
Cola "blocked" n
Espere evento
. . .
evento 2
Ocurrió
evento n
Ocurrió
Figura 2-3: Diagrama de Múltiples Colas para Procesos Bloqueados
24
En sistemas con manejos de prioridades de procesos, se pueden poseer múltiples colas “ready”.
Procesos 59

Notas de sistemas operativos/Saade Sergio

Notas de sistemas operativos/Saade Sergio

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Notas de sistemas operativos/Saade Sergio

Similar a Notas de sistemas operativos/Saade Sergio (20)

Último

Último (20)

Notas de sistemas operativos/Saade Sergio