Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Diseño y Simulación de Sistemas Operativos
Diseño y Simulación de Sistemas Operativos
TESIS
PRESENTA:
http://creativecommons.org/licenses/by-nc-nd/2.5/mx/legalcode
2
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
i
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Agradecimientos
A mi esposa y compañera Mar Sallago por su alegría y aliento (gracias por mostrarme otras
perspectivasπ); y a toda la familia y amigos en Argentina, en especial a Pedro, Lis y Leo por su
amistad.
A mis profesores: Enrique Calderón, Carlos Calderón, Miguel Orozco, Alejandro Domínguez,
Miguel Leal; Marcos Calderón y Edgar Herrador (después de todo, se superaron las dudas de ese
mítico curso).
A mis colegas: Jorge Vasconcelos por su ejemplo de perseverancia en la vida académica y sus
comentarios a este trabajo; Miguel Armas por compartir muchos alucines académicos y a Roberto
Murcio por sus comentarios a este trabajo en sus inicios.
A los buenos amigos del Instituto de Química de la UNAM, en especial a Jaime Lagunez por
abrirme la perspectiva de las consideraciones biológicas en cuestiones de sistemas cómputo.
A los alumnos de licenciatura de la FAR del curso de sistemas operativos en el periodo 2002-3
(Gonzalo, Humberto, Gerardo, Josué, Héctor, Enrique, Luis) y 2003-1 (Lizethe, Rodrigo, Oscar,
Christian, J. Ignacio, Josué), por la oportunidad de poner en práctica los resultados de este
trabajo y el reto de transmitirles los conocimientos de un tema complejo y apasionante.
A Paco Otero, Hugo Gutiérrez y a Rodrigo Herrera por su amistad. A Antonio Martinez por
demostrarnos que es posible vivir la vida fuera del sistema.
A la familia Morán; Alfonso Sr. y Jr., Manolo: gracias por su apoyo y amistad.
To Rachael Dunne, Oisin & friends, (thanks for the opportunity of visiting Ireland, even when I
preferred to stay in México; it was a great time) and Alan Armijo (thanks for offer me the
opportunity of going to the US even when the odds were against the idea).
ii
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Resumen
Estamos en una época donde parece que el interés por cómo funcionan las cosas o cómo
hacerlas, pasa a un segundo plano a raíz de estar más ocupados utilizándolas. El software no es
la excepción. Toda aplicación que se use tiene un proceso de desarrollo, y más aún, cuenta con
un sistema que soporta su ejecución. Estas piezas de ingeniería de software que nos hacen la
vida más amable son los sistemas operativos, y vale mencionar que sin ellos, seguramente
seguiríamos requiriendo de operadores de computadora súper especializados.
Este trabajo es una investigación acerca de los sistemas operativos. El objetivo es proveer una
visión integral de este tipo de sistemas; desde sus antecedentes y fundamentos, hasta un análisis
de sus componentes y el establecimiento de criterios de diseño.
Este trabajo será de utilidad para todos aquellos usuarios, administradores y desarrolladores de
sistemas operativos, así como para cualquier profesional de las ciencias de la computación.
iii
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
iv
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Contenido
Introducción ___________________________________________________________ 1
Capitulo 1. Fundamentos de los Sistemas Operativos _______________________ 7
1.1 ¿Qué es un sistema operativo? ___________________________________________ 7
1.1.1 Definiciones ______________________________________________________________ 8
1.1.2 Características principales__________________________________________________ 10
1.2 Principales conceptos de los Sistemas Operativos___________________________ 11
1.2.1 Administración de procesos _________________________________________________ 12
1.2.2 Administración de memoria _________________________________________________ 13
1.2.3 La gestión de la integridad __________________________________________________ 13
1.2.4 Administración de dispositivos ______________________________________________ 14
1.2.5 Almacenamiento secundario ________________________________________________ 14
1.2.6 Transmisión de datos e información __________________________________________ 15
1.2.7 Núcleo del sistema (Kernel)_________________________________________________ 15
1.2.8 Comunicación con el usuario ________________________________________________ 16
1.3 Desarrollo histórico de los Sistemas Operativos ____________________________ 18
1.3.1 En el principio...__________________________________________________________ 20
1.3.2 Procesamiento por lotes y monitores __________________________________________ 21
1.3.3 Sistemas de operación simultanea de periféricos en línea __________________________ 23
1.3.4 Sistemas de Multiprogramación______________________________________________ 24
Sistemas de tiempo compartido (Timesharing) ____________________________________ 25
Sistemas de Tiempo Real _____________________________________________________ 27
1.3.5 Sistemas Multiprocesador, distribuidos y en red _________________________________ 28
1.3.6 Computadoras Personales __________________________________________________ 30
1.4 Comentarios _________________________________________________________ 32
1.5 Obras consultadas ____________________________________________________ 33
Capitulo 2. Funcionamiento básico de un sistema operativo_________________ 35
2.1 El hardware y la ejecución de programas _________________________________ 35
2.1.1 La unidad central de procesamiento___________________________________________ 36
2.1.2 La memoria _____________________________________________________________ 38
2.1.3 Ejecución de programas ____________________________________________________ 39
2.1.4 Interacción entre los componentes de hardware__________________________________ 41
Tipos de interrupciones ______________________________________________________ 45
2.2 Software para el control del hardware____________________________________ 46
2.2.1 El papel del BIOS ________________________________________________________ 46
Rutinas del BIOS ___________________________________________________________ 47
Secuencia de arranque _______________________________________________________ 48
El BIOS y el sistema operativo ________________________________________________ 49
2.2.2 Cargador del sistema ______________________________________________________ 49
Carga desde un CD-ROM ____________________________________________________ 50
Carga por medio de conexión en red ____________________________________________ 51
2.2.3 Inicio de la ejecución del sistema operativo_____________________________________ 52
2.2.4 Protección del hardware____________________________________________________ 54
Funcionamiento del kernel____________________________________________________ 55
2.3 Comentarios _________________________________________________________ 55
v
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
vi
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Subalojadores_____________________________________________________________ 112
4.3.4 Paginación _____________________________________________________________ 112
Reemplazo de páginas ______________________________________________________ 115
4.3.5 Segmentación ___________________________________________________________ 116
4.3.6 Segmentación con paginación ______________________________________________ 117
4.4 Simulación del servicio de administración de memoria _____________________ 119
4.5 Comentarios ________________________________________________________ 122
4.5 Obras consultadas ___________________________________________________ 123
Capitulo 5. Administración de procesos ________________________________ 125
5.1 Ejecución de programas y procesos _____________________________________ 125
5.1.1 Modelos de ejecución_____________________________________________________ 125
5.1.2 Procesos _______________________________________________________________ 127
5.1.3 Hilos__________________________________________________________________ 128
5.1.4 Representación de los procesos _____________________________________________ 129
5.1.5 Creación de procesos _____________________________________________________ 130
5.1.6 Estados de un proceso ____________________________________________________ 132
5.1.7 Colas de procesos________________________________________________________ 133
Llamadas de servicios ______________________________________________________ 134
5.1.8 Operaciones de manipulación de procesos_____________________________________ 134
5.1.9 ¿Por qué usar procesos? ___________________________________________________ 135
5.2 Planificación de procesos ______________________________________________ 136
5.2.1 Tipos de planificación ____________________________________________________ 137
Planificación del CPU ______________________________________________________ 138
Planificación de largo plazo __________________________________________________ 139
Planificación de mediano plazo _______________________________________________ 140
Caso de estudio: Sistema de planificación de procesos de Linux _____________________ 141
5.2.2 Algoritmos de planificación ________________________________________________ 142
Algoritmo de planificación FCFS (First Come - First Served) _______________________ 143
Algoritmo Round-robin _____________________________________________________ 145
• Planificación por prioridad___________________________________________________ 146
• Algoritmo del trabajo más corto primero (Shortest Job First) ________________________ 147
• Múltiples colas de prioridad (MPQ)____________________________________________ 148
Planificación de dos niveles __________________________________________________ 150
Planificación por herencia (Inheritance scheduling) _______________________________ 151
Planificación evolutiva______________________________________________________ 151
5.3 Simulación del servicio de administración de procesos _____________________ 152
5.4 Procesos concurrentes ________________________________________________ 155
5.4.1 Sincronización de procesos ________________________________________________ 159
Semáforos _______________________________________________________________ 161
Candados (Locks) _________________________________________________________ 162
Monitores y variables de condición ____________________________________________ 163
Interbloqueos _____________________________________________________________ 167
Prevención y tratamiento ____________________________________________________ 168
5.4.2 Comunicación entre procesos ______________________________________________ 170
El esquema productor-consumidor_____________________________________________ 170
Mensajes ________________________________________________________________ 171
Tuberías (pipes) ___________________________________________________________ 173
Caso de estudio: Comunicación entre procesos en Linux ___________________________ 174
5.4.3 Comunicación entre procesos en Sistemas Distribuidos __________________________ 175
5.4.4 Modelo cliente-servidor ___________________________________________________ 177
Direccionamiento __________________________________________________________ 177
vii
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
viii
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
ix
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
x
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
xi
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
xii
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 6.8 Objetos del sistema operativo y sus operaciones relacionadas con archivos. ............................ 197
Figura 6.9 Esquema del sistema de almacenamiento secundario............................................................... 197
Figura 6.10 Esquema del sistema de almacenamiento terciario.................................................................. 199
Figura 6.11 Formato de un archivo ejecutable............................................................................................ 200
Figura 6.12 Organización de archivos con directorios................................................................................ 200
Figura 6.13 Representaciones de archivos en UNIX, MS-DOS y Windows NT ........................................ 201
Figura 6.14 Ejemplos de estructuras en sistemas operativos como UNIX, MS-DOS y Windows. ............ 202
Figura 6.15 Esquema de la aplicación de operaciones de acceso y manipulación en un archivo .............. 204
Figura 6.16 Sistema virtual de archivos de Linux....................................................................................... 209
Figura 6.17 Estructura del administrador de archivos de Linux ................................................................. 210
Figura 6.18a Algunas ejemplos de las topologías que una red puede adoptar. .......................................... 213
Figura 6.18b Modelo OSI y los equivalentes en el modelo de protocolos TCP/IP..................................... 214
Figura 6.19 Arquitectura de Netware 2.2.................................................................................................... 214
Figura 6.20 Estructura del subsistema de red de Linux .............................................................................. 216
Figura 6.21 Conjunto de protocolos TCP/IP y su relación con el modelo OSI........................................... 218
Tabla 3. Relación de dispositivos de cómputo y sus sistemas operativos................................................... 229
Figura 7.1 Esquema del proceso unificado de desarrollo (RUP) ................................................................ 231
Figura 7.2 Ciclo de vida en cascada............................................................................................................ 232
Figura 7.3 Visiones de un sistema de software ........................................................................................... 237
Figura 7.4 La definición de la arquitectura está entre el análisis del sistema y su diseño........................... 240
Figura 7.5 Descomposición de elementos de diseño................................................................................... 241
Tabla 4. Estructuras de una arquitectura de software.................................................................................. 243
Figura 7.6 Vistas posibles de un elemento de diseño (lógica, concurrente o de instalación)...................... 244
Figura 7.7 Algunos tipos de estilos arquitectónicos.................................................................................... 247
Figura 7.8 Diagrama de clase del patrón microkernel ................................................................................ 250
Figura 7.9 Vista de capas de la arquitectura de un sistema operativo ......................................................... 256
Figura 7.10 Dispositivos de interfaz ........................................................................................................... 268
Figura 7.11 Interfaz de usuario del MS-DOS ............................................................................................. 269
Figura 7.12 Patrón de diseño Interpreter..................................................................................................... 270
Figura 7.13 Interfaz de la aplicación shell de MS-DOS.............................................................................. 270
Figura 7.14 Interfaz gráfica GNOME en Linux[7.87] ................................................................................ 271
Figura 7.15 Patrón MVC como base de una GUI ...................................................................................... 272
Figura 7.16 Elementos de la interfaz de usuario de Swing en Java ............................................................ 272
Figura 7.17 Arquitectura de la GUI del WCEfA ........................................................................................ 273
Figura 7.18 Arquitectura del Mac OS X y su interfaz de usuario Aqua ..................................................... 275
Figura 7.19 Consideraciones para el desarrollo de software....................................................................... 278
Figura 7.20 Diseño de sistemas operativos ................................................................................................. 279
Figura 8.1 Arquitectura de Windows NT representada en un esquema de módulos................................... 286
Figura 8.2 Especificación formal de alto nivel de la arquitectura de Windows NT usando UML (paquetes y
relaciones)........................................................................................................................................... 287
Figura 8.3 Arquitectura de kernel monolítico ............................................................................................. 289
Figura 8.4 Arquitectura conceptual de Linux ............................................................................................. 290
Figura 8.5 Esquema de la organización en capas de un sistema operativo ................................................. 291
Figura 8.6 Organización del sistema operativo en anillos........................................................................... 291
Figura 8.7 La característica central de la arquitectura de Mac OS X es la división en capas del software del
sistema ................................................................................................................................................ 292
Figura 8.8 Esquema de una arquitectura de máquina virtual ...................................................................... 293
Figura 8.9 Niveles de máquinas virtuales ................................................................................................... 294
Figura 8.10 Convivencia entre el sistema operativo nativo y ..................................................................... 295
el creado por la máquina virtual.................................................................................................................. 295
Figura 8.11 Esquema de la arquitectura de un microkernel. Pueden identificarse los modos de operación
(modo kernel y modo usuario), así como los procesos del sistema y los procesos de usuario............ 296
Figura 8.12 Esquema de la arquitectura del Palm OS. El núcleo de este sistema es el microkernel AMX
(Kadak) que implementa multiprocesamiento .................................................................................... 297
Figura 8.13 La arquitectura de paso de mensajes del QNX RTOS forma un bus de software que permite
conectar o desconectar los módulos del SO que se necesiten, sin reiniciar el sistema........................ 298
xiii
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 8.14 En el corazón del JavaOS se encuentra la máquina virtual de Java (JVM). Los servicios del
sistema, manejadores, applets y aplicaciones se ejecutan en la VM y un microkernel provee los
servicios básicos de la plataforma....................................................................................................... 300
Figura 8.15 La red de módulos de software que forma una aplicación puede visualizarse en distintos niveles
............................................................................................................................................................ 301
Figura 8.16 Arquitectura del sistema operativo Go .................................................................................... 302
Figura 8.17 Arquitectura del sistema X Window, para el intercambio de mensajes de interfaz gráfica de
usuario................................................................................................................................................. 304
Figura 8.18 Esquema de operación de un sistema operativo de red............................................................ 305
Figura 8.18a Arquitectura de Windows NT en referencia al modelo OSI .................................................. 306
Figura 8.19 Esquema de operación de un sistema operativo distribuido .................................................... 307
Figura 8.20 Esquema del middleware y entornos distribuidos .................................................................. 308
Figura 8.21 Esquema de la arquitectura de Mach ....................................................................................... 310
Figura 8.22 Arquitectura del microkernel Darwin del Mac OS X que integra el kernel Mach 3.0 y servicios
del BSD UNIX.................................................................................................................................... 312
Figura 8.23 Estructura de un sistema exokernel. Las aplicaciones usan sus propias librerías de Sistema
Operativo (Library Operating System (LibOS)) que a su vez usan el exokernel para cargar y descargar
recursos de hardware........................................................................................................................... 314
Figura 8.24 Esquema de un servidor Web montado en un SO convencional ............................................. 315
Figura 8.25 El solicitar una página HTML desencadena una serie de procesos que el SO tiene que hacer
para darle el soporte a la aplicación, lo cual no necesariamente puede ser óptimo. En el segundo
diagrama pueden apreciarse las dependencias del sistema de administración de memoria de Linux. 315
Figura 8.26 El exokernel provee la protección del hardware y las librerías de aplicación, pero el control lo
tiene la aplicación, lo que elimina procesos que el servidor Web no necesita .................................... 316
Figura 8.27 Un sistema de exokernel simplificado con dos aplicaciones, cada una ligada con su propia
libOS y compartiendo páginas por medio de un registro .................................................................... 316
Figura 8.28 Arquitecturas de sistemas operativos y sus características ...................................................... 320
Figura 9.1 Simulador de administración de memoria con particiones fijas (Oscar Ceceña)....................... 328
Figura 9.2 Simulador de administración de procesos (Christian Islas) ....................................................... 328
Figura 9.3 Simulador de administración de procesos (Josué Huizar) ......................................................... 328
xiv
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Introducción
Algunos ven las cosas como son y preguntan:¿Por qué?
Yo sueño en lo que nunca existió y pregunto:¿Por qué no?
Robert F. Kennedy
Las computadoras desde un principio han sido máquinas complejas (y un gran logro técnico
iniciado por Babbage en el siglo XIX y desarrollado en el siglo XX), compuestas de diversas partes
físicas (el hardware), las cuales realizan acciones cuando se les dan instrucciones (el llamado
software). Los conjuntos ordenados de instrucciones son llamados programas, y son los que le
dicen a la computadora como debe hacer diferentes cosas con objetivos específicos y
particulares.
La idea de realizar notas y hasta un libro de sistemas operativos nació en 1997 cuando daba un
curso relacionado al tema en la Fundación Arturo Rosenblueth (el titulo de ese proyecto era
"Sistemas operativos: Teoría y práctica"), sin embargo por motivos de trabajo la idea quedó en el
baúl. Fue hasta 1999 (tal vez un poco antes) con el advenimiento de un movimiento importante
en el país respaldando a Linux (por parte de entusiastas estudiantes de diversas universidades)
que decidí retomar el tema de los sistemas operativos.
Una motivación adicional apareció durante el tiempo que pasé colaborando en el Instituto de
Química de la UNAM; hubo una pregunta que me intrigó cuando charlábamos sobre las analogías
de los mecanismos celulares con las computadoras: "Si el núcleo celular era el hardware, ¿cuál
era el software (y el sistema operativo) de la célula?" Aunque se comentó que el ADN podía
considerarse como el software de control, me pareció que debía estudiar a fondo la teoría de los
sistemas operativos para un análisis futuro del tema.
• El desarrollo de este tipo de sistemas está en manos de una élite de desarrolladores (ya sean
los apoyados por universidades o compañías, o los que lo hacen como pasatiempo; esfuerzos
sin duda, loables). Aunque hacer sistemas operativos no es una de las ofertas de trabajo que
salgan a menudo en los periódicos, el conocimiento de este tema es obligado para cualquier
profesional del área de cómputo.
• La bibliografía relacionada es escasa e importada (aunque hay traducciones) y en general
más teórica que práctica. Esto último no ha tenido un balance (hay obras con mucha teoría y
otras con la mitad de la publicación con listados de código fuente) y ante todo, no ha
reportado la experiencia de las personas o equipos de trabajo, exponiendo cómo es que
llegaron a sus soluciones (es decir, a sistemas que actualmente se usan en ambientes de
producción).
• Un experto en sistemas operativos debe tener una perspectiva amplia sobre los diferentes
sistemas operativos existentes. Alguien que trata o logra recompilar el kernel de Linux, o que
1
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Por todo lo anterior, decidí llevar a cabo una investigación que lograra, ante todo, aclarar
muchas dudas que creo compartir con muchas personas (sin ir mas lejos, preguntas sobre qué
son o cómo funcionan los sistemas operativos) con respuestas convincentes que vayan a la
médula de la principal interrogante de todo estudiante de ciencias de la computación: ¿cómo se
diseña y construye un sistema operativo?
No he querido tomar un solo sistema como caso de estudio, pues esto sería limitado, dada la
variedad que existe (además tratar de adivinar por qué se codificó de cierta manera un
programa, o conjeturar sobre las decisiones de diseño del sistema puede ser poco objetivo). Por
el contrario, he tratado de integrar las diversas visiones en torno a los sistemas operativos para
ejemplificar (en lo posible), las ideas y técnicas más representativas aplicadas a estos sistemas (a
nivel de sus componentes y su estructura general).
2
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
hacer un sistema operativo, ninguna de las exposiciones establece una metodología clara, por lo
que es difícil abordar un proyecto de este tipo.
La comprensión es básica si se desea analizar o construir uno de estos sistemas (hay muchos
detalles entre líneas que pueden ser omitidos y que son importantes en la arquitectura del
sistema); no sólo se trata de que cada quien haga su sistema operativo (pues esto no tendría
mucho sentido), sino de tener los elementos necesarios para que con el advenimiento de nuevas
tecnologías, se pueda colaborar en su desarrollo, o por lo menos entender cuál es el sentido y
capacidades de las nuevas soluciones.
1. Exponer los principales conceptos de la teoría de sistemas operativos con un enfoque práctico.
2. Analizar diversas arquitecturas de sistemas operativos y sus subsistemas, con el fin de
establecer criterios para el diseño de nuevos sistemas operativos, así como para evaluar los
existentes.
3. Proponer algunos modelos de simulación que integren a los elementos relacionados con el
funcionamiento de un sistema operativo.
3
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El capitulo 3 expone la justificación del uso de la simulación para el estudio de los SO, y se
analizan algunas de las plataformas de simulación más usadas, con el fin de establecer los
criterios y elementos de diseño para la simulación de los conceptos generales de funcionamiento
expuestos en el capitulo 2. Para ello primero se presentan las consideraciones para la simulación
de hardware y sistemas operativos, y un primer prototipo del simulador, el cual fue hecho sin
tener un fundamento arquitectónico.
Todo esto brinda una perspectiva de los servicios que por lo general los sistemas operativos
ofrecen (y que el usuario espera).
III. Diseño de sistemas operativos. Una vez que contamos con el conocimiento de lo que es y
cómo funciona un sistema operativo, y partes que lo integran, llega el momento de aplicarlo. En
principio creí que el principal producto sería un simulador, pero de hecho hay un vacío más
importante que llenar: la metodología de diseño de los sistemas operativos. Por ello, se
presentan algunos casos de estudio de varios sistemas operativos para identificar los principales
componentes de las diversas arquitecturas que existen, con el fin de establecer criterios
metodológicos de diseño.
4
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La última sección contiene los resultados del trabajo, la experiencia del desarrollo, las
conclusiones obtenidas, así como las perspectivas a futuro del proyecto.
a. Simulación de sistemas operativos (modelado del hardware y software que se relaciona al SO).
b. Implementación de servicios del sistema operativo (administración de la memoria y procesos).
c. Casos de estudio de implementaciones (un microkernel).
Temas relacionados
• Sistemas operativos.
• Sistemas distribuidos.
• Arquitectura de computadoras.
• Compiladores y lenguajes de programación.
• Simulación y modelado.
• Simulación y emulación de hardware.
• Ingeniería de software.
• Arquitectura de software.
5
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
6
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 1.
Fundamentos de los Sistemas Operativos
Todo aquel que desee saber qué ocurrirá
debe examinar qué ha ocurrido: todas las
cosas de este mundo, en cualquier época,
tienen su réplica en la antigüedad.
Maquiavelo.
Para entrar en materia, este primer capítulo está dedicado a dar respuesta a las preguntas más
comunes relacionadas a los sistemas operativos, tales como:
Se han tratado de incluir todos los aspectos que puedan requerirse para entender estas
cuestiones, y para tener las bases para comprender la disertación de los siguientes capítulos.
Además, puesto que uno de los principales objetivos de este trabajo es el diseño de este tipo de
sistemas, es esencial que se comprenda cuales son sus antecedentes, los elementos
conceptuales a manejar y la interacción entre ellos, para así pasar a cuestiones más específicas.
Aunque en las últimas décadas se han hecho propuestas en cuanto a nuevos tipos de
computadoras, el hecho es que sin el software (o programas, que son conjuntos de instrucciones
que una máquina ejecuta) una computadora es solo un ingenio electrónico incapaz de realizar
tareas útiles. Con el software, una computadora puede almacenar, procesar y recuperar
información.
7
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Puesto que hay una gran variedad de puntos de vista respecto a lo que es un sistema
operativo, es prudente presentar algunas de las definiciones más representativas para empezar a
comprender la amplitud de funciones de este tipo de sistemas.
1.1.1 Definiciones
8
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
III. Un SO es un conjunto de programas de control del sistema de cómputo, cuyas funciones son:
Estas funciones deben ser provistas por el sistema ya que no siempre pueden ser manejadas
adecuadamente por los mismos procesos. El software encargado de asistir al hardware en estas
funciones es conocido como el sistema operativo.
Todas estas definiciones son complementarias, y en resumen, se puede decir que los Sistemas
Operativos son un conjunto de programas que crean la interfaz del hardware con el usuario, y
que tienen como funciones primordiales:
9
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Administrar el hardware. Se refiere al hecho de administrar de una forma más eficiente los
recursos de la máquina.
• Facilitar el trabajo al usuario. Permite una comunicación con los dispositivos de la máquina.
• Controlar la ejecución de programas y proveer los servicios necesarios para hacerlo.
Algunas de las principales características generales de los sistemas operativos actuales son:
i) Costos. A causa de que proveer con equipo suficiente a varios usuarios resulta muy
caro.
ii) Reutilización. Utilización de de programas o rutinas ya existentes para desarrollar
nuevas aplicaciones.
iii) Compartir datos de una misma base de datos para diferentes programas.
iv) Evitar la redundancia de utilizar copias individuales de un programa en vez de
compartir una sola.
10
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 1.3 Soporte de software necesario para aprovechar los recursos del hardware.
⊕
Obras consultadas: [1.11] [1.12]
11
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La idea de crear un sistema tan grande y complejo como un SO, solo puede manejarse
partiéndolo en pequeños módulos, los cuales poseen una función bien definida en el sistema, con
sus correspondientes entradas y salidas.
En las siguientes secciones se define el objetivo y actividades de cada uno de esos módulos (el
criterio de selección de los módulos expuestos es que en su mayoría aparecen de forma
constante en casi cualquier sistema operativo).
12
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Hay que tener en cuenta que cualquier programa puede, aunque no sea deseable, hacer
mención a recursos, direcciones y otros accesos indebidos; si dichos accesos no son controlados,
se produciría un error que daría como origen algo que no nos podríamos imaginar (reinicio de la
máquina, bloqueo, etc.).
Para evitar todos estos problemas, los sistemas operativos tienen distintos niveles de
seguridad:
a. En la memoria: Hemos dicho que los programas se cargan en la memoria, pero imaginemos
que un programa hace una escritura en una zona de memoria que es de otro programa, para
evitar esto el sistema operativo realiza una gestión de la memoria entre los usuarios.
13
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
efecto imprevisible. Para ello el sistema operativo controla la ejecución de los procesos, la
duración de cada uno de ellos y cuando deben entrar o salir de la ejecución.
Puesto que las configuraciones de hardware de las computadoras varían según las necesidades
y desarrollo tecnológico, un área de constante desarrollo es la construcción de nuevos
dispositivos periféricos que permitan a las computadoras expandir sus capacidades básicas. Para
ello, es necesario que un SO cuente con subsistemas que permitan acceder a tales dispositivos.
Dichos subsistemas son los siguientes:
1. Administración del sistema de E/S (I/O). Puesto que uno de los propósitos del SO es
hacer transparente las peculiaridades del hardware al usuario, se tiene un sistema de E/S que
consiste de:
• Una interfaz general dispositivo-controlador (device-driver).
• Manejadores para dispositivos específicos de hardware.
14
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Distribución de almacenamiento.
• Organización del disco.
El sistema de archivos trabaja sobre los manejadores de dispositivos para proveer una
interfaz abstracta con los diferentes manejadores. Define la forma de almacenar información en
dispositivos de almacenamiento, por lo que no es necesario aprender un nuevo método de
almacenamiento para cada dispositivo posible.
15
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El kernel (o núcleo) es la parte del sistema que en realidad se encarga de los aspectos más
básicos de la funcionalidad, principalmente con la forma en que la computadora se comportará.
Comúnmente, el kernel establecerá las políticas de trabajo (tarea simple o multi-tarea; métodos
de planificación), como manejar a los componentes básicos (p.ej. políticas de manejo de
memoria como el uso de la memoria virtual), las medidas de seguridad básica y como iniciar,
comunicarse y apagar todos los demás componentes.
Toda esta gestión la realiza para atender al funcionamiento y peticiones de los trabajos que se
ejecutan en el sistema.
El núcleo normalmente representa sólo una pequeña parte de lo que por lo general se piensa
que es todo el sistema operativo, pero es el código que más se utiliza. Por esta razón el núcleo
reside por lo regular en la memoria principal, mientras que otras partes del sistema
operativo son cargadas en la memoria principal sólo cuando se necesitan.
a. Interfaz de usuario. La Interfaz de usuario es la parte del sistema que provee una forma en
que la computadora capte y reaccione a las acciones del usuario, y transmita la información que
el usuario produce. Es el componente que se encarga de traducir los datos binarios en números y
caracteres en la pantalla, o interpretar los códigos binarios del teclado, y si se trata de una
interfaz grafica de usuario (GUI), se encarga de dibujar las ventanas y otros objetos en la
pantalla. Nótese que una computadora puede tener varias interfaces de usuario para adaptarse a
diferentes modelos de terminales o preferencias del usuario.
⊕
Obras consultadas: [1.29]
16
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
c. Interfaz gráfica de usuario (GUIs -Graphical User Interfaces). Las GUIs despliegan objetos
gráficos en la pantalla (imágenes, iconos, botones, etc.) y el usuario interactúa con ellos usando
un dispositivo apuntador (por lo general un ratón (mouse)). Las interfaces gráficas modernas
usan una "metáfora de escritorio" en las que áreas conocidas como ventanas, contienen
actividades de trabajo, como hojas de papel sobre un escritorio real.
Las GUIs hacen uso extensivo de los gráficos por computadora para organizar el área de trabajo
del usuario, y presentan formas intuitivas para realizar diversas tareas. En 1968 Doug Engelbart
del Stanford Research Center's Augmentation Research Center, patrocinado por la Agencia de
Proyectos de Investigación Avanzados del Departamento de Defensa (ARPA), instrumentó el
primer sistema de ventanas (windowing system). En 1970, investigadores del Centro de
Investigación de Palo Alto (XEROX PARC) diseñaron la primera computadora con interfaz gráfica
(Alto Computer).
17
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
(a) (b)
Figura 1.6 Ejemplos de interfaz gráfica de usuario: (a) el sistema NeXT; (b) Mac OS X.
Por lo anterior, se puede decir que aunque el SO es una parte muy importante del sistema de
computo, este queda fuera de la vista de los usuarios, los cuales lo notan de forma indirecta por
medio de las capacidades que el SO provee y las cosas que permite y no permite hacer, cuando
lo acceden por medio de otros programas como los shells o las GUIs, que son los que
comprenden e interpretan las acciones que el usuario quiere realizar.
Para entender cómo es que aparecieron este tipo de sistemas, revisaremos la historia de la
computación con la intención de entender las motivaciones que condujeron al desarrollo de los
sistemas operativos.
Para tener una perspectiva completa de los sistemas operativos, es importante revisar su
historia, la cual es paralela al desarrollo del hardware de las computadoras, pues los nuevos
avances requerían de nuevas soluciones. Basado en algunas referencias relativas a la historia y
evolución de las computadoras, se ha desarrollado la siguiente cronología (fig. 1.7) la cual integra
a las generaciones de computadoras digitales y a los sistemas operativos. En ella se han tratado
de incluir los principales paradigmas de ambas áreas.
Por convención, la primera generación inicia con las primeras computadoras electrónicas, en
lugar de las máquinas mecánicas y electromecánicas que les antecedieron. Cabe mencionar que
de todas las referencias consultadas, no hay un consenso en cuanto a los periodos de tiempo que
cada generación cubre, o incluso a los criterios que se usan para definirlas. Un criterio
interesante se basa en los cambios en la tecnología de implementación dominante, que permiten
crear nuevas computadoras. Sin embargo, es posible obtener nuevas configuraciones con la
tecnología disponible, creando arreglos complejos de procesadores (que además implica
desarrollar tecnologías de conectividad y sincronización).
⊕
Obras consultadas: [1.1] [1.2] [1.3] [1.4] [1.5] [1.6] [1.7] [1.8] [1.9] [1.10]
18
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 1.7 Cronología del desarrollo de las computadoras y los sistemas operativos.
19
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En las siguientes secciones se explora el desarrollo histórico de los sistemas operativos, con el
fin de tener una idea de como han ido evolucionando, y para apreciar un poco más "los lujos"
que hoy disfrutamos en nuestras computadoras. Aunque los primeros sistemas ahora pueden ser
(o parecer) obsoletos, no deja de ser interesante su análisis para comprender las tendencias
actuales en su desarrollo.
1.3.1 En el principio...
Las primeras computadoras de fines de los 1940s no tenían sistema operativo. En un
principio solo existía el hardware de la computadora. Las primeras computadoras eran
(físicamente) grandes máquinas que se operaban desde una consola. El programador escribía un
programa y luego lo controlaba directamente.
El trabajo de los operadores humanos, quienes planificaban los trabajos listos para ejecutar y
supervisaban el uso de los recursos de la computadora, fue una de las primeras ocupaciones en
ser automatizada.
Estas computadoras eran tan caras, que el principal objetivo de un sistema operativo era hacer
al hardware tan eficiente como fuera posible. Además, los programadores producían su propio
20
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
código objeto para los programas, incluyendo todas las instrucciones para entrada de datos de
las tarjetas o cinta de papel y salida de resultados a impresoras o cinta magnética.
Un programa (o trabajo) era cargado y ejecutado a la vez hasta su término o detenido a causa
de un error; el sistema estaba ocioso hasta que el siguiente programa fuera cargado y ejecutado.
Durante los 1950s, los cargadores, rutinas estándar de entrada/salida (E/S), ligadores,
ensambladores y compiladores fueron introducidos, junto con el concepto de archivo, así que el
código de programa o conjuntos de datos podían ser referidos por medio de nombres de
archivos.
Lotes de archivos de programas eran cargados de una sola vez (a través de lectoras de
tarjetas), y compartían el CPU y la memoria primaria: cuando un programa esperaba por el
término de la lenta E/S, era suspendido de forma que otro programa pudiera usar el CPU (multi-
programación).
En los anales de la historia de la computación, 1956 es el año en que aparece el primer sistema
operativo, diseñado para la IBM 704 (por Bob Patrick (General Motors) y Owen Mock (North
American Aviation)), llamado GM-NAA I/O, y permitía el procesamiento por lotes (una forma
simple de combinar comandos existentes en nuevos comandos).
Un sistema de lotes es aquel cuyos trabajos (jobs) son reunidos con las instrucciones
necesarias para permitirles ser procesados sin intervención de un operador.
21
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 1.9 Esquema básico de la memoria de una computadora con procesamiento por
lotes (monitor residente).
Por lo general se usaban cintas magnéticas o tambores para almacenar los datos intermedios y
programas compilados. Las ventajas y desventajas de este tipo de sistemas son:
1. Ventajas
mueve mucho del trabajo del operador a la computadora
incrementa el desempeño, puesto que es posible para un trabajo comenzar tan pronto
como el anterior termina
2. Desventajas
depuración complicada de programas
debido al esquema de protección, un trabajo del lote puede afectar a los demás trabajos
pendientes (p.ej. a causa de la lectura de demasiadas tarjetas, etc.)
un trabajo puede corromper al monitor, afectando también a los trabajos pendientes
un trabajo puede entrar en un ciclo infinito
Como se mencionó, una de las mayores carencias de los sistemas por lotes era que no existía
un esquema de protección para prevenir que algún trabajo afecte adversamente a otros. La
solución a esto era un simple esquema de protección, donde cierta memoria (p.ej. donde reside
22
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
el monitor) era restringida a los programas de usuario. Esto prevenía que los programas de
usuario corrompieran al monitor.
Para evitar que los programas de usuario leyeran demasiadas (o pocas) tarjetas, el hardware
era cambiado para permitir a la computadora operar en uno de dos modos: uno para el monitor y
uno para los programas de usuario. La entrada/salida (E/S) podría solo ser realizada en modo de
monitor, así que las peticiones de E/S de los programas de usuario eran pasadas al monitor. De
esta manera, el monitor podría evitar que un trabajo no leyera su tarjeta de fin de trabajo
($EOJ).
Para prevenir un ciclo infinito, un temporizador (timer) fue agregado al sistema y la tarjeta
$JOB fue modificada para que el tiempo máximo de ejecución de un trabajo fuera enviado al
monitor. La computadora podría interrumpir el trabajo y regresar el control al monitor si se
excedía este tiempo.
Cuando estos sistemas son bien planeados, pueden tener un tiempo de ejecución muy alto,
porque el procesador es mejor utilizado y los Sistemas Operativos pueden ser simples, debido a
la naturaleza secuencial de la ejecución de los trabajos.
Algunos ejemplos de Sistemas Operativos por lotes exitosos son el SCOPE, del DC6600, el cual
está orientado a procesamiento científico pesado, y el EXEC II para el UNIVAC 1107, orientado a
procesamiento académico.
23
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Puesto que es más rápida la lectura de una cinta magnética que un bloque de tarjetas, se volvió
común para los centros de cómputo tener una o más computadoras menos potentes en
complemento a su computadora principal. Las computadoras pequeñas eran usadas para leer y
cargar las tarjetas a las cintas, por lo que la cinta podía contener varios trabajos en lote. Esta
cinta era entonces cargada en la computadora principal y los trabajos de la cinta eran
ejecutados. La salida de los trabajos podía ser escrita a otra cinta que era retirada y cargada en
una computadora de menor capacidad para producir cualquier salida deseada (p.ej. impresiones).
Una extensión lógica del temporizador en el sistema por lotes, fue tener un temporizador que
pudiera permitir a los trabajos ejecutarse solo por un corto periodo de tiempo antes de
interrumpirlos para que el monitor pudiera iniciar alguna operación de E/S.
Puesto que la operación de E/S podría proceder mientras el CPU se ocupaba en un programa de
usuario (realizar E/S y cálculos en paralelo), fue posible que la computadora leyera tarjetas a las
cintas, tambores o discos y escribir la salida a una cinta mientras seguía procesando programas.
Este proceso es llamado SPOOLing (Simultaneous Peripheral Operation OnLine). Los sistemas
por lotes Spooling (Spooling Batch Systems) fueron los primeros (y más simples) sistemas de
multiprogramación.
Una ventaja de los sistemas de spooling era que la salida estaba disponible tan pronto como el
trabajo se completara, en vez de tenerla cuando todos los trabajos del lote se completaran.
24
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En este punto, el monitor crece hasta el punto de parecer un sistema operativo moderno, el
cual es responsable de:
Como un simple y común ejemplo, considérese una máquina que puede correr dos trabajos a la
vez. Incluso, supongamos que un trabajo es de E/S intensiva y que el otro usa el CPU
intensivamente. Una forma para el monitor de obtener tiempo de CPU entre estos trabajos podría
ser dividir el tiempo equitativamente entre ellos. Sin embargo, el monitor podría estar ocioso
gran parte del tiempo durante la ejecución del proceso de E/S.
Una buena solución en este caso es permitir al trabajo del CPU (background job) ejecutarse
hasta que el trabajo de E/S (foreground job) necesite tiempo de CPU, momento en el cual el
monitor le permite ejecutarse, y cuando requiera de nuevo realizar sus operaciones de E/S, se
devuelve el control al trabajo anterior.
Su objetivo es tener a varias tareas en la memoria principal, de manera que cada uno está
usando el procesador, o un procesador distinto, es decir, involucra máquinas con más de una
CPU.
Sistemas Operativos como UNIX, Windows 95, Windows 98, Windows NT, MAC-OS, OS/2,
soportan la multitarea.
25
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Uno de los problemas más comunes era que los usuarios y los programadores en particular,
tardaban en tener acceso a la máquina (sobre todo en los esquemas de lotes). Tal cuestión
trato de solucionarse por medio de un esquema llamado de tiempo compartido
(timesharing/timeslicing).
La idea de multiprogramación fue extendida para permitir que varias terminales fueran
conectadas a la computadora, y que a cada terminal en uso se le asociaran uno o más trabajos
en la computadora. El SO era entonces responsable de intercalar (switching) los trabajos
(también llamados procesos) de manera que se favoreciera la interacción con el usuario. Si el
cambio de contexto (context-switches) ocurría lo suficientemente rápido y con la suficiente
frecuencia, el usuario tenía la impresión de tener acceso directo a la computadora.
A los procesos interactivos se les da una mayor prioridad, así que cuando una E/S es
requerida (p.ej. una tecla presionada), el control del CPU le es dado al proceso asociado, así
que puede procesarlo. Esto es instrumentado mediante el uso de una interrupción que causa
que la computadora se de cuenta que un evento de E/S ha ocurrido.
Debe mencionarse que existen varios tipos de sistemas de tiempo compartido. Una clase es
representada por computadoras como las VAX/VMS y las estaciones de trabajo UNIX. En estas
computadoras, procesos enteros se encuentran en memoria, y la computadora intercala la
ejecución entre ellos. En otros tipos de sistemas, como los de reservación de vuelos, una sola
aplicación puede hacer la distribución de tiempo entre las terminales. De esta forma no se
necesita ejecutar un programa diferente asociado a cada terminal.
Los Sistemas Operativos de tiempo compartido permiten simular que el sistema y sus
recursos son todos para cada usuario. El usuario hace una petición a la computadora, esta la
procesa tan pronto como le es posible, y la respuesta aparecerá en la terminal del usuario en
un tiempo muy corto, dando la impresión al usuario de tener al sistema bajo su control
exclusivo.
Los principales recursos del sistema, el procesador, la memoria, dispositivos de E/S, son
continuamente utilizados entre los diversos usuarios, dando a cada usuario la ilusión de que
tiene el sistema dedicado para sí mismo. Esto trae como consecuencia una gran carga de
trabajo al sistema operativo, principalmente en la administración de la memoria principal y
secundaria.
26
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Una computadora de tiempo real es aquella que ejecuta programas que están
garantizados en poseer un desempeño superior en las tareas que desarrollan. Por ejemplo los
sistemas de guía de misiles y equipo de monitoreo médico. Las computadoras dedicadas son
computadoras de propósito especial que son usadas para realizar solo una o más tareas.
Comúnmente estas son computadoras de tiempo real que incluyen aplicaciones de control
(misiles, inyección electrónica de gasolina, control automático de trenes, etc.).
Los sistemas operativos de este tipo de computadoras están severamente restringidos por
requerimientos de tiempo.
Los Sistemas Operativos de tiempo real son aquellos en los cuales no tiene importancia
el usuario, sino los procesos. Por lo general, están subutilizados sus recursos con la finalidad de
prestar atención a los procesos en el momento que lo requieran. Se utilizan en entornos donde
son procesados un gran número de sucesos o eventos.
Muchos sistemas operativos de tiempo real son construidos para aplicaciones muy específicas
como control de tráfico aéreo, bolsas de valores, refinerías, etc. También en el ramo
automovilístico y de la electrónica de consumo, las aplicaciones de tiempo real están creciendo
muy rápidamente.
Otros campos de aplicación de los Sistemas Operativos de tiempo real son los siguientes:
- Control de trenes.
- Control automático de procesos químicos.
- Telecomunicaciones.
⊕
Obras consultadas: [1.18] [1.19]
27
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Algunos ejemplos de Sistemas Operativos de tiempo real son: VxWorks, Solaris, Lyns OS y
Spectra.
1. El control de los procesadores. Dos o más procesadores similares están conectados por
medio de conexiones de alta velocidad y son administrados por un sistema operativo, donde cada
procesador tiene el mismo acceso a los dispositivos de entrada/salida. Los procesadores son
tratados más o menos igual, permitiendo que los programas de aplicación se ejecuten en
cualquiera o tal vez, hasta en todos los procesadores del sistema, bajo la dirección del sistema
operativo.
El multiprocesamiento simple usualmente consiste en asignar a cada procesador una tarea fija
(como administrar el sistema de archivos), reservando el CPU principal para tareas generales (fig.
1.15).
⊕
Obras consultadas: [1.20] [1.30] [1.31]
28
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En los Sistemas Operativos Paralelos se pretende que cuando existan dos o más procesos
que compitan por algún recurso, se puedan realizar o ejecutar al mismo tiempo.
En una máquina paralela, el sistema operativo paralelo se construye encima de los sistemas
operativos (o kernels) de cada procesador. Por ejemplo, en la IBM SP-2, el sistema operativo
paralelo consiste de procesadores individuales ejecutando AIX y un componente unificador
paralelo conocido como POE (Parallel Operating Environment).
En UNIX existe también la posibilidad de ejecutar programas sin tener que atenderlos en forma
interactiva, simulando paralelismo (es decir, atender de manera concurrente varios procesos de
un mismo usuario). Así, en lugar de esperar a que el proceso termine de ejecutarse (como lo
haría normalmente), regresa a atender al usuario inmediatamente después de haber creado el
proceso.
Ejemplos de Sistemas Operativos Paralelos son: Alpha, PVM, la serie AIX (que es utilizado en los
sistemas RS/6000 de IBM), Tornado, Hurricane y Helios.
a. Sistemas en red, que consisten de varias computadoras que están conectadas entre si,
usualmente con un sistema operativo común y recursos compartidos. Los usuarios sin embargo,
están informados de las computadoras que conforman el sistema.
Los sistemas operativos de red son aquellos sistemas que mantienen a dos o más
computadoras unidas a través de algún medio de comunicación (físico o no), con el objetivo
primordial de poder compartir los diferentes recursos y la información contenida en cada equipo.
Los Sistemas Operativos de red más usados son: Novell Netware, Personal Netware, LAN
Manager, Windows NT Server, UNIX y, LANtastic.
b. Sistemas distribuidos, también consisten de varias computadoras pero difieren del enfoque
de redes en que estas computadoras son transparentes al usuario. Por lo general hay recursos
redundantes y se comparte la carga de trabajo entre las diferentes computadoras, pero esto es
transparente al usuario (fig. 1.16).
Los sistemas operativos distribuidos permiten distribuir trabajos, tareas o procesos, entre un
conjunto de procesadores. Puede ser que este conjunto de procesadores esté en un equipo o en
diferentes, en este caso es transparente para el usuario.
29
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los sistemas distribuidos deben de ser muy confiables, ya que si un componente del sistema se
descompone, otro componente debe de ser capaz de reemplazarlo. Entre los diferentes Sistemas
Operativos distribuidos que existen tenemos los siguientes: Sprite, Solaris-MC, Mach, Chorus,
Spring, Amoeba, Taos, etc.
La segunda forma en la que los programadores y usuarios retomaron las computadoras fue el
advenimiento de las computadoras personales cerca de 1980. Finalmente las computadoras
fueron suficientemente pequeñas y baratas que un individuo podía tener una (fig. 1.17).
⊕
Obras consultadas: [1.25] [1.26] [1.27] [1.28]
30
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La primera computadora de Tandy fue la TRS-80. La TRS, cuando se presentó, fue un gran
éxito de venta gracias a su poderoso sistema operativo y el creciente numero de aplicaciones
desarrolladas para él. En lo que falló, fue en mantenerse al día en los campos de mejoras de
video y facilidad de uso de su SO.
Las series Apple II (hasta que oficialmente fueron descontinuadas), fue usada por todos los
sistemas escolares y muchos hogares estadounidenses. La Apple tenía varios sistemas
operativos, como el Integer BASIC, el DOS 3.3, y el sofisticado ProDOS.
(a) (b)
(c) (d)
Figura 1.17 Las primeras PCs: (a) MITS Altair (1974), (b) Radio Shack TRS-80 (1977),
(c) Apple I (1976), (d) Apple Lisa (1983).
Sin embargo la mayor contribución de Apple viene con la línea Macintosh. Steve Jobs estaba
buscando una forma para mejorar la Apple II. En diciembre de 1979, fue invitado a participar en
un paseo por el centro de desarrollo de Xerox (PARC), el cual estaba tecnológicamente avanzado
para su tiempo y tenia dispositivos de los que no se había escuchado. Durante este paseo, le
mostraron tres paradigmas revolucionarios: Ethernet, impresoras láser, y lo que más impresiono
a Jobs, la interfaz gráfica de usuario (GUI). De inmediato Jobs vio esto como el futuro de los
sistemas operativos (lo cual se plasmó en LISA).
Cuando Commodore introdujo la PET, era bastante popular, pero no tanto como cuando
introdujo su línea de 8-bits de color, con la VIC-20, la 64 y la 128. El contemporáneo sistema
operativo de Commodore estaba basado en su versión de BASIC. Todos los comandos a
periféricos, los cuales eran "inteligentes" (tenían su propia memoria, procesador y manejadores),
eran hechos por medio de BASIC; la computadora arrancaba en BASIC; y BASIC estaba
construido en ROM.
31
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La Commodore 64 fue la caja maravilla para el mundo desde su llegada en 1982, con gráficos
extraordinarios de 16 colores y sonido 3-voice, basada en la eficiente serie MOS 6500 (como
nota, una variante del 6510 de 16 bits, el 65816, es el que soporta al Super Nintendo). Puesto
que el BASIC no tenia los comandos nativos para manipular muchas de las avanzadas
características de la 64, aparecieron una gran cantidad de accesorios: cargadores rápidos para
mejorar la velocidad de las unidades de disco 1541; extensiones de BASIC de todo tipo, y
mejoras de hardware, como extensiones de RAM, cajas de alta velocidad RS232 e interfaces a
impresoras no-Commodore.
Otra clave fue el sistema operativo GEOS, hecho por Berkeley Softworks (ahora GeoWorks).
Aunque era lento y beligerante, desarrolló un fiel grupo de seguidores por a su poderosa GUI de
80 columnas (a la Mac) en la 64, y la gran cantidad de software existente para el (desde juegos
hasta programas de negocio). La 64 podía incluso comportarse como una PC o estación Unix:
programas como CS-DOS y los potentes sistemas operativos A64/OS y Lunix, que convertían a la
64 en pequeñas versiones de sus competidores más grandes.
OS9 fue uno de los pocos SO, sino el único, multitarea, multihilado y, con un poco de suerte,
multiusuario en los sistemas de 8 bits. Corriendo en sistemas basados en versiones del 6809,
como CoCos, para sistemas 68000 como el Atari STs, e incluso para la Apple II.
La gran piedra angular de los sistemas operativos de 8 bits fue CP/M (el cual casi reemplaza al
MS-DOS como el SO para la PC, de no haber sido por una compañía de software de Redmond,
Washington que hizo un mejor trabajo de relaciones públicas). Desarrollado por Gary Kildall (de
Digital Research) a mediados de los 1970s, CP/M fue el primer SO estandarizado jamás creado
para microcomputadoras. CP/M tenía un conjunto estándar de comandos, (eventualmente) un
DOS estandarizado, e incluso utilerías del sistema.
Las primeras versiones presentadas eran similares al interprete de comandos de CP/M. MS-DOS
fue escrito en lenguaje ensamblador de 16-bits (Intel) por lo que era difícil de portar a otras
máquinas, a diferencia de CP/M, que en su mayor parte estaba escrito en un lenguaje de alto
nivel. El DOS era un SO monousuario y monotarea, donde el usuario puede ejecutar un programa
a la vez hasta su termino.
1.4 Comentarios
32
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
33
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
34
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 2.
Funcionamiento básico de un sistema operativo
Una de las preguntas más sencillas y comunes que podemos hacernos, es ¿cómo funciona un
sistema operativo?, la cual no tiene una respuesta trivial si tomamos en cuenta todos los
elementos relacionados en su funcionamiento. En esta sección se trata de dar una respuesta que
contemple todos los aspectos involucrados, tanto del hardware (donde se ejecuta el SO), como
del software (el propio SO) en la etapa específica en la que el SO toma control del hardware; el
funcionamiento de los componentes específicos del sistema se expone en los capítulos 3, 4 y 5.
Este escenario es básico, pues es lo mínimo indispensable que debe conocerse para construir
un sistema operativo. Debe aclararse que mucho del material de este capítulo se basa en
hardware de arquitectura secuencial y en específico de PCs (Intel), así como la interacción del
software a bajo nivel, lo cual es un proceso bastante genérico para casi todos los sistemas
existentes. No se tratan cuestiones del funcionamiento de servicios más sofisticados como
conectividad con redes o almacenamiento secundario. La idea es mostrar como el SO toma
control del hardware y establece las funciones básicas para ejecutar e implementar servicios más
complejos.
La función principal de una computadora es ejecutar programas, por lo que primero debe
entenderse el funcionamiento del hardware de la computadora. Citando a Von Neumann, "para
que un sistema de computo sea eficiente y de propósito general, debe tener una unidad central
aritmética, una unidad central de control que orqueste todas las operaciones, una memoria, una
unidad de entrada y otra de salida".
⊕
Obras consultadas: [2.1] [2.2]
35
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Un sistema mínimo de hardware está compuesto por un procesador(CPU) que ejecuta las
instrucciones provenientes de una memoria de código (ROM), utilizando posiblemente una
memoria de datos (RAM), e interactuando con dispositivos de entrada y salida (E/S), como
teclado, monitor, discos, etc. Para comunicar a los distintos componentes, se utilizan un
conjunto de cables por los que circulan los datos de un dispositivo a otro, o de un dispositivo a la
memoria y/o CPU, llamados buses (fig.2.2). No hay que olvidar dos componentes esenciales: el
reloj (que es un mecanismo de sincronización) y la alimentación (que es la que provee de energía
a los componentes).
Figura 2.2 El procesador y demás dispositivos se conectan por medio de enlaces físicos
conocidos como buses.
⊕
Obras consultadas: [2.10]
36
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
1
Imagen reproducida de [2.10]
37
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Todo procesador posee un conjunto de instrucciones que puede realizar. Esta colección de
instrucciones es implementada como un patrón de bits, y cada uno tiene un significado diferente
al ser cargado en el registro de instrucción; una forma de representar estos patrones de forma
un poco más legible, es mediante palabras o mnemónicos conocidos como lenguaje
ensamblador. Como ejemplo se presenta el conjunto de instrucciones en lenguaje ensamblador
del procesador de la figura 2.3:
• LOADA mem - Carga el registro A de la dirección de memoria
• LOADB mem - Carga el registro B de la dirección de memoria
• CONB con - Carga un valor constante en el registro B
• SAVEB mem - Salva el registro B a la dirección de memoria
• SAVEC mem - Salva el registro C a la dirección de memoria
• ADD - Sumar A y B y almacenar el resultado en C
• SUB - Restar A y B y almacenar el resultado en C
• MUL - Multiplicar A y B y almacenar el resultado en C
• DIV - Dividir A y B y almacenar el resultado en C
• COM - Comparar A y B y almacenar el resultado en test
• JUMP addr - Saltar a una dirección
• JEQ addr - Saltar si igual, a la dirección
• JNEQ addr - Saltar si no es igual, a la dirección
• JG addr - Saltar si es mayor, a la dirección
• JGE addr - Saltar si es mayor o igual, a la dirección
• JL addr - Saltar si es menor, a la dirección
• JLE addr - Saltar si es menor o igual, a la dirección
• STOP - Detiene la ejecución
A continuación se exponen detalles acerca de la memoria y como el CPU ejecuta los programas.
2.1.2 La memoria⊕
El término memoria es técnicamente cualquier forma de almacenamiento electrónico (fig. 2.4).
Anteriormente se habló de los buses de datos y direcciones, así como de las líneas RD y WR.
Estos buses y líneas conectan tanto a la RAM como a la ROM.
⊕
Obras consultadas: [2.11] [2.15] [2.16]
38
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El ancho de los buses determina la capacidad de bytes de memoria que pueden ser
direccionados, es decir, la cantidad de memoria del sistema. Por ejemplo en el microprocesador
de la figura 2.3, si se tiene un bus de direcciones de 8 bits significa que el procesador puede
acceder a 28 = 256 bytes de memoria, y puede leer o escribir 8 bits de la memoria a la vez.
39
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
conocido como ensamblador puede traducir estas palabras a lenguaje máquina, para después
colocar el resultado en la memoria para su ejecución por medio de otro programa conocido como
cargador.
Para poder ejecutar un programa (fig. 2.5) es necesario traer cada una de estas instrucciones
desde la memoria, hasta un registro de instrucciones (IR) que es interno y no accesible por el
programador, en un proceso denominado fetch. Una vez en este IR, la Unidad Lógico-Aritmética
(ALU) podrá decodificar esta instrucción, y luego determinar cuales son los datos necesarios.
40
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Lo anterior es lo más representativo de la mayoría de los casos, pero existen CPUs que
incorporan muchas más etapas, debido a la complejidad de las instrucciones que procesan.
La operación se hace más compleja cuando el sistema mínimo integra dispositivos adicionales.
En la siguiente sección se analiza la interacción entre los componentes de hardware, donde
veremos que hay nuevas consideraciones para la ejecución de instrucciones.
⊕
Obras consultadas: [2.3]
41
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 2.6 Los componentes de hardware pueden comunicarse con el CPU mediante
controladores.
Pero, ¿cómo se puede enterar el CPU que los datos están ahí? Existen dos formas:
• El método de polling
• El uso de señales de interrupción
La idea más simple, que no tiene porque ser la mejor, es que el CPU este comprobando una y
otra vez si le han llegado datos. Cuando al fin los encuentre, los procesará. Este método es
llamado polling, puesto que la CPU está comprobando el dispositivo continuamente para ver si
tiene información de algún dato. Desgraciadamente, aunque el polling es muy simple, es también
muy poco eficiente. El CPU está desaprovechando su tiempo en espera de que le llegue la
entrada.
Una opción más elaborada es el uso de una señal llamada interrupción, que es la forma en
que el controlador notifica al CPU de la finalización de una operación o la llegada de nuevos
datos. El CPU responde a la señal de interrupción dejando a un lado cualquier cosa que este
haciendo para atender a la interrupción. Una vez que ha terminado de atender (handled) la
interrupción, continua con lo que estaba haciendo antes de ser interrumpida. Por ejemplo,
cuando se presiona una tecla de la computadora, el teclado envía una interrupción al CPU, el cual
responde a esta señal interrumpiendo lo que estuviera haciendo, leyendo la tecla pulsada,
procesándola, y continuando con la tarea que estaba realizando antes de que la tecla se
presionara.
42
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Una interrupción puede ser iniciada específicamente por un proceso en ejecución, en cuyo caso
se le suele denominar trampa (trap) y se dice que está sincronizada con la operación del
proceso; o puede ser causada por algún evento que puede estar relacionado o no con el proceso
en ejecución, en cuyo caso se dice que la interrupción es asíncrona con la operación del proceso.
43
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
4. Interrupciones.
– Pueden ocurrir al finalizar el ciclo de ejecución.
– Se ejecuta si alguna señal de interrupción ha sido emitida.
– Objetivo:
• Guardar la siguiente dirección a ejecutarse.
• Pasar el control a la rutina de interrupción.
• Retornar el control al proceso al terminar la interrupción
Cuando llega una señal de interrupción al CPU, este suspende su trabajo para ejecutar una
rutina de servicio de interrupción (IRS o RSI). Antes de ejecutar dicha rutina, debe
guardarse el estado del procesador, para que pueda continuar con sus actividades después de
ejecutar la RSI.
Debe recordarse que todo esto es un proceso puramente mecánico. La señal de interrupción del
dispositivo, simplemente envía una señal por un cable. El CPU está construido para que cuando
se reciba una señal por ese cable, guarde la información que está manejando en ese momento, y
pueda volver a ese estado más tarde. Esa información consiste en el contenido de los registros
internos importante como pueda ser el contador de instrucciones (PC). El CPU salta a una
dirección de memoria predeterminada y ejecuta las instrucciones allí almacenadas. Estas
instrucciones forman el manejador de interrupciones y definen el proceso necesario a realizar
para responder a la interrupción. (El manejador de interrupciones, es parte del driver del
dispositivo que ha activado la interrupción). Al final del manejador de interrupciones, hay una
instrucción que hace que la CPU realice un salto hasta donde estaba antes, restaurando
previamente los datos guardados.
Una pregunta lógica de este proceso es: ¿cómo se identifica al dispositivo que lanzó la
interrupción? Para ello se tienen dos opciones: preguntar a todos los dispositivos (polling) o que
el dispositivo envíe un numero (su identificador) por el bus (interrupciones vectorizadas).
En el segundo caso, el CPU usa una tabla en memoria con las direcciones de las distintas RSI
que puede ejecutar (por lo tanto el numero enviado por el dispositivo es el índice en el vector de
interrupciones).
Las interrupciones permiten al CPU trabajar con eventos asíncronos. Durante el ciclo regular de
leer-y-ejecutar, las cosas ocurren en un orden predeterminado, todo lo que pasa, esta
sincronizado con todo lo demás. Las interrupciones hacen posible que el CPU pueda tratar
eficientemente las cosas que pasan de manera asíncrona, esto es, en momentos impredecibles.
Un ejemplo del uso de las interrupciones, es lo que pasa cuando el CPU necesita acceder a
datos almacenados en el disco duro. El CPU solo puede acceder directamente a los datos si están
44
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
almacenados en la memoria principal. Los datos del disco, han de ser trasladados a memoria
antes de que puedan ser accedidos. Desafortunadamente, en la escala de velocidades en las que
opera el CPU, el disco es extremadamente lento. Cuando el CPU necesita datos almacenados en
disco, envía una señal para indicarle al manejador del disco donde esta la información, y que esta
preparada para recibirla. Esta señal es enviada en forma sincronizada, bajo el control de un
programa normal. Entonces, en vez de quedarse esperando una importante e impredecible
cantidad de tiempo a que el disco lo haga, el CPU se dedica a alguna otra tarea. Cuando el
manejador del disco tenga los datos disponibles, enviara una señal de interrupción al CPU y el
manejador de interrupciones, leerá los datos solicitados en forma asíncrona.
Tipos de interrupciones
Existen tres tipos de interrupciones que pueden encontrarse en una computadora:
Un ejemplo claro de este tipo de interrupciones es la que actualiza el contador del reloj
interno de la computadora, el hardware hace el llamado a esta interrupción varias veces
durante un segundo para mantener la hora actualizada.
Aunque no podemos manejar directamente esta interrupción (no podemos controlar por
software las actualizaciones del reloj), es posible utilizar sus efectos en la computadora para
nuestro beneficio, por ejemplo para crear un "reloj virtual" actualizado continuamente gracias
al contador del reloj interno. Únicamente debemos escribir un programa que lea el valor actual
del contador y lo traduzca a un formato entendible para el usuario.
Estas interrupciones no son enviadas directamente al CPU, sino que se mandan a un circuito
integrado cuya función es exclusivamente manejar este tipo de interrupciones.
45
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para que el software administre los elementos clave del hardware debe por lo menos
desempeñar las siguientes cuatro funciones:
• Ejecución de programas.
• Asignación de recursos del sistema - La habilidad de organizar y asignar memoria,
canales IRQ's (Interrupt Request Channels), canales DMA's (Direct Memory Access
channels), etc. a los programas y al propio sistema operativo.
• Administración de archivos (I/O) - La habilidad de crear, almacenar y consultar
archivos.
• Acceso a dispositivos - La habilidad para comunicarse con los diferentes dispositivos
de entrada y salida conectados al procesador.
En las siguientes secciones se analizarán los componentes de software que están relacionados
al control del hardware y que conforman al sistema operativo (fig. 2.7).
⊕
Obras consultadas: [2.4] [2.5]
46
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La parte de código del SO para una máquina específica, hablaba directamente con el hardware
de la computadora y ofrecía una serie de servicios genéricos, en forma de manejadores de
interrupciones (interrupt handlers), al resto del sistema operativo. A partir de esto, el SO podía
hacer una petición de un servicio (como el acceso a un archivo en un disco) sin preocuparse
sobre los detalles de como el servicio se llevaba a cabo. La parte especifica de control y
descripción de la máquina en el SO, llamada BIOS (Basic Input and Output System), podía
manejar los accesos específicos de un disco duro de 20Mb ó un floppy de 720Kb.
La decisión original de Gary Kildall de dividir (por conveniencia) su sistema operativo en dos
partes, el BIOS específico del hardware y el SO independiente del hardware es un modelo que ha
permanecido desde entonces.
El BIOS en una PCs está comprimido en una serie de chips, integrados en la tarjeta madre, con
instrucciones (hardwired) para acceder los diversos dispositivos conectados a la PC y para cargar
el resto del código del sistema operativo; este se complementa con un chip CMOS
(Complementary Metal Oxide Semiconductor) reescribible capaz de almacenar la configuración
del hardware definida por el usuario.
1. Rutinas de arranque (Start-Up Routines) Las rutinas de arranque del BIOS son
responsables del POST (Power-On Self Test) o auto-prueba de encendido; el
proceso con el que la computadora prueba el estado de su hardware. De forma
secundaria, estas rutinas inicializan la memoria y crean (en memoria) la tabla del
vector de interrupciones (Interrupt Vector Table) inicial y una tabla con la lista del
equipo. Ambas tablas son referidas (y en algunos casos alteradas) durante el proceso
de BOOT subsecuente. Por último, las rutinas de arranque colocan en memoria la
primera de varias rutinas de carga (bootstrap loader) en memoria. El propósito de
este cargador es simplemente examinar el primer sector de la primera unidad de disco,
47
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
en busca de una firma que identifica a la unidad como de arranque (bootable drive) y
además hasta una segunda (y posiblemente una tercera) rutina de carga que de hecho
carga el primer archivo del sistema operativo.
2. ROM BIOS El ROM BIOS contiene las rutinas de software que permiten el acceso
rudimentario a los dispositivos. Estas rutinas son por lo general, cargadas en memoria
durante el proceso de boot, donde pueden ser accesadas más rápido. Algunas de estas
rutinas permanecen en memoria como destinos de la tabla del vector de
interrupciones, mientras otras son reemplazadas por rutinas más sofisticadas, al
cargarse el sistema operativo.
3. ROM Basic Incluido en los primeros BIOS para dar soporte al lenguaje de
programación BASIC. No se uso mucho durante versiones posteriores.
4. ROM Extensions Las rutinas en el BIOS fueron diseñadas para ser extendidas al
aparecer nuevos dispositivos. Esto fue manejado con la implementación de las
extensiones del ROM BIOS. Leídas en el arranque durante la fase de inicialización,
estas rutinas proveen soporte de bajo nivel a nuevos dispositivos y comúnmente
reemplazan algunos elementos de la tabla del vector de interrupciones.
En la siguiente sección se analizan con más detalle los procesos de POST y BOOT.
Secuencia de arranque
Además de servir como un intermediario entre el hardware de la computadora y el sistema
operativo, el BIOS también sirve para probar el hardware durante el arranque de la
computadora. La secuencia que se sigue durante el arranque consiste de los siguientes pasos:
2. Power-On Self Test (POST). Almacenado en memoria de solo lectura (ROM) en el chip
BIOS se encuentra un pequeño conjunto de instrucciones de software que permiten a la
computadora iniciar el proceso de auto-prueba y configuración. Estas instrucciones incluyen
una serie de diagnósticos o pruebas de encendido:
• Prueba de video: inicializa el adaptador del monitor, prueba la tarjeta de video y la
memoria de video y despliega la información de configuración o cualquier error.
• Identificación del BIOS: despliega la versión del BIOS, fecha y fabricante.
• Prueba de Memoria: Prueba los chips de memoria. La suma de la cantidad de memoria
probada desplegará el total de memoria instalada (hasta puede generarse un sonido
mientras la memoria es revisada). Un mensaje de error en esta parte puede indicar una
falla en los chips de memoria que requerirán que sean reemplazados.
Los errores ocurridos durante el POST pueden clasificarse como "fatales" o "no-fatales". Un
error no-fatal causará que el sistema despliegue el error en pantalla pero puede no impedir
que el sistema continúe con el arranque. Un error fatal, detendrá el sistema y evitará que
continúe con el proceso. Estos errores son desplegados generalmente por una serie de señales
audibles (beep codes).
48
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
etc. La corriente que alimenta al CMOS es enviada por una pequeña batería dentro de la
computadora la cual, mantiene esta información. Las computadoras actuales usan una batería
recargable con una vida media de cerca de diez años, mientras que computadoras más viejas
usan baterías reemplazables con vida útil de aproximadamente dos años.
Las direcciones de memoria son también inicializadas durante esta fase. Las direcciones de
memoria baja son usadas para almacenar tanto la lista de equipo como la tabla del vector de
interrupciones.
En casi todos los casos, el SO es la primera pieza de software que comienza a ejecutarse
después de que el hardware ha terminado el POST (Power On Self Test) o el BIST (Built In Self
Test). Este software por lo general es colocado en una dirección predeterminada de memoria
(que puede ser en RAM, ROM o disco) a la cual es transferido el control automáticamente.
49
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Un ejemplo de este proceso es el sistema de arranque del JavaOS consiste de 128 KB de código
(varia según la implementación), cuyo deber es cargar primero la imagen del núcleo del SO e
informarle de la configuración de dispositivos de la plataforma.
Los detalles para instrumentar programas de carga desde un disco, se pueden consultar en el
Apéndice A.
⊕
Obras consultadas: [2.6]
50
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El arranque por red (network booting) es una idea vieja. La idea central es que la
computadora tenga algún código de bootstrap en memoria no volátil (p.ej. un chip ROM), que
le permita el contacto con un servidor y obtenga los archivos del sistema por medio de una
conexión de red.
Uno de los objetivos es evitar el uso del disco duro para inicializar. Hay varias razones para
hacer esto. Una es reducir el costo de mantener software en diferentes máquinas. Con el
arranque por red los archivos son administrados en un servidor central y pueden ser
actualizados en un solo sitio. Otro objetivo es usar computadoras en sitios donde los discos
duros no son lo suficientemente robustos. Por ejemplo, esto podría ser una computadora en el
piso de una fábrica donde el disco duro puede ser frágil o estar expuesto a golpes. Finalmente,
otro objetivo es tener un sistema que pueda cambiar de sistemas operativos, sin tener que
instalar el software.
Consideremos una computadora sin disco (diskless computer -DC) que tiene una ROM de
arranque en red, y que puede ser una de varias computadoras idénticas. ¿Cómo podemos
distinguir esta computadora de las otras? Hay una pieza de información que es única para esta
computadora que es su dirección Ethernet (contenida en su adaptador de red). Cada adaptador
Ethernet en el mundo tiene una dirección Ethernet única de 48 bits por que cada a constructor
de hardware Ethernet le ha sido asignado un bloque de direcciones. Por convención estas
direcciones están escritas en dígitos hexadecimales donde cada dos dígitos se separan
mediante dos puntos (p.ej. 00:60:08:C7:A3:D8).
Los protocolos para obtener la dirección IP dada una dirección Ethernet, son llamados Boot
Protocol (BOOTP) y Dynamic Host Configuration Protocol (DHCP). DHCP es la evolución del
BOOTP (de hecho casi todo lo aplicable a BOOTP se aplica también en DHCP).
Cuando todos los bloques se han recibido, la ROM de arranque en red le cede el control al
punto de inicio de la imagen del sistema operativo. Finalmente para ejecutar un SO, un
sistema de archivos raíz debe proveerse. El protocolo usado por Linux y otros sistemas Unix es
⊕
Obras consultadas: [2.7] [2.8]
51
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
normalmente el Network File System (NFS), aunque otras opciones son posibles. En este caso
el código no tiene que residir en la ROM pero puede ser parte del sistema operativo que se
descargó. Sin embargo el SO debe ser capaz de ejecutarse con un sistema de archivos raíz que
es un NFS, en lugar de un disco verdadero. Linux tiene las variables de configuración
requeridas para construir una versión que pueda hacerlo.
a. Primero se ejecuta el programa de arranque (bootstrap) que inicializa todos los aspectos del
sistema, como los registros del CPU, controladores de dispositivos, la unidad de administración
de memoria, etc.
• El programa de arranque es el software alojado en memoria ROM (boot firmware)
que controla la computadora desde el momento que se enciende, hasta que el sistema
operativo primario toma control de la máquina. La función principal de este software
es inicializar el hardware y luego, cargar y ejecutar (boot) el sistema operativo.
52
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
b. Se localiza el sistema operativo (puede ser por medio de una rutina en ROM).
• En el caso de las PCs, estas primeras tareas se hacen con un programa que reside en
un chip de memoria llamado BIOS (Basic In-Out System) ROM y que al encender la
computadora, ocupa una posición FIJA de memoria en cualquier PC. Suponiendo que
el BIOS ya ha inicializado todos los dispositivos de la máquina (asignado las
correspondientes IRQs y recursos a los dispositivos), ahora va a proceder a cargar el
sistema operativo. Lo más normal es que intente su carga primero desde un disco. Si
esta carga falla, lo intenta desde el primer disco duro.
c. Una vez localizado, se carga en memoria por medio de un programa llamado Cargador
(Loader).
• Generalmente las partes críticas del SO se mantienen en RAM mientras la computadora
este encendida. Esto permite al CPU tener acceso inmediato al SO, lo que mejora el
rendimiento y funcionalidad de todo el sistema.
• EL IO.SYS inicia la carga y ejecución. Lo primero que busca es otro archivo oculto en la
misma unidad llamado MSDOS.SYS. Este archivo no es un archivo de ejecución, sino un
archivo de parámetros del sistema que en cualquier momento podemos ver (no es
aconsejable tocarlo), con un editor. Mas adelante veremos el posible contenido de este
archivo.
• A continuación el IO.SYS, busca en el directorio raíz de esa unidad un archivo llamado
CONFIG.SYS. Sí el archivo existe, lo lee y ejecuta las instrucciones que lleva dicho
archivo. Básicamente el config.sys, contiene los parámetros del propio sistema y sobre
todo, carga de manejadores de dispositivo. No es obligatorio que exista. Solo si lo
encuentra lo ejecuta.
• A continuación, el IO.SYS, busca el COMMAND.COM, es decir al intérprete de comandos.
• El COMMAND, busca a su vez la existencia de un archivo llamado AUTOEXEC.BAT
también en el directorio raíz de la unidad de arranque y lo lee para ejecutar los
comandos que allí existan. Dichos comandos, serian básicamente programas (no pueden
ser ya manejadores de dispositivos) y algún parámetro de configuración (como el PATH
por ejemplo) propio del interprete de comandos.
53
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Además, ciertas instrucciones de la máquina no pueden ser usadas por cualquiera. Por ejemplo,
la instrucción de paro (Halt) podría ser peligrosa en manos de usuarios maliciosos o descuidados,
por lo que ciertas instrucciones deberían ser usadas solo por usuarios privilegiados. Estas son
llamadas Instrucciones Privilegiadas. Por esta razón la computadora ejecutará sus tareas en
uno de (por lo menos) dos modos:
• Modo Usuario: Donde las instrucciones privilegiadas no pueden ser usadas; en caso de que
se trate de usar una de estas instrucciones el sistema interrumpe la ejecución y genera una
excepción.
• Modo Supervisor (Kernel): Donde todas las instrucciones pueden ser ejecutadas.
Un ejemplo de procesador con modos es el MC6800 [2.19], que define sus modos de la
siguiente manera:
La transferencia del modo supervisor a modo usuario ocurre por una instrucción explicita de
regreso llamada REI (REturn from Interrupt). Cada transferencia al modo de supervisor a causa
de una llamada supervisora debe guardar el estado del emisor, y debería llevar los parámetros
del modo en la petición, y debería dársele seguimiento checando la legalidad de dicha petición.
⊕
Obras consultadas: [2.17] [2.18] [2.19] [2.21]
54
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El código ejecutado en modo supervisor es llamado ejecutivo, y una porción de este es el núcleo
del sistema. La idea de modos separados e instrucciones privilegiadas ha sido tan exitosa que ya
se han encontrado usos para más de dos modos.
Todas estas tareas son muy delicadas, por lo que deben realizarlas programas especializados.
La protección (verificación de nivel de confianza del código) usualmente viene del hardware. El
hardware reconoce el código por medio de un nivel de privilegio (más alto para el kernel).
La regla del pulgar seguida por el procesador es que un código puede siempre disminuir sus
privilegios pero no aumentarlos, excepto en algunas condiciones especiales que son
determinadas por el código de alto nivel de privilegio (las cuales son llamadas trampas o
llamadas al sistema).
El kernel puede proveer ciertos puntos de entrada que permitan la ejecución de cierto código
en el nivel más alto de privilegio en un punto posterior en el tiempo, y esta facilidad es
extensamente usada por el enfoque de manejadores de dispositivos modulares.
2.3 Comentarios ⊕
Con respecto a la protección del hardware mediante el uso de modos, vale la pena comentar
que el principal atributo que distingue a los kernels monolíticos y micro-kernels es lo que sus
respectivas arquitecturas implementan en modo supervisor (kernel mode) de la CPU y lo que se
implementa en el modo usuario (user mode) de la CPU.
⊕
Obras consultadas: [2.22]
55
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La arquitectura monolítica implementa todos los servicios del sistema operativo (controladores
de dispositivos, memoria virtual, sistema de archivos, comunicación en redes, etc.) en el
espacio dominado por el modo supervisor de la CPU. En cambio, la arquitectura micro-kernel
hace una división entre los servicios del sistema operativo dividiéndolos en "alto-nivel"
implementados en el espacio dominado por el modo usuario y "bajo nivel" implementados en el
espacio dominado por el modo supervisor.
56
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
57
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
58
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 3.
Simulación de Hardware y Sistemas Operativos
Escucho y olvido, veo y recuerdo, hago y comprendo.
Proverbio chino
Es muy interesante que algunos autores citen la posibilidad de simular un sistema operativo, así
que en este capítulo se tratará de implementar uno propio para entender los conceptos e ideas
que se han expuesto hasta el momento. Tal vez parecería que aun no se han tratado los temas
suficientes como para emprender un esfuerzo de este tipo, pero cabe aclarar que no se quiere
simular un Windows o un Linux, sino entender las funciones más primitivas del sistema, es decir:
59
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En los apéndices se ha incluido como caso de estudio el código del simulador propuesto en este
capítulo (apéndice B).
Aún cuando se considera que una implantación real es la única forma de comprobar la eficacia
de un diseño, en el caso de los sistemas operativos, la simulación ha sido aplicada por varios
grupos de trabajo. Aún cuando Silberschatz menciona en su tercera edición de Conceptos de
sistemas operativos (pp. 126) que "las simulaciones pueden ser muy caras, al requerir horas de
tiempo de computo, y más cuando se desea mucho detalle", es claro que con el poder de las
actuales computadoras, y lo que está por venir, las consideraciones de recursos pueden quedar
en un segundo plano.
b. SimOS. Simula el hardware de una computadora con detalle suficiente para cargar y ejecutar
sistemas operativos comerciales, además de proveer un ambiente completo de análisis de
ejecución y carga de trabajo (workload).
c. RCOS. Está diseñado para demostrar los principios generales de los sistemas operativos por
medio de animación controlada. Básicamente es una herramienta diseñada para ayudar a la
gente a comprender el funcionamiento interno de un sistema operativo. RCOS es un sistema
operativo multitarea que se ejecuta en hardware simulado, el cual esta basado en la máquina P
⊕
Obras consultadas: [3.1] [3.2] [3.22] [3.23] [3.24]
60
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
e. Flux OSKit (Utah). Es una plataforma con un conjunto de 34 librerías de componentes que
facilita la creación de un nuevo sistema operativo portando un SO existente a otra plataforma
(p.ej. x86), ampliar el soporte de dispositivos, formatos de sistemas de archivos, formatos
ejecutables, o servicios de red; así como construir programas relacionados, como cargadores o
servidores montados sobre un microkernel.
Las librerías contienen el código nativo del OSKit, código para integrar subsistemas y código
legado (fig. 3.1a). La funcionalidad del OSKit se divide en tres categorías: interfaces, librerías de
funciones y librerías de componentes. Las interfaces proveen el “pegamento” nuevos
componentes a un SO. Las librería de funciones proveen servicios básicos de bajo nivel (manejo
de memoria, carga de programas, manejo de interrupciones, etc.). Las librerías de componentes
proveen funcionalidad de alto nivel (administración de memoria y procesos, soporte POSIX,
sistemas de archivos, comunicaciones en red, multimedia, etc.).
f. Palm OS Simulator. Es el simulador del Palm OS 5.0; no es una emulación del hardware
como el PalmOS Emulator, sino el sistema operativo real ejecutándose sobre una DAL (capa de
abstracción de dispositivos). Se usa más como herramienta para validar los posibles errores y
2
Imagen reproducida de [3.24]
61
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
compatibilidad de las aplicaciones en dispositivos PDA que tengan esta versión del sistema (que
en el momento en el que lo descubrí, es una versión de prueba del sistema que esta compañía
liberará, por lo que su estrategia para con los desarrolladores resulta sumamente útil). Se
recomienda su uso en conjunto con el emulador para asegurar una buena compatibilidad de los
desarrollos.
Por lo anterior, puede decirse que los objetivos de la simulación de sistemas operativos
son:
• entender el funcionamiento interno de un SO
• determinación de cargas de trabajo del SO en un procesador especifico (SimOS)
• diseño de nuevas arquitecturas de SOs
Un ejemplo de esto es la propuesta del OSKit con un enfoque basado en componentes, donde
los diseñadores de SOs se beneficiarían de las técnicas de ingeniería de software como la
orientación a objetos y excepciones, tal como los desarrolladores de aplicaciones lo hicieron en la
década de los noventas.
3
Imagen reproducida de [3.22]
62
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Este último enfoque es tal vez el más flexible y más complejo a la vez. En la siguiente sección
se presentan los fundamentos de la simulación de hardware.
Existen 3 esquemas básicos que pueden ser usados para un emulador (y pueden ser
combinados para un mejor resultado):
mientras(CPUEnEjecucion) {
Fetch OpCode
Interpretar OpCode
}
⊕
Obras consultadas: [3.3] [3.4] [3.5]
63
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La única gran debilidad obvia es el bajo rendimiento. La interpretación toma demasiado tiempo
del CPU y puede requerirse una computadora muy rápida para ejecutar el código a una velocidad
razonable.
64
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El enfoque tradicional para simular dispositivos paralelos es tratar a todos los componentes
como si estuvieran sincronizados con respecto a la llamada cola global de eventos (global
event queue). Esta estructura consiste básicamente de una lista ligada de nodos de tiempo,
donde cada nodo tiene un apuntador a una lista de componentes, o eventos, que tienen que ser
procesados en el tiempo indicado.
Todos los eventos ligados al mismo nodo de tiempo están esencialmente en paralelo entre sí.
Cuando un componente produce una salida, todos los componentes que tienen una entrada que
depende de la salida son colocados en la cola global de eventos en el nodo que representa el
momento en que la señal de salida fue producida. Puesto que los nodos de tiempo son
⊕
Obras consultadas: [3.6]
65
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
secuenciales, los componentes conectados a cada uno de los nodos son simulados y más eventos
son planificados para instantes posteriores, reflejando la salida de estos componentes. Esto
continua hasta el fin de la cola de tiempos es alcanzado o el tiempo asignado para la simulación
se acaba.
Un segundo enfoque, las colas de eventos distribuidos, consiste en encapsular una o más
colas dentro de lo mismos componentes, por lo que se elimina todos los problemas inherentes de
mantener una estructura global. Las colas son distribuidas en el componente y pueden existir en
casi cualquier nivel de descripción. Cada cola mantiene la historia de señales que han sido
enviadas al componente durante el curso de la simulación y mantiene una lista de todos los
componentes que están a la espera de la señal. Por lo tanto, la cola distribuida sirve como un
conector entre 2 componentes y también sirve como el medio en que las señales pueden
propagarse en paralelo usando un lenguaje secuencial de programación.
Con respecto al hardware, las colas de eventos distribuidos representan cables; las señales
viajan a través de cables, y los cables conectan a los componentes entre sí. Puesto que las colas
y los cables realizan la misma función y están estrechamente relacionados, el concepto de colas
distribuidas es mucho más atractivo e intuitivo que una cola global de eventos.
⊕
Obras consultadas: [3.7] [3.8]
66
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El término "virtual" ha evolucionado para describir casi cualquier cosa que sea una simulación
de un objeto real, con términos como memoria virtual, discos virtuales, y realidad virtual. En el
caso de las máquinas virtuales se desea que estas se vean y comporten exactamente como una
máquina real. Esto significa que la máquina virtual no es realmente de hecho una máquina, pero
se comporta exactamente como una verdadera.
Todas las máquinas tienen una cosa en común, ya sea un microondas, un refrigerador, una
reproductora de video o una computadora; todas ellas están diseñadas para llevar a cabo ciertos
tipos de conjuntos de instrucciones. Los conjuntos de instrucciones, pueden ser concebidos para
cualquier máquina como piezas (como las de un rompecabezas o Lego) que al unirlas forman un
objeto completo. Con las máquinas, estas piezas son instrucciones, las cuales son usadas para
decirle a la máquina que hacer o que tareas realizar.
En el caso de las máquinas virtuales, lo virtual se refiere a los conjuntos de instrucciones. Hay
muchos tipos de máquinas virtuales, pero lo común entre ellas es la idea de simular un conjunto
de instrucciones. Cada máquina virtual usa un conjunto virtual de instrucciones al que el usuario
tiene acceso, y después la máquina virtual "mapea" estas instrucciones virtuales a instrucciones
reales de la computadora.
Los modelos han sido utilizados para resolver problemas como: particionar una máquina
(modelo IBM), crear una semi-plataforma independiente para lenguajes de programación
(modelo Java), y crear sistemas operativos (modelo Unix y OSI).
El poder y éxito del concepto de la máquina virtual viene de brindar a los usuarios la habilidad
de acceder y utilizar funciones y dispositivos que son simples combinaciones de conjuntos de
instrucciones. La habilidad de proveer una solución virtual a las limitaciones reales de los
sistemas de cómputo modernos es una herramienta muy poderosa que continua extendiendo las
habilidades de los sistemas modernos.
3.3.1 El sistema P⊕
Un caso interesante relacionado a las máquinas virtuales es el sistema P, el cual está
relacionado a RCOS, una de las plataformas de simulación de sistemas operativos que se analiza
en las siguientes secciones.
⊕
Obras consultadas: [3.9] [3.10]
67
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El sistema P es un sistema operativo portable que fue popular en los primeros días de las
computadoras personales, a fines de los 1970s y principios de los 1980s.
El sistema-P, como Java actualmente, estaba basado en una máquina virtual con un conjunto
estándar de instrucciones de "código-p" (p-code es un lenguaje de máquina de bajo nivel para
una máquina de pila hipotética llamada máquina-P, que es una imitación del conjunto de
instrucciones de la Burroughs Large System) que eran emuladas en hardware diferente,
incluyendo el 6502, el 8080, el Z-80, y el PDP-11. En esta forma, un compilador de Pascal que
emitía ejecutables de código-p, podía producir programas que podían ejecutarse en los sistemas
P en las Apple II, Xerox 820, o una DEC PDP-11.
El lenguaje más popular para el sistema P era el UCSD Pascal. De hecho, el sistema operativo
del sistema P estaba escrito en UCSD Pascal, haciendo al SO relativamente fácil de portar entre
plataformas. Al escribir un interprete de código P en el lenguaje ensamblador nativo de la
plataforma y haciendo unos cuanto ajustes mínimos a las funciones del sistema operativo
(sistemas de archivos e interacción con el usuario), era posible llevar ejecutables de un sistema y
ejecutarlos en una nueva plataforma.
∇
Para más detalles sobre la administración de procesos y conceptos relacionados consulte el capítulo 4
68
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Si se desean ver algunos detalles de bajo nivel como el intercambio de procesos, puede verse el
apéndice "Caso de estudio: Implementación de un microkernel".
Hasta el momento se ha establecido que las principales entidades que deben implementarse
son:
• Procesos
• Colas de procesos
Adicionalmente, puede incluirse a los dispositivos, pues como se mencionó hay procesos que
pueden estar relacionados con el uso de los periféricos de la computadora.
Sea entonces un sistema que puede contener uno ó más dispositivos (tomando en cuenta al
CPU como dispositivo), los cuales tienen asociada una cola de procesos. Cada cola puede
implementar un algoritmo de planificación para administrar los procesos creados en el sistema.
Aunque una decisión posible es implementar estas colas con estructuras de datos FIFO, el
asunto es que dichas estructuras consumen memoria y no son la opción de implementación si lo
que se desea es rendimiento y velocidad (además de que lo que deseamos ver es como lo hacen
a bajo nivel)
Lo primero que hay que hacer es contar con un bloque de control de proceso, donde se puedan
integrar los conceptos de identificador de proceso (ID), prioridad, tiempos de respuesta y un
apuntador al proceso siguiente.
69
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
int priority;
int cpu_time_required;
int cpu_time_slice;
int cpu_time_total;
int io_time_required;
int io_time_total;
int response_time;
int time_in;
public int nextPos; /* next process array index--"pointer" */
...
Hecho esto podemos hablar de la estructura que contendrá y planificará a los procesos. Cada
cola debe tener un máximo de procesos que puede atender (esto de forma dinámica tiene que
ver con la memoria disponible del sistema) así como implementar un tipo de algoritmo de
planificación (esto lo implementa la clase OSQueue).
/*** put processes into the queue based on the queue type's ***/
/*** algorithm. The head must be the next in line to leave. ***/
public void insert(int P) {
int ptr, optr=0;
System.out.println("We are in Q insert");
if (curElements == maxElements)
return;
switch(queueType) {
case 1: /* FIFO */
case 5: /* Round Robin */
/* traverse the Q to first */
System.out.println("IN OSQueueInsert, Qtype: "+queueType+
",qHead: "+qHead+" P: "+P);
70
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
ptr = qHead;
if(qHead == -1) {
qHead = P;
OSSystem.ProcessArray[qHead].nextPos = -1;
} else {
optr = ptr;
while(ptr != -1) {
System.out.println("We are in FIFO while ptr = "+ptr);
optr = ptr;
ptr = OSSystem.ProcessArray[ptr].nextPos;
}
OSSystem.ProcessArray[optr].nextPos = P;
}
curElements++;
System.out.println("We are leaving FIFO; current elements: "+
curElements);
break;
}
System.out.println("We are at the end of Q insert");
}
Tomemos como ejemplo la implementación para los algoritmos FIFO y Round robin (que en
este caso es casi lo mismo). En realidad se esta implementando una estructura FIFO, pero lo
interesante es que la inserción solo está operando sobre los índices del arreglo principal de
procesos.
if (devName.equals("CPU")) {
System.out.println("Qtype inside: "+devName);
OSSystem.ProcessArray[curr_process].cpu_time_total++;
if (devName.equals("IO")) {
System.out.println("Qtype inside IO device: "+devName);
OSSystem.ProcessArray[curr_process].io_time_total++;
3.4.2 NachOS⊕
Nachos es un software instruccional que permite a los estudiantes analizar y modificar un
sistema operativo real operacional. Fue desarrollado en la Universidad de Berkeley y es usado por
varias escuelas para la enseñanza de cursos de sistemas operativos.
Como en cualquier sistema operativo, hay un planificador (Scheduler) que mantiene el control
de los procesos en el sistema y los alterna periódicamente, y mantiene una lista de procesos
(readyList) para este propósito. Todos los procesos en Nachos se ejecutan como hilos. Esto
significa que todos los programas que se ejecutan en Nachos son implementados como hilos.
⊕
Obras consultadas: [3.11] [3.12] [3.13]
71
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 3.5 Forma en que los diferentes componentes de Nachos están ligados durante la
ejecución4
El componente Interrupt maneja todas las interrupciones generadas por el componente Timer.
La causa de las interrupciones pueden ser la E/S de algún dispositivo (p.ej. la escritura a un
archivo por parte de un proceso, una señal del planificador para cambiar a otro proceso, etc.).
Todos los sistemas operativos necesitan al hardware para ejecutar sus procesos. El componente
Machine provee dicha funcionalidad, al simular la arquitectura MIPS. El componente FileSystem
administra todas las operaciones de archivos. SynchDisk provee acceso sincronizado al disco.
Para conectar una maquina con otras, se tiene el componente PostOffice que administra la
recepción y envió de mensajes a través de una red. Stats es un componente que mantiene
ciertas estadísticas sobre la ejecución y eficiencia del sistema. Por ejemplo, puede mantener el
rastro de cuantos caracteres han sido escritos en la pantalla, cuantos errores de paginación han
ocurrido, cuantos paquetes han sido recibidos por medio de la red, etc.
La máquina Nachos
Nachos simula una máquina parecida a la arquitectura MIPS. La máquina tiene registros,
memoria y CPU. Además, un reloj simulado manejado por eventos provee un mecanismo para
planificar las interrupciones y ejecutarlas posteriormente. La simulación de la máquina MIPS
puede ejecutar cualquier programa. Solo hay que cargar las instrucciones en la memoria de la
4
Imagen reproducida de [3.11]
72
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
3.4.3 RCOS⊕
RCOS esta implementado en Java (aunque la distribución original está en C++), y pertenece a la
categoría de sistemas operativos basados en kernels.
1. Hardware
2. Sistema operativo
- Kernel. RCOS usa un micro-kernel basado en una estructura de paso de mensajes. El kernel es
responsable de varias funciones específicas de la plataforma incluyendo:
a. manejo de interrupciones
b. salvado/restauración del contexto (saving/retrieving context)
⊕
Obras consultadas: [3.16] [3.17] [3.18] [3.19] [3.20]
73
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
- Paso de mensajes (Message passing). Las funciones estándar del sistema operativo están
divididas en diversos componentes. Toda la comunicación entre ellos debe ser en forma de
mensajes. Todos los mensajes pasan por el componente Post Office que es responsable de
entregar los mensajes a los destinos correctos. La intención es que componentes diferentes
puedan ser localizados en computadoras diferentes.
- Funciones del SO. Las responsabilidades restantes de SO están divididas en los siguientes
componentes:
3. Animación
El sistema de Animación esta oculto del resto del sistema por la clase Post Office Animator. Sus
responsabilidades incluyen:
74
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Aunque sería en extremo interesante poder simular cada una de las configuraciones históricas
de los diversos sistemas operativos (una idea extremista pero interesante si se quiere hacer una
exploración desde los inicios), esto sería en extremo un esfuerzo de mucho tiempo y escapa al
objetivo de este trabajo.
En cuanto todos los conceptos y sus interacciones cobraron sentido, se decidió hacer el intento
de codificar un simulador que hiciera las cosas más sencillas que un SO se supone que realiza. La
primera pregunta que surgió fue: ¿modelar solo el SO, o se requiere modelar también el
hardware donde se ejecuta? Este primer problema no es tan sencillo como podría suponerse.
Modelar una computadora es un ejercicio bastante complejo; y por lo visto hasta el momento un
SO también es un sistema bastante complejo, como para aumentar la complejidad de la
implementación. Sin embargo, hay algunos hechos que no pueden dejarse de lado:
5
Imagen reproducida de [3.17]
75
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Esto deja claro que es necesario modelar el hardware para tener una simulación completa.
Basta con ver los casos de estudio expuestos (NachOS y RCOS) para ver que es necesario
(consulte los detalles de la implementación en el Apéndice. Simulación de un sistema mínimo de
hardware y su sistema operativo).
La URM tiene un numero infinito de registros (R1,R2,R3...) cada uno de los cuales contiene en
todo momento un numero natural. El contenido de los registros puede ser alterado por la URM
en respuesta a ciertas instrucciones que puede reconocer. Estas instrucciones corresponden a
operaciones simples usadas para realizar cálculos con números. Una lista finita de instrucciones
constituye un programa. Las instrucciones son las siguientes:
- Z(n). Instrucción cero. Cambia el contenido del registro Rn a cero, dejando sin alteración a
los demás registros.
- S(n). Instrucción sucesora. Incrementa el valor del número contenido en Rn en 1, dejando a
los otros registros sin alteración.
- T(m,n). Instrucción de transferencia. Reemplaza el contenido del registro Rn por el valor
contenido en Rm.
- J(m,n,q). Instrucción de salto. El contenido de los registros Rm y Rn son comparados; si
rm=rn la URM procede a la instrucción q-ésima del programa en ejecución; si rm<>rn la
URM procede a la siguiente instrucción.
En la implementación original del simulador de la máquina URM, la idea era darle a la máquina
un programa escrito con las instrucciones del modelo, y que este las ejecutara.
Retomar este simulador con el fin de simular un sistema operativo mínimo (SOM) requiere de
nuevas consideraciones y varios cambios. La consideración principal debe ser el separar los
componentes de hardware y software del modelo. Además en la implementación original:
76
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
interface Processor {
/**
ciclo de "fetch" donde la instrucción a ejecutarse se trae de memoria
primaria y se coloca en el IR.
El ciclo de Fetch
-Va al PC
-Va a la dirección que apunta el PC
-Hace IR = MEM[PC]
-Incrementa PC
*/
public void fetchInstruction(Memory m);
En cuanto a la memoria, esta puede modelarse como un arreglo, donde cada celda de memoria
puede contener una instrucción y sus parámetros. Por tanto, el acceso a la memoria es de forma
77
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
lineal, donde el índice del arreglo es equivalente a una dirección (celda) de memoria. Este
acceso, implica la lectura y escritura de datos en memoria. Aunque no forman parte
explícitamente del modelo, se requerirá implementar un par de instrucciones para estos fines
(p.ej. READ/WRITE, GET/SET, IN/out, LOAD ax,dir/LOAD dir,ax, etc.)
interface Memory {
public void setMemLoc(int adr, Object value);
public Object getMemLoc(int adr);
public void showMem();
}
Como se mencionó al principio, lo que se quiere es un sistema operativo mínimo, pero... ¿qué
es eso? En concreto, es una pieza de software que permita cargar un programa a la memoria del
modelo y que el procesador lo ejecute.
78
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Si tomáramos la primera opción, lo primero que salta a la vista es que como el modelo solo
consta de 4 instrucciones, el conjunto de instrucciones tendría que ser ampliado para permitir el
acceso al disco, controlar dispositivos, mostrar resultados en un dispositivo de salida, etc. Aunque
puede hacerse, el modelo se convertiría en un nuevo procesador, y en ese caso sería mejor
emular un procesador con las instrucciones suficientes como para implementar un SO completo.
De esta forma el SOM tendría todas las características de un monitor residente, uno de los
primeros SOs, las cuales pueden extenderse para implementar el procesamiento por lotes
(batch), para lo que se debe incluir un JCL (Job Control Language).
El modelo solo ejecutará un programa a la vez, por lo que la administración de procesos no fue
implementada. Además con la simplificación del acceso a memoria tampoco se necesita un
administrador de memoria, aunque pudiera ser útil si se quisiera expandir la memoria base del
modelo.
79
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 3.8 Modelo del simulador con un SOM para una URM modificada, basado en el
concepto de un monitor residente.
80
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Aunque sin incorporar el manejo de interrupciones, dispositivos, etc., este primer diseño es lo
bastante ilustrativo como para entender lo que hace un sistema operativo, y como codificarlo (a
un nivel muy básico).
En la siguiente sección se comentan algunos de los elementos que no han sido considerados en
el simulador, pero podrían ser modelados para incluir los aspectos del manejo de dispositivos,
pero por el momento eso no está incluido en la implementación del apéndice B.
Para mejorar el modelo propuesto, será entonces necesario incluir el sistema de E/S en el
simulador. Puede resumirse de lo expuesto en la sección 1.4.2, que los elementos a tomar en
cuenta son:
• El dispositivo
⊕
Obras consultadas: [3.14]
81
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
a. Modelar un dispositivo abstracto, con un protocolo de mensajes que sea aceptado por
cualquier implementación de un dispositivo específico. El dispositivo genérico deberá proveer
como mínimo la lectura y escritura de sus datos, así como su configuración e identificación. Esto
será ampliado después por las implementaciones específicas, pero debe tomarse en cuanta que
el protocolo de mensajes puede verse ampliado, según el tipo de dispositivo (un monitor es
mucho más complejo que un teclado en su funcionamiento e interfaz).
- Las interrupciones, que notifican al CPU de una operación o llegada de nuevos datos.
- Las rutinas de servicio de interrupción (ISR), que son los procesos que se ejecutan
cuando llega una señal de interrupción y el CPU debe atenderla.
- El vector de interrupciones, que es una tabla en memoria con las direcciones de las ISRs
con que se cuenta.
d. Puede tenerse en cuenta el mecanismo de acceso directo a memoria (DMA), por medio del
cual los dispositivos tienen acceso a la memoria principal sin necesidad de que el CPU intervenga.
Ahora hay que revisar si el modelo actual permite la comunicación entre los dispositivos y
el CPU. Puesto que todo lo anterior no fue considerado desde un principio, es casi seguro que se
tenga que modificar una buena parte de la estructura del modelo.
82
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
3.5.4 Resultados
La estrategia para la construcción del modelo de simulación consistió en modelar los principales
servicios de administración de los sistemas operativos (procesos, memoria y dispositivos), para
después integrarlos en diferentes configuraciones, esperando que la tarea de integración arroje
problemas y consideraciones que aporten soluciones y experiencias interesantes para la
comprensión del diseño e implementación del simulador.
Aunque al principio se había planteado solo codificar los algoritmos y módulos que son
importantes para los sistemas basados en núcleos modulares (los más difundidos actualmente),
la simulación de cada una de estas partes, y del hardware relacionado a su funcionamiento, ha
dado como resultados algunas configuraciones similares a los primeros sistemas (sencillos pero
muy ilustrativos). Lo positivo de esto, es que se brinda al lector una perspectiva real, no sólo de
como funciona un sistema operativo y como hacerlo, sino de todas las reflexiones y decisiones
que involucra su diseño.
83
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Debo hacer notar que el enfoque de simular el hardware y el SO, es el más completo. Sin
embargo, en los siguientes tres capítulos es probable que se simulen solo los elementos
relacionados a cada sistema de administración, o probablemente solo se modelen puramente los
elementos de administración, sin el hardware. Ambos enfoques considero que siguen siendo
válidos, sobre todo para aclarar que hace cada parte y tomar a sus simulaciones como pruebas
de concepto.
3.5.5 morfo-Hardware
Uno de los resultados adicionales de este primer modelo de simulación fue la idea de crear un
sistema de hardware que pudiera modificarse para probar diferentes conjuntos de instrucciones.
A este modelo se le llamó morfo-Hardware.
84
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La idea es contar con una abstracción genérica de un dispositivo de hardware (HWDevice), del
cual se puedan derivar procesadores, memoria, y dispositivos periféricos, quienes se comunican
por medio de señales administradas por medio de un controlador.
Se incluyen algunos de los diagramas de clases preliminares de este modelo (figuras 3.11 y
3.12), pues a consideración del autor esto sería de mucha utilidad si se quieren comprobar
cuestiones de portabilidad de una plataforma de hardware a otra.
85
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Lo interesante del modelo es que una vez que el framework quede establecido solo hay que
codificar el conjunto de instrucciones del nuevo procesador; todo lo demás quedaría intacto. En
fin, esta es una idea que sigue en desarrollo.
3.6 Comentarios
Como ya se comentó, simular el hardware puede ser una tarea exhaustiva, y dependerá mucho
del nivel de detalle y realismo que se desee en el simulador. Para muchos fines bastará con
incluir en los modelos elementos que efectúen las operaciones básicas de los dispositivos de
hardware; sobre todo si en lo que se quiere hacer énfasis, es en los componentes del sistema
operativo. En tal caso debe tenerse en cuenta que muchos algoritmos relacionados a la
administración de recursos ya están disponibles, por lo que es deseable hacer énfasis en el
análisis y visualización de resultados.
Ya que se han planteado los principales elementos para la simulación de sistemas operativos,
en los siguientes dos capítulos se planteará el desarrollo de simuladores para los subsistemas de
administración de memoria y de procesos, respectivamente.
86
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[3.9] THE UCSD P-SYSTEM MUSEUM IN THE WEST [3.20] Not just another teaching operating system
WING OF THE JEFFERSON COMPUTER MUSEUM
http://webfuse.cqu.edu.au/Information/Resources/Rea
http://www.threedee.com/jcm/psystem/index.html dings/RCOS.java/njato/
http://cq-pan.cqu.edu.au/david-jones/Projects/rcos/
[3.10] The Free Online Dictionary of Computing Edited
Denis Howe
[3.21] Modern Operating Systems Simulators
http://foldoc.doc.ic.ac.uk/
http://www.ontko.com/moss/
[3.11] NACHOS
[3.22] Palm OS Simulator
http://http.cs.berkeley.edu/~tea/nachos/
http://www.palmos.com/dev/tools/simulator/
[3.13] A Road Map Through Nachos. Thomas Narten. [3.24] The OS Kit Project
Department of Computer Sciences, Levine Science http://www.cs.utah.edu/flux/oskit/
87
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
88
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 4.
Administración de la memoria
Para hacer una tarta de manzana,
primero tienes que crear un universo.
Carl Sagan, Cosmos
Los sistemas operativos ofrecen un mecanismo para que el software acceda a la memoria. En el
enfoque más sencillo, la memoria entera de la computadora se dedica a los programas. Este
enfoque es el más común en sistemas de una sola tarea (solo un programa se ejecuta a la vez).
Incluso en este caso, existirán porciones de la memoria designados para ciertos propósitos
(variables, áreas para las rutinas del SO, mapeo del hardware, memoria de video, etc.).
Con el hardware de soporte para memoria virtual, los sistemas operativos pueden darle a los
programas la ilusión de tener la memoria entera para ellos (o incluso dar la ilusión de que hay
más memoria de la que en realidad exista, usando el espacio en disco), cuando en realidad el SO
está moviendo continuamente programas en la memoria y asignando dinámicamente la memoria
cuando se necesita.
4.1 La memoria⊕
La memoria es una colección de elementos (bytes o words), cada uno con su propia dirección.
La interacción con la memoria se lleva a cabo por medio de una secuencia de lecturas o
escrituras a direcciones específicas.
⊕
Obras consultadas: [4.14]
89
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El CPU intercambia datos de forma intensiva con la memoria. En un ciclo típico de instrucción,
por ejemplo, primero se obtiene una instrucción de la memoria; la instrucción es entonces
decodificada y puede causar que los operandos sean traídos de la memoria. Después de ejecutar
la instrucción sobre los operandos, los resultados pueden ser almacenados en la memoria.
En los programas, las ubicaciones de memoria a las que se hace referencia son llamadas
direcciones lógicas, porque una dirección especificada por un programa puede o no ser la
dirección física correcta.
Básicamente hay tres formas diferentes de que las direcciones lógicas sean mapeadas a
direcciones físicas, lo cual es llamado ligado de direcciones (address binding). Estás técnicas
de ligado dependen de los métodos de administración de memoria que el SO de la computadora
use y el hardware disponible:
90
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
corresponden a las direcciones físicas 000 - 999. Por ejemplo, consideremos un sistema simple
donde el SO reside en las direcciones físicas 000 - 500, por lo que cualquier programa tendría
que comenzar en la dirección 501. Un programa que tiene el espacio de direcciones lógicas 000 -
999 podría ser modificado para que sus direcciones lógicas correspondan con las direcciones
físicas 501 - 1500. Si el programa se compiló para una dirección específica, pero tiene que ser
cargado en una dirección diferente de arranque, entonces el programa tendrá que ser
recompilado. Los sistemas modernos no usan este método por no ser flexible.
⊕
Obras consultadas: [4.6] [4.7] [4.8] [4.9]
91
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las direcciones generadas por el CPU, después de cualquier indexación u operación realizada
por los modos de direccionamiento, es llamada dirección virtual, y la dirección transformada
por la MMU es llamada dirección física (fig. 4.3).
Figura 4.3 Cuando el CPU quiere acceder a la memoria, le manda la dirección que
quiere a la MMU quien la traduce en otra dirección que le pasa a la unidad de memoria.
La MMU incluye una pequeña cantidad de memoria que contiene una tabla que relaciona las
direcciones virtuales y las direcciones físicas; esta tabla es llamada TLB (Translation Look-
aside Buffer). Todas las peticiones de datos son enviadas a la MMU, la cual determina si los
datos están en la RAM o es necesario extraerlos de un medio de almacenamiento secundario. Si
los datos no están en memoria, la MMU genera una interrupción de falló de página (page fault
interrupt).
Memoria asociativa
La memoria asociativa se basa en el principio de localidad que establece que la mayoría
de programas tiende a referenciar un porcentaje reducido de sus páginas durante períodos
relativamente largos de tiempo. Con base en este principio se equipa a los computadores de un
dispositivo de hardware para asociar las direcciones virtuales con las direcciones reales (físicas)
92
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
sin tener que recurrir a la tabla de páginas. Este se encuentra en la MMU y consta de un
número pequeño de entradas (8, 16, 32 son cantidades típicas), cada una de las cuales tiene la
estructura similar a una entrada en una tabla de páginas convencional.
- Compile and go: (compile y ejecute). Son los utilizados por los compiladores tipo Turbo
(Pascal, C, Prolog, etc.), cuando la compilación se realiza directamente a la memoria. La idea
central consiste en que a medida que se va compilando se va escribiendo directamente sobre la
memoria el código ejecutable y una vez se termine el proceso, se le da el control al programa
compilado para su ejecución.
- Cargadores Absolutos: Existen en sistemas en los que los compiladores generan código
absoluto (no relocalizable). De esta forma se obliga a que el programa siempre se deba carga en
⊕
Obras consultadas: [4.14]
93
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
las mismas posiciones de memoria. Son relativamente simples pero no permiten tener
multiprogramación.
- Cargadores Relocalizadores: permiten cargar el programa en cualquier sitio de la memoria.
Para que esto sea posible, es necesario contar con algún mecanismo de relocalización.
- Cargadores Dinámicos: Cargan los procedimientos del programa dinámicamente durante su
ejecución. Son necesarios en el caso de presentarse recubrimientos.
- Cargadores en memoria virtual: Para cargar un programa en memoria virtual este primero
se mueve a una zona de módulos cargables en el espacio auxiliar y creando las correspondientes
entradas en la tabla de páginas, las cuales deben quedar con el bit presente/ausente apagado, lo
que implica que las páginas aún no están en la memoria real, a pesar de que el programa ya está
cargado en la memoria virtual. Este mecanismo recibe el nombre de acoplamientos y también se
utiliza para realizar operaciones de E/S (fig. 4.4).
Overlays⊕
¿Cómo implementar múltiples programas en un sistema operativo usando direcciones
absolutas? o en las primeras computadoras, ¿Cómo se implementaba un programa que era
más grande que la memoria RAM disponible (especialmente en una época donde los
procesadores apenas tenían más de 1k, 2k, o 4k de RAM? La respuesta más fácil eran los
sistemas de recubrimientos.
Así, aunque el tamaño combinado del programa, los datos y la pila excediera el tamaño de la
memoria física disponible, el SO podría ejecutar el programa. Aquellas partes del programa que
estén en uso son almacenadas en memoria principal; el resto en el disco. Por ejemplo, un
programa de 16Mb puede ejecutarse en una máquina con 4Mb escogiendo que partes deberían
mantenerse en memoria, y cuales en disco. Las piezas del programa eran intercambiadas entre
la memoria y el disco como se fuera requiriendo (fig. 4.5).
⊕
Obras consultadas: [4.14]
94
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Relocalización
La relocalización consiste en ajustar las direcciones de un programa al sitio donde fue
cargado, para que este pueda ser ejecutado. Este proceso es indispensable para poder tener
multiprogramación, puesto que un programa no siempre va a ocupar las mismas posiciones de
memoria.
Para su ejecución el programa debe ser traducido a lenguaje de máquina. Sin embargo el
ensamblador no conoce el sitio en donde va a ser cargado el programa y por lo tanto no puede
traducir adecuadamente las referencias a la memoria. Si el programa fuese cargado en la
posición 0, por ejemplo, y suponiendo que las variables f y g están en las posiciones 50 y 54
respectivamente, con respecto al inicio del programa, el programa generado sería:
6
Imagen reproducida de [G12]
95
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Sin embargo, si el programa fuese cargado a partir de la posición 100, el código debe
relocalizarse y sería:
Una de las primeras tareas del sistema operativo es organizar una estructura heterogénea de
memoria (resultado de las constantes presiones de los fabricantes de sistemas y dispositivos
periféricos por mantener la compatibilidad con sus esquemas de memoria originales), asignando
direcciones lógicas a direcciones de memoria física (en conjunto con el bus de memoria) y
asignando varias áreas reservadas a la tabla del vector de interrupciones, memoria de video y
código del BIOS.
⊕
Obras consultadas: [4.1] [4.2] [4.3] [4.4] [4.5]
96
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
incremento en el desempeño deben mantenerse varios procesos en la memoria, por lo que esta
debe poder compartirse.
Su labor consiste en llevar un registro de qué partes de la memoria se están utilizando y qué
partes no (donde están almacenados los procesos y datos), con el fin de asignar espacio a los
procesos cuando estos hagan requerimientos, liberarlo cuando terminen, así como administrar el
intercambio entre la memoria principal y el disco, en el caso en que esta no pueda albergar a
todos los procesos. También facilita los mecanismos de protección para que un proceso no
invada el espacio de otros procesos.
Es muy común para los programadores que se encuentran con un administrador manual
ineficiente o inadecuado, escribir código para duplicar el comportamiento de un administrador de
memoria, ya sea alojando grandes bloques o partiéndolos para usarlos, o reciclando los bloques
internamente. Tal código se conoce como subalojador (suballocator). Los subalojadores pueden
tomar ventaja del conocimiento especial del comportamiento del programa, pero son menos
eficientes que arreglar el alojador. Los subalojadores pueden ser ineficientes o ineficaces a
menos que un experto en administración de memoria lo implemente.
97
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• provee máxima flexibilidad al usuario, pues se puede controlar el uso de la memoria como se
desee;
• máxima simplicidad;
• no se necesita soporte de hardware adicional para la administración de la memoria;
• se tiene la capacidad de ejecutar un solo proceso;
• NO se necesita de un sistema operativo.
Este esquema es usado solamente en sistemas dedicados donde los usuarios requieren
flexibilidad y se requiere de rutinas de soporte propietaria.
⊕
Obras consultadas: [4.10]
98
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Pero además esto tiene sus limitaciones: NO PROVEE NINGUN SERVICIO; es decir que
aunque el usuario tiene control total sobre la computadora, el SO no tiene:
• control sobre las interrupciones,
• ni mecanismos para llamadas a procesos o errores,
• y ningún espacio para proveer capacidades de multiprogramación.
Por lo anterior será necesario explorar esquemas que permitan proveer servicios a las
aplicaciones y al sistema operativo.
La organización física bajo este esquema es muy simple: El sistema operativo se ubica en las
localidades superiores o inferiores de la memoria, seguido por algunos manejadores de
dispositivos (drivers). Esto deja un espacio contiguo de memoria disponible que es tomado por
los programas del usuario, dejando generalmente la ubicación de la pila (stack) al último, con
el objetivo de que ésta pueda crecer hasta el máximo posible.
Bajo este esquema no se requieren algoritmos sofisticados para asignar la memoria a los
diferentes procesos, ya que éstos son ejecutados secuencialmente conforme van terminando.
⊕
Obras consultadas: [4.11]
99
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
De esta forma solo se puede ejecutar un programa a la vez y entonces se hace un mal uso
del procesador y de la memoria, pues usualmente los usuarios no ocupan todo el espacio
disponible. Otro inconveniente es que no se puede correr un programa más grande que la
memoria disponible sin recurrir a recubrimientos (overlays). Además se requiere de
mecanismos de protección para proteger al sistema operativo contra los programas del usuario.
Algunos de los inconvenientes que presenta este modelo, son los siguientes:
- Se hace una mala utilización de la memoria debido a la poca flexibilidad del método.
- Es complicado correr programas más grandes que el tamaño de la zona.
- Se presenta fragmentación interna. Este fenómeno ocurre cuando un proceso no ocupa toda
la memoria asignada y sin embargo el espacio libre no puede ser utilizado por ningún otro
proceso.
100
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para solucionar este problema, se puede recurrir a realizar una compactación de la memoria,
siempre y cuando se cuente con relocalización dinámica. Este procedimiento puede ser muy
costoso en tiempo.
• A pesar de que para ejecutar un programa solo se necesita tener cargado una parte de él,
en este modelo se hace necesario tener todo el código en memoria.
• La administración de la memoria no es tan sencilla como en el caso de particiones fijas.
101
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El tamaño de la unidad de asignación define qué tan grande será el mapa de bits. Si la unidad
de asignación es pequeña, el mapa de bits será mayor, caso contrario ocurre si la unidad de
asignación es grande. Sin embargo, si se define demasiado grande puede generar problemas
de fragmentación interna. Cuando un proceso, solicita un espacio de tamaño k unidades, el
sistema debe buscar una cadena de k bits de ceros consecutivos.
7
Imagen reproducida de [4.5]
8
Imagen reproducida de [4.5]
102
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Esta lista puede estar ordenada por direcciones en cuyo caso la actualización de la misma al
terminar un proceso es casi que inmediata. Un proceso que termina tiene por lo general dos
vecinos (uno por arriba y uno por abajo), a menos que se encuentre en algún extremo de la
memoria.
Cuando los procesos y los huecos se mantienen en una lista ordenada por direcciones, se
pueden utilizar diversos algoritmos para asignar la memoria para un proceso de reciente
creación. Se supone que el administrador de memoria conoce la cantidad de memoria a
asignar. Entre ellos están:
Estos cuatro algoritmos pueden agilizarse si se tienen dos listas independientes, una para los
procesos y otra para los huecos. De esta forma todos ellos, pueden limitarse a inspeccionar la
lista de huecos y no la de los procesos. Sin embargo, el aumentar la velocidad implica que la
complejidad se aumenta y la velocidad al liberar la memoria se aumenta, ya que un segmento
liberado, debe ser liberado de la lista de procesos y adicionado a la lista de huecos.
Para la gestión de memoria existe dos sistemas que se pueden diferenciar claramente: los
que durante la ejecución intercambian procesos entre la memoria principal y el disco, y los que
no. Los segundos como es de suponer son los más sencillos.
103
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Dentro de esta forma de gestión de memoria existen también diferentes estrategias. La más
sencilla es la de tener un solo programa en memoria ejecutándose que la ocupe toda, pero
este método es nefasto porque el aprovechamiento de la memoria es mínimo. La otra forma es
tener particiones de la memoria de tamaño fijo de forma que puedan coexistir varios
programas en la memoria principal. Así se da soporte para la multiprogramación pero se
generan 2 problemas: la reubicación y la protección.
Estos dos problemas están íntimamente ligados y consisten en que los programas pueden
saltar a direcciones de memoria que no pertenecen a su área de direcciones. Estos problemas
se soluciona dotando a la máquina registros especiales llamados registro base y registro límite,
de forma que el programa genera direcciones virtuales y para acceder a la dirección real se
utilizan estos registros. La dirección de memoria se calcula sumando al a dirección virtual la
dirección contenida en el registro base y sólo puede llegar a la posición indicada en el registro
límite.
Intercambio (Swapping)
El esquema de intercambio es útil en los sistemas de tiempo compartido. En estos sistemas
cuando se ha finalizado una transacción con el usuario, se entra en un período de espera
relativamente largo en términos del tiempo del procesador, mientras el usuario responde.
Durante este tiempo, se puede cargar un nuevo programa en la zona asignada al usuario. Para
ello, se requiere transferir el primer programa a la memoria auxiliar (disco) y cargar un nuevo
programa en la zona. Cuando este finalice su transacción, se puede volver a cargar el primer
programa (fig. 4.11).
104
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El sistema operativo mantiene una tabla que indica qué partes de la memoria están
desocupadas, y cuáles en uso. Las partes desocupadas son hoyos en la memoria; inicialmente,
toda la memoria es un solo gran hoyo. Cuando se crea un proceso o se trae uno del disco, se
busca un hueco capaz de contenerlo, y se pone el proceso allí.
Las particiones ya no son fijas, sino que van cambiando dinámicamente, tanto en cantidad
como en ubicación y tamaño. Además, cuando un proceso es pasado a disco, no hay ninguna
garantía de que vuelva a quedar en la misma posición de memoria al traerlo de vuelta, de
manera que es imprescindible el apoyo del hardware para hacer ligadura en tiempo de
ejecución.
Si los procesos pueden crecer, conviene reservar un poco más de memoria que la que
estrictamente necesita al momento de ponerlo en memoria. Al hacer swapping, no es necesario
guardar todo el espacio que tiene reservado, sino sólo el que está usando.
Otro punto que hay que tener en cuenta al usar swappping, es la E/S que pudiera estar
pendiente. Cuando se hace, por ejemplo, input, se especifica una dirección de memoria donde
se va a poner lo que se lea desde el dispositivo. Supongamos que proceso A trata de leer del
disco hacia la dirección d, pero el dispositivo está ocupado: su solicitud, por lo tanto, es
encolada. Entretanto, el proceso A es intercambiado a disco, y la operación se completa cuando
A no está en memoria. En esas circunstancias, lo leído se escribe en la dirección d, que ahora
corresponde a otro proceso.
Memoria virtual⊕
En tiempos pasados cuando un programa era más grande que el tamaño de la memoria, este
debía dividirse en módulos o partes e irse cargando a medida que se iban necesitando
(recubrimientos). Este trabajo correspondía al programador y esto además de ser un trabajo
engorroso implicaba pérdida de tiempo. Posteriormente se creó un mecanismo para encargarle
este trabajo en su totalidad al sistema operativo.
⊕
Obras consultadas: [4.12] [4.13]
105
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La memoria virtual se llama así porque el programador ve una cantidad de memoria mucho
mayor que la real, y en realidad se trata de la suma de la memoria de almacenamiento
primario y una cantidad determinada de almacenamiento secundario. El sistema operativo, en
su módulo de manejo de memoria, se encarga de intercambiar programas enteros, segmentos
o páginas entre la memoria real y el medio de almacenamiento secundario. Si lo que se
intercambia son procesos enteros, se habla entonces de multiprogramación en memoria real,
pero si lo que se intercambian son segmentos o páginas, se puede hablar de
multiprogramación con memoria virtual.
En los sistemas que utilizan memoria virtual, todas las direcciones son virtuales y el conjunto
de todas ellas conforman el espacio de direcciones virtuales. En los computadores donde no
hay memoria virtual, la dirección se coloca directamente sobre el bus de la memoria, lo que
permite que se pueda acceder a la palabra de la memoria física que tenga tal dirección. Al
utilizar memoria virtual, las direcciones no pasan directamente al bus de memoria, sino que van
a una unidad de administración de la memoria (MMU), un conjunto de chips que asocian
las direcciones virtuales con las direcciones de memoria física.
Todas las referencias a memoria dentro de un proceso son direcciones lógicas que se
traducen dinámicamente a direcciones físicas durante la ejecución. Esto quiere decir que un
proceso puede cargarse y descargarse de memoria principal de forma que ocupe regiones
diferentes en instantes diferentes a lo largo de su ejecución.
9
Imagen reproducida de [4.5]
106
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La memoria virtual se apoya en varias técnicas interesantes para lograr su objetivo. Una de las
teorías más fuertes es la del conjunto de trabajo, la cual se refiere a que un programa o
proceso no está usando todo su espacio de direcciones en todo momento, sino que existen un
conjunto de localidades activas que conforman el conjunto de trabajo. Si se logra que las
páginas o segmentos que contienen al conjunto de trabajo estén siempre en RAM, entonces el
programa se desempeñará muy bien.
Otro factor importante es si los programas exhiben un fenómeno llamado localidad, lo cual
quiere decir que algunos programas tienden a usar mucho las instrucciones que están cercanas
a la localidad de la instrucción que se está ejecutando actualmente.
107
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
tiende a hacer suposiciones sobre la forma en que los programas van a usar la memoria,
como tamaños típicos de bloques, patrones de referencia, o tiempos de vida de los objetos.
Si tales suposiciones están equivocadas, entonces el administrador de memoria puede gastar
mucho tiempo tratando de lidiar con lo que en realidad este sucediendo.
• Complejidad de la interfaz. Si los objetos son pasados entre módulos, entonces el diseño
de la interfaz debe considerar la administración de su memoria.
Un administrador de memoria bien diseñado puede hacer más fácil crear herramientas de
depuración, porque mucho del código puede ser compartido. Tales herramientas podrían
desplegar objetos, ligas de navegación, validar objetos o detectar acumulaciones anormales de
cierto tipo de objetos o tamaños de los bloques de memoria.
b. Interfaz Intra-Kernel
• kmalloc() / kfree() - aloja y libera memoria para el uso de las estructuras de datos
del kernel
• verify_area() - verifica que una región de memoria de usuario sea relacionada con
los permisos correspondientes
• get_free_page() / free_page() - aloja y libera página de memoria física
Además de las interfaces, el administrador construye todas sus estructuras de datos y la mayor
parte de sus rutinas están disponibles en el kernel. Varios de los módulos del kernel se
comunican con el administrador por medio del acceso a las estructuras de datos y detalles de
implementación del subsistema.
108
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
10
Imagen reproducida de [4.15]
109
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
11
Imagen reproducida de [4.16]
⊕
Obras consultadas:[4.3] [4.11]
110
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Cuando un proceso llega y necesita memoria, el sistema operativo busca en la tabla un espacio
suficientemente grande para el proceso. Si tal espacio está disponible, la memoria es asignada al
proceso. Cuando un proceso termina su ejecución, libera su memoria, la cual puede ser asignada
por el sistema operativo a otro proceso.
La asignación no contigua significa que la memoria se asigna de tal modo que partes de un
objeto lógico pueden ser colocadas en áreas no contiguas de memoria física.
Por lo general, el alojador recibe memoria del sistema operativo en un pequeño numero de
grandes bloques que deben ser divididos para satisfacer las peticiones por bloques más
pequeños. También hace que los bloques regresados estén disponibles para su reutilización.
Las simulaciones han mostrado que los las técnicas first-fit y best-fit son mejores que el worst-
fit en términos de disminuir el tiempo e incrementar el uso del almacenamiento.
111
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Otro problema que puede ocurrir con el alojamiento contiguo es la fragmentación interna. Si
a un proceso le es asignada más memoria de la que necesita por que no había un espacio
disponible en el que ajustara exactamente, habrá memoria que el proceso tiene pero no ocupa.
La fragmentación interna es entonces interna al proceso.
Subalojadores
Hay muchos ejemplos de programas de aplicación que incluyen adicionalmente código de
administración de memoria, llamado un subalojador. Un subalojador obtiene grandes bloques
de memoria del sistema de administración de memoria, y asigna la memoria a la aplicación en
piezas más pequeñas. Los subalojadores por lo general se escriben por alguna de las siguientes
razones:
• Para evitar ineficiencia general en el sistema de administración de memoria;
• Para tomar ventaja de conocimiento especial de los requerimientos de memoria de la
aplicación que no pueden ser expresados al sistema de administración de memoria;
• Para proveer servicios de administración de memoria que el sistema de administración no
ofrece.
En general, los subalojadores son menos eficientes que tener un solo administrador de
memoria que esté bien escrito y tenga una interfaz flexible. Es también más difícil evitar
errores de administración de memoria, si el administrador de memoria se compone de varias
capas, y si cada aplicación tiene su propia versión del subalojador.
Muchas aplicaciones tienen uno o dos tamaños de bloques que forman la mayoría de sus
asignaciones. Uno de los usos comunes del subalojador es suplir a la aplicación con objetos de
un tamaño uniforme, lo que reduce el problema de fragmentación externa.
4.3.4 Paginación
La paginación consiste en considerar el espacio de direcciones lógicas de cada proceso como
un conjunto de bloques de tamaño consistente llamados páginas. Cada dirección lógica
manejada para un proceso estará conformada por un par de valores [página:
desplazamiento] (fig. 4.15).
112
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 4.15 En la paginación el tamaño de la página debe ser una potencia de 212
Las páginas de un proceso son mapeadas en la memoria principal usando una tabla de
páginas, que define que parte de la memoria física contiene a la página en particular. La
implementación de la tabla de páginas puede ser:
1. Implementada completamente en hardware.
a. VENTAJA: Se obtiene una alta velocidad de acceso a memoria.
b. DESVENTAJA: Resulta problemática cuando la tabla de páginas debe ser
grande.
2. Implementada en la memoria principal.
a. VENTAJA: La tabla de páginas puede crecer según se requiera.
b. DESVENTAJA: La velocidad de acceder a memoria es relativamente baja, dado
que cada referencia a memoria involucra 2 accesos.
12
Imagen reproducida de [4.3]
13
Imagen reproducida de [4.3]
113
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En la paginación, se debe cuidar el tamaño de las páginas, ya que si éstas son muy pequeñas el
control por parte del sistema operativo para saber cuáles están en RAM y cuales en disco, sus
direcciones reales, etc., crece y provoca mucha sobrecarga (overhead). Por otro lado, si las
páginas son muy grandes, la sobrecarga disminuye pero entonces puede ocurrir que se
desperdicie memoria en procesos pequeños. Debe haber un equilibrio.
Cuando se está buscando una página cualquiera y ésta no está cargada, surge lo que se llama
un fallo de página (page fault). Esto es caro para el manejador de memoria, ya que tiene que
realizar una serie de pasos extra para poder resolver la dirección deseada y darle su contenido a
quien lo pide. Primero, se detecta que la página no está presente y entonces se busca en la tabla
la dirección de esta página en disco. Una vez localizada en disco se intenta cargar en alguna
página libre de RAM. Si no hay páginas libres se tiene que escoger alguna para enviarla hacia el
disco. Una vez escogida y enviada a disco, se marca su valor de control en la tabla de direcciones
virtuales para indicar que ya no está en RAM, mientras que la página deseada se carga en RAM y
se marca su valor para indicar que ahora ya está en RAM.
Todo este procedimiento es caro, ya que se sabe que los accesos a disco duro son del orden de
decenas de veces más lentos que en RAM. En el ejemplo anterior se mencionó que cuando se
necesita descargar una página de RAM hacia disco se debe de hacer una elección. Para realizar
esta elección existen varios algoritmos, los cuales se describen a continuación.
•La primera en entrar, primera en salir. Se escoge la página que haya entrado primero y esté
cargada en RAM. Se necesita que en los valores de control se guarde un dato de tiempo. No es
eficiente porque no aprovecha ninguna característica de ningún sistema. Es justa e imparcial.
14
Imagen reproducida de [4.3]
114
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
•La no usada recientemente. Se escoge la página que no haya sido usada (referenciada) en el
ciclo anterior. Pretende aprovechar el hecho de la localidad en el conjunto de trabajo.
•La usada menos recientemente. Es parecida a la anterior, pero escoge la página que se usó
hace más tiempo, pretendiendo que como ya tiene mucho sin usarse es muy probable que siga
sin usarse en los próximos ciclos. Necesita de una búsqueda exhaustiva.
•La no usada frecuentemente. Este algoritmo toma en cuenta no tanto el tiempo, sino el número
de referencias. En este caso cualquier página que se use muy poco, menos veces que alguna
otra.
•La menos frecuentemente usada. Es parecida a la anterior, pero aquí se busca en forma
exhaustiva aquella página que se ha usado menos que todas las demás.
•En forma aleatoria. Elige cualquier página sin aprovechar nada. Es justa e imparcial, pero
ineficiente.
Otro dato interesante de la paginación es que ya no se requiere que los programas estén
ubicados en zonas de memoria adyacente, ya que las páginas pueden estar ubicadas en
cualquier lugar de la memoria RAM.
Reemplazo de páginas
Cuando ocurre un defecto de página (interrupción que se lanza cuando se hace referencia a
una dirección virtual que no se encuentra en la memoria real), el sistema operativo debe
seleccionar una página para retirarla de la memoria real y así dejar un marco vacío que
contendrá a la página referenciada. Si el marco seleccionado contiene una página que haya
sido modificada, esta deberá ser escrita de nuevo al disco. Por el contrario, si no se ha
modificado, la página a cargar reemplazará a la existente en memoria real sin necesidad de
rescribirla, pues su imagen en disco es idéntica a la existente en memoria principal.
A pesar de que se puede elegir una página al azar, es mejor seleccionar una de poco uso para
favorecer el Principio de Optimalidad dice que el mejor algoritmo de reemplazo será aquel que
seleccione la página que será referenciada más tarde en el tiempo. A pesar de ser muy fácil de
enunciar, este principio es imposible de implementar pues para ello se requeriría saber de
antemano, el orden en el que van a ser referenciadas las páginas.
Dentro de los algoritmos realizables, los más conocidos son los siguientes:
Este último es uno de los más utilizados a pesar de que para su implementación se requieren
mecanismos sofisticados, ya que para poder llevarlo a cabo, se requeriría guardar para cada
115
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
página la hora exacta en la cual ocurrió la última referencia, lo cual implicaría ampliar el
tamaño de la entrada en la tabla de páginas, lo que resulta muy costoso. Por esta razón, se
recurre a una aproximación que consiste en que cada vez que la página es referenciada, el bit
de referencia se prende en la entrada correspondiente en la tabla de páginas. Periódicamente,
un proceso demonio (un proceso background del sistema operativo), se encarga de apagar tal
bit en aquellas páginas que lo tengan prendido. Cuando se necesita un marco, se selecciona
una de aquellos que contengan páginas que tengan el bit apagado.
4.3.5 Segmentación
Este método consiste en la asignación de bloques de memoria de tamaño variable, llamados
segmentos. El tamaño de cada segmento será el requerido según la petición, por ejemplo el
tamaño del proceso a cargar.
La segmentación se aprovecha del hecho de que los programas se dividen en partes lógicas,
como son las partes de datos, de código y de pila (stack). La segmentación asigna particiones de
memoria a cada segmento de un programa y busca como objetivos el hacer fácil el compartir
15
Imagen reproducida de [4.3]
116
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
segmentos (por ejemplo librerías compartidas) y el intercambio entre memoria y los medios de
almacenamiento secundario.
Por ejemplo, en la versión de UNIX SunOS 3.5, no existían librerías compartidas para algunas
herramientas, por ejemplo, para los editores de texto orientados al ratón y menús. Cada vez que
un usuario invocaba a un editor, se tenía que reservar 1 megabyte de memoria. Como los
editores son una herramienta muy solicitada y frecuentemente usada, se dividió en segmentos
para la versión 4.x ( que a su vez se dividen en páginas ), pero lo importante es que la mayor
parte del editor es común para todos los usuarios, de manera que la primera vez que cualquier
usuario lo invocaba, se reservaba un megabyte de memoria como antes, pero para el segundo,
tercero y resto de usuarios, cada editor extra sólo consumía 20 kilobytes de memoria. El ahorro
es impresionante.
Obsérvese que en la segmentación pura las particiones de memoria son de tamaño variable, en
contraste con páginas de tamaño fijo en la paginación pura. También se puede decir que la
segmentación pura tiene una granularidad menor que la paginación por el tamaño de segmentos
versus tamaño de páginas.
16
Imagen reproducida de [4.3]
117
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
dirección en la Tabla Asociativa para por fin formar una dirección real con el desplazamiento
de V (fig. 4.20).
En un sistema con un número muy grande de procesos, segmentos o paginas, ésta estructura
puede consumir una parte muy importante de la memoria real. La cuestión es que la traducción
de direcciones puede realizarse con rapidez pero si se tienen demasiadas tablas, el sistema
puede soportar menos procesos y bajar su rendimiento
17
Imagen reproducida de [4.3]
18
Imagen reproducida de [4.3]
118
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Con el fin de integrar los conceptos y técnicas descritos en las secciones anteriores de este
capítulo, se implemento un pequeño simulador para ejemplificar la administración de la memoria.
Después de analizar la información presentada en este capítulo, pueden distinguirse 2 escenarios
de administración en relación a los programas:
• Los esquemas que manejan programas como bloques monolíticos (todo el código del
programa está en un bloque)
• Los esquemas que manejan programas en forma de módulos (p.ej. en el caso de usar
overlays, librerías dinámicas, etc.)
Particiones
fijas
PP
Particiones
PP variables
Paginación
PP
119
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
PP
Segmentación
PP
Segmentación con
Paginación por
demanda
Figura 4.23 La segmentación y la segmentación con paginación son más aptos para
manejar programas y módulos dinámicos.
120
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
121
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El código del simulador puede ser consultado en el apéndice "Simulador del servicio de
administración de memoria".
4.5 Comentarios
El sistema de administración de memoria está dedicado a manipular el código y los datos que
integran una aplicación, y por lo tanto está muy relacionado al sistema de administración de
procesos. Por ello fue necesario en el primer capítulo introducir toda la terminología relacionada a
todos los subsistemas de los sistemas operativos, pues es difícil hablar de ambos en forma
aislada.
Cabe mencionar que todos los esquemas de administración de memoria presentados se aplican
por lo general a una sola máquina, aunque es posible ampliar estos conceptos a esquemas
distribuidos donde se trate de unificar las capacidades de memoria de varios equipos en un solo
recurso.
122
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
123
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
124
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 5.
Administración de procesos
Lo que conduce y arrastra al mundo
no son las máquinas sino las ideas.
Víctor Hugo
Un sistema operativo puede ejecutar una gran variedad de programas, y para ello, debe brindar
un ambiente y soporte adecuado para su ejecución. El cómo iniciar la ejecución de un programa,
cómo permitir que varios programas se ejecuten a la vez, se comuniquen entre ellos, etc., es
responsabilidad del subsistema del sistema operativo encargado de la administración de
procesos.
⊕
Obras consultadas: [5.40]
125
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En los viejos sistemas de cómputo, los sistemas operativos permitían solo la ejecución
secuencial de programas (fig. 5.1a), aunque durante su evolución la ejecución de varias tareas
como operaciones de impresión y luego otros programas, fue haciéndose posible.
En los sistemas de lotes se ejecutaban trabajos, y en los sistemas de tiempo compartido las
ejecuciones eran llamadas programas de usuario o tareas.
La multiprogramación implica que existan varios programas que se ejecutan a la vez (fig. 5.1b).
La abstracción para un programa en ejecución es un proceso, el cual es un concepto reciente
pues las primeras máquinas y las PCs no tenían procesos.
19
Imagen reproducida de [5.40]
126
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
5.1.2 Procesos⊕
Podemos iniciar por preguntarnos, ¿qué es un proceso? Para ello tenemos las siguientes
respuestas:
• Un proceso no es el código de un programa.
• Cada invocación de un programa es un proceso distinto.
• Un proceso es una actividad que se apoya en datos, recursos, un estado en cada momento y
un programa.
Un proceso es más que el código de un programa y la actividad que este desarrolla. Cada
proceso tiene su propio contador de programa, que es el registro que le dice en que parte del
programa está. También necesita un lugar para almacenar las direcciones de retorno cuando
llama a una subrutina, para que en el caso de que dos procesos ejecuten la misma subrutina
desde diferentes lugares, pueda regresar a los puntos de inicio adecuados. Puesto que las
subrutinas pueden llamar otras subrutinas, cada proceso necesita su propia pila de direcciones de
retorno, así como espacio para variables locales y globales.
⊕
Obras consultadas: [5.26] [5.27]
127
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
5.1.3 Hilos⊕
Un problema con el uso de procesos múltiples es que los cambios de contexto son muy
costosos. Un segundo problema es que el poder compartir los recursos como datos, archivos
abiertos, I/O con el usuario, etc., puede ser difícil.
Los hilos (threads) son entidades separadas de ejecución dentro de un espacio existente de
direcciones, que poseen su propio contador de programa, registros y pila. Al hacer referencia al
término espacio de direcciones, esto quiere decir que el hilo comparte sus secciones de código y
datos con otros hilos.
Un proceso secuencial tiene un solo flujo de control (una secuencia de instrucciones ejecutadas
por el proceso). En un proceso multihilado, hay diversos flujos de control planificables llamados
hilos. Los hilos están asociados con una secuencia de instrucciones, y comúnmente se les refiere
como hilos de ejecución.
Los hilos también son conocidos como procesos ligeros (lightweight processes -LWPs), pues
el contexto que se mantiene para los hilos es mucho más ligero que el de los procesos. Aún
cuando los hilos son entidades ejecutables, esto no significa que se ejecuten en paralelo.
Los hilos pueden ser planificados concurrentemente en varios procesadores, mientras que en
máquinas con un solo procesador el tiempo de ejecución se reparte.
Con Solaris 2.2, Sun introdujo una librería de hilos para desarrollo de aplicaciones que
aprovechara las características de multiprocesamiento y multihilado de su nuevo kernel.
A partir del modelo de Solaris (el cual usa un modelo de dos capas de hilos) se tienen los
siguientes esquemas de implementación:
• los hilos de usuario, los cuales son manejados por la librería de hilos, y administrados en el
espacio de usuario. El SO no se percata de su existencia, pues la alternancia entre hilos no
requiere de llamadas al sistema o interrumpir al kernel, por lo que es muy rápida. Una
desventaja de este esquema es que si uno de estos hilos se bloquea al ejecutar una llamada
al sistema, el kernel bloquea a todo el proceso, pues no se da cuenta de que existan otros
hilos.
⊕
Obras consultadas: [5.1]
128
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• los hilos del kernel (LWPs), que usan los recursos del kernel y son las entidades planificables
del sistema. En este caso el kernel esta al tanto de la existencia de varios hilos por proceso,
por lo que si un hilo se bloquea, el SO escoge otro para continuar la ejecución, ya sea del
mismo espacio o de otro diferente.
El objetivo de los hilos es facilitar la escritura de aplicaciones concurrentes (ver sección 5.4). Ya
que los hilos comparten los recursos, un proceso pesado puede contener varios hilos sin un costo
adicional (solo los bloques de control de sus hilos). Además la comunicación entre los hilos del
proceso es más sencilla pues comparten la memoria. Sin embargo, su uso implica la necesidad de
controlar el acceso a los datos compartidos.
Figura 5.2 Esquema del intercambio de procesos con el CPU en un sistema multitarea.
• Estado del proceso. Información relativa al contenido del contador del programa (Program
Counter, PC), estado de procesador en cuanto a prioridad del proceso, modo de ejecución,
etc., y por último el estado de los registros internos de la computadora.
129
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Esta información relativa al estado del proceso, se encuentra siempre en memoria principal y se
accede a ella en los momentos en que se hace necesaria su actualización o consulta. Todos los
bloques de control son almacenados en una estructura llamada tabla de procesos.
Existe un Bloque de Control de Sistema (SCB) con objetivos similares al anterior y entre los
que se encuentra el enlazado de los bloques de control de procesos existentes en el sistema.
Los procesos pueden crear procesos nuevos, donde se llama padre al proceso creador e hijo al
proceso creado. Los hijos pueden obtener sus recursos (tiempo de la CPU, archivos, memoria,
etc.) del SO o de un subconjunto de los recursos del padre. El hijo puede ser un programa nuevo
o un duplicado del espacio de direcciones del padre.
130
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Cabe mencionar que los procesos son creados por medio de una llamada al sistema (en
Windows se hace por medio de la función CreateProcess, y en Unix por medio de la operación
fork).
Un proceso termina cuando realiza una llamada especifica al sistema (p.ej. exit), o si se genera
una excepción (error) y el SO decide abortarlo.
Cuando un nuevo proceso es creado, necesita saber donde empezar a ejecutarse. En Java,
cuando un objeto es creado se le da a un hilo. Cuando es iniciado, comienza su ejecución al
principio del método run() del objeto.
En Unix, un nuevo proceso se inicia con el comando fork(), el cual comienza un nuevo proceso
ejecutándose en el mismo programa, comenzando en la declaración siguiente inmediata a la
llamada del fork(). Después de la llamada, tanto el proceso padre como el hijo se ejecutan en el
mismo punto en el programa. Al hijo se le da su propio espacio en memoria, que es inicializado
con una copia exacta de del espacio de memoria (objetos globales, stack, heap) del padre.
Aunque el hijo se ve como un clon exacto del padre, es difícil distinguirlos; la única diferencia es
que el fork() regresa cero en el hijo, y un valor diferente a cero en el padre.
#include <iostream.h>
#include <unistd.h>
char *str;
int f() {
int k;
k = fork();
if (k == 0) {
str = "el hijo tiene el valor de: ";
return 1;
}
else {
str = "el padre tiene el valor de:";
return 9;
}
}
main() {
int j;
str = "programa principal";
j = f();
cout << str << j << endl;
}
131
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En el programa, se inicia con un proceso que se ejecuta en main(). Este proceso llama a f(), y
adentro de f() se llama al fork(). Entonces aparecen 2 procesos como consecuencia de la
llamada. Cada uno tiene su propia copia de la variable str y su propia copia del stack, que
contiene un área para main() con la variable j y un área para f() con la variable k. Después de
regresar del fork() el padre asigna a su copia de k un valor diferente de cero, mientras el hijo
asigna a su copia de k el valor de cero. Cada proceso entonces asigna su propio valor de la
cadena a su copia de str y regresa valores diferentes.
Estos estados no son los únicos que un proceso puede adoptar, pues muchas veces depende de
las especificaciones y objetivos del sistema operativo el esquema de estados que se usa para la
administración de los procesos. Por ejemplo, QNX que es un sistema de tiempo real, define 8
estados posibles para sus procesos [5.29], mientras Linux define 5 estados [5.30].
La primera tarea importante del manejo de procesos es poder rastrearlos, es decir, mantener
un registro que nos diga que es lo que existe y en que estado se encuentra.
Todo proceso a lo largo de su existencia puede cambiar de estado varias veces. Cada uno de
estos cambios se denomina transacción de estado. Estas transacciones son las siguientes:
132
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Comienzo de la ejecución. Todo proceso comienza al ser dada la orden de ejecución del
programa insertándose en la cola de preparados. El encolamiento dependerá de la política de
gestión de dicha cola.
• Paso de estado de ejecución. Cuando el procesador se encuentra inactivo y en la cola de
preparados exista algún proceso en espera de ser ejecutado, se pondrá en ejecución el
primero de ellos.
• Paso a estado bloqueado. Un proceso que se encuentre en ejecución y que solicite una
operación a un dispositivo externo, teniendo que esperar a que dicha operación finalice, será
pasado de estado de ejecución a estado bloqueado insertándose su PCB en la cola
correspondientes de bloqueado. A partir de este momento el procesador pone en ejecución el
siguiente proceso, que será el primero de la cola de preparados.
• Paso a estado preparado. Este paso puede ser producido por alguna de las siguientes causas.
Orden de ejecución de un programa, con la cual, ya se ha mencionado, el proceso pasa a la
cola de preparados. Si un proceso está en estado bloqueado por causa de una operación de
entrada/salida y está finaliza, pasará de la cola de bloqueados a la de preparados. Si un
proceso está en ejecución y aparece una interrupción que fuerza al sistema operativo a
ejecutar otro proceso, el primero pasará al estado de preparado y su PCB a la cola de
preparados. Activación. Un proceso suspendido previamente sin estar bloqueado pasará al
estado preparado al ser activado nuevamente.
• Paso a estado suspendido bloqueado. Si un proceso está bloqueado y el sistema operativo
recibe la orden de suspenderlo, su PCB entrará en la cola de procesos suspendidos
bloqueados.
• Paso a estado suspendido preparado. Este paso se puede producir bajo tres circunstancias:
• Suspensión de un proceso preparado pasando éste de la cola de procesos preparados
a la de suspendidos preparados.
• Suspensión de un proceso en ejecución, con lo cual el proceso pasa a la cola de
suspendidos preparados.
• Desbloqueo de un proceso suspendido bloqueado por desaparecer la causa que
impedía el ser activado de nuevo.
Preferentemente, el kernel debe mantener una lista diferente para cada tipo de servicio que
pueda ser requerido.
133
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Por ejemplo, la administración de espacio a veces causa que los procesos esperen en una lista
principal de espera (main-store wait), hasta que haya suficiente espacio para ejecutarlos. Un
proceso que lee datos de un archivo puede esperar en una lista de espera de acceso a archivos
(file transput wait) hasta que los datos sean leídos.
Cada dispositivo que un proceso pueda usar para operaciones de entrada/salida deberá tener
su propia lista de espera. Mientras un proceso este en una lista de espera, se dirá que esta
bloqueado.
Estas listas son llamadas también colas (queues) pero no necesitan ser construidas como
colas, con su entrada en un extremo y su salida por el otro. Estas listas pueden ser
representadas incluyendo en cada bloque de contexto un campo que indique en que lista se
encuentra. Dichos bloques pueden ser almacenados en una estructura de datos de pila (heap) de
acuerdo a cierta prioridad, de modo que aquel con mayor urgencia pueda ser accesado
rápidamente.
Llamadas de servicios
Varios eventos pueden provocar que un proceso sea enviado de una lista a otra. Un proceso
hace una petición al kernel enviando una llamada de servicio (Service call), la cual puede
pedir recursos, retornar recursos o realizar una operación de E/S (transput).
Como resultado de dicha llamada, el planificador debe decidir si coloca el proceso de regreso
en la lista de de preparados y comenzar a ejecutar otro proceso de dicha lista. Esta operación,
llamada intercambio de proceso (process switch), usualmente toma más tiempo que un simple
cambio de contexto (context switch). Después de un intercambio de proceso, un cambio de
contexto inicia la ejecución de un nuevo proceso. La mayoría de los sistemas operativos
construyen las llamadas de servicio a partir de instrucciones que causan interrupciones en el
procesador (processor traps).
Una interrupción (trap) causa que el hardware copie ciertos registros del hardware, como el
contador de programa y el estado del procesador, a un lugar seguro (por lo general en un
stack). El hardware carga entonces los registros apropiados con el nuevo contexto (que incluye
el contador de programa para establecer el sitio en el kernel donde el programa manejador de
interrupciones es almacenado). Entonces se cambia el procesador al estado privilegiado. El SO
debe colocar la información de contexto salvada por el hardware en el bloque de contexto del
proceso que estaba ejecutándose en el momento de la interrupción.
Las llamadas de servicio son como llamadas a subrutinas desde el punto de vista de llamar a
un proceso.
134
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los sistemas operativos actuales poseen una serie de funciones orientadas a la manipulación de
los procesos. Las operaciones que se pueden hacer sobre un proceso son las siguientes:
• Crear el proceso. Se produce con la orden de ejecución del programa y suele necesitar
varios argumentos, como el nombre y la prioridad del proceso. Aparece en este momento el
PCB, que será insertado en la cola de procesos preparados. La creación de un proceso puede
ser de dos tipos:
a. Jerárquica. En ella, cada proceso que se crea es hijo del proceso creador y hereda el
entorno de ejecución de su padre. El primer proceso que ejecuta un usuario será hijo del
intérprete de comandos con el que interactúa.
b. No jerárquica. Cada proceso creado por otro proceso se ejecuta independientemente
de su creador con un entorno diferente. Es un tipo de creación que no suele darse en los
sistemas operativos actuales.
• Destruir un proceso. Se trata de la orden de eliminación del proceso con la cual el sistema
operativo destruye su PCB.
• Suspender un proceso. Es un proceso de alta prioridad que paraliza un proceso que puede
ser reanudado posteriormente. Suele utilizarse en ocasiones de mal funcionamiento o
sobrecarga del sistema.
• Reanudar un proceso. Trata de activar un proceso que a sido previamente suspendido.
• Cambiar la prioridad de un proceso. Todo proceso por sus características e importancia
lleva aparejadas unas determinadas necesidades de ejecución en cuanto a urgencia y
asignación de recursos. Las prioridades según los sistemas operativos se pueden clasificar del
siguiente modo:
• Asignadas por el sistema operativo. Se trata de prioridades que son asignadas a un
proceso en el momento de comenzar su ejecución y dependen fundamentalmente de los
privilegios de su propietario y del modo de ejecución.
• Asignadas por el propietario.
• Estáticas.
• Dinámicas.
• Temporizar la ejecución de un proceso. Hace que un determinado proceso se ejecute
cada cierto tiempo (segundos, minutos, horas) por etapas de una sola vez, pero transcurrido
un periodo de tiempo fijo.
• Despertar un proceso. Es una forma de desbloquear un proceso que habrá sido bloqueado
previamente por temporización o cualquier otra causa.
135
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La planificación es una tarea fundamental de los sistemas operativos. La mayor parte de los
recursos se planifican antes de usarse. Desde luego, el CPU es uno de los principales recursos de
la computadora, por lo que su planificación es importante para el diseño de los sistemas
operativos.
Los sistemas operativos realizan dos tipos de decisiones relacionadas a los recursos:
136
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
ser atendidos. Se tienen por ejemplo, la planificación del procesador (un procesador,
muchos procesos), la planificación de la memoria en sistemas de memoria virtual.
El planificador es un componente del SO que se encarga de elegir la tarea siguiente que hay
que admitir en el sistema y el proceso siguiente que hay que ejecutar.
La finalidad del planificador es asignar procesos para que sean ejecutados por el procesador o
procesadores con el fin de obtener mejores tiempos de respuesta, mayor productividad o
rendimiento y eficiencia del procesador.
1. Planificador a largo plazo (Planificador de trabajos). Cada vez que un usuario inicia la
ejecución de un programa, el planificador a largo plazo recibe la orden de ejecución, crea el
proceso correspondiente y lo pasa al planificador a corto plazo, colocándose en la cola de
procesos listos. Este planificador es, por tanto, el encargado de crear los procesos. Cada vez que
termina un trabajo, el planificador tomara la decisión de añadir uno o más trabajos nuevos.
137
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El despachador es el módulo que cede el control del CPU al proceso seleccionado por el
planificador a corto plazo. Esta función implica:
Cambiar de contexto
Cambiar a modo de usuario
Saltar al punto apropiado del programa del usuario para reiniciar ese programa
El despachador debe ser lo más rápido posible, porque se invoca en cada conmutación de
proceso. El tiempo que el despachador tarda en detener un proceso y poner otro en ejecución
se denomina latencia del despachador.
Una pregunta lógica es: ¿cómo decide el despachador cuál es el proceso siguiente que debe
ejecutar? Para ello el planificador de corto plazo utiliza las siguientes estrategias:
• Plan 0: buscar desde el principio de la tabla de procesos, algún proceso que este listo para
ejecutarse (este método es muy lento por ser una búsqueda lineal).
• Plan 1: reunir a los procesos listos para ejecutarse en una cola. El Despachador toma el
primer proceso de la cola. Cuando los procesos se tornan listos para ejecutarse, se insertan
al final de la cola.
• Plan 2: dar a cada proceso una prioridad, y organizar la cola de acuerdo a la prioridad, o tal
vez tener varias colas (una para cada tipo de prioridad).
138
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Puesto que el CPU solo puede hacer una cosa a la vez, si un proceso de usuario se está
ejecutando, el despachador pierde el control del CPU. Para recuperarlo puede emplearse un
"despertador" que puede ser:
a. Un evento Interno (trampas), que ocurra dentro del proceso de usuario que devuelva el
control al SO, por ejemplo:
- Llamadas al sistema.
- Errores (instrucciones ilegales, violación de direccionamiento, etc.).
- Error de página (page fault).
b. Un evento Externo (interrupciones), que ocurra fuera del control del proceso de usuario
que devuelva el control al SO, por ejemplo:
- Caracteres tecleados en una terminal.
- Termino de una operación en disco (el controlador esta listo para más trabajo).
- Temporizador (Timer), que asegura que eventualmente el SO recupere el control.
El diseño del planificador de corto plazo es una de las áreas criticas en el diseño del sistema
en general, y una de las más "truculentas" puesto que como cada arquitectura de procesadores
posee sus propias facilidades para intercambio de tareas, la implementación del mecanismo de
software de intercambio de procesos por lo general debe ser independiente de la máquina,
pero el software de intercambio se codifica por lo general en lenguaje ensamblador especifico
de la máquina (debe ser el único módulo dependiente de la arquitectura).
1. El intercambio de procesos debe ser hecho eficientemente. Puesto que la mayor parte
del tiempo que toma llevar a cabo el cambio de procesos es sacrificado en salvar y
restaurar el contexto del proceso, es importante que la cantidad de información que
representa al proceso y su estado, se reduzca a un mínimo indispensable.
2. Puesto que muchas estructuras de datos son compartidas entre los procesos (p.ej. tablas
de dispositivos, información de tiempo, prioridades relativas, etc.), debe haber un
método consistente para permitir el acceso a los datos entre ellas. La única respuesta
obvia es almacenar estas estructuras en la memoria principal.
3. Puesto que el sistema administra varios procesos, cada uno de los cuales asume que es
el único proceso ejecutándose, el sistema debe escoger un esquema en el que los
procesos tengan una justa repartición del tiempo del procesador.
⊕
Obras consultadas: [5.3]
139
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las llamadas al sistema deben ser hechas también por el planificador de largo plazo, pues
llama al administrador de memoria para alojar memoria para el nuevo proceso, o desalojar la
memoria para un proceso muerto.
La principal función del LTS, después de verificar que la memoria ha sido correctamente
asignada al proceso por el administrador de memoria, es crear el bloque de control de proceso
(PCB) para el nuevo proceso. Esto puede hacerse examinando el PCB del proceso padre, y
copiando gran parte de su información en el nuevo PCB. Los campos del PCB tales como
valores de registro del usuario, permisos del proceso, y recursos pueden ser copiados
directamente. Los registros base y limite, y el contador de programa (PC) son ejemplos de
campos que el LTS tendrá que crear con la ayuda del administrador de memoria. El nuevo PCB
es entonces agregado a la cola apropiada con su estado inicializado en ejecutable (runnable).
En cambio desasignar es más sencillo, pues el planificador solo cierra los recursos y borra el
PCB de las colas de planificación. Sin embargo, si el sistema está muy cargado con procesos, el
planificador de largo plazo puede elegir mantener el trabajo en disco hasta que los recursos del
sistema sean suficientes para agregar un nuevo trabajo.
Una vez que el estado de un proceso es cambiado de "nuevo" a "listo" por el planificador de
largo plazo, entonces el planificador de corto plazo pasa a determinar cual es el proceso que
será despachado.
El código del programa ejecutado por el CPU y los datos que el programa maneja deben ser
almacenados en la memoria principal (RAM).
El intercambio con el disco (disk swapping) permite al SO usar el disco duro (memoria
secundaria) para simular la memoria primaria, intercambiando trozos de la memoria principal al
disco, y de vuelta como vaya siendo necesario. Con esta memoria virtual, un SO con, digamos,
64 Mbytes de RAM puede simular cientos de megabytes o hasta gigabytes de memoria
principal.
Cuando dicha memoria es requerida nuevamente por su proceso asociado, es leída del disco y
devuelta a la memoria principal (swapped in). El proceso no sabe que su código y datos están
140
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
siendo intercambiados, puesto que esto ocurre cuando el proceso esta en estado de bloqueo o
listo para ejecutarse.
Esto significa que si se desea considerar un diagrama de procesos para un sistema que
provee intercambio de procesos, deben agregarse los estados:
• Suspendido-bloqueado (suspended-blocked)
• Suspendido-preparado (suspended-ready)
El MTS es usado por el SO para decidir que procesos serán intercambiados, y cuando;
además debe asegurarse que antes de que un proceso sea despachado al CPU, su código y
datos hayan sido devueltos a la memoria principal. Por lo tanto es claro que este planificador
requerirá su propio algoritmo de planificación.
20
Imagen reproducida de [5.31]
141
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El planificador también provee soporte para la carga dinámica de módulos; estos módulos
representan funcionalidades del kernel que pueden cargarse después de que el kernel ha
comenzado a ejecutarse. Esta capacidad es usada por los subsistemas de administración de
archivos (vfs) y de red (net).
• Equidad: Garantizar que cada proceso obtenga su proporción justa de la CPU. Es decir, que
ningún proceso llegue a apoderarse por completo de la CPU.
• Eficiencia: Mantener ocupada la CPU al 100%, esto con el fin de evitar los tiempos ociosos
que pueda tener el CPU.
• Rendimiento: Maximizar el número de tareas procesadas por hora, es decir, que el CPU
pueda atender todos y cada una de las peticiones que le fueron hechas.
Para garantizar que ningún proceso se ejecute un tiempo excesivo, casi todas las computadoras
tienen un cronómetro electrónico o un reloj incluido, que provoca una interrupción en forma
periódica. En cada interrupción del reloj, el sistema operativo logra ejecutarse y decidir si el
proceso que se ejecuta en ese momento tiene permiso de continuar o si tiene el tiempo
suficiente en la CPU por el momento, para después suspenderlo para que otro proceso utilice la
CPU.
21
Imagen reproducida de [5.32]
⊕
Obras consultadas: [5.5] [5.6] [5.12] [5.13] [5.14] [5.15]
142
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La mayor parte de los sistemas operativos usan algoritmos de planificación de tiempo de CPU
muy similares, todos basados en las mismas ideas básicas, pero con adaptaciones y extensiones
especificas a cada SO.
La toma de decisión del próximo proceso a ser ejecutado puede llevarse a cabo cuando sucede
alguna de las siguientes transiciones:
• Cuando un proceso pasa de estado Running a Waiting.
• Cuando un proceso pasa de estado Running a Ready
• Cuando un proceso pasa de estado Waiting a Ready
• Cuando un proceso finaliza y pasa del estado Running a Terminated.
Para la primera y última transición, el planificador seleccionará un proceso (si hay alguno en la
cola de listos). Si las decisiones del planificador se llevan a cabo solamente cuando ocurren estas
transiciones, decimos que el esquema de planificación es no expropiativa. Bajo este esquema,
una vez que el CPU ha sido asignado a un proceso, el proceso mantendrá el CPU hasta que él lo
libere ya sea porque finalizó la ejecución del proceso o porque necesite esperar por la ocurrencia
de algún evento. Este esquema no requiere hardware especial (timer). Cuando se permite la
suspensión de la ejecución de un proceso estamos hablando de un esquema expropiativo.
Los esquemas de planificación expropiativos incurren en ciertos costos y afectan el diseño del
kernel del sistema de operación. Por ejemplo, considérese el caso en que dos procesos
comparten cierta data. Si uno de ellos está en ejecución y se encuentra alterando dichos datos,
puede suceder que dicho proceso sea suspendido temporalmente y se le pase el control del CPU
al otro proceso. El nuevo proceso puede encontrarse con los datos en un estado de
inconsistencia. Por lo tanto, nuevos mecanismos son necesarios para coordinar el acceso a datos
compartidos.
Cabe preguntarnos ¿qué hace el CPU si no hay procesos para ejecutar en la cola de listos? Aquí
el sistema operativo crea un proceso estático (iddle process), que es un proceso limitado por el
CPU construido en el sistema (podríamos pensar en un pequeño ciclo), al que se le da la menor
prioridad posible, por lo que no es ejecutado si hay procesos preparados en el sistema.
⊕
Obras consultadas: [5.16] [5.17] [5.18]
143
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Cuando un proceso tiene el CPU, se ejecuta hasta terminar. Es justo en el sentido formal, pero
algo injusta en cuanto a que los trabajos largos hacen esperar a los cortos y los trabajos sin
importancia hacen esperar a los importantes.
El tiempo de espera promedio en este tipo de algoritmo es muy variable, pues el tiempo de
espera de cada uno de los procesos que están en la cola de listos depende del orden de dichos
procesos en la cola. Consideremos el siguiente ejemplo:
Luego, se puede concluir el tiempo de espera promedio no es mínimo y puede variar mucho
debido, por una parte a las diferencias por requerimiento de tiempo de CPU y por el orden de
llegada de los procesos a la cola de procesos listos.
FCFS es un algoritmo no expropiativo, pues una vez de que el CPU sea asignado a un
proceso, este lo mantiene hasta que espontáneamente lo suelta, ya sea porque el proceso
finalizó o por algún requerimiento de E/S.
El tiempo de espera bajo esta política tiende a ser alto. Además, tiende a favorecer aquellos
procesos que requieren más tiempo de CPU (CPU-bound). No es útil en la planificación para
los usuarios interactivos porque no puede garantizar buenos tiempos de respuesta.
El esquema FIFO rara vez se usa como esquema principal en los sistemas actuales, pero a
menudo está incorporado en otros sistemas. Por ejemplo, muchos esquemas de planificación
despachan los procesos de acuerdo con la prioridad, pero los procesos con la misma prioridad
se despachan de acuerdo con el esquema FIFO.
144
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• No es expropiativo
• Es justo, aunque los procesos largos hacen esperar mucho a los cortos.
• Es una política predecible
• El tiempo promedio de servicio es muy variable ya que está en función del número de
procesos y la duración promedio que tenga
El tiempo promedio de espera que tengan los procesos depende por completo del orden en
que llegan los procesos a ejecutarse.
Algoritmo Round-robin⊕
Una manera rápida de reducir la penalización que los procesos cortos sufren con FCFS es usar
expropiación basada en un reloj. Una interrupción de reloj es generada a intervalos periódicos.
El algoritmo consiste en tener una cola tipo FIFO de procesos listos. El planificador de
procesos toma el primer proceso de la cola, programa un cronómetro para que interrumpa
después de un lapso o quantum de tiempo y despacha el proceso en la CPU.
La principal decisión de diseño que surge con Round Robin es el tamaño del trozo o quantum.
Si el quantum es muy corto, entonces los procesos se moverán a través del sistema
rápidamente. Por otro lado, hay un cierto overhead o desperdicio de tiempo envuelto con el
manejo de la interrupción de reloj y las funciones de planificación y despacho. Por lo tanto
trozos muy pequeños deberían evitarse. Una alternativa es usar un quantum de tiempo que sea
un poco más grande que el tiempo promedio requerido para una interacción típica.
El desempeño de este algoritmo dependerá del tamaño del quantum. Si el quantum es infinito
entonces degenera en FCFS. Si el quantum es muy pequeño entonces Round Robin es llamado
compartición de CPU y en teoría pareciera que cada proceso tiene su propio procesador
corriendo a 1/n la velocidad del procesador real.
⊕
Obras consultadas: [5.19] [5.20]
145
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Este algoritmo no es el lo mejor para SOs de propósito general, pero es muy útil para SOs de
procesamiento por lotes, en donde todos los trabajos tienen la misma prioridad, y en donde el
tiempo de respuesta es de menor o nula importancia.
22
Imagen reproducida de [G12]
⊕
Obras consultadas: [5.21]
146
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En este algoritmo, a cada proceso le es asignada una prioridad, y el proceso con la prioridad
más alta obtiene siempre el tiempo de CPU. Es posible asignar una prioridad alta a los procesos
interactivos, para obtener un mejor tiempo de respuesta. Los procesos de cómputo intensivo
reciben una prioridad más baja, pues no necesitan un tiempo de respuesta. Las prioridades
pueden ser definidas interna o externamente. En el primer caso, el sistema operativo se basa
en una serie de informaciones medibles para el cálculo y asignación de dichas prioridades
(tiempo necesitado del procesador, necesidad de memoria, etc.). En las externas la asignación
de prioridades se basa en la categoría que tenga el usuario.
Un problema que presenta un esquema de planificación por prioridades puro es que los
procesos con la prioridad más baja pueden sufrir de inanición o bloqueo indefinido. Un proceso
que está listo para correr pero espera porque siempre hay procesos con prioridad más alta. Un
mecanismo que se utiliza para evitar el aplazamiento indefinido de los procesos de baja
prioridad es el envejecimiento, el cual consiste en aumentar gradualmente en el tiempo la
prioridad de los procesos que esperan durante mucho tiempo en el sistema.
SJF es un caso especial de planificación por prioridad, donde la prioridad es el inverso del
valor estimado del próximo ciclo de CPU (a menor ciclo, mayor prioridad).
⊕
Obras consultadas: [5.22]
147
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
en conocer dichos valores, pero podemos predecirlos usando la información de los ciclos
anteriores ejecutados.
Este algoritmo puede ser expropiativo o no. Cuando un nuevo proceso llega a la cola de
procesos listos mientras otro se está ejecutando, el nuevo proceso puede tener el ciclo de
duración de CPU más corto que lo que falta por ejecutar del proceso actual. En el caso de un
esquema expropiativo, el CPU será asignado al proceso que acaba de llegar a la cola. Este
algoritmo se conoce como Shortest Remaining Time First (SRTF).
23
Imagen reproducida de [5.11]
⊕
Obras consultadas: [5.23] [5.24]
148
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Este algoritmo surge para tratar de dar un mejor servicio a los usuarios interactivos y está
basado en una mezcla entre algoritmos ya vistos y el algoritmo por prioridades, lo usual es que
se mezcle el algoritmo Round-robin y el de prioridades.
Este algoritmo contempla distintas colas de procesos en donde a cada una de ellas se le
asigna una determinada prioridad y se utiliza el algoritmo RR para la planificación de procesos
pertenecientes a una misma cola.
La operación del algoritmo es como sigue: la CPU es asignada a los procesos pertenecientes a
las colas de mayor prioridad, cuando la cola queda vacía se pasa a la cola de procesos asociada
a la siguiente prioridad.
Este esquema permite dejar los procesos interactivos en las colas de mayor prioridad, ya que
los procesos interactivos requieren tiempos de respuesta pequeños y necesitan ser atendidos
con mayor frecuencia. Los procesos por lotes, en cambio, no requieren interactuar con el
sistema y básicamente lo que les interesa es ejecutar su tarea completamente en un tiempo de
retorno razonable.
De esta manera, lo que sucede en este algoritmo es que cada una de las colas posee una
prioridad asociada y la planificación de los procesos que le pertenecen se realiza mediante RR.
Sin embargo, el quantum no es el mismo en ambas colas, siendo más pequeño para los
procesos de mayor prioridad que corresponde a los procesos interactivos, y mayores para las
prioridades más bajas.
149
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Como ya sabemos, para que un proceso se pueda ejecutar, las instrucciones que definen su
acción deben estar almacenadas en memoria, luego, si no se dispone de suficiente memoria, es
necesario que algunos de los procesos o porciones de ellos se encuentren en memoria
secundaria. Desde el punto de vista de planificación de procesos esta es una situación que
debe ser considerada, ya que el tiempo involucrado para ejecutar un proceso que está en disco
es mucho mayor que el tiempo requerido para ejecutar un proceso que está en memoria;
puesto que, necesariamente, hay que traspasar el proceso de disco a memoria antes de
ejecutarlo.
Por otro lado, el planificador de largo plazo se ejecuta con mucha menos frecuencia que el de
corto plazo. Este planificador es el encargado de controlar el grado de multiprogramación
(el número de procesos en memoria). Si el grado de programación se mantiene más o menos
estable, entonces el planificador debe velar porque la cantidad de procesos que entran a
memoria sea más o menos igual a la cantidad de procesos que salen de memoria.
150
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Algunos de los parámetros que se analizan para decidir qué procesos se intercambian de disco
a memoria y viceversa son:
• Tiempo que proceso ha permanecido en memoria o disco.
• Tiempo que proceso ha utilizado CPU.
• Prioridad del proceso
• Tamaño del proceso
Planificación evolutiva⊕
La planificación evolutiva se propone para resolver el problema de optimización de:
• la planificación de colas de procesos listos
• la planificación de colas de procesos bloqueados
• la planificación de colas de control por prioridad
• la planificación de colas cliente-servidor.
⊕
Obras consultadas: [5.25]
151
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los procesos evolutivos pueden adaptarse a su ambiente cambiando sus funciones de aptitud.
Este tipo de reacción puede hacer a un proceso siempre adecuado en casos en el que el uso
del CPU fluctúa y se tiene una mucha carga en la E/S.
Nótese que los procesos cambiarán automáticamente sus valores de aptitud de acuerdo al
procesamiento de las ordenes ganadoras en las optimizaciones de la planificación, pero no
podrán cambiar sus funciones de aptitud originales (las cuales solo pueden cambiarlas usuarios
autorizados como el administrador del sistema).
152
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Es importante que el modelo refleje los principales componentes de este subsistema, por lo que
deseablemente deben integrarse en el modelo (fig. 5.11):
1. La carga de programas a partir de un evento determinado (generado por el usuario u
otro programa)
2. La transferencia del código del almacenamiento secundario a la memoria.
3. La creación de un nuevo proceso para el programa requerido.
4. La inclusión del proceso en una estructura que permite administrar un conjunto de varios
procesos (modelo de multiprogramación).
5. Los modulos encargados de la planificación de mediano y corto plazo.
6. El intercambio en el control del uso del CPU.
153
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La idea es poder crear procesos que puedan ser ejecutados de forma simultánea, aplicando una
política de planificación para repartir el tiempo del procesador al proceso. Es posible también
destruir un proceso existente.
154
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El código del simulador puede ser consultado en el apéndice "Simulador del servicio de
administración de procesos".
Se dice que dos o más procesos son concurrentes si están activos simultáneamente. Los
procesos concurrentes pueden ser independientes si no hay interacción directa entre ellos o
dependientes si la hay (fig. 5.12).
Figura 5.12 Los procesos P1 y P2, así como P2 y P3 son concurrentes, en cambio P3 y
P1 no lo son24
⊕
Obras consultadas: [5.7] [5.8] [5.9] [G19]
24
Imagen reproducida de [5.10]
155
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
#include<stdio.h>
#include<iostream.h>
#include<dos.h>
/* prototipos de funciones */
void corrutina1();
void corrutina2();
void transfer_1();
void transfer_2();
void salto_ac1();
void restablecer();
WPointer allocCorrutinaSP(WPointer, WORD);
/* variables globales*/
WPointer mem_bloque1, mem_bloque2, Almacen1, Almacen2, AlmacenTmp;
/*programa principal*/
main () {
mem_bloque1=new WORD[mb_size];
mem_bloque2=new WORD[mb_size];
Almacen1 = allocCorrutinaSP(mem_bloque1,(WORD)corrutina1);
Almacen2 = allocCorrutinaSP(mem_bloque2,(WORD)corrutina2);
salto_ac1();
return(0);
}
En este caso, las funciones (corrutinas) solo imprimen un mensaje distintivo, y transfieren de
inmediato el control entre sí.
void corrutina1() {
cout<<"\n Corrutina 1, Acceso 1";
transfer_2();
cout<<"\n Corrutina 1, Acceso 2";
156
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
transfer_2();
cout<<"\n Corrutina 1, Acceso 3";
transfer_2();
restablecer();
}
void corrutina2() {
cout<<"\n Corrutina 2, Acceso 1";
transfer_1();
cout<<"\n Corrutina 2, Acceso 2";
transfer_1();
cout<<"\n Corrutina 2, Acceso 3";
transfer_1();
}
La transferencia del control entre las corrutinas se realiza intercambiando los bloques de
memoria en el SP.
157
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Por otro lado la cooperación implica poder compartir el estado de los procesos (procesos
cooperativos). En este caso:
158
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Un caso típico en el cual se requiere sincronización ocurre cuando un proceso inicia una lectura
y va a utilizar en la siguiente instrucción la información leída. En este caso se debe esperar a que
la operación de E/S termine para poder continuar la ejecución.
Existen dos puntos que se necesitan considerar en relación a la sincronización entre procesos:
Cómo hacer seguro que dos procesos no se estorben el uno al otro cuando accedan un
recurso común. En muchas aplicaciones, un proceso necesita el acceso exclusivo no sólo
a un recurso, sino a varios. Un proceso que copie un archivo mayor que un disco desde una
cinta magnética hacia la impresora necesita el acceso exclusivo a la unidad de cinta y a la
impresora al mismo tiempo. En un sistema con un único proceso, éste puede tener el acceso
a todos los recursos que necesite y realizar su trabajo. Sin embargo, en un sistema con
multiprogramación, pueden surgir serios problemas. Supongamos, por ejemplo, que 2
procesos desean imprimir cada uno un archivo enorme. El proceso A solicita el permiso para
utilizar la impresora, el cual se le concede. Es entonces cuando el proceso B solicita permiso
para utilizar la unidad cinta y se le otorga. El proceso A solicita entonces la unidad de cinta,
pero la solicitud es denegada hasta que B la libere. Por desgracia, en este momento, en vez
de liberar unidad de cinta, B solicita la impresora. Los procesos se bloquean en ese momento
y permanecen así por siempre. Esta situación se llama bloqueo (deadlock).
Por lo general, una computadora tiene distintos recursos que pueden ser otorgados. Algunos
recursos podrán tener varias instancias idénticas, como es el caso de tres unidad es de cinta. Si
se tienen disponibles varias copias de un recurso, cualquiera de ellas se puede utilizar para
satisfacer cualquier solicitud del recurso. En resumen, un recurso es cualquier cosa que sólo
puede ser utilizada por un único proceso en un instante dado.
Los recursos son de dos tipos: apropiables y no apropiables. Un recurso apropiable es aquel
que se puede tomar del proceso que lo posee sin efectos dañinos. La memoria es un ejemplo de
⊕
Obras consultadas: [5.10]
159
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los interbloqueos se relacionan con los recursos no apropiables. Lo usual es que los bloqueos
asociados a recursos apropiables se pueden resolver, mediante la reasignación de recursos de un
proceso a otro. La secuencia de eventos necesarios para utilizar un recurso es:
• Solicitar el recurso.
• Utilizar el recuso.
• Liberar el recurso.
Cómo secuenciar los procesos cuando hay dependencias entre ellos (p.ej. que el
proceso B espere la salida del proceso A). Sean dos procesos A y B, que necesitan leer e
incrementar el valor de la variable x cuyo valor inicial es 7; después de que A y B
incrementan a x su valor debe ser 9. Supongamos que el proceso A lee el valor de 7 y antes
de incrementarlo es retirado (preempted) por el planificador del CPU que empieza a ejecutar
a B. B lee el valor de 7 también, lo incrementa y lo almacena en x. Ahora A retoma el CPU,
incrementa el valor que leyó a 8 y lo guarda. Aunque el valor de x fue leído e incrementado
por A y B, es incorrecto. Situaciones como esta, donde 2 o más procesos están leyendo o
escribiendo algún dato compartido y el valor depende en que los procesos ejecutados sean
ejecutados en el instante preciso, son llamadas condiciones de competencia (race
conditions).
La clave para evitar este tipo de condiciones es proveer exclusión mutua, es decir, alguna
forma de asegurar que si un proceso está accediendo una variable compartida, otros procesos
serán excluidos de hacer lo mismo.
La parte de un programa donde las variables compartidas son accedidas es llamada sección
crítica (o región crítica). Si la ejecución de procesos es arreglada de manera que ningún par de
procesos estuvieran en su sección crítica al mismo tiempo, se evitarían las condiciones de
competencia.
La solución más sencilla de hardware es tener deshabilitadas las interrupciones de cada proceso
cuando entra a su región crítica y habilitarlas cuando sale. Esta solución no es viable pues no es
lo más correcto dar el control de deshabilitación de interrupciones a un proceso, y por que en
sistemas multiprocesador, esta deshabilitación afecta solo al CPU donde se ejecutan las
instrucciones, mientras los otros continúan ejecutándose y accediendo al recurso o variable
compartido.
Por ello, muchas máquinas proveen instrucciones especiales de hardware que permiten a los
procesos probar y modificar el contenido de una palabra o intercambiar el contenido de dos
palabras, atómicamente como las instrucciones Test-and-Set y Swap.
160
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Estas instrucciones pueden usarse para resolver el problema de sección crítica (SC). Cualquiera
de estas soluciones puede usarse como base para resolver problemas de sincronización más
complejos. Las soluciones de software construidas en las soluciones de hardware, proveen un
soporte de alto nivel para el soporte de sincronización. Existen tres mecanismos de software para
ello:
• Semáforos
• Candados (locks)
• Monitores
Semáforos
Un semáforo (S) es una variable entera que puede ser accedida solo por medio de 2
operaciones atómicas: P y V (alemán para Espera y Señal), las cuales se definen como:
P(S):
while S <= 0 do no-op;
S = S-1;
V(S):
S = S + 1;
La prueba y modificación del valor del semáforo en ambas operaciones debe hacerse
atómicamente (p.ej. cuando un proceso esta probando o modificando el valor del semáforo,
ningún otro proceso puede modificar el valor). Para ver como se usan estas operaciones para
sincronizar procesos, sean dos procesos A y B, ejecutando las sentencias S1 y S2
respectivamente. La condición es que S2 puede ser excluido solo después de S1. Esto se logra
con un semáforo (synch) inicializado en cero. A y B ejecutarán el siguiente código:
A:
S1;
V(synch);
B:
P(synch);
S2;
161
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Puesto que synch está inicializada a cero, B ejecutará S2 sólo después de que A lo haya
señalado por la invocación de V(synch) que está después de S1.
Cuando un proceso ejecuta P() y encuentra que el semáforo no es positivo, debe esperar. Sin
embargo, en vez de esperar, el proceso puede bloquearse a si mismo. La operación de bloque
coloca al proceso en una cola de espera asociada con el semáforo. El control es entonces
transferido al planificador del CPU, el cual selecciona otro proceso para ejecutar. Un proceso
que es bloqueado, esperando a un semáforo, debe reestablecerse cuando otro proceso ejecute
la operación V().
La cuestión importante es percatarse de que los semáforos trabajan solo cuando sus
operaciones son atómicas. En un ambiente de un solo procesador, esto se logra deshabilitando
las interrupciones por el tiempo que duren estas operaciones.
Candados (Locks)
Un candado es una primitiva de sincronización parecida a los semáforos, que provee
exclusión mutua. Las operaciones atómicas provistas son Acquire y Release. Un candado puede
estar libre u ocupado (al inicio esa libre). Antes de acceder a una variable compartida, un
proceso adquiere un candado, y lo libera al terminar su acceso a la variable.
Dos procesos A y B que acceden a una variable compartida podrían ejecutar el siguiente
código para sincronizar su acceso a sus secciones críticas:
Por convención, un candado es liberado por el proceso que lo adquiere (lo cual es diferente a
los semáforos). Un ejemplo simple es una lista con sincronización:
Lock candado;
InsertaEnCola() {
candado.Acquire();
añade un elemento en la cola;
candado.Release();
}
ExtraeDeCola() {
candado.Acquire();
162
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
if (algo en la cola)
extrae(elemento);
candado.Release();
return elemento;
}
El ejemplo anterior nos muestra un problema que los candados no son capaces de resolver.
La rutina ExtraeDeCola debería esperar a que hubiera algún elemento en la cola. Si lo que
hacemos es dormir al hilo hasta que alguien deposite un elemento en la cola, resulta que el
programa se bloquea, ya que al estar retenido el cerrojo, ningún otro hilo puede manipular la
cola. Por tanto hay que liberar el candado antes de esperar. Una posible solución sería:
ExtraeDeCola() {
candado.Acquire();
while (cola vacía) {
candado.Release();
candado.Acquire();
}
extrae(elemento);
candado.Release();
return elemento;
}
Esta solución funciona, pero utiliza espera activa, es decir que el hilo está continuamente
entrando y saliendo de la sección crítica para revisar si la cola está vacía.
Un proceso puede hacer llamadas a procedimientos por medio de un monitor, pero no puede
acceder directamente a las estructuras de datos del monitor. La propiedad más importante de
un monitor es que un solo proceso puede estar activo en el monitor en cualquier instante.
Cuando un proceso llama al procedimiento monitor, el procedimiento primero checa si otro
proceso esta activo en el monitor. Si es así, el proceso que hace la llamada es suspendido
hasta que el otro proceso haya dejado el monitor. Si ningún otro proceso esta usando el
monitor, el proceso que llamó puede entrar.
163
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los monitores necesitan proveer una forma para que los procesos se bloqueen entre si
cuando no puedan proceder. La idea de las variables de condición es tener un mecanismo que
permita a un proceso abandonar una sección crítica y a la misma vez quedarse bloqueado en
espera de una condición que alguien le debe notificar.
Como en los casos de los candados y los semáforos, se provee un conjunto de operaciones
atómicas, que son:
• wait(): libera el candado del monitor del objeto; pone el hilo a dormir.
• notify(): levanta a un proceso que espera en la condición; este proceso tratara de
readquirir el candado del monitor.
• notifyall(): despierta a todos los procesos en condición de espera; cada proceso tratara de
retomar el candado del monitor.
Sea por ejemplo un proceso productor que genera numeros, y uno o varios procesos
consumidores que harán uso de ellos. Para asegurar que el producto estará disponible para
todos los consumidores, este se ofrecerá como recurso compartido a todos aquellos que lo
requieran.
En lenguajes de alto nivel como Java se cuenta con construcciones del lenguaje que permiten
codificar este tipo de programas de manera sencilla. La sección de código en donde se declaran
las estructuras de sincronización es en el recurso compartido. En el ejemplo puede apreciarse
como los métodos get() y put() encargados de aceptar o ceder un valor almacenado tienen la
declaración synchronized, y dentro de los métodos es donde se hace referencia a las
operaciones del monitor.
164
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El productor entonces deberá contar con una instancia del recurso compartido, la cual será
enviada como parámetro durante su inicialización, para después hacer uso de él depositando
los objetos que genere.
165
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
sleep((int)(Math.random() * 100));
} catch (InterruptedException e) { }
}
}
}
Por su parte el consumidor tambien debe contar con una instancia del recurso compartido, la
cual será enviada como parámetro durante su inicialización; de esta manera tendrá acceso a
los objetos generados por el productor.
Para evitar que dos procesos se activen dentro de un monitor al mismo tiempo, se necesita
una regla que especifique que es lo que pasa después de una llamada Signal.
Debería B esperar hasta que A deje el monitor o debería A esperar hasta que B deje el
monitor. Los investigadores han defendido las dos alternativas: prioridad al que ya está dentro,
o al que estaba esperando. Las dos propuestas clásicas son las de Tony Hoare (investigador
británico) y la de Mesa (lenguaje de programación desarrollado por Xerox en los 1970s):
166
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Estilo Mesa: Quien hace Signal continúa reteniendo el candado. El proceso que había hecho
Wait se pone en la cola de preparados sin ninguna prioridad especial y esperará a adquirir
de nuevo el candado (en pugna con los restantes procesos).
• Estilo Hoare: Quien hace Signal cede el cerrojo al del Wait y abandona la CPU. El proceso
que había hecho Wait entra en ejecución sobre la marcha. El que hizo Signal tiene que
esperar a adquirir de nuevo el candado.
Una diferencia fundamental entre semáforos y variables de condición es que éstas no tienen
memoria. Si alguien ejecuta una operación Signal sin que haya nadie esperando, esa operación
se pierde para siempre, mientras que un semáforo "recuerda" para posteriores Waits.
Interbloqueos⊕
Un sistema está interbloqueado cuando dos o más procesos esperan por un evento que no va
a ocurrir. Por ejemplo, supóngase que existen dos procesos P1 y P2 que comparten dos
recursos R1 y R2. P1 solicita el recurso R2 mientras tiene asignado R1 y simultáneamente P2
solicita R1 mientras tiene asignado R2. En este caso se presenta un interbloqueo.
Cuando los recursos son compartidos entre varios usuarios, donde cada uno mantiene un
control exclusivo sobre determinados recursos asignados a ese usuario, pueden producirse
interbloqueos, en los cuales los procesos de algunos usuarios no podrán llegar a su término.
⊕
Obras consultadas: [5.10] [5.33] [5.34]
25
Imagen reproducida de [5.10]
167
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Cuando los recursos son planeados en función de prioridades, es posible que un proceso dado
espere indefinidamente en tanto continúen llegando procesos de prioridades más importantes.
Hay cuatro condiciones necesarias que deben darse para que se produzca un interbloqueo
[5.34]:
1. Los procesos reclaman control exclusivo de los recursos que piden (condición de
exclusión mutua).
2. Los procesos mantienen los recursos que ya les han sido asignados, mientras esperan
recursos adicionales (condición de espera por).
3. Los recursos no pueden ser extraídos de los procesos que los tienen hasta su completa
utilización (condición de no apropiatividad).
4. Existe una cadena circular de procesos en la cual cada uno de ellos mantiene a uno o
más recursos que son requeridos por el siguiente proceso de la cadena (condición de
espera circular).
Existen algunas estrategias para evitar varias de las condiciones de interbloqueo [5.34]:
1. Cada proceso deberá pedir todos sus recursos requeridos de una sola vez y no podrá
proceder hasta que le hayan sido asignados.
2. Si a un proceso que mantiene ciertos recursos se le niega una nueva petición, éste
deberá liberar sus recursos originales y en caso necesario pedirlos de nuevo junto con
los recursos adicionales.
3. Se impondrá la ordenación lineal de los tipos de recursos en todos los procesos, es
decir, si a un proceso le han sido asignados recursos de un tipo dado, en lo sucesivo
sólo podrá pedir aquellos recursos de los tipos que siguen en el ordenamiento.
Prevención y tratamiento
Existen dos tipos de prevenciones: una estática, cuya solución se basa en un conjunto de
reglas y otra dinámica, en la cual se evita que ocurra, no asignando recursos cuando ello puede
conducir a interbloqueos.
La prevención estática se basa en el hecho que para que ocurra un interbloqueo se deben
dar las siguientes cuatro condiciones en forma simultánea:
168
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Si se desea evitar los interbloqueos, se debe impedir que se cumpla al menos una de las
cuatro condiciones. La condición (c1) no se puede evitar, ya que como se mencionó
previamente, los recursos se deben utilizar en exclusión mutua. Para evitar la condición (c2) se
puede actuar de la siguiente forma: Si un proceso tiene asignado un recurso R1 y le es negado
otro recurso R2, entonces se le retira el recurso R1. Sin embargo, esta solución puede llevar a
que la ejecución de un proceso se prolongue indefinidamente, debido a que nadie puede
garantizar que termine en un tiempo determinado.
Para evitar la condición (c3), se pueden asignar todos los recursos necesitados por el proceso
en el momento de su creación, sin embargo, esto conlleva a un manejo poco eficiente de los
mismos.
Para eludir la condición (c4) se puede hacer una asignación recursos por niveles. En este caso
se le asigna a cada tipo de recurso un nivel y se establece que los recursos deben ser
asignados en orden ascendente de nivel.
La prevención dinámica consiste en analizar cada vez que se va a asignar un recurso, si tal
asignación puede conducir a un interbloqueo (situación no-segura), en cuyo caso no se asigna.
En caso contrario (situación segura) el recurso se asigna.
Por ejemplo suponga que en el sistema existen múltiples recursos de un solo tipo y que
existen cuatro procesos que quieren usarlos.
MÁXIMO RECURSOS
PROCESO RECURSOS ASIGNADOS
NECESARIOS
P1 4 8
P2 3 7
P3 3 5
P4 0 5
169
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 5.14 Esquema donde los procesos que requieren acceder a un recurso
compartido
Tanto los semáforos como los monitores, están limitados por el alcance que tienen, es decir son
primitivas y abstracciones que operan sobre una computadora aislada. Cuando se desea trabajar
sobre un sistema distribuido en un ambiente de red, estos mecanismos ya no sirven, pues no
permiten comunicar procesos residentes en computadoras distintas.
Por esta razón existen otros tipos de comunicación entre procesos, en donde no es necesario
que los procesos se encuentren en la misma máquina. Dentro de estos mecanismos se
encuentran:
1. Paso de mensajes
2. Tuberías (Pipes)
3. RPC (esta se trata en la sección 5.4.3)
El esquema productor-consumidor
En el esquema productor-consumidor se definen dos tipos de procesos, productores y
consumidores, que escriben y leen información de una zona común denominada buzón.
Dado que la zona es compartida, se debe garantizar exclusión mutua para su manejo. Cuando
la zona se llene, se debe bloquear a los productores. Cuando la zona esté vacía, se debe
bloquear a los consumidores.
170
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Consumir(q)
p(lleno,q);
p(em,q);
m<==buzon[prox_cons];
prox_cons=(prox_cons+1)%n;
v(em);
v(vacío);
Fin_consumir
Vale la pena notar que la exclusión mutua solo afecta a las variables comunes (buzón,
prox_prod, prox_cons).
Mensajes
Consideraremos que un mensaje es una pieza de información que es enviada de un proceso
a otro. Además diremos que un buzón (Mailbox) es un lugar donde se almacenan los mensajes
a medida que estos se envían y reciben.
Por otro lado, existen 2 posibles operaciones sobre los mensajes, que son las siguientes.
171
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
#define N 100
#define MAILBOX 4;
typedef int message[MAILBOX];
void productor(void) {
int item;
message m;
while(1){
produce_item(item);
receive(consumidor,&m);
construir_mensaje;
send(consumidor,&m);
}
}
void consumidor(void) {
int item, i;
message m;
for (i=0;i<N;i++) send(productor,&m);
while(1){
receive(productor,&m);
extrae_mensaje;
send(productor,&m);
consume_item(item);
}
}
172
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Tuberías (pipes)⊕
Las tuberías (pipes) son mecanismos de comunicación entre procesos que permiten que dos o
más procesos se envíen información entre ellos. Un usuario puede ejecutar varios procesos e
interconectarlos a través de tuberías, simbolizados por el carácter ¦ (ASCII 124). Son usados
comúnmente por el shell para conectar la salida estándar de un comando a la entrada estándar
de otro. Aquí se muestra un ejemplo de un comando en UNIX que determina cuantos archivos,
con extensión .c hay en el directorio actual.
$ ls *.c | wc -l
El comando ls lista los archivos con extensión .c , y su salida va hacia el comando wc que
cuando se invoca con la opción -l muestra el total de líneas en la entrada. Así, el comando
completo con el pipe calcula el total de archivos con extensión .c que hay en el directorio
actual.
El pipe tiene un extremo para lectura y otro para escritura. Asociados a cada extremo puede
haber uno o más lectores o escritores. Si el pipe esta full, el escritor de turno automáticamente
⊕
Obras consultadas: [5.35] [5.36]
173
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
se suspende. Del mismo modo, si el pipe esta vacío, el lector de turno se suspende. Hay dos
tipos de pipes:
a. Nominales (named pipes). Los pipes nominales tienen menos restricciones que los pipes no
nominales, y entre sus ventajas se encuentran:
• Tienen un nombre que existe en el sistema de archivos.
• Pueden ser usados por procesos que no tienen ninguna relación.
• Existen hasta que son borrados explícitamente.
Todas las reglas mencionadas para los pipes no nominales aplican para los pipes nominales.
Excepto que los pipes nominales tienen mayor capacidad.
Los pipes nominales son archivos especiales del sistema de archivos y pueden crearse de las
siguientes formas (en sistemas UNIX):
• Usando el comando mknod desde el shell.
• Usando la llamada al sistema mknod().
174
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Semáforos. Una implementación del clásico modelo de semáforos (el cual se trata con mas
detalle en el siguiente capitulo), que además permite la creación de arreglos de semáforos.
• Colas de mensajes (Message queues). Son un modelo de transferencia de datos. Un
mensaje es una secuencia de bytes, con un tipo asociado. Los mensajes son escritos a las
colas de mensajes, y los mensajes pueden obtenerse leyendo las mismas estructuras,
restringiendo la lectura por medio del tipo de mensaje.
• Memoria compartida. Es un mecanismo por el cual varios procesos tienen acceso a la
misma región de memoria física.
• Sockets de dominio (Unix Domain sockets). Otro mecanismo de transferencia de datos
orientado a conexión que provee el mismo modelo de comunicación que los sockets INET.
El subsistema IPC expone llamadas de espera a otros subsistemas del kernel. Puesto que las
colas de espera no son usadas por los procesos de usuario, no tienen una interfaz de llamadas
al sistema.
26
Imagen reproducida de [5.32]
⊕
Obras consultadas: [5.11]
175
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• El medio sobre el cual circulan los datos y que forman una red local dotada de
propiedades estructurales y dinámicas
Los procesos para comunicarse, deben apegarse a reglas conocidas como protocolos. Para los
sistemas distribuidos en un área amplia, estos protocolos toman frecuentemente la forma de
varias capas y cada capa tiene sus propias metas y reglas. Los mensajes se intercambian de
diversas formas, existiendo muchas opciones de diseño al respecto; una importante opción son
las llamadas remotas a procedimientos.
176
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El modelo cliente - servidor tiene como idea fundamental la estructuración del SO como:
• Un grupo de procesos en cooperación, llamados servidores, que ofrecen servicios a
los usuarios.
• Un grupo de procesos usuarios llamados clientes.
Los procesos clientes y servidores han de seguir un protocolo de comunicaciones que defina
cómo se codifican las peticiones y cómo se sincronizan entre sí los procesos.
Direccionamiento
Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la dirección de
éste. Un esquema de direccionamiento se basa en la dirección de la máquina destinataria del
177
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Otro método de direccionamiento consiste en asignarle a cada proceso una única dirección
que no contenga un número de máquina. Una forma es mediante un asignador centralizado de
direcciones a los procesos que mantenga un contador. Al recibir una solicitud de dirección
regresa el valor actual del contador y lo incrementa en uno. La desventaja es el elemento
centralizado.
También existe el método de dejar que cada proceso elija su propio identificador en un
espacio de direcciones grande y disperso, por ejemplo: enteros binarios de 64 bits. La
probabilidad de que dos procesos elijan el mismo número es muy pequeña. Existe el problema,
para el núcleo emisor, de saber a qué máquina enviar el mensaje
Una opción distinta fue planteada por Birrel y Nelson, quienes propusieron permitir a los
programas que llamasen a procedimientos localizados en otras máquinas.
⊕
Obras consultadas: [5.11] [5.37]
178
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En cuanto a la ejecución, el ideal sería que no hubiera distinción entre una ejecución remota o
local de una función. Sin embargo, existen dos problemas que atentan contra esta transparencia:
1. La latencia de la red. El invocar una función remota puede tardar más que una
invocación local.
2. La confiabilidad de la red. La invocación remota implica enviar al servidor la identificación
de la función a ejecutar, al igual que los parámetros, y recibir del servidor el resultado de
la ejecución. Cualquiera de estos mensajes (solicitud o respuesta) puede ser extraviado o
duplicado por la red, por lo que deberá considerarse el manejo de estos errores en las
aplicaciones.
179
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
5.5 Comentarios
En el capítulo siguiente se hablará de los recursos que los procesos pueden consumir, y como
se requieren otros subsistemas para la administración de periféricos, almacenamiento y
comunicaciones en red.
180
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[5.6] Sistemas operativos I. Instituto tecnologico de [5.18] Sistemas operativos. Gabriela Herrera B.
Veracruz http://www.inf.udec.cl/~sistcomp/SistOpe/
http://itver.edu.mx/so1/sistemas_operativos.htm
[5.19] Round Robin Scheduling
[5.7] CS 537 Notes, Section #4: Independent and http://megahertz.njit.edu/~wxl3226/rr.html
Cooperating Processes. Barton P. Miller. 1997.
http://www.cs.wisc.edu/~bart/537/lecturenotes/
[5.20] Round Robin CPU Scheduling
http://www.cs.njit.edu/~web332/F98/CPU_scheduling/
[5.8] Monitores, variables condición y los cpuschd_rr.html
lectores/escritores
Adaptado del original de Tom Anderson (Universidad de
[5.21] Priority scheduling
Berkeley)
http://megahertz.njit.edu/~wxl3226/pr.html
[5.11] Sistemas operativos. Master David Luis la Red [5.24] Multilevel Feedback Queue Scheduling
Martínez http://megahertz.njit.edu/~yxy8776/node200.html
http://exa.unne.edu.ar/depar/areas/informatica/Sistem
asOperativos/SOF.htm
[5.25] Evolutionary Computation for Scheduling
Controls in Concurrent Object-Oriented Systems.
[5.12] Scheduling Simulations. Charles Baldridge and Tzilla Elrad, Jinlong Lin & Douglas J. Cork
Karl Papadantonakis. CS414 project
IJCA, PP.11-20, Vol.5, No.3, Sept, 1998, Published by
http://www.people.cornell.edu/pages/csb11/CS414/sim
ISCA.
.html
181
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
http://www.rice.iit.edu/~linjin/ijca98.zip
[5.34] Interbloqueo
[5.26] CS 537 Lecture Notes Part 3 - Processes and http://vysec.galeon.com/INTERB.HTML
Synchronization
http://www.cs.wisc.edu/~solomon/cs537/notes.html [5.35] Comunicación entre procesos
http://www.ldc.usb.ve/~adiserio/ci3825/CLASEPS21.ht
[5.27] Apuntes de Sistemas Operativos. Luis Mateu - ml
DCC - U. de Chile
http://www.dcc.uchile.cl/~jpiquer/Docencia/SO/aps/ap [5.36] Redirecciones y pipes
s.html
http://highland.dit.upm.es:8000/UNIX/movs2/3redir.ht
ml
[5.28] The Linux architecture
http://se.uwaterloo.ca/~mnarmstr/report1/node7.html [5.37] Remote procedure call
http://www.ai.ldc.usb.ve/~figueira/Cursos/redes/resour
[5.29] QNX Process manager ces/claseRPC.html
http://mazsola.iit.uni-
miskolc.hu/tempus/parallel/doc/drotos/rtos/procman/ [5.38] Message Passing Interface standard
http://www-unix.mcs.anl.gov/mpi/
[5.30] The Linux OS process management
http://home.att.net/~ejuke/papers/tlos1.0/procmgt.ht [5.39] An introduction to parallel computing
m http://www.pcc.qub.ac.uk/tec/courses/intro/ohp/intro-
ohp.html
[5.31] Conceptual Architecture of the Linux Kernel. Ivan
Bowman (ibowman@sybase.com) January 1998 [5.40] What is multithreading?
http://plg.uwaterloo.ca/~itbowman/CS746G/a1/ http://www.ece.gatech.edu/research/pica/compiler/mth
read.htm
[5.32] Concrete Architecture of the Linux Kernel. Ivan
Bowman (ibowman@sybase.com), Saheem Siddiqi [5.41] Introduction to Multithreading, Superthreading
(s4siddiqi@neumann), Meyer C. Tanuan and Hyperthreading. Jon "Hannibal" Stokes
(mtanuan@descartes.com). Department of Computer
Science, University of Waterloo. Winter 1998 http://www.arstechnica.com/paedia/h/hyperthreading/
hyperthreading-1.html
http://plg.uwaterloo.ca/~itbowman/CS746G/a2
182
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 6.
Administración de dispositivos, almacenamiento y
comunicaciones.
Se debe hacer todo tan sencillo como
sea posible, pero no más sencillo.
Albert Einstein
Además, los dispositivos varían mucho en cuanto a su velocidad. En muchos sentidos, estos
dispositivos también son los más lentos de los componentes principales de la computadora.
183
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En este capítulo veremos cómo es que el sistema operativo puede soportar la integración de
dispositivos adicionales en una computadora, y en específico se analizan los casos del
almacenamiento secundario y la comunicación en redes.
En lugar de colocar código en cada aplicación que se desarrolla para controlar cada dispositivo,
se comparte este código entre las aplicaciones. Para asegurarse de que el código no es
comprometido, se protege de los usuarios y programas normales que lo usan. Si se hace de
forma correcta, se tendrá la capacidad de agregar y quitar dispositivos al sistema sin cambiar las
aplicaciones.
Uno de los objetivos clave del subsistema de entrada/salida (E/S) de un sistema operativo es
proporcionar la interfaz más sencilla posible al resto del sistema, y puesto que los dispositivos
son un cuello de botella para el desempeño, es necesario optimizar la E/S de modo que la
concurrencia sea máxima.
El papel del sistema operativo en la E/S de una computadora es administrar y controlar las
operaciones de E/S y los dispositivos de E/S.
⊕
Obras consultadas: [6.5] [6.6]
184
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La tecnología de dispositivos de E/S exhibe dos tendencias que están en conflicto. Por un lado
vemos una creciente estandarización de las interfases de software y hardware. Esta tendencia
nos ayuda a incorporar generaciones de dispositivos mejorados a computadores y sistemas
operativos existentes. Por otro lado, vemos una variedad cada vez más amplia de dispositivos de
E/S. Algunos dispositivos nuevos son tan distintos de los anteriores que es un reto incorporarlos
en nuestros computadores y sistemas operativos. Este reto se enfrenta con una combinación de
técnicas de hardware y software.
La clasificación anterior no es perfecta, porque existen varios dispositivos que generan entrada
o salida que no pueden englobarse en esas categorías. Por ejemplo, un reloj que genera pulsos.
Sin embargo, aunque existan algunos periféricos que no se puedan categorizar, todos están
administrados por el sistema operativo por medio de una parte electrónica-mecánica y una parte
de software.
185
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Algunas veces el mismo controlador contiene un pequeño programa en una memoria de solo
lectura o en memoria de acceso aleatorio no volátil y re-escribible que interactúa con el
correspondiente manejador en la computadora. En la figura 6.1 se muestra un esquema simple
de dispositivos orientados a bloques y otros a caracteres.
Por ejemplo, la terminal (CRT) tiene un chip que se encarga de enviar cadenas de bits por
medio de un cable serial que a su vez son recibidos por un controlador de puerto serial en la
computadora. Este chip también se encarga de leer secuencias de bits que agrupa para su
despliegue en la pantalla o para ejecutar algunas funciones de control. Lo importante en todos
estos dispositivos es que se debe ejercer un mecanismo para sincronizar el envío y llegada de
datos de manera concurrente.
27
Imagen reproducida de [6.26]
28
Imagen reproducida de [6.26]
186
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para intercambiar datos o señales entre la computadora y los controladores, muchas veces se
usan registros o secciones predefinidas de la memoria de la computadora. A este esquema se le
llama manejo de entrada-salida mapeado por memoria (memory mapped I/O).
Por ejemplo, para una IBM PC se muestran los vectores de interrupción y las direcciones para la
entrada-salida:
⊕
Obras consultadas: [6.7]
187
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Proceso
de usuario
Aplicación
Subsistema
o DLL
Copia en
memoria del
Modo usuario usuario
Modo núcleo
Servicios
SW de E/S Gestor de
independiente archivos
de dispositivo Gestor de
bloques Copia en el
Gestor de sistema
SW de E/S cache operativo
independiente
de dispositivo Manejador
SW de E/S de
dependiente
dispositivo
de dispositivo
Manejador de
Software interrupción
Hardware Copia en el
Controlador controlador
Los manejadores de dispositivo son programas añadidos al núcleo del sistema operativo,
concebidos inicialmente para gestionar periféricos y dispositivos especiales. Los controladores de
dispositivo pueden ser de dos tipos:
• orientados a caracteres (tales como los dispositivos NUL, AUX, PRN, etc. del sistema) o bien
• orientados a bloques, constituyendo las conocidas unidades de disco.
La diferencia fundamental entre ambos tipos de controladores es que los primeros reciben o
envían la información carácter a carácter; en cambio, los controladores de dispositivo de bloques
procesan, como su propio nombre indica, bloques de cierta longitud en bytes (sectores).
188
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Peticiones de
E/S del dispositivo
Si No
Enviar mandatos
Error
al controlador
Programación del
controlador
No Leer registros
Bloqueo estado del
controlador
Si
Esperar Interrupción
interrupción
Muchos sistemas operativos modernos tienen un método para instalar archivos especiales para
hacer que el hardware funcione; aquí algunos casos:
• En la Mac, por ejemplo, los manejadores para los dispositivos de hardware son archivos que
se encuentran en la carpeta System Extensions.
• Linux también tiene archivos especiales que usa para controlar el hardware.
• En el JavaOS una colección de clases llamada JDI (Java Driver Interface) provee soporte para
manejadores de dispositivo. Los manejadores acceden a los dispositivos indirectamente por
medio de las clases de la plataforma que abstraen las interrupciones, direccionamiento y
administración de memoria del dispositivo de hardware. Puesto que los manejadores están
protegidos del contacto directo con el hardware, la integridad del sistema operativo y errores
de procesamiento se minimiza.
189
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Como se ve, el CPU gasta varios ciclos en leer los datos deseados. El DMA soluciona ese
problema de la siguiente forma. Cuando un proceso requiere uno o varios bloques de datos, el
190
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
CPU envía al controlador la petición junto con el número de bytes deseados y la dirección de en
dónde quiere que se almacenen de regreso. El DMA actuará como un "CPU secundario" en
cuanto a que tiene el poder de tomar el control del bus e indicarle al verdadero CPU que espere.
Cuando el controlador tiene listos los datos, el DMA "escucha" si el bus está libre aprovechando
esos ciclos para ir leyendo los datos del buffer del controlador e ir escribiéndolos en el área de
memoria que el CPU le indicó. Cuando todos los datos fueron escritos, se le envía una
interrupción al CPU para que use los datos.
El ahorro con el DMA es que el CPU ya no es interrumpido (aunque sí puede ser retardado por
el DMA) salvando así el cambio de contexto y además el DMA aprovechará aquellos ciclos en que
el bus no fue usado por el CPU. El hecho de que los controladores necesiten buffers internos se
debe a que conforme ellos reciben datos de los dispositivos que controlan, los deben poder
almacenar temporalmente, ya que el CPU no está listo en todo momento para leerlos.
En los dispositivos simples, como los puertos serie, terminales, teclados, etc., la interacción se
limita a menudo a abrir el archivo con la llamada open(), para lectura o escritura y volcar o leer
los datos que queremos transmitir o recibir, mediante las llamadas read() y write(). En muchos
dispositivos, sobre todo en los más sofisticados, como tarjetas de sonido, escáners, tarjetas de
video, etc., es necesario interactuar de forma más específica con el hardware. Para ello se
recurre a la llamada ioctl(), que permite modificar los parámetros del dispositivo (como velocidad,
paridad, bits de stop, etc. del puerto serie; bits por muestra o frecuencia de muestreo en una
tarjeta de sonido, etc.), así como instruir al periférico para que realice accesos directos a
memoria u otras operaciones específicas.
Los archivos especiales (en UNIX hay tres tipos de archivo: archivos normales o "regulares",
archivos especiales y directorios) ocultan una funcionalidad especial bajo la apariencia de
archivos convencionales, con su ruta de acceso, sus atributos, etc.
De hecho, estos archivos no contienen información ni ocupan espacio si los duplicamos. Los
únicos datos útiles que contienen son el major number y el minor number, que identifican
unívocamente el dispositivo que representan.
• El major number indica el tipo de dispositivo (p.ej. 3 es un disco del primer IDE, 22 uno
del segundo IDE, 2 es un disco flexible, etc.)
⊕
Obras consultadas: [6.11]
191
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• El minor number indica un número de orden dentro de los dispositivos de cada tipo
(p.ej., entre los discos de un IDE, el 0 es el primer disco, el 64 el segundo, el 1 es la
primera partición del primer disco, el 2 la segunda, etc.).
Para crear un archivo especial de dispositivo se usa la orden mknod(), que recibe un nombre de
archivo, un tipo (bloques o caracteres), un major y un minor number.
• /dev/fd0: Primer floppy.
• /dev/hda: Disco master del primer IDE.
• /dev/hdd3: Tercera partición del disco slave del segundo IDE. (Las particiones primarias
van de la 1 a la 4 y las lógicas de la 5 a la 20.)
• /dev/sda2: Segunda partición del primer disco SCSI.
• /dev/scd0: Primer CD-ROM SCSI. (Los CD-ROM IDE se ven como discos magnéticos.)
• /dev/st0: Primera unidad de cinta SCSI.
• /dev/tty2: Tercera consola.
• /dev/ttyS0: Primer puerto serie.
• /dev/ptyp5: Sexta pseudoterminal maestra.
• /dev/ttyp5: Sexta pseudoterminal esclava (el proceso que crea la terminal abre la
maestra y el que la va a usar abre la esclava).
Dispositivos virtuales:
• /dev/loop0: Primer archivo "loopback". Se asocia un archivo normal para poder montarlo
como un dispositivo de bloques.
• /dev/mem: Permite acceder a la memoria física.
• /dev/kmem: Permite acceder a la memoria virtual del núcleo.
• /dev/null: Como un agujero negro que se lo "traga" todo.
• /dev/port: Permite acceder a los puertos de E/S.
• /dev/zero: Suministra incansablemente caracteres "\0".
• /dev/full: Devuelve error de dispositivo lleno.
• /dev/random: Da auténticos números aleatorios de un pozo de entropía.
• /dev/urandom: Devuelve siempre números (pseudo)aleatorios.
• /dev/stdin: Entrada estándar del proceso en curso.
192
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las rutinas para acceder a los puertos de E/S residen en include/asm-i386/io.h y son macros,
de modo que basta con incluir el archivo para poder usarlas, sin necesidad de enlazar con librería
alguna. Debido a una peculiaridad del compilador gcc, la optimización debe estar activada
cuando se usan estas funciones.
Para acceder a los puertos desde un programa C fuera del núcleo, hay que ser súper usuario y,
además, requerir del sistema operativo el permiso para hacerlo. Para ello se dispone de la
función ioperm() o iopl(). Desde dentro del núcleo (o de un módulo, que es lo mismo), no hace
falta llamar a estas funciones.
La E/S se realiza a través de la función inb(port), que devuelve el valor (de 8 bits) al que se
encuentra el puerto correspondiente, y de la función outb(valor,puerto), que envía un valor de 8
bits sobre un puerto. Debe ponerse atención al orden de los parámetros, pues es distinto al
adoptado por algunos compiladores comunes en el mundo de DOS y Windows.
Desde el núcleo, el acceso a los puertos de E/S está regulado mediante un mecanismo de
reserva de rangos de direcciones. Esto permite que los manejadores sepan si un rango de
puertos está siendo utilizado por otros manejadores. Para ello se dispone de tres funciones que
debemos emplear para no colisionar con otros manejadores.
• int check_region (unsigned int port, unsigned int range) : Comprueba si un rango de range
puertos a partir de port están siendo utilizadas por otro módulo, devolviendo un valor
negativo si es así.
• void request_region (unsigned int port, unsigned int range, const char *name) : Reserva un
rango de range puertos a partir de port, identificándolo con name.
• void release_region (unsigned int port, unsigned int range) : Libera un rango de range
puertos a partir de port, reservados anteriormente.
Se puede saber en un momento dado cuáles son los rangos de puertos reservados por los
diferentes manejadores que se han instalados en el sistema visualizando el archivo /proc/ioports.
En un sistema de cómputo es evidente que existe la necesidad por parte de los usuarios y
aplicaciones de almacenar datos en algún medio, a veces por periodos largos y a veces por
instantes. Cada aplicación y cada usuario debe tener ciertos derechos con sus datos, como son el
poder crearlos y borrarlos, o cambiarlos de lugar; así como tener privacidad contra otros usuarios
193
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• El almacenamiento Magnético.
1. Discos Flexibles
2. Discos Duros
3. Cintas Magnéticas o Cartuchos.
• Medios Magnético - Ópticos. Estos medios combinan algunas de las mejores características
de las tecnologías de grabación magnética y óptica. Un disco MO tiene la capacidad de un
disco óptico, pero puede ser re-grabable con la facilidad de un disco magnético. Actualmente
están disponibles en varios tamaños y capacidades.
Debe ser conocido por todos que tradicionalmente la información en los sistemas modernos se
almacena en discos duros, flexibles y unidades de disco óptico, y en todos ellos se comparten
algunos esquemas básicos para darles formato físico:
• Las superficies de almacenamiento son divididas en círculos concéntricos llamados "pistas" y
cada pista se divide en "sectores".
194
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para poder acceder a estos dispositivos es necesario contar con manejadores específicos.
Planificador
Manejador de disco
Manejador Manejador Manejador … Manejador
de CD_ROM SCSI IDE de floppy
195
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
6.2.3 Archivos
La unidad lógica de almacenamiento para la información son los archivos. Estos son mapeados
por el SO en los dispositivos físicos. En general son tratados como una secuencia de bits, bytes o
registros (el significado lo da el creador del archivo).
Un archivo es un repositorio persistente de información, que puede ser leído o escrito por los
procesos de usuario. Los archivos son identificados por nombres. En sistemas antiguos, el
nombre del archivo estaba estructurado con un nombre (8 caracteres por lo regular) y una
extensión (que identifica el formato del archivo). Los sistemas actuales permiten que el nombre
contenga (casi) cualquier número de caracteres.
La información de todos los archivos se guarda en una estructura de directorios que reside en el
dispositivo de almacenamiento secundario junto con los archivos. Los directorios permiten al
usuario administrar grupos de archivos de una forma jerárquica.
Todos los archivos poseen un nombre, su localización y datos. Además pueden tener algunos o
todos los siguientes atributos asociados:
La interfaz que el SO provee para el sistema de archivos contiene, entre otras cosas, las
operaciones para manipular archivos (creación, apertura, escritura o truncamiento de archivos).
Muchas de estas operaciones con archivos implican la búsqueda de algún atributo asociado con
los archivos en la estructura de directorios. Puesto que buscar la referencia de un archivo para
cada operación realizada en él puede ser costoso, el SO mantiene una pequeña tabla que
contiene información sobre los archivos abiertos (la tabla de archivos abiertos). Cuando se
requiere una operación, un índice en esta tabla de archivos se usa para obtener el resultado
adecuado. Cuando el archivo ya no se está usando, se cierra por el proceso y el SO quita sus
datos de la tabla de archivos abiertos.
196
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 6.8 Objetos del sistema operativo y sus operaciones relacionadas con archivos.
Cada proceso también mantiene una tabla de todos los archivos que ha abierto. Esta almacena
la información sobre como el (los) archivo(s) están siendo usados, p.ej., la localización actual del
apuntador al archivo. Cada elemento de esta tabla apunta al elemento correspondiente de la
tabla de archivos abiertos.
⊕
Obras consultadas: [6.3]
197
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
198
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
199
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Directorios. Son archivos del sistema para el mantenimiento de una estructura del
sistema de archivos
29
Imagen reproducida de [6.25]
200
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
cabecera
Atributos
Tamaño
Nombre
Nombre Seguridad
Atrib.
Size KB
Agrup. FAT Datos
Vclusters
Adicionalmente deben definirse las unidades que maneja el sistema de archivos para operar:
Una partición es una porción de un disco a la que se la dota de una identidad propia y que
puede ser manipulada por el sistema operativo como una entidad lógica independiente. Una
201
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
vez creadas las particiones, el sistema operativo debe crear las estructuras de los sistemas de
archivos dentro de esas particiones.
202
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Crear ( create ) : Permite crear un archivo sin datos, con el propósito de indicar que
ese nombre ya está usado y se deben crear las estructuras básicas para soportarlo.
• Borrar ( delete ): Eliminar el archivo y liberar los bloques para su uso posterior.
• Abrir ( open ): Antes de usar un archivo se debe abrir para que el sistema conozca sus
atributos, tales como el dueño, la fecha de modificación, etc.
• Cerrar ( close ): Después de realizar todas las operaciones deseadas, el archivo debe
cerrarse para asegurar su integridad y para liberar recursos de su control en la
memoria.
Los subsistemas de archivos también proveen un conjunto de llamadas para operar sobre
directorios, las más comunes son crear, borrar, abrir, cerrar, renombrar y leer. Sus
funcionalidades son obvias, pero existen también otras dos operaciones no tan comunes que
son la de “crear una liga” y la de “destruir la liga”.
La operación de crear una liga sirve para que desde diferentes puntos de la organización de
directorios se pueda acceder un mismo directorio sin necesidad de copiarlo o duplicarlo. La
llamada a "destruir la liga" lo que hace es eliminar esas referencias, siendo su efecto la de
eliminar las ligas y no el directorio real. El directorio real es eliminado hasta que la llamada a
"destruir liga" se realiza sobre él.
203
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
204
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
otro a la dirección deseada. Este es un esquema excelente para archivos grandes pero
no para pequeños, porque la relación entre bloques destinados para índices respecto a
los asignados para datos es incosteable..
205
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Tolerancia a fallas
Al sistema de E/S se le exige máxima fiabilidad, ya a que no se desea perder los datos y
programas que almacena.
Cuando un proceso realiza una llamada al sistema orientada a los archivos, el kernel llama
una función contenida en el VFS. Esta función se encarga de las manipulaciones de la
estructura independiente y redirecciona la llamada a una función del sistema físico indicado,
que es responsable de manejar las operaciones del sistema dependiente. El código del sistema
de archivos usa las funciones de caché para las peticiones de E/S de los dispositivos.
206
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El VFS define un conjunto de funciones que cada sistema de archivos debe implementar. Esta
interfaz esta formada por un conjunto de operaciones asociadas a tres tipos de objetos:
filesystems, inodes, y open files.
El VFS tiene conocimiento de los sistemas de archivos soportados por el kernel, para lo que
usa una tabla definida durante la configuración del kernel. Cada elemento de la tabla describe
un tipo de sistema de archivos: contiene el nombre del tipo de sistema de archivos y un
apuntador a la función llamada durante la operación de montaje (del dispositivo de
almacenamiento). Cuando un sistema de archivos va a ser montado, la función apropiada de
montaje es llamada. Esta función es responsable de leer el superbloque del disco, inicializar sus
variables internas, y regresar un descriptor del sistema de archivos montado al VFS. Después
de que el sistema de archivos es montado, las funciones del el VFS pueden usar este descriptor
para acceder a las rutinas del sistema de archivos físico.
El descriptor del sistema de archivos montado contiene varios tipos de datos: información que
es común a todos los sistemas de archivos, apuntadores a las funciones provistas por el código
del sistema de archivos físico, y datos privados mantenidos por el sistema de archivos físico.
Los apuntadores a funciones están contenidos en los descriptores del sistema de archivos,
permitiendo que el VFS accese a las rutinas internas del sistema de archivos.
El sistema operativo de los laboratorios AT&T Bell, Plan 9, establece varios principios
interesantes en relación al manejo de archivos. El primero es que todos los objetos del sistema
son archivos o sistemas de archivos. Todo con lo que un programa puede comunicarse, se ajusta
a esta abstracción.
En Plan 9, toda la comunicación con archivos está expresada por un protocolo que puede ser
transmitido, por lo que todo puede convertirse en un sistema remoto de archivos (por lo que no
importaría saber el lugar donde reside un archivo particular).
⊕
Obras consultadas: [6.4] [6.21]
207
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En el caso de Off++ se propone una abstracción llamada caja (box), que se define como un
recipiente siempre abierto que contiene datos. Los recursos del sistema que pueden ir desde
aplicaciones enteras hasta variables definidas por el usuario pueden representarse mediante
cajas. Las operaciones que aplican a estas estructuras son:
copy(otherBox,aBox) , la cual copia una caja en otra (suponiendo que ambas cajas sean
de tipos compatibles)
share(otherBox,aBox) , la cual hace a una caja convertirse lógicamente en otra (en el
caso de que sean de tipos compatibles)
select(aBox,aSelector)->innerBox, la cual regresa una referencia de una caja dentro de
otra.
El objetivo de las cajas es proveer una abstracción y mecanismos para expresar relaciones y
dependencias en un ambiente distribuido.
El sistema de archivos provee dos niveles de interfaz: una interfaz de llamadas al sistema
disponible a los procesos de usuario (operaciones con archivos (open/close/read/write/seek/tell)
y directorios (readdir/creat/unlink/chmod/stat) que cumplen con la especificación de sistemas
POSIX), y una interfaz interna, usada por los subsistemas del kernel (inodes y archivos).
Los dispositivos de caracteres deben ser accedidos secuencialmente; ejemplos típicos son
cintas, módems, y el ratón. Los dispositivos de bloque pueden ser accedidos en cualquier orden,
pero solo pueden ser leídos o escritos en múltiplos del tamaño de bloque.
208
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Aunque es posible acceder dispositivos físicos por medio de sus archivos especiales de
dispositivo, es más común acceder dispositivos de bloque por medio de un sistema lógico de
archivos. Un sistema de archivos lógico puede ser montado en algún punto del sistema virtual de
archivos, lo que significa que el dispositivo de bloque asociado contiene archivos y estructuras de
información que permiten al sistema lógico de archivos acceder al dispositivo.
30
Imagen reproducida de [6.24]
209
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los grandes sistemas centralizados fueron dejando paso lentamente a sistemas mucho más
descentralizados, y formados por varias computadoras o sistemas multiprocesador. Pronto
surgieron nuevas necesidades de interconexión de los equipos, y se desarrollaron las redes de
área local (LAN), como Ethernet o Token Ring. En la actualidad, Internet es la red de mayor
tamaño y la más usada, y mantiene un impresionante ritmo de crecimiento. Además, Internet es
la base de muchos nuevos proyectos de sistemas distribuidos.
31
Imagen reproducida de [6.24]
⊕
Obras consultadas: [6.14][6.15]
210
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Una vez resuelto el problema de extender el poder de cálculo en las primeras generaciones de
computadoras, se comenzó a atacar el problema de compartir los datos y la información que ese
poder de cálculo produjo, lo cual llevó a inventar formas de compartir recursos (impresoras,
graficadores, archivos, etc.) a través de algún medio de transmisión usando una serie de reglas
(protocolos) para acceder y manipular dichos recursos.
Este modelo fue reemplazado por otro que considera un gran número de computadoras
separadas, pero interconectadas, que efectúan el mismo trabajo. Estos sistemas, se conocen con
el nombre de redes de computadoras.
Una red de computadoras es un sistema de comunicación de datos que enlaza dos o más
computadoras y dispositivos o periféricos.
En 1969 la Advanced Research Projects Agency (ARPA) del Pentagono creó la primera red
llamada ARPAnet, la cual constaba sólo de cuatro computadoras conectadas. ARPAnet (la
antecesora de la actual Internet) era una red experimental de investigación militar, en particular
la investigación sobre cómo construir redes que pudieran soportar fallas parciales (como las
producidas por bombardeos) y aún así funcionar. En el modelo ARPAnet, la comunicación
siempre ocurre entre una computadora fuente y una destino. La red asume por si misma que es
falible; cualquier parte de la red puede desaparecer en cualquier momento. La red fue diseñada
para requerir un mínimo de información de las computadoras que forman parte de ella.
Las primeras redes de cómputo comenzaron a operar a mediados de los años 70’s y la forma de
comunicación entre dos computadoras era manual, se empleaba una cinta magnética o una pila
de tarjetas perforadas, las cuales necesitaban ser insertadas a la otra computadora mediante la
intervención humana, es decir, no funcionaban automáticamente como hoy se hace. Más tarde,
este proceso se perfecciono y se logró transmitir información mediante cables conectando 3 o
más computadoras, surgiendo así las redes, esta comunicación se establecía a muy baja
velocidad y además había un gran inconveniente, las computadoras que formaban la red tenían
que funcionar a la perfección porque a la menor falla de cualquiera de ellas la red dejaba de
operar y era necesario desconectarla para dejar funcionando a las demás.
211
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las redes en general, se avocan a compartir recursos, y uno de sus objetivos es hacer que
todos los programas, datos y equipo estén disponibles para cualquiera en la red que así lo
solicite, sin importar la localización física del recurso y del usuario.
Redes Punto a punto.- Cada máquina tiene los mismos derechos de acceso como todas las
demás; no existe un local central para las aplicaciones. Una red punto a punto es una
colección de computadoras que comparten información igualmente, donde no existe una
máquina central en la red. Los sistemas punto a punto son menos costosos que los
sistemas basados en servidores, pero poseen más restricciones, especialmente en el
aspecto del desempeño y del número total de usuarios. Los sistemas punto a punto están
formados por pequeños grupos de trabajo que conectan un número pequeño de
computadoras (de 2 a 20); los sistemas basados en servidores normalmente conectan más
de 100 computadoras.
Redes Cliente - Servidor.- Una red tipo Cliente-Servidor es una colección de computadoras
(servidores) que agrupan recursos compatibles y computadoras (clientes) que acceden a
dichos recursos desde los servidores.
• Malla.- Son las más caras, pero a su vez son las más flexibles. Vienen caracterizadas por
encontrar caminos entre estaciones muy rápidamente, pero hay que tener en cuenta que
para N nodos, necesitamos N-1 enlaces, teniendo pues en total (N(N-1))/2 enlaces.
• Bus.- Tenemos un enlace por cada nodo, y estos se conectan a un enlace que une todas
las estaciones. Típica.
• Anillo.- Cada nodo tiene dos enlaces, puesto que la información siempre le vendrá de un
lado y la enviará hacia el otro. Un ejemplo de esta configuración la encontramos en un
Token Ring.
• Estrella.- Esta configuración está siendo eliminada poco a poco, puesto que todo el
sistema se basa en la estación central y si por algún motivo cayese, todo el sistema se
vería afectado. El nodo central, para N estaciones, tiene N-1 enlaces, mientras que las
otras estaciones tan sólo tendrían uno que es el que les vendría de la estación central.
• Árbol.- Todas las estaciones cuelgan de una computadora central y se conectan entre ellas
a través de los hubs que haya instalados.
⊕
Obras consultadas: [6.16][6.17]
212
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 6.18a Algunas ejemplos de las topologías que una red puede adoptar.
Las redes también se pueden clasificar en base a su ámbito de influencia. Según este criterio
se pueden clasificar en tres grandes grupos:
• LAN (Local Area Network): Redes de área local. La longitud entre los nodos más distantes
no debe exceder los 5 Km.
• MAN (Metropolitan Area Network): Redes de área metropolitana.
• WAN (Wide Area Network): redes de área extensa o amplia.
1. Capa física. Transmite bits de una computadora a otra, y regula la transmisión de cadenas
de bits sobre el medio físico. En esta capa se define cómo se une el cable al adaptador de red,
y qué técnica de transmisión se emplea para enviar datos por el cable.
2. Capa de enlace. Aquí se empaquetan en bruto los bits de la capa física en tramas (paquetes
de datos estructurados y lógicos) Es la responsable de transferir tramas de una computadora a
otra sin errores. Después de enviar una trama se espera una expresión de reconocimiento de la
computadora receptor.
3. Capa de red: Dirige mensajes y traduce traducciones lógicas, y nombres de direcciones
físicas. También determina la ruta desde el origen al destino, y gestiona problemas de tráfico
como conmutar, encaminar y controlar la congestión de paquetes de datos.
4. Capa de transporte: Maneja los errores de reconocimiento y la recuperación. También
empaqueta grandes mensajes cuando es necesario transmitirlos en pequeños paquetes o
reconstruye los originales en el lado de la recepción. También envía reconocimiento de la
recepción.
5. Capa de sesión: permite a dos aplicaciones de diferentes computadoras establecer, usar y
terminar una comunicación. A este nivel se establece el diálogo de control entre dos
computadoras regulando cuál transmite, cuándo y cuánto.
6. Capa de presentación: en este nivel el sistema operativo traduce la información que el
usuario generó en el nivel anterior. Se encripta la información (si fuese necesario) o se
comprime, con el objetivo de disminuir el tráfico de la red y de la forma más fiable.
7. Capa de aplicación: representa el nivel en el que se encuentran las aplicaciones que acceden
a los servicios de red. El usuario maneja estas aplicaciones en esta capa cuando trabaja con
programas clientes de correo electrónico, acceso a datos de otros equipos, etc.
213
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Interconexión de computadoras
Hay varias maneras de conectar computadoras físicamente: los puertos seriales, puertos
paralelos, o adaptadores a los medios de comunicación especiales. Los ejemplos de medios de
comunicación especiales incluyen Ethernet, Token Ring, ISDN, y otros.
214
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Hecha la elección del medio físico, todavía se tiene que escoger un protocolo. El protocolo es
un juego de reglas que describen cosas como el formato de mensajes de la red.
215
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Protocolos⊕
Un protocolo de comunicaciones es un conjunto de normas que están obligadas a cumplir
todas las máquinas y programas que intervienen en una comunicación de datos entre
computadoras sin las cuales la comunicación resultaría caótica y por tanto imposible
Los protocolos establecen una descripción formal de los formatos que deberán presentar los
mensajes para poder ser intercambiados por equipos de cómputo; además definen las reglas
que ellos deben seguir para lograrlo.
32
Imagen reproducida de [6.24]
⊕
Obras consultadas: [6.18] [6.19]
216
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los protocolos están presentes en todas las etapas necesarias para establecer una
comunicación entre equipos de cómputo, desde aquellas de más bajo nivel (p.ej. la transmisión
de flujos de bits a un medio físico) hasta aquellas de más alto nivel (p.ej. el compartir o
transferir información desde una computadora a otra en la red). Tomando al modelo OSI
(Open Systems Interconection) como referencia podemos afirmar que para cada capa o nivel
que él define existen uno o más protocolos interactuando. Los protocolos son entre pares
(peer-to-peer), es decir, un protocolo de algún nivel dialoga con el protocolo del mismo nivel
en la computadora remota.
Protocolos punto a punto. Son los protocolos más antiguos y elementales utilizados para la
comunicación mediante una línea de datos entre dos únicas computadoras. Algunas de sus
normas básicas establecen los criterios siguientes:
• Papel que asume cada una de las dos partes durante una sesión de comunicaciones,
identificándose y definiendo el papel correspondiente a la computadora que ha iniciado
la sesión y al que responde. Al primero se le llama "comando" y al segundo,
"respuesta".
• Manera de controlar la correcta recepción de los datos. Por ejemplo, añadiendo un
carácter al final de cada mensaje que sea la suma total de bit utilizados.
• Tiempo máximo que debe pasar entre el envío de un mensaje y la recepción del acuse
de recibo desde la estación receptora.
• Número veces que se debe repetir un mensaje en caso de que, pasados los tiempos
correspondientes, no se reciba el mensaje de acuse de recibo.
Comunicación entre redes. Además de las normas del apartado anterior, han de especificar
la forma de identificar al terminal concreto de la red con el que se debe establecer la
comunicación en el caso de que las máquinas que se están comunicando directamente
sean servidores de una red local (LAN). Por ejemplo asignando un numero a cada uno de
los terminales.
• Sistemas de polling: Estos sistemas controlan las comunicaciones en una red dirigida
por una computadora central, y se organizan de manera que es éste el que les
pregunta secuencialmente a todas las computadoras de la red si tienen algo que
comunicar, y les insta a que lo hagan en caso afirmativo, ningún otro componentes de
la red toma, en ningún momento, la iniciativa de la comunicación.
• Protocolos de transmisión de paquetes: En los protocolos de transmisión de
paquetes la transmisión se apoya en la propia información contenida en los datos que
transitan por las redes de comunicaciones, mientras que en los protocolos anteriores,
la responsabilidad del buen funcionamiento de las comunicaciones recae sobre los
equipos y las líneas de datos. Para ello los datos se fragmentan y organizan en
paquetes, como cartas de correo ordinario, con sus datos de origen y destino y van de
equipo en equipo como las cartas van de estafeta en estafeta, de tren correo a camión
de reparto y de otra estafeta al bolso del cartero quien finalmente la hace llegar a su
destinatario.
Los equipos que conforman las redes se limitan a leer las direcciones contenidas en los
paquetes de datos y a entregar a la siguiente máquina el paquete, quien a su vez la
entregará a otra y así sucesivamente hasta que finalmente llegue al destino.
217
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los protocolos son para realizar tareas específicas, como por ejemplo transferencia de
archivos entre computadoras, enviar correo, etc. Inicialmente TCP/IP fue utilizado comúnmente
entre minicomputadoras y mainframes. Los servicios tradicionales más importantes de TCP/IP
son:
218
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Estos servicios pueden estar presentes en cualquier implementación de TCP/IP. Este sistema
se apoya en un modelo de servicio de redes Cliente/Servidor. Un servidor es un sistema que
provee un servicio específico para el resto de la red. Un cliente es otro sistema que utiliza los
servicios del servidor. A continuación mostramos los servicios típicos en un servidor. Estos
servicios también pueden ser provistos sin la estructura de TCP/IP.
• Sistema de Archivo de Red. Este permite a un sistema acceder archivos sobre otra
computadora (algo más integrada que FTP). El sistema de archivo de red crea la ilusión
que el disco u otro recurso compartido desde un sistema está directamente conectado
a otro sistema. No se necesita usar una utilería especial de red para acceder un archivo
sobre otro sistema. La computadora simplemente piensa que existe un disco extra.
Este disco "virtual" extra hace referencia al disco del otro sistema.
• Impresión remota. Este permite que acceder impresoras en otras computadoras
como si estas estuvieran colocadas en su máquina directamente.
• Ejecución remota. Este permite que haga una solicitud para correr un programa
sobre una computadora diferente. Existe un número de diferente de clases de
ejecución remota. Algunas operan sobre comandos básicos. Existen sistemas de
"llamadas a procedimientos remotos" (remote procedure call - RPC) que permite a un
programa llamar a una subrutina para que corra sobre otro computadora.
• Servidor de Nombres. En redes grandes, existe diferente número de nombres que
tienen que ser administrado. Es tedioso mantener actualizado esta información en
todas las computadoras, por lo que se creó este servicio que utiliza una base de datos
para resolver los nombre de las computadoras a su dirección.
• Servidor de terminal. Un servidor de terminal es simplemente una pequeña
computadora que solo permite correr Telnet. Si la terminal está conectada a uno de
estos servidores, simplemente hay que escribir el nombre de una computadora y se
estará conectado a esta. Por lo general es posible mantener conexiones activas con
más de una computadora al mismo tiempo.
Los anteriores son un simple ejemplo de algunos de los servicios que puede implementarse a
través de TCP/IP.
Sockets⊕
Los sockets no son más que puntos o mecanismos de comunicación entre procesos que
permiten que un proceso hable (emita o reciba información) con otro proceso incluso estando
estos procesos en distintas máquinas (2 programas que se ejecutan a través de una red).
⊕
Obras consultadas: [6.20] [6.22]
219
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
conexión del puerto original.) El servidor también asigna un socket a este puerto local y
comunica con él mediante la lectura y escritura sobre él.
El cliente y el servidor deben ponerse de acuerdo sobre el protocolo -- esto es, debe ponerse
de acuerdo en el lenguaje para transferir la información de vuelta a través del socket.
La comunicación mediante sockets es una interfaz (o servicio) con la capa de transporte (nivel
4) de la jerarquía OSI. La filosofía de la división por capas de un sistema es encapsular, dentro
de cada una de ellas, detalles que conciernen sólo a cada capa, y presentársela al usuario de
tal forma que este pueda trabajar con ella sin necesidad de conocer sus detalles de
implementación. La interfaz de acceso a la capa de transporte del sistema UNIX de Berkeley no
está totalmente aislada de las capas inferiores, por lo que a la hora de trabajar con sockets, es
necesario conocer algunos detalles sobre esas capas. En concreto, a la hora de establecer una
conexión mediante sockets, es necesario conocer la familia o dominio de la conexión, y el tipo
de conexión.
Cada tipo de socket va a definir una serie de propiedades en función de las comunicaciones en
las cuales está implicado:
a. La fiabilidad de la transmisión. Ningún dato transmitido se pierde.
b. La conservación del orden de los datos. Los datos llegan en el orden en el que han sido
emitidos.
c. La no duplicación de datos. Sólo llega a destino un ejemplar de cada dato emitido.
d. La comunicación en modo conectado. Se establece una conexión entre dos puntos antes
del principio de la comunicación (es decir, se establece un circuito virtual). A partir de
entonces, una emisión desde un extremo está implícitamente destinada al otro extremo
conectado.
e. La conservación de los límites de los mensajes. Los límites de los mensajes emitidos se
pueden encontrar en el destino.
f. El envío de mensajes (urgentes). Corresponde a la posibilidad de enviar datos fuera del
flujo normal, y por consecuencia accesibles inmediatamente (datos fuera de flujo).
Cabe resaltar que un cauce de comunicación normal tiene las cuatro primeras propiedades,
pero no las dos últimas.
220
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
red telefónica conmutada para establecer una conexión entre dos teléfonos). Una vez
establecida la conexión, se puede proceder al envío secuencial de los datos, ya que
la conexión es permanente. Son streams de bytes full-dúplex (similar a pipes). Un
socket stream debe estar en estado conectado antes de que se envíe o reciba en él.
• SOCK_DGRAM: Corresponde a los sockets destinados a la comunicación en modo no
conectado para el envío de datagramas de tamaño limitado. Las comunicaciones
correspondientes tienen la propiedad e. En el dominio Internet, el protocolo
subyacente es el UDP. Los datagramas no trabajan con conexiones permanentes. La
transmisión por los datagramas es a nivel de paquetes, donde cada paquete puede
seguir una ruta distinta, no garantizándose una recepción secuencial de la
información.
• SOCK_RAW: Permite el acceso a los protocolos de más bajo nivel (por ejemplo, el
protocolo IP en el dominio Internet). Su uso está reservado al superusuario.
• SOCK_SEQPACKET: Corresponde a las comunicaciones que poseen las propiedades
a, b, c, d y e. Estas comunicaciones se encuentran en el dominio XNS.
Ambos modelos definen las características que debe poseer un sistema de red, distribuyendo
todos los componentes de la misma en capas interrelacionadas y perfectamente definidas. Se
contemplan desde los programas que maneja el usuario, hasta el cableado que une los
adaptadores y elementos de la red.
7. Aplicación
6. Proveedores de red
5. Administradores IFS
4. Redirector red Microsoft/compatible NetWare
3. Protocolo de transporte
2. NDIS.YXD
1. Controlador de la tarjeta de red. NIC (tarjeta de red)
221
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Con el fin de permitir que sobre una tarjeta se pudiese montar más de un protocolo surgieron
dos especificaciones:
• ODI: Open Device Interface de Novell.
• NEDIS: Network Device Interface Specification de Microsoft.
En Windows 9x, tanto la tarjeta de red como cada uno de los protocolos que se montan sobre
ella deben de admitir la especificación NEDIS. Así, entre los controladores que acompañan a las
tarjetas en los discos, se incluyen los que soportan tanto NEDIS como ODI.
Los adaptadores NEDIS 3.1, se gestionan a través de un controlador que se divide en dos
partes. La primera es un mini-controlador que realiza detalles como el establecimiento de
comunicaciones con el adaptador, el apagado o encendido del aislamiento eléctrico para
dispositivo P&P y la activación de cualquier propiedad añadida que tenga el adaptador. La
segunda es una envoltura que implementa las funciones NDIS.
222
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Conexiones lógicas de red; Las conexiones lógicas de red, también llamadas WinSockets,
están diseñadas basadas en las API (Aplication Program Interface) de conexión lógica de
red U.C.Berkeley, el estándar de facto para acceder a servicios de datagrama y sesión
sobre TCP/IP.
• Llamadas a procedimientos remotos (RPC: Remote Procedure Call). El componente RPC de
Microsoft es compatible con la especificación de intercambio de comunicación de datos DCE
de Open Software Foundation (OSF) para llamadas a procedimientos remotos, y por tanto
funciona con sistemas compatibles DCE, como sistemas HP y AIX. RPC emplea mecanismos
tales como canales identificativos NetBIOS o conexiones lógicas de red para establecer
comunicaciones entre el cliente y el servidor. Con el componente RPC la lógica de
programación básica y el código relacionado pueden funcionar en diferentes computadoras,
lo que es muy importante para aplicaciones distribuidas.
• NetBIOS. El sistema básico de entrada y salida de red (NetBIOS) es el conjunto de
funciones de bajo nivel que dan soporte a todos los servicios de la red Windows. NetBIOS
puede ser usado para comunicación entre protocolos y el software de alto nivel como el
reexpedidor y el servicio de servidor. Proporciona compatibilidad hacia abajo para
aplicaciones desarrolladas para versiones anteriores de Windows.
• Canales identificativos
• Buzones.
6.4 Comentarios
223
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Con estos elementos, en los siguientes capítulos se discute el diseño de sistemas operativos para
después hacer una categorización y descripción de las principales arquitecturas existentes. Por
ello, es importante el referente de los capítulos 4, 5 y 6 para que el lector sepa con que bloques
funcionales puede contar.
224
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[6.1] Sistemas operativos: una visión aplicada. Félix [6.13] Linux Device Drivers Demystified. James
García Carballeira, et. al. 1999 Andrews
http://laurel.datsi.fi.upm.es/~ssoo/DSO/ http://www.linuxplanet.com/linuxplanet/tutorials/
[6.4] Plan 9: Feature Film to Feature-Rich OS. Paul [6.16] Sistemas operativos para redes punto a punto
Fillinich. March, 1996.
http://www.geocities.com/SiliconValley/8195/nospp.ht
http://www.byte.com/art/9603/sec14/sec14.htm ml
[6.5] EL UNIVERSO DIGITAL DEL IBM PC, AT Y PS/2 [6.17] Sistemas Operativos de Red y Distribuidos
Ciriaco García de Celis. Edición 4.0 http://www.lafacu.com/apuntes/informatica/Sistemas_
http://udigital.homepage.com/libro/index.html Operativos_en_Red_y_Distribuidos/default.htm
[6.9] Historia de Sistemas Operativos para Red y [6.21] The Box: A Replacement for Files
Porque es más fácil y económico configurar Unix que
Francisco J. Ballesteros
Windows en Red ?
http://plan9.escet.urjc.es/who/nemo/export/2kblocks/in
http://www.osmosislatina.com/diversos/mas_facil.htm
dex.html
225
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
226
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 7.
Diseño de sistemas operativos
-¿Cual es su código de entrada en computadora doctora Rash?- pregunto Calvin-. O márcalo tú misma, si
esto te tranquiliza. Quiero inspeccionar el diseño del cerebro positrónico.(...)
Linda se asombró. Era imposible analizar un diseño sin la ayuda, por lo menos de una computadora de
mano. No obstante, la vieja simplemente observaba.¿Tendría acaso una computadora implantada en su
cráneo? ¿o era que su cerebro durante décadas no había hecho otra cosa que inventar, estudiar y analizar
los diseños de cerebros positrónicos? ¿Captaba los diseños como Mozart captaba la notación de una
sinfonía?
-¿Qué es lo que has hecho Rash?- dijo Calvin por fin.
Linda, algo avergonzada contestó:
-He utilizado la geometría fractal.
-Ya me he dado cuenta, pero, ¿por qué?
-Nunca se había hecho. Pensé que a lo mejor produciría un diseño cerebral con complejidad añadida,
posiblemente más cercano al cerebro humano.
-¿Consultaste a alguien? ¿Lo hiciste todo por tu cuenta?
-No consulte a nadie. Lo hice sola. Los ojos ya apagados de la doctora miraron fijamente a la joven. -No
tenías derecho a hacerlo. Tu nombre es Rash; tu naturaleza hace juego con tu nombre.¿Quién eres tu para
obrar sin consultar? Yo misma, yo, Susan Calvin, lo hubiera discutido antes.
-Temí que se me impidiera.
-Por supuesto que se te habría impedido.
Después de haber expuesto todos los fundamentos teóricos, analizar los principales servicios y
componentes de los sistemas operativos, y contar con el antecedente del uso de la simulación
para el diseño de este tipo de sistemas, llegó la hora de integrar todo este conocimiento.
Todo aquel que ha tomado un curso de sistemas operativos o ha comprado un libro sobre el
tema, siempre ha deseado saber cómo se construye uno (lo cual por lo general no es un tema
trivial).
En el primer caso, no se ha tenido una buena razón para codificar un sistema operativo (en lo
laboral, lo más que el autor ha aplicado y desarrollado son compiladores). En el segundo caso,
siendo realistas, es una tarea que implicaría otro trabajo por sí mismo. Además, después de
reflexionar, se llegó a la conclusión de que inventar el hilo negro no tiene mucho sentido, por lo
que se prefirió investigar si existía alguna forma de abordar el desarrollo de SOs sin que implicará
replantear algo que grupos de trabajo fuertes en ingeniería de software ya han hecho.
227
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Hablar de un proyecto para el desarrollo de un sistema operativo puede ser muy basto. Hablar
de todo el proceso de desarrollo y los detalles que un sistema, o varios deben tomar en cuenta,
es complejo y hay poca documentación al respecto.
Sin embargo la etapa crítica es la elaboración del sistema, cuyo propósito es analizar el dominio
del problema, establecer una arquitectura, desarrollar un plan para el proyecto y eliminar los
mayores elementos de riesgo del proyecto. En específico, se decidió acotar la exposición de este
capítulo a ¿cómo definir la arquitectura de un sistema operativo?
Después de investigar algunas referencias, se encontró un enfoque que está cobrando fuerza
en el proceso de desarrollo de sistemas, llamado arquitectura de software, el cual está orientado
al planteamiento de arquitecturas conceptuales. Este parece un enfoque realista de alto nivel que
no entra al detalle de resultados de aplicar completamente una metodología para desarrollo de
sistemas.
La idea no es crear la mini-especificación de un sistema, pues esto solo serviría como un caso
de estudio particular. Por el contrario, la idea es establecer los lineamiento generales para poder
enfocar los esfuerzos de desarrollo de manera óptima, y aprovechando el conocimiento expuesto
hasta el momento, por lo que se expondrán consideraciones de diseño de alto nivel, relacionadas
con la definición de una arquitectura de software.
Además este enfoque permitirá incluir algunos consejos y lineamientos de los doctos en la
cuestión de diseñar este tipo de sistemas (aficionados y académicos), lo que resulta más
ilustrativo al dejar constancia de todo lo que a alguien se le puede ocurrir o pensar para llegar a
concretar un prototipo de este tipo de sistemas.
Todo sistema de cómputo, es una combinación de hardware y software, y este último es vital
para su funcionamiento. El software de computadoras actúa como la base de control de la
computadora, la comunicación de información y la creación y control de otros programas. El
software es la parte lógica con que trabaja una computadora: programas de sistemas,
aplicaciones y utilerías.
228
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Es un hecho que no todas las computadoras tienen SOs. La computadora que controla un horno
microondas, o una lavadora, no necesita un SO. Este tipo de dispositivos tienen un conjunto
relativamente simple de tareas a realizar, como métodos simples de entrada y salida (un teclado
y una pantalla LCD) y el hardware a controlar (que nunca cambia). Para una computadora como
estas, un SO no es necesario (puede ser implementado por una máquina de estados sencilla) y
sería hasta exagerado (aunque hay que aclarar que ya hay proyectos donde los refrigeradores se
conectán al Internet y hacen las compras, y el concepto de casas inteligentes y cómputo ubicuo
si pueden llegar a necesitar SOs en diferentes dispositivos). En su lugar, la computadora del
microondas ejecuta un solo programa todo el tiempo.
⊕
Obras consultadas: [7.9] [7.10]
229
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Así que primero hay que establecer la complejidad del sistema para el cual se quiere desarrollar
el SO, para determinar el esfuerzo y los costos del desarrollo.
Debe tomarse en cuenta que en los últimos años se ha planteado el paradigma de los sistemas
ubicuos, es decir muchas computadoras trabajando en conjunto, pero sin que el usuario lo note.
Esto hace que no solo nos preguntemos si el dispositivo requiere de un SO, sino si el dispositivo
formará parte (ahora o en un futuro) de este tipo de sistemas de cómputo.
El desarrollo de sistemas de software complejos no es una actividad trivial que pueda abordarse
sin una preparación previa. El considerar que un proyecto de desarrollo de software podía
abordarse como cualquier otro, ha llevado a una serie de problemas que limitan nuestra
capacidad de aprovechar los recursos que el hardware pone a nuestra disposición.
230
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La gestión de un proceso engloba, por tanto, todas las funciones que mantengan a un proyecto
dentro de unos objetivos de coste, calidad y duración previamente estimados. La mayoría de
estas funciones y técnicas de gestión y control empleadas, se han importado de otras industrias
de producción que desarrollaron estos métodos a principios de siglo.
No existe una fórmula mágica para solucionar estos problemas, pero combinando métodos
aplicables a cada una de las fases del desarrollo de software, construyendo herramientas para
automatizar estos métodos, utilizando técnicas para garantizar la calidad de los productos
desarrollados y coordinando todas las personas involucradas en el desarrollo de un proyecto,
podremos avanzar mucho en la solución de estos problemas. De ello se encarga la disciplina
llamada Ingeniería del Software.
La ingeniería del software abarca un conjunto de tres elementos clave: métodos, herramientas y
procedimientos, que faciliten al gestor el control el proceso de desarrollo y suministren a los
desarrolladores bases para construir de forma productiva software de alta calidad.
231
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Los métodos indican cómo construir técnicamente el software, y abarcan una amplia serie
de tareas que incluyen la planificación y estimación de proyectos, el análisis de requisitos, el
diseño de estructuras de datos, programas y procedimientos, la codificación, las pruebas y el
mantenimiento. Los métodos introducen frecuentemente una notación específica para la
tarea en cuestión y una serie de criterios de calidad.
• Las herramientas proporcionan un soporte automático o semiautomático para utilizar los
métodos. Existen herramientas automatizadas para cada una de las fases vistas
anteriormente, y sistemas que integran las herramientas de cada fase de forma que sirven
para todo el proceso de desarrollo. Estas herramientas se denominan CASE (Computer
Assisted Software Engineering).
• Los procedimientos definen la secuencia en que se aplican los métodos, los documentos
que se requieren, los controles que permiten asegurar la calidad y las directrices que
permiten a los gestores evaluar los progresos.
232
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Aunque los pasos concretos dependen del modelo de ciclo de vida utilizado, en general se
realizarán tres tareas específicas:
1. Análisis del sistema. Como ya hemos visto, el análisis del sistema define el papel de cada
elemento de un sistema informático, estableciendo cuál es el papel del software dentro de ese
sistema.
2. Análisis de requisitos del software. El análisis del sistema proporciona el ámbito del software,
su relación con el resto de componentes del sistema, pero antes de empezar a desarrollar es
necesario hacer una definición más detallada de la función del software.
Existen dos formas de realizar el análisis y refinamiento de los requisitos del software. Por una
parte, se puede hacer un análisis formal del ámbito de la información para establecer modelos
del flujo y la estructura de la información. Luego se amplían unos modelos para convertirlos en
una especificación del software. La otra alternativa consiste en construir un prototipo del
software, que será evaluado por el cliente para intentar consolidar los requisitos. Los requisitos
de rendimiento y las limitaciones de recursos se traducen en directivas para la fase de diseño.
El análisis y definición de los requisitos es una tarea que debe llevarse a cabo conjuntamente
por el desarrollador de software y por el cliente. La especificación de requisitos del software es
el documento que se produce como resultado de esta etapa.
233
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
3. Planificación del proyecto software. Durante esta etapa se lleva a cabo el análisis de riesgos,
se definen los recursos necesarios para desarrollar el software y se establecen las estimaciones
de tiempo y costes. El propósito de esta etapa de planificación es proporcionar una indicación
preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se hayan
establecido. Posteriormente, la gestión del proyecto durante el desarrollo del mismo realiza y
revisa el plan de proyecto de software.
Aunque, al igual que antes, los pasos concretos dependen del modelo de ciclo de vida
utilizado, en general se realizarán cuatro tareas específicas:
Una vez codificados los programas debe revisarse su estilo y claridad, y se comprueba que
haya una correspondencia con la estructura de los mismos definida en la fase de diseño. El
listado fuente de cada módulo (o el programa fuente en soporte magnético) pasa a formar
parte de la configuración del sistema.
3. Pruebas. Una vez que tenemos implementado el software es preciso probarlo, para
detectar errores de codificación, de diseño o de especificación. Las pruebas son necesarias para
encontrar el mayor número posible de errores antes de entregar el programa al cliente. Es
necesario probar cada uno de los componentes por separado (cada uno de los módulos o
programas) para comprobar el rendimiento funcional de cada una de estas unidades.
A continuación se procede a integrar los componentes para probar toda la arquitectura del
software, y probar su funcionamiento y las interfaces. En este punto hay que comprobar si se
cumplen todos los requisitos de la especificación.
234
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
3.1 Garantía de calidad. Una vez terminada la fase de pruebas, el software está casi preparado
para ser entregado al cliente.
La fase de mantenimiento vuelve a aplicar los pasos de las fases de definición y de desarrollo,
pero en el contexto de un software ya existente y en funcionamiento.
El proceso de diseño
El diseño es el proceso de aplicar varias técnicas y principios con el propósito de definir un
dispositivo, un proceso o un sistema con suficiente detalle como para permitir su realización
física. Los conceptos del diseño proporcionan criterios básicos para su calidad, es decir
proporcionan la estructura básica necesaria para hacerlo bien.
La importancia del diseño del software se puede definir en una sola palabra: Calidad. Dentro
del diseño es donde se fomenta la calidad del Proyecto. El diseño es la única manera de
materializar con precisión los requerimientos del cliente.
235
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos
para un buen diseño como son:
• Un diseño debe presentar una organización jerárquica que haga un uso inteligente del
control entre los componentes del software.
• El diseño debe ser modular, es decir, se debe hacer una partición lógica del software
en elementos que realicen funciones y subfunciones especificas.
• Un diseño debe contener abstracciones de datos y procedimientos.
• Debe producir módulos que presenten características de funcionamiento
independiente.
• Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los
módulos y el entorno exterior.
• Debe producir un diseño usando un método que pudiera repetirse según la información
obtenida durante el análisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de diseño del software exige buena
calidad a través de la aplicación de principios fundamentales de diseño, metodología
sistemática y una revisión exhaustiva.
236
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La arquitectura de software es un nivel de diseño que va más allá de los algoritmos y las
estructuras de datos: el diseño y la especificación de la estructura del sistema como un todo
emerge como un nuevo problema. Los elementos estructurales incluyen la organización y el
control global, los protocolos de comunicación, la distribución física, la composición de elementos
de diseño, la escalabilidad y el rendimiento, y la elección entre distintas alternativas de diseño.
237
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La arquitectura de software debe distinguirse del diseño de bajo nivel (p.ej. el diseño de los
algoritmos y partes internas de los componentes) y la implementación.
238
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Una arquitectura ayuda a los usuarios a razonar y administrar el cambio (cerca del 80% del
esfuerzo en sistemas ocurre después de implantarlos). La arquitectura divide el cambio en tres
clases:
• local: modificar un solo componente
• no-local: modificar varios componentes
• arquitectónico: modificar el grueso de la topología, comunicaciones y mecanismos de
coordinación del sistema.
239
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 7.4 La definición de la arquitectura está entre el análisis del sistema y su diseño.
Además una arquitectura bien documentada ayuda no solo al diseñar, sino durante todo el ciclo
de vida del sistema. Para satisfacer sus objetivos, una descripción de la arquitectura debe ser lo
suficientemente simple para permitir el razonamiento y predicción a nivel del sistema. En la
práctica, esto limita las descripciones de la arquitectura a un nivel de detalle que puede abarcar
una o dos páginas. Por lo tanto, para representar diseños de arquitecturas, las descripciones son
por lo general jerárquicas: los elementos atómicos de la arquitectura en un nivel de abstracción
son descritos con una arquitectura más detallada a bajo nivel.
240
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
241
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las propiedades de los componentes son asunciones que un componente puede hacer de otro.
Estas propiedades incluyen:
• Servicios provistos (funcionalidad)
• Servicios requeridos
• Características de desempeño
• Manejo de errores
• Uso de recursos compartidos
Las relaciones son más genéricas que los conectores. Las relaciones pueden ser:
• Dinámicas o a tiempo de ejecución (conectores)
• enviar dato(s) a; invocar; señales
• Estáticas
• es un submódulo de; encapsula información; hereda de
• Vistas (estructuras)
Una arquitectura de software debe ser descrita por diversas vistas (relacionadas), también
llamadas estructuras.
242
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
243
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Lo más importante de las estructuras es elegir cuales pueden ser útiles para describir mejor
los detalles del sistema.
Los componentes, sus relaciones y estructuras, conforman una vista que se usa para
especificar el sistema, resaltar diversas cualidades del sistema y puede ser usada por varias
personas.
⊕
Obras consultadas: [7.57]
244
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
objetos, deben mapearse en los diversos nodos. Muchas configuraciones físicas serán
usadas en el desarrollo, prueba e implantación.
4. Vista de desarrollo. Se enfoca a la organización de los módulos de software en el
ambiente de desarrollo. El software es empacado en librerías o subsistemas que pueden
ser desarrollados por uno o más desarrolladores. Los subsistemas son organizados en
capas jerárquicas, y cada una provee una interfaz bien definida con las capas superiores.
5. Vista de escenarios. Consiste de un subconjunto de escenarios importantes de casos de
uso, para mostrar que los elementos de las 4 vistas trabajan conjuntamente. Para cada
escenario se describe el correspondiente guión (secuencias de interacciones entre objetos y
entre procesos). Esta vista es redundante, pero tiene dos roles importantes:
• actúa como manejador para ayudar a los diseñadores a descubrir elementos
arquitectónicos durante el diseño de la arquitectura;
• valida e ilustra el diseño de la arquitectura, y es el punto de inicio para las pruebas
de un prototipo arquitectónico.
Las capas, como todas las estructuras arquitectónicas, reflejan una división del software en
unidades. En este caso, las unidades son capas; cada capa representa una máquina virtual.
Una máquina virtual es una colección de software que en conjunto provee un servicio que otro
software puede utilizar sin conocimiento de como esos servicios están implementados.
Las capas tienen una propiedad fundamental: las máquinas virtuales son creadas para
interactuar entre si de acuerdo a una relación estricta de orden. Si (A,B) está en esta relación,
se dice que la capa B está bajo la capa A, lo que puede significar:
1. La capa de implementación A está autorizada para usar cualquier facilidad pública de la
máquina virtual provista por la capa B.
2. Las facilidades públicas en la capa B pueden ser usadas por el software de la capa A.
Lo que puede interpretarse como que la capa A está autorizada para usar la capa B:
245
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Estilos arquitectónicos
Como en cualquier actividad de diseño, una pregunta central es cómo aprovechar la
experiencia del pasado para producir mejores diseños. En la práctica actual, la codificación y
reuso de diseños arquitectónicos ha ocurrido principalmente por medio de la transmisión
informal de idiomas arquitectónicos. Por ejemplo, un sistema puede ser definido
arquitectónicamente como un "sistema cliente-servidor", un "sistema de pizarrón", una
"tubería" (pipeline), un "interprete" o un "sistema de capas". Mientras estas caracterizaciones
no siempre cuentan con definiciones formales, si nos dan mucha idea sobre la estructura y el
modelo computacional del sistema. Una clase importante de idiomas arquitectónicos son los
llamados estilos arquitectónicos.
Un estilo arquitectónico caracteriza a una familia de sistemas que se relacionan por compartir
propiedades estructurales y semánticas. Específicamente, los estilos proveen 4 cosas:
1. Un vocabulario de elementos de diseño – componentes y tipos de conectores como
tuberías (pipes), filtros, clientes, servidores, parsers, bases de datos, etc.
2. Reglas de diseño – o restricciones – que determinan la composición permitida de los
elementos. Por ejemplo, las reglas deben prohibir ciclos en un estilo particular de filtro-
tubería, especificando que una organización cliente-servidor debe ser una relación de N a
1, o definir un patrón de composición específico.
3. Interpretación semántica, donde composiciones de elementos de diseño, se
restringen por reglas de diseño con significados bien definidos.
246
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
4. Análisis que pueden realizarse en sistemas construidos con dicho estilo. Algunos
ejemplos incluyen el análisis de planificación para estilos orientados al procesamiento en
tiempo real y detección de bloqueos para el paso de mensajes cliente-servidor. Un caso
especial de análisis es la generación de sistemas: muchos estilos soportan generadores
de aplicaciones (p.ej. generadores de parsers), o llevan al reuso de ciertas
implementaciones de base compartidas (p.ej. frameworks de interfaces de usuario o
soporte para comunicaciones entre procesos distribuidos).
247
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Sin embargo no hay una definición universalmente aceptada, aunque los patrones tienen 4
elementos fundamentales:
1. Un nombre. Nombrar un patrón incrementa nuestro vocabulario de diseño y facilita el
diseño a niveles altos de abstracción. También hace más fácil comunicar diseños a otros.
2. Un problema. Una explicación del problema y su contexto. Para que la solución de un
problema de nacimiento a un patrón, el problema (y su contexto) deben plasmarse en
más de un esfuerzo de diseño.
3. Una solución. El patrón provee una descripción abstracta de un problema de diseño y
cómo un arreglo general de elementos (clases y objetos) lo solucionan.
4. Consecuencias. Una discusión de los resultados y por menores de aplicar el patrón.
⊕
Obras consultadas: [7.59] [7.60] [7.61]
248
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Sistemas distribuidos
• Broker, tuberías y filtros, microkernel
• Sistemas interactivos
• Modelo-Vista-Controlador (Model-View-Controller), Presentación-Abstracción-
Control (Presentation-Abstraction-Control)
• Sistemas adaptables
• Reflexión, Microkernel
El patrón Layers⊕
El patrón Layers (capas) estructura el sistema en grupos de subtareas que trabajan en un
nivel particular de abstracción.
Beneficios:
• Reuso de capas
• Soporta la estandarización
• Las dependencias se mantienen locales
• Intercambio
Ejemplos:
• OSI
• Conjunto de protocolos de Internet
En el mundo real por lo general se usa una mezcla de criterios de abstracción para agrupar
tareas en capas. Por ejemplo, la distancia del hardware puede darle forma a los niveles más
bajos, y complejidad conceptual a los más altos. Un ejemplo de capas es el siguiente:
• Elementos visibles al usuario
• Módulos específicos de aplicación
• Nivel de servicios común
• Nivel de interfaz del sistema operativo
• Sistema operativo (siendo un sistema en capas en sí mismo, o estructurado de acuerdo
al patrón microkernel)
• Hardware
El patrón Microkernel
El patrón Microkernel aplica a los sistemas de software que deben ser capaces de adaptarse
a requerimientos del sistema variables. Separa un núcleo mínimo de funcionalidad de la
funcionalidad extendida y partes específicas del consumidor. El microkernel también sirve como
un enchufe para conectar estas extensiones y coordinar su colaboración.
⊕
Obras consultadas: [7.62]
249
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Mi cr o ke r n el
Exte rnal Server
Internal Serve r
+calls +a ctiva tes
in itC om m u nicatio n()
rece ive R equ es t()
fin dR ec eiver() 1..* r eceiveR eq u e s t()
dis p atchR e que s t() 1..* 1 1
e xe cuteMe chan is m () execu teService()
execute Se rvic e()
ca llInternalServe r()
1
33
Imagen reproducida de [7.59]
250
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El patrón Broker
El patrón Broker puede usarse para estructurar sistemas de software distribuidos con
componentes desacoplados que interactúan mediante invocaciones a servicios remotos. Un
componente del broker es responsable de coordinar la comunicación, así como de transmitir
resultados y excepciones.
Un broker coordina la comunicación entre los sistemas de software distribuido para permitir el
uso remoto de servicios.
Beneficios:
• Transparencia en la localización
• Independencia del sistema
• Interoperabilidad y portabilidad
• Modificabilidad y reusabilidad
• Configuración a tiempo de ejecución
Ejemplos:
• CORBA (Common Object Request Broker Architecture) [OMG]
• OLE / ActiveX [Microsoft]
• SOM/DSOM [IBM]
• WWW
Las siguientes actividades han sido reconocidas como parte del proceso de diseño basado en la
arquitectura:
• crear los casos de negocio para el sistema
• comprender los requerimientos
• crear o seleccionar la arquitectura
251
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Este escenario es difícil y poco productivo. El diseño se termina en los descansos durante la
codificación y está delimitado por cosas ya implementadas y que funcionan. Los programadores
tienden a pensar "lo cambio después", y esto casi nunca pasa. Nadie quiere modificar el código
de la aplicación para ajustarlo al diseño.
Implementar un SO es difícil, porque un diseño incompleto puede consumir más recursos; sin
embargo, sin un diseño es difícil orientar un proyecto de esta naturaleza, y su control de vuelve
extremadamente complejo.
252
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
253
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Hay 2 razones por las que la abstracción del hardware es importante: simplicidad y
compatibilidad. La idea es que el sistema operativo provea una interfaz simple a la aplicación y
haga el trabajo rudo. Con respecto a la compatibilidad, muchos SOs de propósito general
permiten el uso de una gran variedad de hardware, y aunque sería deseable que los dispositivos
similares hablaran en un mismo idioma, esto no siempre es cierto. Alguna parte del sistema
necesita saber que tipo de dispositivo se tiene y como hablar con dicho dispositivo.
Es parte del proceso de abstracción tratar de encontrar una abstracción que sea relativamente
simple, y aun así expresar un monto razonable de flexibilidad en el hardware que pueda
abstraerse y el uso del hardware. La abstracción necesita formas de lidiar con las fallas si el
dispositivo debe ser tolerante a fallas. Todas estas metas pueden hacer de la abstracción una
tarea muy difícil que puede realizarse de muchas maneras.
2. Administración de recursos. Los sistemas operativos administran los recursos del sistema
de cómputo. Esta es una gran preocupación con la multitarea y en algunos casos sistemas
multiusuario. Un "recurso" es un término genérico para referirse a cualquier componente del
sistema capaz de hacer un trabajo. Por ejemplo, el procesador, la RAM, los discos, las tarjetas de
sonido o de red, son recursos. No todos los recursos son hardware. La administración de
recursos es el proceso de asignar recursos a las aplicaciones para su uso. Esto se hace de
diversas formas, pero las principales son:
• Multiplexado. Consiste en compartir un recurso mediante accesos concurrentes. Esta es una
preocupación central en los SO multitarea. Muchos recursos pueden ser multiplexados por
diferentes aplicaciones.
• Bloqueo. Algunos dispositivos pueden no ser multiplexados (por ejemplo una cinta de
respaldo), pero ello implica asegurar que para evitar errores solo una aplicación a la vez
pueda acceder al dispositivo en cierto momento.
• Control de acceso. A veces la administración de recursos no se involucra en solucionar el
problema de que varios procesos accedan al hardware; en cambio si le incumbe proteger a
los procesos entre sí. La seguridad se implementa de alguna forma como parte de la
administración de recursos.
• Máquinas virtuales: Combinando la administración de recursos con la abstracción.
Administrar el acceso a los recursos demanda que alguna interfaz sea provista para el
recurso, así que en lugar de accesar al hardware directamente una aplicación debe pedirle al
SO que acceda al hardware. El resultado de esto es un concepto llamado máquina virtual. A
254
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
3. Interfaz de usuario. Una meta importante de un sistema operativo es proveer algún tipo de
interfaz a los usuarios para controlar el sistema y ejecutar aplicaciones. Esto lleva al SO lejos de
las discusiones puramente técnicas, a cuestiones relacionadas con la interacción del sistema con
el usuario.
4. Metas especializadas de diseño. Algo que hay que señalar es que un sistema operativo no
lo puede hacer todo. Muchos SO son construidos para propósitos específicos. Algunos casos son:
• Sistemas incrustados (embedded). Los SO incrustados son escritos para ambientes donde los
recursos son muy limitados, para realizar una tarea específica para un dispositivo específico.
Por ejemplo, el SO que ejecuta el software de un teléfono celular es uno de estos sistemas,
los cuales deben ser muy pequeños por que sus ambientes pueden tener solo unos cuantos
kilobytes de memoria disponible.
• Sistemas de tiempo real. Diseñados para ejecutar tareas criticas de tiempo real, donde se
garantice que cada tarea cumplirá su labor en un tiempo límite.
• Sistemas distribuidos. Estos sistemas se ejecutan en varias máquinas a la vez, y distribuyen
tareas entre los nodos. Esta es la forma en que una red se comporta como un solo SO.
• Sistemas tolerantes a fallas. La respuesta típica a una falla del procesadores un SO que se
estropea y arrastra al usuario con él. Sin embargo, hay sistemas que necesitan estar
trabajando sin importar lo que pase. Estos sistemas están diseñados para recuperarse de un
problema de hardware y seguir ejecutándose. Estos SOs se escriben con el fin de ocultar a
las aplicaciones las fallas de hardware.
Estructura de capas. Este es un enfoque usado en sistemas como el THE, UNIX y Windows
2000. Sin embargo este es más una forma de describir el sistema. Para un sistema nuevo, los
diseñadores que tomen este camino deben ser cuidadosos al elegir las capas y definir la
funcionalidad de cada una. La capa del fondo siempre debe tratar de ocultar los detalles más
rudos del hardware (como el HAL-Hardware Abstraction Layer). Tal vez la siguiente capa deba
encargarse de las interrupciones, cambios de contexto, y la MMU, para que en los niveles
superiores el código sea lo más independiente de la máquina. En los niveles superiores, los
diseñadores tienen diferentes tendencias. Una posibilidad es que la capa 3 administre los hilos,
incluyendo la planificación y sincronización.
⊕
Obras consultadas: [7.23]
255
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Arriba de la capa 4, se puede esperar encontrar la memoria virtual, uno o más sistemas de
archivos y los manejadores de llamadas del sistema.
Exokernels. Los exokernels toman un enfoque interesante, al tomar gran parte del código fuera
del kernel, pero en lugar de colocar el código en programas externos como lo hace el
microkernel, lo colocan en librerías compartidas ligadas al código de la aplicación. La aplicación
entonces hace peticiones a recursos protegidos solo llamando a las funciones en la librería.
Esencialmente el exokernel dejará cualquier código crítico para la seguridad en el kernel, pero las
abstracciones se colocan en las librerías.
Sistemas extensibles. Este enfoque consiste en poner más módulos en el kernel, de una forma
protegida. Un sistema extensible por sí mismo no es una forma de estructurar un SO. Sin
embargo, al comenzar con un sistema mínimo consistente de un poco más que un mecanismo de
protección y después agregar módulos protegidos al kernel, uno a la vez, hasta alcanzar la
funcionalidad deseada, un sistema mínimo puede construirse para la aplicación deseada. Con
este enfoque un nuevo sistema operativo puede ajustarse a cada aplicación al incluir solo las
partes que se requieran (Paramecium es un ejemplo de este tipo de sistemas).
34
Imagen reproducida de [7.23]
256
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En el siguiente capítulo se hace una investigación más detallada de las estructuras que los SOs
adoptan.
⊕
Obras consultadas: [7.1] [7.2] [7.3] [7.4]
257
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
nuevas aplicaciones que aprovechen esta infraestructura. Así que ¿cómo hacer que el SO de a los
usuarios la ilusión de contar con recursos infinitos: memoria, CPUs, cómputo distribuido, etc.?
En el camino habrá que tomar decisiones importantes, pues es un hecho que no puede tenerse
todo (no hay sistema que implemente lo mejor de toda la teoría). Por ello el diseño deberá
sacrificar en su momento:
• el rendimiento y la conveniencia de las abstracciones del SO
• el rendimiento y la sencillez del diseño del SO
• añadir funcionalidad en el hardware o el software
El requisito indispensable para un proyecto de este tipo (y para cualquier proyecto de SO) es
conocer bien el hardware, por lo que contar con documentación sobre los diferentes
componentes (procesador, memoria, controlador de dispositivos, dispositivos periféricos, timer,
BIOS, etc.) y sus características es vital.
⊕
Obras consultadas: [7.47] [7.48] [7.49]
258
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
una máquina dedicada para pruebas) o por medio de red (se necesitaría una tarjeta , una red
montada y el sitio de donde se descargaría el SO).
Para el kernel, lo más simple es desplegar un mensaje o implementar algún programa sencillo,
asegurándonos de implementar una manera de salir (bien podríamos generar un ciclo infinito y
reiniciar apagando la computadora, pero hacer que termine por medio de un teclazo, u otro
evento es más interesante).
Algunos de los principales requerimientos técnicos que deben estar documentados son:
así como contar con un ensamblador para generar ejecutables con características muy
particulares, por ejemplo:
• que el código del cargador se guarde en determinado sector del disco y que de ahi cargue el
SO a una dirección determinada de memoria)
• que el tamaño del archivo sea de un tamaño determinado
• que el código generado tenga un determinado modelo de memoria
Para más información, consulte la sección "Cargador del Sistema" y las referencias del capítulo
2, así como el apéndice de "Sectores de arranque". Debe tomarse en cuenta que el cargador no
es necesario implementarlo, pues ya hay varios cargadores que pueden manipular diversos tipos
de ejecutables y sistemas operativos (multiboot) como el GRUB (GRand Unified Bootloader),
OSL, XOSL, Etherboot, NILO, etc., que se encargan de esta tarea; pero lo cierto es que hacerlo
resulta más ilustrativo.
Sin embargo, usar un programa de este tipo tiene sus ventajas; en el caso del GNU GRUB, este
sigue los siguientes requerimientos:
• Cumple con la especificación Multiboot.
• Las funciones básicas son sencillas de usar para el usuario final.
• Funcionalidad para diseñadores/expertos en sistemas operativos.
• Compatibilidad para arrancar FreeBSD, NetBSD, OpenBSD, y GNU/Linux. SOs propietarios
como Win 98, NT y OS/2 se soportan mediante chain-loading function.
y adicionalmente proporciona:
• Soporta múltiples formatos ejecutables.
• Soporta sistemas no-Multiboot.
• Carga múltiples módulos.
• Interfaz de usuario.
• Interfaz de comandos flexible.
• Soporta múltiples tipos de sistemas de archivos.
• Soporta descompresión automática.
259
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Por lo anterior debe quedar claro que SI vale la pena usar este tipo de herramientas (hacer algo
así parece bastante complejo).
Aunque todo esto no suene tan difícil, es bastante complejo y es un buen reto técnico. Como
ejemplos de este tipo de desarrollos tenemos el SO JOSH y un proyecto del SIGOPS para enseñar
como construir un sistema operativo sencillo, pero que a fin de cuentas permita aprender varios
principios básicos de su implementación.
1. Tipo de sistema a implantar. Sistemas de control, robots, PCs. Propósito específico o general.
Usuarios finales.
2. Especificaciones técnicas y herramientas de hardware y software. Dependencia por la
arquitectura del microprocesador (CISC, RISC, microcontroladores) o su disposición (serial,
paralelo). Memoria y periféricos disponibles.
3. Metodología de desarrollo. Metodologías Estructuradas u orientadas a objetos.
4. Distribución de módulos en base al modelo OSI.
5. Protocolos de comunicación.
6. Modelo cliente/servidor.
7. Control de periféricos. Estándares de fabricación.
8. Aprovechamiento de instrucciones nativas del procesador.
9. Portabilidad.
10. Dimensionamiento (rigth sizing). Kernels compactos para cualquier tipo de sistema
(escalabilidad). Versiones para servidores y terminales o dedicados.
• Cargador
• Kernel
• Utilerías mínimas (programas de aplicación)
⊕
Obras consultadas: [7.21]
260
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Tales decisiones requieren de diversas consideraciones tales como el acceso que proveerá el
kernel, el tipo de dispositivos (hardware) con los que se va trabajar, etc.
Estas decisiones son influenciadas por la naturaleza de las funciones que se quieran
proporcionar. Pero una muy clara es la interdependencia. No se debe optar por un diseño
complejo que exija un alto nivel de complejidad en el kernel.
La idea básica es comenzar con una plataforma modesta de funciones y construir un kernel
prototipo funcional, para después ir incrementando lentamente la complejidad de las funciones
para optimizar el kernel.
Algunas de las opciones para implementar un sistema operativo, y en específico un kernel son
las siguientes:
261
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Actualmente los programadores implementan estos objetivos por medio de un gran programa
llamado kernel. Puesto que este programa debe ser accesible a todos los demás programas de
usuario, es el lugar natural para agregar toda la funcionalidad del sistema. Puesto que el único
modelo para la interacción de procesos es el de servicios individuales provistos por el kernel,
nadie crea otros lugares para agregar funcionalidad; así al pasar del tiempo, más y más cosas se
le agregan al kernel (esta práctica es común en los sistemas de kernel monolítico).
Muchas buenas ideas, que pueden hacerse con una interfaz open/read/write no pueden ser
implementadas a causa de los problemas inherentes a la naturaleza monolítica de los sistemas
tradicionales. Incluso aquellos con la determinación de implementar nuevas ideas, solo aquellos
que son usuarios privilegiados de sus computadoras pueden hacerlo. El sistema de copyright de
software además ha obscurecido este campo previniendo a personas sin "licencia" de incluso leer
el código fuente del kernel.
Algunos sistemas han tratado de solucionar estas dificultades. Smalltalk-80 y la máquina Lisp,
representan una forma de darle vuelta al problema. El código del sistema no es distinguible del
código del usuario; todo el sistema es accesible al usuario y puede cambiarse según las
necesidades. Ambos sistemas fueron construidos alrededor de lenguajes que facilitaran el fácil
reemplazo y extensión, y fueron moderadamente exitosos. Pero ambos fueron bastante
deficientes, distanciando a los usuarios y a los programas uno del otro, fallando con uno de los
principales objetivos del diseño de sistemas operativos.
Muchos de los proyectos que usan el kernel Mach 3.0 siguen aplicando el tan difícil de cambiar
diseño de SOs tradicional: la estructura interna es diferente, pero la misma barrera entre el
usuario y el sistema permanece. Sus servidores individuales (single-servers) aunque fáciles de
construir, heredan todas las deficiencias de los kernels monolíticos.
262
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Tipo 0. Tareas estáticas ligadas al kernel cuando este se construye, usando la instrucción CALL
para accesar los servicios del kernel (sin protección)
Ejemplos: Pequeños SOs de tiempo real (p.ej. u-COS)
Ventajas:
• Muy simple
• Llamadas al sistema rápidas y simples (instrucción near CALL) por que las tareas se
ejecutan en el mismo espacio de direcciones y en el mismo nivel de privilegios del CPU
que el kernel
• Alternancia de tareas rápida y simple por que las tareas se ejecutan en el mismo
espacio de direcciones y en el mismo nivel de privilegios del CPU que el kernel
Desventajas:
• La protección no es posible por que las tareas están ligadas al kernel
• No es posible crear nuevas tareas después de que el kernel comienza a ejecutarse
• Todo debe ser vuelto a ligar cuando el kernel o alguna tarea se reconstruye
Tipo 1. Tareas dinámicas son ligadas al kernel cuando la tarea se carga, usando la instrucción
CALL para accesar los servicios del kernel (sin protección)
• Tipo 1a: tareas relocalizables
• Tipo 1b: las tareas usan código independiente de la posición (PIC)
• Tipo 1c: las tareas están en direcciones fijas, y el kernel usa el MMU solo para
traducción de direcciones
Ventajas:
• Pueden crearse nuevas tareas después de que el kernel comienza a ejecutarse
• Llamadas al sistema (syscalls) rápidas y simples por que las tareas se ejecutan en el
mismo espacio de direcciones y en el mismo nivel de privilegios del CPU que el kernel
• Alternancia de tareas rápida y simple por que las tareas se ejecutan en el mismo
espacio de direcciones y en el mismo nivel de privilegios del CPU que el kernel
Desventajas:
• La protección no es posible porque las tareas están ligadas al kernel
• El kernel es más grande y complejo por que debe tener una tabla de símbolos y código
para relocalizar/ligar las tareas
• (tareas relocalizables) Las tareas son más grandes por que deben tener
relocalizaciones externas e internas
263
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• (tareas PIC) Las tareas son más grandes por que deben tener relocalizaciones
externas, y por que PIC consume uno de los registros de propósito general
Tipo 2. Tareas dinámicas NO ligadas al kernel (usan la instrucción INT para accesar los
servicios del kernel); sin protección
• Tipo 2a: tareas relocalizables
• Tipo 2b: las tareas usan PIC
• Tipo 2c: las tareas están en direcciones fijas; el kernel usa la MMU solo para
traducción de direcciones
Ejemplos
• (tipo 2a) DOS. Usa la INT 21h para llamadas al sistema. El formato de archivo
relocalizable es .EXE
• (tipo 2b) OS/9 para el CPU 6809 (Radio Shack Color Computer). Usa SWI para
llamadas al sistema. El 6809 no requiere un registro de propósito general para PIC.
• (tipo 2b) Macintosh basada en el 68000 original. Usas TRAP nn para llamadas al
sistema. El registro A5 es usado para PIC.
Ventajas:
• Pueden crearse nuevas tareas después de que el kernel comienza a ejecutarse
• Alternancia de tareas rápida y simple por que las tareas se ejecutan en el mismo
espacio de direcciones y en el mismo nivel de privilegios del CPU que el kernel
Desventajas:
• No hay protección
• Las llamadas al sistema que usan INT son un poco más lentas que near CALL, y el
código de llamada al sistema agrega complejidad al kernel y las tareas
• (tareas relocalizables) Las tareas son más grandes por que deben tener
relocalizaciones internas
• (tareas PIC) Las tareas son más grandes por que PIC consume uno de los registros de
propósito general
Tipo 3. Tareas dinámicas NO ligadas al kernel (usan la instrucción INT para accesar los
servicios del kernel); con protección
• Tipo 3a: tareas relocalizables, usando la MMU solo para protección
• Tipo 3b: las tareas usan PIC, usando la MMU solo para protección
• Tipo 3c: las tareas están en una dirección fija, usando la MMU para protección y
traducción de direcciones
Ejemplos:
• (tipo 3a) pk/Roadrunner. Usa la INT 30h para llamadas al sistema. El formato de
archivo relocalizable es ELF. La protección de memoria usa paginación.
• (tipo 3c) Linux. Usa la INT 80h para llamadas al sistema. la dirección fija de carga para
ejecutables ELF Linux ELF es 8048000h. La traducción y protección de direcciones usa
paginación.
Ventajas:
• Pueden crearse nuevas tareas después de que el kernel comienza a ejecutarse
• Código defectuoso o malicioso de una tarea no puede dañar al kernel u otras tareas
264
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Desventajas:
• Las llamadas al sistema que usan INT son un poco más lentas que near CALL, y el
código de llamada al sistema agrega complejidad al kernel y las tareas
• (tareas relocalizables) Las tareas son más grandes por que deben tener
relocalizaciones internas
• (tareas PIC) Las tareas son más grandes por que PIC consume uno de los registros de
propósito general
• La protección impone sobrecarga, haciendo las llamadas al sistema y el intercambio de
tareas más lento, y el código de protección agrega complejidad al kernel
• Se requiere soporte de hardware en forma de niveles de privilegio en el CPU y una
MMU
Criterios de planificación⊕
Los algoritmos de planificación deben tener en cuenta una serie de casos:
• Utilización del CPU., queremos que el CPU se mantenga tan ocupado como sea
posible.
• Productividad, una medida del trabajo es el número de procesos que se completa
por unidad de tiempo.
• Tiempo de Retorno, sería la suma de los periodos transcurridos esperando entrar en
la memoria, esperando en la cola de procesos listos, ejecutándose en el CPU y
efectuando operaciones de E/S.
• La cantidad de tiempo, que el proceso espera en la cola de procesos listos.
• El tiempo de respuesta, el tiempo transcurrido desde la presentación de una
solicitud hasta que se produce la primera respuesta.
Las prioridades consisten en asignarle a cada proceso un calificador que determine la atención
que va a recibir del sistema, las prioridades pueden ser asignadas directamente por el Sistema
Operativo (serían las internas) o por el usuario o Administrador (serían las externas). A su vez
dentro de estas prioridades pueden ser:
- Estáticas. Las que no cambian durante la ejecución del proceso. Siempre el proceso va
a tener la misma prioridad. Son fáciles de implementar y sobrecarga menos el sistema (el
procesador no tiene que dedicar tiempo a administrar prioridades).
- Dinámicas. Son las que responden a cambios, al proceso se le da una prioridad inicial
que en principio será de duración corta para después pasar a ajustarse a un mejor valor.
⊕
Referencias: [7.4]
265
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las ventajas son que el código se escribe rápidamente, es más compacto, es más fácil de
entender y revisar, y es fácilmente portable (trasladarse a otro tipo de hardware). Las
desventajas son una menor velocidad y mayor capacidad de almacenamiento. Aunque los SOs
son sistemas grandes, solo parte de su código es crítico para su desempeño (administración de la
memoria, planificador del CPU).
Después de que el sistema esté operando, las rutinas que forman cuellos de botella pueden ser
identificadas, y como posible solución, reemplazadas por código en ensamblador. Para identificar
esos cuellos de botella debe monitorearse el desempeño del sistema, por lo que debe agregarse
código que calcule y despliegue medidas del comportamiento del sistema (algunas veces se
guardan en archivos log para su análisis posterior o puede optarse por el despliegue a tiempo
real).
Aunque es posible diseñar, codificar e implementar un SO para una máquina en un solo sitio, la
práctica más común es que los SOs sean diseñados para funcionar en cualquier clase de
máquina, en una gran variedad de sitios y con una gran variedad de configuraciones de
periféricos. El sistema debe ser entonces configurado o generado para cada computadora. Este
proceso es conocido como SYSGEN (system generation).
Al ser distribuido en disco, se utiliza un programa especial para leer de un archivo o preguntar al
operador la información relacionada a la configuración del sistema de hardware, tal como:
• El tipo de CPU a utilizar, sus opciones, o la descripción de cada CPU en sistemas
multiprocesador.
• La cantidad de memoria.
• Disponibilidad de dispositivos.
• Opciones deseadas del SO (buffers, número de procesos, tipo de scheduling, etc.)
⊕
Referencias: [7.28] [7.29] [7.30] [7.31] [7.32] [7.33] [7.34]
266
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
una interfaz, así que otros pueden proveer la interfaz estándar en sus propios sistemas
operativos.
Hay más de diez partes del estándar POSIX, pero dos están disponibles:
• POSIX.1 define interfases de programación en C (una librería de llamadas al sistema) para
archivos, procesos, y entrada/salida de terminales. Para soportar la librería, un sistema
POSIX debe implementar un sistema de archivos jerárquico (Hierarchical File System (HFS)).
• POSIX.2 define un intérprete de comandos (shell) y utilerías (p.ej. ls para listar archivos).
Ciertos estándares importantes no son cubiertos por POSIX (p.ej. spooling, procesamiento
por lotes, y soporte de lenguaje nativo (NLS, Native Language Support, que esta definido por
el estándar X/Open)).
Aunque el uso de los recursos del hardware de la computadora sea el objetivo principal del
diseño de un sistema operativo, no se puede dejar de pensar en como los usuarios interactuarán
con la computadora, pues hay que recordar que por lo menos en la arena de las computadoras
personales, esto ha sido el factor principal para el éxito de cualquier producto, ya sea una
computadora o alguno de sus periféricos.
En un principio los operadores expertos tenían que recurrir a teclados especiales para perforar
tarjetas que alimentaban a la máquina, y debían consultar sus resultados en manojos de hojas
⊕
Obras consultadas: [7.64] [7.65] [7.66] [7.67] [7.69]
267
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
que salían de las impresoras. Poco a poco, la mejora en interfaces con el usuario ha permitido
que pueda disminuirse la complejidad de interacción entre las computadoras y usuarios.
HCI va más allá de diseñar pantallas o menús que sean más fáciles de usar (usabilidad), pues
estudia el razonamiento que implica construir determinada funcionalidad en las computadoras y
sus efectos a largo plazo que estos sistemas tienen en los humanos.
Una de las principales actividades en esta área es el desarrollo de nuevos sistemas de interfaz
para el usuario, lo que implica desarrollar nuevos dispositivos de interfaz (fig. 7.10), nuevas
técnicas de graficación por computadora y técnicas de diálogo [7.89].
Una interfaz de usuario es un medio para que el usuario interactúe con la computadora. Este
medio se constituye tanto de software como de hardware. Aunque las interfaces de usuario
pueden adoptar diversas formas, sus objetivos fundamentales son: comunicar información de la
máquina al usuario y comunicar información del usuario a la máquina.
Douglas Engelbart fue el pionero en esta área, pues planteó una visión en la que “las
computadoras fueran extensiones de las capacidades de comunicación del ser humano y fueran
un recurso para aumentar el intelecto humano” [7.75]. Él, junto con un grupo de jóvenes
⊕
Obras consultadas: [7.81] [7.82] [7.83] [7.89]
268
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las primeras interfaces de usuario con la computadora estaban orientadas al uso de texto
proveniente de un teclado, y usualmente consistían de un conjunto de comando que el usuario
debía memorizar y a los que la computadora respondía (fig. 7.11).
Así que por una parte está el manejo del modo gráfico correspondiente a la interfaz para
desplegar sus resultados en el monitor, y por otro esta el programa encargado de captar y
ejecutar los comandos correspondientes. Dichos comandos corresponden a un lenguaje que debe
ser especificado por una gramática. Este programa por lo general es un interprete que puede
basar su codificación en el patrón Interpreter (fig. 7.12).
⊕
Obras consultadas: [7.79] [7.80]
269
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Un paso intermedio entre la interfaz de línea de comando y las interfaces gráficas, fue el uso de
interfaces basadas en menús en modo texto (fig. 7.13), donde se podía interactuar por medio de
un ratón en lugar de escribir el comando correspondiente en el teclado. Esto demandaba un
esfuerzo considerable de programación, y por lo general no había una manera estandarizada de
programar este tipo de interfaces.
En este punto, muchas librerías para interfaces de usuario aparecieron prometiendo disminuir
los tiempos de desarrollo, pero con el advenimiento de las interfaces gráficas integradas en el
sistema operativo, mucho de este trabajo fue efímero.
⊕
Obras consultadas: [7.70] [7.71] [7.72] [7.73] [7.74] [7.75] [7.76] [7.77] [7.78]
270
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
los programas [7.78]. Este cambio de paradigma en las interfaces de usuario se dio en el centro
de investigación de Xerox, cuando se construyó la computadora Alto (1973).
Además de sus componentes gráficos, la interfaz debe permitir mover datos de una aplicación a
otra. Una buena GUI debe incluir formatos estándar para representar texto y gráficos, lo que
permite que las aplicaciones puedan compartir sus contenidos (p.ej. llevar un gráfico de una hoja
de cálculo a un procesador de palabras).
Una arquitectura que es comúnmente usada para el desarrollo de la GUI es el patrón modelo-
vista-controlador (MVC), que permite separar los componentes gráficos, el control de los
dispositivos periféricos y eventos, y sus efectos en el modelo (fig. 7.15).
271
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En este esquema las aplicaciones usan los elementos del GUI que proporciona el sistema
operativo, y es posible agregar elementos gráficos adicionales. Tómese como ejemplo el caso de
Java donde se tiene un marco de trabajo llamado Swing que permite la programación de
interfaces de usuario (fig. 7.16).
Cada sistema operativo tiene su propia arquitectura de GUI, pues sistemas como BeOs o el Mac
OS X, orientados a diseñadores y artistas gráficos, hacen un uso intensivo de las capacidades
gráficas de la computadora, por lo que debe optimizar el uso de estos recursos.
35
Imagen reproducida de [7.70]
272
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Una tendencia adicional es la personalización del diseño gráfico de los elementos de la interfaz
gráfica. Para ello se ha introducido el concepto de tema, donde existe una separación en el
trabajo de los diseñadores gráficos y los programadores. De esta manera, pueden cambiarse el
diseño y distribución de los controles sin tener que recompilar el código encargado del GUI (fig.
7.17)
Una interfaz de usuario basada en el habla (speech user interface - SUI) es aquella que soporta
un diálogo interactivo entre el usuario y una aplicación de software, ofreciendo una forma de
interacción más natural para el usuario.
Los dispositivos de interfaz neuronal (Neural Interface Devices) permiten a los usuarios
aprovechar las señales eléctricas generadas por sus cuerpos para controlar una computadora o
dispositivos eléctricos conectados a ella.
36
Imagen adaptada de [7.67]
⊕
Obras consultadas: [7.68] [7.83] [7.84]
273
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Las señales pueden adquirirse de forma directa o indirecta. Los métodos directos implican
implantes quirúrgicos en el cuerpo del usuario. El implante puede localizarse en el cerebro o en
algún miembro amputado, dependiendo de la aplicación. Este tipo de tecnología aún está en
desarrollo.
Los métodos indirectos de obtención de señales no requieren cirugía. Estas señales neuronales
indirectas pueden obtenerse de los músculos (EMG), movimiento de los ojos (EOG) o de las
ondas cerebrales (EEG).
Después de que las señales eléctricas se obtienen del cuerpo se amplifican, y se traducen en su
equivalente digital para que el software pueda interpretar las señales. Dicho software permite a
los usuarios controlar un cursor, jugar videojuegos especialmente diseñados o controlar otros
dispositivos conectados a la computadora.
En el contexto de los sistemas operativos, sobre todo de los de uso general, dichas interfaces
deben implementar una metáfora del espacio de trabajo y sus correspondientes elementos de
diseño, así como contemplar los dispositivos con que la computadora podrá contar, lo que lleva al
desarrollo de:
⊕
Obras consultadas: [7.86] [7.87] [7.88]
274
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Un ejemplo palpable de este enfoque es la arquitectura del Mac OS X (fig. 7.18). Como soporte
se tiene un microkernel muy potente (Darwin), sobre el que se monta la capa del sistema de
gráficos que integra 3 tecnologías [7.88]:
Aqua es la interfaz gráfica de usuario de este sistema operativo, que integra la apariencia y
comportamiento de la interfaz, que basa mucha de su funcionalidad gráfica en las capacidades
de Quartz.
Todo esto queda plasmado en el término definido por Apple como experiencia del usuario (User
Experience) el cuál abarca la apariencia visual, comportamiento interactivo, y capacidades
asistivas del software.
Todo este soporte debe ser considerado por quien desarrolle un sistema operativo, pues esta
infraestructura representa una ventaja competitiva si se quiere que el SO sea adoptado por el
mayor numero de usuarios posible, y sobre todo si se quiere que las comunidades de
desarrolladores produzcan aplicaciones en la nueva plataforma.
Incluso aunque la parte de interfaz de usuario este contemplada en el diseño del SO, puede que
su implementación no sea del gusto de los desarrolladores, o que por estar implementada en un
lenguaje estructurado, si se requiere desarrollar con orientación a objetos existan problemas de
37
Imagen reproducida de [7.88]
275
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Existe un tipo de usuarios especializados de los sistemas operativos para los cuales la simple
funcionalidad de ejecutar sus programas no es suficiente. Estos usuarios, llamados
administradores de sistemas, requieren el control completo del sistema para cumplir con 3
objetivos fundamentales:
Para realizar estos objetivos el administrador del sistema debe entender más que solo la
estructura e interacción del hardware y el software; debe comprender el ambiente de
interconexión en el que actualmente los sistemas existen y los efectos que el ambiente tiene en
el funcionamiento y rendimiento del sistema local.
• Unidades de disco
o Control de la agrupación y subdivisión del espacio en disco.
o Control de la localización de datos y programas para un desempeño óptimo.
o Control de la cantidad de espacio asignado para diversos propósitos.
• Programas de aplicación
o Control del uso de programas costosos o “sensibles” (uso restringido)
o Instalación y ajuste del desempeño de aplicaciones críticas.
• Datos de aplicación
o Control del acceso a datos sensibles.
o Asegurar las medidas de respaldo apropiado.
• Memoria y procesadores de computadoras individuales
o Control de acceso al sistema por individuos y grupos.
o Ajustar el sistema operative para el uso óptimo de los recursos disponibles.
• Redes de area local
o Ajustar la red para un óptimo desempeño.
o Control de los mecanismos de direccionamiento de la red.
⊕
Obras consultadas: [7.90][7.91][7.92][7.93]
276
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Terminales locales
o Control de la conección de las terminals a los procesadores.
o Asegurar que las terminales y procesadores esten ajustados para un óptimo
desempeño.
• Acceso a sistemas remotos
o Control de los permisos de acceso en ambas direcciones.
o Monitoreo y ajuste del desempeño de la carga impuesta por la conexiones
remota.
• Acceso a datos remotos
o Control de los método y disponibilidad de acceso.
Por la amplia variedad de funciones que se requieren para que un sistema opere debidamente,
el sistema operativo debe considerar en su diseño el soporte de las actividades propias de
administración de sistemas. Esto puede incluir:
• archivos que permitan parametrizar la operación del SO (p.ej. el archivo AUTOEXEC.BAT
en DOS que permitía definir que manejadores de dispositivos adicionales debían
cargarse, o el tamaño o modo de la memoria)
• estructuras de datos y archivos que permitan controlar la configuración del sistema
operativo (p.ej. el Registry de Windows)
• APIs que permitan el acceso a la información de administración y monitoreo.
• herramientas de administración por línea de comandos (p.ej. el comando kill para
destruir procesos en UNIX)
• herramientas de interfaz gráfica de administración y monitoreo (p.ej. el Task Manager de
Windows)
• herramientas web de administración y monitoreo (p.ej. el Web-based System Manager
de AIX)
• servicios de administración remota del SO (p.ej. herramientas que usan protocolos como
el Simple Network Management Protocol)
• ayuda en linea (p.ej. el comando man de UNIX)
Aunque muchas de estas herramientas son usados por administradores experimentados, una
tendencia de los nuevos sistemas operativos es brindar al usuario convencional algunas de estas
funcionalidades, pues el usuario casero no optará por un sistema complejo o costoso de
administrar.
Inclusive compañías como Symantec han optado por desarrollar herramientas muy sofisticadas
que simplifican la labor de la administración de sistemas, y que cubren las posibles carencias que
un sistema operativo tenga en este rubro. Este es un nicho de mercado paralelo al desarrollo de
sistemas operativos, y que seguramente implica la formación de alianzas entre los productores de
software para que estos productos tengan el impacto deseado.
7.8 Comentarios
Esta parte del trabajo se ha dedicado a ubicar la actividad de diseño de sistemas operativos en
el marco del proceso de desarrollo e ingeniería de software (fig. 7.19), con el fin de recalcar una
277
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
vez más a los desarrolladores la importancia de contar con un modelo de referencia para la
producción de sistemas operativos (fig. 7.20). Dicho modelo dista mucho del enfoque orientado
exclusivamente a la programación, y expone todos los requerimientos, consideraciones y criterios
que deberán tomarse en cuenta al enfrentar un desarrollo de estas dimensiones.
De igual forma puede notarse que aunque el presente es extenso y trata de cubrir la mayoría
de los aspectos, hay muchos otros que quedan sin explorar.
Como se puede apreciar en la última parte de este capítulo, los desafíos técnicos a solucionar
son muchos y variados, por lo que los desarrolladores tienden a ocuparse más en domar al
hardware, hasta alcanzar un nivel de complejidad suficiente en la codificación como para pensar
en las cuestiones de alto nivel. Esto de ninguna manera es censurable; sin embargo, se reafirma
la necesidad de aplicar los métodos de ingeniería de software para que el producto pueda
alcanzar sus objetivos.
278
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
279
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
280
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[7.25] Operating system design & implementation - [7.40] Software Architecture and Related Concerns
tutorial.
http://www.bredemeyer.com/whatis.htm
http://www.ansawide.com/josh/index.htm
[7.27] The Special Interest Group for Operating [7.42] Model Problems
Systems. ACM
http://www-2.cs.cmu.edu/People/ModProb/
http://www.acm.uiuc.edu/sigops/
281
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[7.54] Operating System 2010 by Steven J. Vaughan- [7.67] WCEfA. Using Automotive Graphical User
Nichols Interface
Byte. November 5, 2001 http://msdn.microsoft.com/library/default.asp?url=/libr
http://www.byte.com/documents/s=1778/byt20011031 ary/en-us/apcguide/htm/acc_guide_1.asp
s0004/
[7.68] WCEfA. Using Automotive Speech Architecture
[7.55] The Design and Implementation of the 4.4BSD http://msdn.microsoft.com/library/default.asp?url=/libr
Operating System ary/en-us/apcguide/htm/spc_overview_1.asp
Marshall Kirk McKusick, Keith Bostic, Michael J. Karels,
John S. Quarterman [7.69] A Graphical User Interface Toolkit Approach to
Addison-Wesley Longman, Inc, 1996 Thin-Client Computing
http://www.freebsd.org/doc/en_US.ISO8859- Simon Lok, Steven K. Feiner, William M. Chiong and
1/books/design-44bsd/ Yoav J. Hirsch
http://www2002.org/CDROM/refereed/577/
[7.56] DROS
http://www.dros.com/ [7.70] Fundamentals of Swing: Part I Short Course
By MageLang Institute
[7.57] Software Architecture in Practice http://developer.java.sun.com/developer/onlineTraining
http://www.cs.vu.nl/~hansdb/state/node6.html /GUI/Swing1/shortcourse.html
[7.58] Architectural Styles, Design Patterns and [7.71] MVC meets Swing
Objects. Robert T. Monroe, Andrew Kompanek, Ralph Todd Sundsted
Melton, and David Garlan http://www.javaworld.com/javaworld/jw-04-1998/jw-
IEEE Software, January 1997, pp. 43-52. 04-howto_p.html
http://pecan.srv.cs.cmu.edu/afs/cs/project/able/www/p
aper_abstracts/ObjPatternsArch-ieee.html [7.72] Bambookit GUI - XML GUI Software Architecture
http://www.bambookit.com/_architecture.html
[7.59] Architectural patterns
http://www.rational.com/products/whitepapers/390.jsp [7.73] Java Look and Feel Design Guidelines, second
edition. Copyright 2001. Sun Microsystems
[7.60] Architectural Patterns, Design Patterns, Idioms http://java.sun.com/products/jlf/ed2/book/HIGTitle.htm
http://www.tml.hut.fi/Opinnot/Tik-109.450/1998/niska/ l
[7.61] Architectural patterns [7.74] Microsoft, Apple and Xerox. The History of the
Graphical User Interface . David K. Every
http://www.opengroup.org/togaf/p4/patterns/patterns.
htm http://www.mackido.com/Interface/ui_history.html
[7.64] Operating Systems Widely Used on Personal [7.77] User interface Markup Language
Computers http://www.uiml.org/index.php
http://www.abilityhub.com/information/os.htm
[7.78] GUI – Webopedia
[7.65] The X Window system http://www.webopedia.com/TERM/G/Graphical_User_I
http://www.viewtouch.com/xwindows.html nterface_GUI.html
282
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[7.84] ATRC – Neural interface devices [7.91] Windows 95 System Management Architecture
http://www.utoronto.ca/atrc/reference/tech/neuralinter Windows Development Management Technical Articles
face.html July 26, 1994
http://msdn.microsoft.com/archive/default.asp?url=/arc
[7.85] Architecture of the Runtime Engine hive/en-us/dnarmgmt/html/msdn_chic_mgt.asp
http://developer.apple.com/techpubs/macosx/Carbon/g
raphics/OpenGL/OpenGL/chap2/chapter_2_section_4.ht [7.92] Web-based System Manager Administration
ml Guide. IBM.
http://publib16.boulder.ibm.com/pseries/en_US/aixbma
[7.86] User Interface Design n/wsmadmn/mastertoc.htm
Common Front Group
http://cfg.cit.cornell.edu/cfg/design/contents.html [7.93] BolinOS
http://www.med-ia.ch/med-ia/bolinos/
[7.87] GUI Gallery
http://toastytech.com/guis/
283
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
284
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Capitulo 8.
Arquitecturas de Sistemas Operativos
La imaginación es más importante que el conocimiento.
Albert Einstein
Después de explicar qué es un sistema operativo, cuáles son sus partes y cómo funciona,
quedan por responder las incógnitas referentes a su estructura, tales como:
• ¿por qué algunos sistemas tienen más (o menos) elementos que otros?
• ¿por qué algunos son portables entre distintas computadoras?
• ¿cómo están construidos?
• ¿de qué (o de quién) depende que un SO tenga más (o menos) servicios?
Para poder responder lo anterior, debemos hablar de la etapa de concepción del software,
donde se decide qué se quiere hacer y hasta dónde llegar. Es en esta fase del desarrollo de
cualquier sistema donde se plantea una arquitectura, que es la descripción de la estructura de
un sistema y la información que lo hace funcionar.
La idea es contar con una referencia de elementos concretos de diseño para poder establecer
lineamientos y criterios para el diseño de este tipo de sistemas.
285
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
286
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
R es ource
Mana ger
Ker nel
H AL
H ar dw are
Obviamente puede continuarse con la especificación de los detalles usando UML, pero los
esquemas de módulos son útiles (y hasta más amigables) para representar el contexto general
de una arquitectura, razón por la cual se incluyen en las siguientes secciones donde se discuten
las arquitecturas de los sistemas operativos.
Un sistema operativo abstrae y protege los recursos de hardware; por ejemplo abstrae la
memoria física en términos de memoria virtual, los bloques de un disco en archivos, y las
excepciones y CPU en procesos. Esta organización tiene 3 beneficios principales:
• se provee una interfaz portable al hardware de la máquina, por lo que las aplicaciones no
necesitan preocuparse de los detalles del hardware.
• provee una plataforma funcional, eliminando la necesidad de que los desarrolladores escriban
manejadores de dispositivos, u otro código de bajo nivel.
⊕
Obras consultadas: [8.1] [8.12]
287
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Por ello, su estructura tiene un gran impacto en el desempeño y alcance de las aplicaciones que
pueden construirse sobre él.
Así como hay principios que definen las arquitecturas de hardware (ver capítulo 2) y puesto que
el diseño de los sistemas operativos es dependiente de este, es de esperarse que exista una
estructura similar de funciones para los SOs. Además de las funciones que un SO debe proveer
para operar por completo (funciones centrales o core functions), hay un amplio conjunto de
servicios que el usuario espera de un SO. Algunas veces estos servicios son hechos por otros
desarrolladores que quieren expandir las capacidades de un SO, definiendo nuevas habilidades
que eventualmente serán agregadas al SO (a veces por optimización, a veces solo para eliminar
a la competencia)
Existen muchos tipos de modelos de sistemas operativos. Algunos son usados en sistemas
comerciales o de distribución gratuita, mientras que otros están siendo inventados en las
universidades como parte de proyectos de investigación. Todos los tipos de sistemas operativos
tienen sus ventajas y desventajas, al ser hechos para diferentes tipos de hardware o con
diferentes propósitos.
Hablar de ventajas y desventajas es difícil, pues la mayoría de los sistemas operativos están
enfocados a un grupo de usuarios o aplicaciones específico, o son usados en configuraciones
específicas de sistemas de cómputo.
⊕
Obras consultadas: [8.31] [8.32] [8.33] [8.34] [8.35] [8.36]
288
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para construir el programa objeto de un SO bajo este enfoque, lo primero es compilar todos los
procedimientos individuales, o archivos que los contienen, y luego se vinculan en un solo archivo
objeto.
La arquitectura más antigua usada para los sistemas operativos es la de kernel monolítico. Un
kernel monolítico puede ser fácilmente implementado si se está preparado para aceptar una alta
latencia (p.ej. dar servicio a peticiones sin importar la urgencia de otras peticiones).
Los kernels monolíticos más nuevos (p.ej. UNIX) tienen un diseño modular, que ofrece la
adición o remoción de servicios a tiempo de ejecución. El kernel entero se ejecuta en modo
supervisor, un modo de procesador en el que el software tiene control absoluto de la máquina.
Los procesos que se ejecutan sobre el kernel se ejecutan en modo de usuario, en el que los
programas solo tienen acceso a los servicios del kernel.
289
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Como otros sistemas operativos, Linux mantiene seguimiento de archivos en disco, ejecuta
programas, y multiplexa el procesador y otro hardware para proveer multitarea, asigna memoria
y otros recursos a varios procesos, recibe y envía paquetes por medio de una red.
El kernel mantiene mucha de la información sobre el estado del sistema (la mayor parte en
memoria física). Hay varias estructuras de datos en el kernel cuyo propósito es apoyar las
funciones de los subsistemas (o componentes) del kernel.
En realidad, los módulos de Linux "pueden compartir datos" con cualquier otro módulo. Esto es
por que el kernel tiene una estructura monolítica (el sistema operativo está escrito como una
colección de procedimientos, cada uno de los cuales puede llamar a cualquier otro cuando lo
necesite).
Dijkstra introdujo la arquitectura de capas cuando desarrollo el sistema THE (1968), un sencillo
sistema de procesamiento por lotes (figura 8.6). El sistema tenia seis capas:
38
Imagen reproducida de [8.35]
290
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• La capa 1 administraba la memoria, repartiendo espacio para los procesos. Arriba de esta
capa, los procesos no tenían que preocuparse por si estaban en la memoria o en un
tambor.
• La capa 2 manejaba la comunicación entre cada proceso y la consola del operador.
• La capa 3 administraba los dispositivos de entrada/salida.
• En la capa 4 se encontraban los programas de usuario y
• El proceso del operador del sistema estaba en la capa 5.
Una forma más generalizada del concepto de capas estuvo presente en el sistema MULTICS, el
cual estaba organizado como una serie de anillos concéntricos, siendo los interiores más
privilegiados que los exteriores. Cuando un procedimiento exterior quería invocar alguno de un
anillo interior, tenía que emitir el equivalente a una llamada al sistema, cuyos parámetros se
analizaban cuidadosamente para comprobar su validez antes de permitir que la llamada
procediera. Aunque todo el sistema formaba parte del espacio de direcciones de cada proceso de
usuario, el hardware permitía designar procedimientos individuales como protegidos contra
lectura, escritura o ejecución.
291
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En tanto que el esquema por capas del sistema THE era en realidad solo una ayuda para el
diseño, ya que todas las partes del programa en última instancia se vinculaban en un solo
programa objeto, en MULTICS el mecanismo de anillo estaba muy presente en el momento de la
ejecución y el hardware obligaba a ajustarse a él. La ventaja del mecanismo de anillo es que se
puede extender fácilmente para estructurar los subsistemas de usuario.
No siempre es fácil tener una verdadera arquitectura de capas puesto que algunas
funcionalidades pueden describirse como mutuamente dependientes, además de que esta
arquitectura es comúnmente ineficiente al requerir un gran número de interfases transversales.
Un caso donde este enfoque ha sido refinado es el del Mac OS X, el cuál tiene 4 capas distintas
de software del sistema:
39
Imagen reproducida de [8.46]
292
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La idea principal de este enfoque es que por medio del software se proporcione a los programas
la emulación de un hardware que "de facto" no existe. El software emulador convierte las
peticiones hechas a la máquina virtual en operaciones sobre la máquina real (los recursos reales
se reparten entre las distintas máquinas virtuales). Esta arquitectura crea una máquina virtual
(p.ej. una IBM 370) para cada "usuario" y el usuario puede elegir que SO ejecutar en esa
máquina virtual.
La ventaja es que estos monitores son más pequeños y simples pues no proveen ningún
servicio de usuario; son simples simuladores de hardware, y pueden ejecutar diferentes sistemas
operativos en una misma máquina.
Puesto que cada máquina virtual es idéntica al verdadero hardware, cada una puede ejecutar
cualquier sistema operativo que se ejecutaría directamente en el hardware. Diferentes máquinas
virtuales pueden ejecutar diferentes sistemas (p.ej. algún descendiente del OS/360, CMS, etc.).
⊕
Obras consultadas: [8.2]
293
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En el caso de VM/370, cuando un usuario ejecuta una llamada al sistema, la llamada se atrapa
y se envía al sistema operativo de su propia máquina virtual. Al emitir señales de E/S (por
ejemplo para leer un disco virtual), tales instrucciones son atrapadas por el VM el cual las ejecuta
como parte de la simulación del hardware.
294
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La arquitectura de microkernel es muy moderna (Mach, OSF, QNX y Windows NT). Esta radica
en:
Los diseños de microkernels colocan la mayoría de los servicios del SO en procesos separados,
que pueden ser iniciados o detenidos a tiempo de ejecución, lo que hace al kernel mucho más
pequeño y se ofrece una gran flexibilidad.
40
Imagen reproducida de [8.2]
⊕
Obras consultadas: [8.6] [8.7] [8.8] [8.13] [8.14]
295
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Esta arquitectura es de hecho un modelo cliente-servidor, donde los procesos (clientes) pueden
llamar procesos del SO enviando peticiones por medio del IPC a los procesos servidores (p.ej. un
proceso que quiera leer un cierto archivo envía una petición al proceso del sistema de archivos).
Los procesos centrales que proveen la administración de procesos, sistemas de archivos, etc.,
son llamados servidores.
Este cambio se basa en mejorar la eficiencia. Todos los cambios de contexto que se requieren
en la arquitectura de micro-kernel para ir del kernel a las tareas del sistema y de regreso, son
reemplazados por llamadas a subrutinas dentro del mismo kernel, con un gran ahorro de tiempo.
Por supuesto la escritura del kernel se vuelve más compleja, pues dentro de un solo espacio de
direcciones y un solo modo puede tenerse más de una acción concurrente (p.ej. Solaris, usa esta
arquitectura).
Con el multihilado, no solo los programas de usuario pueden crear múltiples tareas a voluntad,
sino que controladores de dispositivos y otros servicios del kernel pueden crear sus propias
tareas, llamadas hilos del kernel. Los hilos del kernel permiten una mejor planificación del manejo
de interrupciones, pues cierto código (de E/S de discos o red) que era parte del manejador de
interrupciones puede colocarse en un hilo de manera que no interfiere con el procesamiento. Por
lo tanto, es posible planificar tareas de usuario críticas a que se ejecuten con una prioridad más
alta, que el hilo del kernel encargado del manejador de dispositivo, por lo que las tareas de
usuario responden más rápido a los eventos.
296
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 8.12 Esquema de la arquitectura del Palm OS. El núcleo de este sistema es el
microkernel AMX (Kadak) que implementa multiprocesamiento41
La mayor dificultad del modelo de microkernel es hacer que el servicio de comunicación entre
procesos sea tan rápido como sea posible. Este fue un problema de diseño en los primeros
microkernels, pues a veces se causaban cuellos de botella en lugar de optimizaciones, aunque
actualmente se ha superado dicho problema.
41
Imagenes reproducidas de [8.13] y [8.14]
297
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 8.13 La arquitectura de paso de mensajes del QNX RTOS forma un bus de
software que permite conectar o desconectar los módulos del SO que se necesiten, sin
reiniciar el sistema42
Aunque no existe una definición exacta, los Sistemas Operativos Orientados a Objetos
(SOOO) son sistemas que proveen recursos por medio de objetos. Imaginemos un sistema de
cómputo como una colección de procesos y objetos. Un sistema consiste de objetos de
hardware: CPU, segmentos de memoria, impresoras, unidades de almacenamiento (discos,
cintas); y objetos de software: archivos, programas y semáforos.
Puede considerarse a los objetos como tipos de datos abstractos. Cada objeto es un tipo
abstracto de datos único que se diferencia de todos los demás objetos y puede ser accedido por
medio de operaciones bien definidas. Tales operaciones son diferentes para cada objeto (por
ejemplo, la memoria puede accederse solo por medio de operaciones de lectura y escritura).
A la hora de diseñar un modelo de cómputo, existen dos alternativas diferentes que definen dos
modelos diferentes y dos conjuntos de características diferentes para los objetos.
a. Modelo de Objetos Pasivo. Este modelo divide los objetos, desde el punto de vista de la
computación, en pasivos y activos. Los primeros sólo son meros contenedores de datos y
métodos; no tienen ninguna capacidad para la ejecución y, por tanto, dependen de otros objetos
para la ejecución de sus métodos. Los segundos, proporcionan la capacidad computacional y son
capaces de ejecutar sus métodos. Representan el flujo de ejecución y pueden involucrar métodos
42
Imagen reproducida de [8.7]
⊕
Obras consultadas: [8.3] [8.4] [8.5] [8.30]
298
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
ofrecidos por más de un objeto. De esta forma su vida es independiente de aquellos objetos que
atraviesa en su ejecución.
b. Modelo de Objetos Activo. Este modelo define un objeto con más contenido semántico. Los
objetos se definen de forma homogénea como entidades con un ciclo de vida propio que no se
limitan a encapsular datos y métodos sino que disponen de sus propios recursos de computación.
En este modelo, el objeto es una entidad autónoma que interacciona con otros objetos en el
sistema. El mecanismo usado para la comunicación es el paso de mensajes.
Generalmente un sistema se dice que es orientado a objetos si por lo menos una de sus partes
está hecha con orientación a objetos.
Los primeros SOOO eran relativamente simples (p.ej., Genera, el primer SOOO comercial;
ambiente de desarrollo en máquinas LISP). A diferencia de la mayoría de los sistemas operativos
(como UNIX), Genera tenia una estructura abierta, lo que significa que no tenia una estructura
supervisor/usuario. Tampoco tenía un núcleo, a excepción de un programa de arranque. No hay
diferencia entre programas de sistema o de usuario. El usuario puede accesar fácilmente
cualquier archivo que necesite, por lo que no se requiere emplear recursos para separar y
controlar los archivos del sistema y el usuario, lo que ahorra espacio en memoria y acelera la
ejecución de procesos.
Cada parte del sistema tiene su propia implementación. Un típico SOOO en general consiste de
un administrador de archivos, administrador de dispositivos, administrador de memoria y una
estructura de manejo de excepciones.
Los SOOO permiten la creación de tantos objetos como se quiera (limitado por supuesto a las
características del sistema) pero sin la necesidad de destruirlos. El ambiente de ejecución elimina
objetos cuando determina que ya no están siendo usados. Este proceso se conoce como
recolección de basura (garbage collection).
El algoritmo del recolector es bastante simple. Se revisan dinámicamente las áreas de memoria
en busca de objetos, y marca aquellos que están referenciados. Después de investigar todas las
posibles rutas a los objetos, aquellos que no se marcaron se recolectan.
En otras palabras, el sistema solo asume que todo lo que no está marcado es espacio libre. El
recolector de basura por lo general se ejecuta de forma síncrona cuando el sistema se queda sin
memoria, o en respuesta a una petición de un programa. De otra forma, se ejecuta
asíncronamente cuando el sistema esta ocioso. Desafortunadamente la recolección de basura
requiere mucho tiempo para completar su tarea, lo que la hace una técnica inadecuada para
sistemas de tiempo real, aunque puede ser útil si se implementa de forma que se ejecute en
partes, teniendo en cuenta que nunca debe interferir con los procesos de prioridad alta, y que
debe ejecutarse durante el procesamiento de procesos de prioridad baja y tiempo de ocio del
procesador (por lo que su prioridad debe ser media).
299
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 8.14 En el corazón del JavaOS se encuentra la máquina virtual de Java (JVM).
Los servicios del sistema, manejadores, applets y aplicaciones se ejecutan en la VM y un
microkernel provee los servicios básicos de la plataforma43
Uno de los SOOO más recientes es el 3-D Visual OS (VOS) que es un nuevo sistema operativo
basado en los conceptos de la programación orientada a objetos (en términos de adaptación y el
uso de componentes disponibles) y la programación visual (en términos del despliegue de
módulos de software). Esto implica que los usuarios pueden usar un editor gráfico para crear y
programar su ambiente y aplicaciones, relacionando los módulos de software apropiados.
300
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 8.15 La red de módulos de software que forma una aplicación puede visualizarse
en distintos niveles44
44
Imagen reproducida de [8.30]
⊕
Obras consultadas: [8.29]
301
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Es el modelo de interacción más común entre aplicaciones en una red. No forma parte de los
conceptos de la Internet como los protocolos IP, TCP o UDP, sin embargo todos los servicios
estándares de alto nivel propuestos en Internet funcionan según este modelo.
Los principales componentes del esquema cliente/servidor son entonces los Clientes, los
Servidores y la infraestructura de comunicaciones.
En este modelo, las aplicaciones se dividen de forma que el servidor contiene la parte que debe
ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada usuario.
45
Imagen reproducida de [8.29]
⊕
Obras consultadas: [8.42]
302
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los Servidores proporcionan un servicio al cliente y devuelven los resultados. En algunos casos
existen procesos auxiliares que se encargan de recibir las solicitudes del cliente, verificar la
protección, activar un proceso servidor para satisfacer el pedido, recibir su respuesta y enviarla al
cliente. Además, deben manejar los interbloqueos, la recuperación ante fallas, y otros aspectos
afines. Por las razones anteriores, la plataforma computacional asociada con los servidores es
más poderosa que la de los clientes. Por esta razón se utilizan PCs poderosas, estaciones de
trabajo, minicomputadoras o sistemas grandes. Además deben manejar servicios como
administración de la red, mensajes, control y administración de la entrada al sistema (login),
auditoria y recuperación y contabilidad. Usualmente en los servidores existe algún tipo de servicio
de bases de datos. En ciertas circunstancias, este término designará a una máquina. Este será el
caso si dicha máquina está dedicada a un servicio particular, por ejemplo: servidores de
impresión, servidor de archivos, servidor de correo electrónico, etc.
Por su parte los servidores realizan, entre otras, las siguientes funciones:
• Gestión de periféricos compartidos.
• Control de accesos concurrentes a bases de datos compartidas.
• Enlaces de comunicaciones con otras redes de área local o extensa.
• Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y éste,
le responde proporcionándolo. Normalmente, pero no necesariamente, el cliente y el
servidor están ubicados en distintos procesadores. Los clientes se suelen situar en
computadoras personales y/o estaciones de trabajo y los servidores en procesadores
departamentales o de grupo.
Para que los clientes y los servidores puedan comunicarse se requiere una infraestructura de
comunicaciones, la cual proporciona los mecanismos básicos de direccionamiento y transporte. La
mayoría de los sistemas Cliente/Servidor actuales, se basan en redes locales y por lo tanto
utilizan protocolos no orientados a conexión, lo cual implica que las aplicaciones deben hacer las
verificaciones. La red debe tener características adecuadas de desempeño, confiabilidad,
transparencia y administración.
303
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Como ejemplos de clientes pueden citarse interfaces de usuario para enviar comandos a un
servidor, APIs para el desarrollo de aplicaciones distribuidas, herramientas en el cliente para
hacer acceso a servidores remotos (por ejemplo, servidores de SQL) o aplicaciones que solicitan
acceso a servidores para algunos servicios.
Como ejemplos de servidores en el software del sistema, pueden citarse servidores de ventanas
como X-Window, servidores de archivos como NFS; en el software de aplicación tenemos
servidores para el manejo de bases de datos (como los servidores de SQL), servidores de diseño
y manufactura asistidos por computadora, etc.
46
Imagen reproducida de [8.57]
304
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• Direccionamiento:
o Número de máquina.
o Direcciones de procesos.
o Búsqueda de nombres en ASCII por medio del servidor.
• Bloqueo:
o Primitivas con bloqueo.
o Sin bloqueo, con copia al núcleo.
o Sin bloqueo, con interrupciones.
• Almacenamiento en buffers:
o No usar el almacenamiento en buffers, descartar los mensajes inesperados.
o Sin almacenamiento en buffers, mantenimiento temporal de los mensajes
inesperados.
o Buzones.
• Confiabilidad:
o No confiable.
o Solicitud - reconocimiento - respuesta - reconocimiento.
o Solicitud - respuesta - reconocimiento
Existen dos tipos básicos de redes: las Redes Locales (LAN) y las Redes de Área Amplia (WAN).
La principal diferencia entre ambas es su distribución geográfica. Las redes locales están
compuestas por procesadores distribuidos en un área geográfica pequeña, como un edificio o
varios edificios adyacentes; en cambio las redes de área ancha, están formadas por varios
procesadores autónomos distribuidos en un área geográfica extensa (como todo un país). Estas
diferencias radican en la velocidad y confiabilidad de la red de comunicaciones y se ven
reflejadas en el diseño del sistema operativo.
Los sistemas operativos de red se definen como aquellos que tiene la capacidad de
interactuar con sistemas operativos en otras computadoras a través de un medio de transmisión
con el objeto de intercambiar información, transferir archivos, ejecutar comandos remotos y un
sin fin de otras actividades. El punto crucial de estos sistemas es que el usuario debe saber la
sintaxis de un conjunto de comandos o llamadas al sistema para ejecutar estas operaciones,
además de la ubicación de los recursos que desee acceder.
305
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Aunque los actuales sistemas de red solucionan parte de las necesidades actuales de
comunicación entre computadoras, tienen importantes limitaciones, y no son aplicables a una
gran cantidad de problemas. Por ello surge la necesidad de crear sistemas distribuidos que
sustituyan a los actuales sistemas de red o a los sistemas multiprocesadores.
47
Imagen reproducida de [8.56]
306
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
El sistema operativo distribuido lleva a cabo todas las actividades que implican la ubicación
física y atributos de procesamiento para satisfacer la demanda del usuario.
• Papel dual de los componentes.- Los componentes individuales de procesamiento pueden
operar independientemente del marco de trabajo del sistema distribuido
307
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Podemos citar como casos de sistemas operativos distribuidos a los siguientes: LynxOS, QNX,
OS-9, JavaOS, Amoeba, Mach, Chorus e Inferno.
Síntomas de Distribución:
• Multiproceso (concurrencia): El hardware permite el progreso simultáneo de varias
actividades (varias CPUs, con memoria local, etc.).
• Interconexión: Permite la comunicación entre las actividades.
• Relación: Uso compartido de recursos, información, etc.
• Fallo independiente: Permite buscar soluciones resistentes en caso de fallo (las
comunicaciones también pueden fallar).
Propiedades
• Nombrado global: el mismo nombre es válido en todo el sistema.
• Acceso global: los mismos métodos actúan en objetos, en cualquier parte del sistema.
• Seguridad global: autenticación y acceso uniformes en todo el sistema.
• Disponibilidad global: funcionamiento correcto en presencia de fallos parciales.
• Gestión global: posibilidad de gestión centralizada del sistema.
Características funcionales
• Cada usuario trabaja con su terminal local inteligente, con lo que obtiene mejores
tiempos de respuesta.
• Los recursos necesarios que no estén disponibles sobre el terminal local (computadora
personal o estación de trabajo), pueden tomarse de la computadora central a través de
la red de telecomunicaciones.
Características físicas
• Sistemas informáticos distribuidos en los que las computadoras, a través de la
organización, están conectados por medio de una red de telecomunicaciones.
• Cada computadora sobre la red tiene capacidad de tratamiento autónomo que permite
servir a las necesidades de los usuarios locales.
• También proporciona acceso a otros elementos de la red o a servidores centrales.
• Toma importancia la red de comunicación de datos.
308
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Características lógicas
• Cada tarea individual puede ser analizada para determinar si puede distribuirse o no. En
general, las tareas más complejas o de carácter estratégico para la organización se
mantienen en la computadora central. Las tareas de complejidad media o específica para
un determinado grupo de usuarios, se distribuyen entre las máquinas locales de ese
grupo.
• La plataforma física seleccionada puede ajustarse a las necesidades del grupo de
usuarios, con lo que surgen las computadoras especializadas para determinados tipos de
tareas.
Ventajas
• Funcionamiento autónomo de los sistemas locales, lo que origina un buen tiempo de
respuesta.
• Los sistemas de información llegan a todos los departamentos de la empresa.
• Abre posibilidades de trabajo mucho más flexibles y potentes.
Inconvenientes
• Requiere un intenso flujo de informaciones (muchas veces no útiles, como pantallas y
datos incorrectos) dentro de la red, lo que puede elevar los costos de comunicaciones.
• Supone una mayor complejidad.
• Si los sistemas no están integrados, pueden producirse problemas de inconsistencia de
datos.
8.9.2 Mach⊕
Como caso de estudio de un sistema operativo distribuido se tiene a Mach, que fue diseñado e
implementado en la universidad de Carnegie-Melon (CMU) como una alternativa más
estructurada y pequeña que el BSD UNIX (de hecho está basado en el sistema operativo Accent,
también desarrollado en CMU). Su desarrollo empezó en 1985 y la primera versión de Mach
estuvo disponible para la familia de computadoras DEC VAX (1986), y las versiones siguientes
aparecieron con soporte pleno de multiprocesamiento (las máquinas que lo usaban eran sistemas
multiprocesador con acceso uniforme a la memoria del sistema).
La versión 2 fue portada a sistemas donde los procesadores compartían la memoria, pero cada
procesador tenia acceso limitado a parte de la memoria del sistema. Actualmente se encuentra
disponible para una gran variedad de sistemas, incluyendo maquinas con un procesador (SUN,
IBM, Intel y DEC).
El sistema operativo Mach fue diseñado para proveer algunos mecanismos básicos que casi
todos los sistemas operativos ofrecen, y ser compatible con BSD. Además:
⊕
Obras consultadas: [8.37]
309
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los diseñadores de Mach se influenciaron por BSD (y en general UNIX), lo que dio como
beneficios:
• Una interfaz de programación simple, con un buen conjunto de servicios básicos (primitivas)
y un conjunto consistente de interfases con el sistema.
• Sencilla portabilidad a una gran gama de sistemas con un procesador.
• Una amplia librería de utilerías y aplicaciones, así como la habilidad de combinar utilerías por
medio de canales (pipes).
Aportaciones
48
Imagen reproducida de [8.38]
310
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Partes de Mach han sido incorporadas en varios sistemas operativos comerciales como:
• Encore's Multimax
• NeXT OS
• MachTen para Macintosh
• Omron's Luna
• DEC's OSF/1 para el DEC Alpha
• IBM's OS/2 para máquinas basadas en el RS6000.
• Mac OS X
311
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 8.22 Arquitectura del microkernel Darwin del Mac OS X que integra el kernel
Mach 3.0 y servicios del BSD UNIX49
La noción de una especialización incremental es solo una de las formas en que los sistemas
operativos pueden adaptarse a circunstancias en continuo cambio. Los sistemas operativos
adaptables se clasifican en 3 formas:
Quién hace la adaptación: Usuario vs. Adaptación del sistema. El programa de usuario
(aplicación) tiene que solicitar explícitamente la adaptación, o el sistema automáticamente se
49
Imagen reproducida de [8.48]
⊕
Obras consultadas: [8.18] [8.19] [8.20] [8.21] [8.22] [8.44]
312
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
En el área de sistemas distribuidos y proyectos como Off++ (microkernel diseñado en 1997 por
Francisco Ballesteros, Roy Campbell, y Fabio Kon), se sabe que la adaptabilidad puede lograrse
usando un microkernel mínimo como base para el sistema operativo. Si el microkernel está
centralizado, la adaptación de los servicios del sistema para requerimientos particulares puede
dañar la distribución de dichos servicios por que están distribuidos sobre el microkernel y esta
distribución no es soportada por el microkernel mismo. La razón es que las extensiones de
usuario pueden fallar en preservar las propiedades encontradas en el hardware distribuido y no
habrá una capa de bajo nivel para soportarlo. Si el microkernel está distribuido, extensiones
simples del sistema pueden beneficiarse de la distribución del sistema, pues la capa de bajo nivel
está distribuida. Este problema puede notarse por el hecho de que es necesario modificar o
reimplementar servicios existentes del sistema para agregar nuevos servicios distribuidos a un
sistema distribuido basado en un microkernel típico.
313
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
La implementación de tal interfaz requeriría resolver todos los contratiempos y anticipar todas
las formas en que la interfaz pueda usarse. La experiencia sugiere que tal anticipación no es
factible y que el costo de los errores es alto.
Un exokernel elimina la noción de que un sistema operativo debe proveer abstracciones sobre
las cuales las aplicaciones son construidas. Por el contrario, esta arquitectura solo se concentra
en el multiplexado seguro del hardware (raw hardware); así, a partir de las primitivas básicas de
hardware, librerías a nivel de aplicación y servidores, pueden implementarse directamente
abstracciones tradicionales de los sistemas operativos para mejorar la velocidad y desempeño.
Figura 8.23 Estructura de un sistema exokernel. Las aplicaciones usan sus propias
librerías de Sistema Operativo (Library Operating System (LibOS)) que a su vez usan el
exokernel para cargar y descargar recursos de hardware50
⊕
Obras consultadas: [8.25] [8.26] [8.58][8.59]
50
Imagen reproducida de [8.26]
314
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para comprender mejor esto, tomemos el ejemplo de un servidor Web. Un servicio de este tipo
se encuentra montado en un SO, el cual se encarga de brindar la conectividad a la red,
administrar la memoria y proveer un sistema de archivos para el almacenamiento secundario;
nada nuevo.
El problema es que el SO hace más trabajo del necesario: maneja desde el protocolo TCP y
todas sus abstracciones superiores hasta el protocolo HTTP, puede estar compartiendo recursos,
etc., lo cual disminuye el rendimiento de nuestra aplicación.
Figura 8.25 El solicitar una página HTML desencadena una serie de procesos que el SO
tiene que hacer para darle el soporte a la aplicación, lo cual no necesariamente puede
ser óptimo52. En el segundo diagrama pueden apreciarse las dependencias del sistema de
administración de memoria de Linux.
51
Imagen reproducida de [8.58]
52
Imagen reproducida de [8.58]
315
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Figura 8.26 El exokernel provee la protección del hardware y las librerías de aplicación,
pero el control lo tiene la aplicación, lo que elimina procesos que el servidor Web no
necesita53
Así, en esta arquitectura los servicios de administración de memoria, sistemas de archivos, etc.
se encuentran en librerías de aplicación (libOS) El escenario ideal de este enfoque es que las
librerías sean tan poderosas y tengan los mismos privilegios de un SO, además de permitir
innovar más rápidamente al no ser un esquema restrictivo (en los aspectos de los privilegios
necesarios para modificar un SO o de causar daños, lo que reduce costos).
Figura 8.27 Un sistema de exokernel simplificado con dos aplicaciones, cada una ligada
con su propia libOS y compartiendo páginas por medio de un registro54
53
Imagen reproducida de [8.58]
54
Imagen reproducida de [8.25]
316
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los paradigmas de comunicación basados en agentes han mostrado un enorme potencial para
operar en ambientes impredecibles y metamórficos, como las redes de cómputo móviles.
Un ejemplo de tareas distribuidas de alto nivel que pueden ser realizadas por agentes es el
procesamiento de transacciones electrónicas. Varias autoridades pude que necesiten ser
contactadas antes de que la transacción sea completada. Por ejemplo, para comprar un producto
de software de forma electrónica, se necesita obtener la verificación del número de tarjeta de
crédito del usuario, el número de la cuenta del usuario y del proveedor, y entregar el producto al
usuario. Tales tareas requieren una serie de operaciones de lectura y escritura en varios nodos.
Los agentes muestran características que son adecuadas para ambientes de red móviles en
áreas amplias:
1. Movilidad: el cómputo móvil muestra una naturaleza transitoria (p.ej. la localización de
los hosts cambia constantemente, y las transacciones pasan por varios nodos y tienen
una vida corta). La habilidad de los agentes para transportar código y datos a través de
los nodos de una red se ajusta muy bien a un ambiente transitorio.
2. Flexibilidad: los algoritmos de los agentes pueden ser modificados dinámicamente de
acuerdo a condiciones ambientales pertinentes (p.ej. congestión en la red, fallo de un
nodo y movilidad del usuario).
⊕
Obras consultadas: [8.28]
317
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Con un sistema lleno de agentes, incluyendo agentes del sistema (las funciones del sistema,
como la administración de recursos, pueden realizarse con agentes), aplicación y usuario, es
necesario un ambiente operativo para administrar dichos agentes; por ello es necesario un
sistema operativo para agentes. Cuando un agente de usuario, aplicación o sistema necesita
realizar una tarea, genera y envía agentes móviles para contactar otros agentes; así que los
protocolos de base son parcialmente generados por agentes.
318
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
8.13 Comentarios
Tras exponer las principales arquitecturas de sistemas operativos, puede contarse con un
panorama más amplio de su desarrollo y una serie de ideas que pueden incorporarse a nuevos
desarrollos, no solo de sistemas operativos sino de sistemas de cómputo en general.
Además cada componente arquitectónico de los sistemas mostrados forma parte de una guía de
diseño de alto nivel (fig. 8.28) que puede aplicarse en los casos como el análisis de un sistema
existente o la propuesta de uno nuevo, en conjunción con los criterios de diseño expuestos en el
capítulo anterior.
En el caso de analizar un sistema existente, puede decirse que Linux es un sistema con
arquitectura monolítica, pero que a su vez tiene una organización en capas, que comparado con
el MS-DOS lo hace muy seguro.
319
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
320
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[8.12] Operating System Architecture. Michael Lynch. [8.22] Adaptive Distributed Computing. Ray Ozzie The
1999 future of software. Winter 2000.
http://www.futureofsoftware.net/ro0010/ro0010.asp
321
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[8.23] Operating System Services For Wide Area [8.35] Conceptual Architecture of the Linux Kernel. Ivan
Applications,'' Amin Vahdat. November 1998. Bowman (ibowman@sybase.com) January 1998
PhD Dissertation, Department of Computer Science, http://plg.uwaterloo.ca/~itbowman/CS746G/a1/
University of California, Berkeley
http://www.cs.duke.edu/~vahdat/ps/thesis.pdf
[8.36] Concrete Architecture of the Linux Kernel. Ivan
Bowman (ibowman@sybase.com), Saheem Siddiqi
[8.24] WebOS: Operating System Services for Wide (s4siddiqi@neumann), Meyer C. Tanuan
Area Applications (mtanuan@descartes.com). Department of Computer
http://www.cs.duke.edu/ari/issg/webos/ Science, University of Waterloo. Winter 1998
http://plg.uwaterloo.ca/~itbowman/CS746G/a2
[8.25] Exokernels (or, making the operating system just
another application library) [8.37] Real-Time Mach OS. Real-Time and Multimedia
http://amsterdam.lcs.mit.edu/exo/exo-slides/index.htm Laboratory in the Department of Computer Science at
Carnegie Mellon University
http://www-2.cs.cmu.edu/afs/cs/project/art-6/www/
[8.26] The exokernel operating system architecture
Dawson R. Engler PhD CSE Thesis MIT 1998
[8.38] MACH - An example of a Distributed Operating
System . Ken Kellow
[8.27] Architectural Styles, Design Patterns and
http://www.rit.edu/~kjk2135/MACH.html
Objects. Robert T. Monroe, Andrew Kompanek, Ralph
Melton, and David Garlan
IEEE Software, January 1997, pp. 43-52. [8.39] Resource Kernel and Services. Raj Rajkumar
http://pecan.srv.cs.cmu.edu/afs/cs/project/able/www/p http://www-2.cs.cmu.edu/afs/cs/project/art-
aper_abstracts/ObjPatternsArch-ieee.html 6/www/Overview97/index.htm
322
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
[8.52] HISTORY OF APPLE™ MACINTOSH™ [8.59] Exokernel: an operating system architecture for
OPERATING SYSTEM application-level resource management. Dawson R.
http://perso.club-internet.fr/jctrotot/Perso/History.html Engler, M. Frans Kaashoek and James O’Toole Jr.
M.I.T. Laboratory for Computer Science. 1995.
[8.53] SciNet - ISTP Perceptual OS http://citeseer.nj.nec.com/engler95exokernel.html
http://www.scinet-
corp.com/associates/index.htm?rsi.htm~index2
323
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
324
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
a. Resultados
Haber integrado las referencias teóricas relativas a los sistemas operativos, ha conformado una
interesante lista de requerimientos para la comprensión y el desarrollo de un sistema operativo.
Así se cuenta con modelos que permiten analizar un sistema operativo a diferentes niveles de
codificación:
• en lenguaje ensamblador o lenguaje de máquina (todo dependerá de la implementación del
modelo de instrucciones y su representación e interpretación en la memoria)
• en un lenguaje de alto nivel orientado a objetos como lo es Java , tomando en cuenta la
consideración presentada en el modelo del simulador, donde parte de la implementación de
alto nivel del simulador pareciera estar ya cargada en memoria, y puede interactuar con los
elementos de hardware simulado.
325
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Como IDE se uso la herramienta llamada BlueJ (hecha en Java), la cual en efecto provee un
ambiente integrado de edición de diagramas de clases (UML) y el desarrollo en Java. BlueJ no
solo se convirtió en una herramienta de desarrollo, sino en una excelente plataforma de pruebas
para los diversos prototipos y modelos desarrollados en este trabajo, por lo que de alguna
manera BlueJ forma parte integral de los simuladores implementados.
Elegir BlueJ como herramienta de trabajo, resultó ser un gran auxiliar en el diseño, pruebas y
depuración de todo el modelo de simulación. Incluso, ejecutando los simuladores sobre esta
herramienta, las capacidades del simulador se incrementan notablemente (es posible explorar
valores de instancias del simulador, a tiempo de ejecución del mismo).
Al diseñar un sistema, muchos elementos pequeños tienden a ser incrustados en clases que
aunque extienden su alcance, encapsulan detalles importantes del modelo. Por ejemplo, en el
caso del despachador del SO, en cualquier implementación puede encontrarse simplemente como
una función más en el kernel, cuando es en sí un objeto con una tarea específica dentro del
sistema. Por ello, el detalle de las referencias teóricas permitió modelar partes que por lo general
hay que buscar entre líneas, y que incluso a veces forman parte de componentes más complejos.
Esto permitió además disminuir la cohesión entre objetos del sistema, pues en casos donde las
llamadas a métodos implicaba una alta dependencia de los objetos e impedía que los modelos
pudieran modificarse con facilidad, esto permitió adoptar estrategias como modelado orientado a
eventos o protocolos y manejadores de mensajes que mejoraron la funcionalidad del sistema. El
uso de patrones permitió un diseño más claro, potente y con una mínima cohesión entre los
objetos que lo componen.
Aunque los modelos no son interactivos (no cuentan con una GUI, la implementación de los
modelos es lo que cuenta) es posible aprender de la implementación en sí. Un punto a resaltar es
la estrecha relación entre el hardware y software modelado. Puede no ser muy claro hacer un
sistema operativo si no se tiene hardware. Tal vez podrá implementarse un intérprete de
comandos, un shell o un complejo GUI, pero ese sería otro terreno. Ya sea para su
implementación de facto o para su simulación, debe contarse con un conocimiento sólido en
cuestiones de hardware.
b. Aportaciones
• Investigación y desarrollo del tema de simulación de los sistemas operativos. Este es un tema
poco tratado, pero del cuál existen muchos trabajos que permiten el acercamiento al área de
los sistemas operativos, en formas como:
• la mejor comprensión del funcionamiento interno del sistema,
• la integración de los diversos componentes del SO,
326
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Complementar toda la teoría acerca de los sistemas operativos, con modelos de programación,
proveen a este trabajo de un enfoque práctico que bien podrá ser aprovechado por estudiantes
de licenciaturas y postgrados en computación, para poder involucrarse en el desarrollo de estos
sistemas. También puede mencionarse que el cúmulo de referencias reunidas durante el
desarrollo de este trabajo, permitirán a los interesados consultar fuentes muy variadas y
especializadas en el tema.
En relación al desarrollo simuladores con interfaces gráficas, los alumnos del periodo 2003-1
hicieron algunos avances, presentando alternativas interesantes en relación a la visualización del
comportamiento de los modelos de simulación.
55
El paradigma de la programación visual. E.J. Hernández Valdelamar y H. Uribe. Consulte [G20]
327
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Será deseable el uso de estas herramientas en cursos futuros para reafirmar los conceptos
teóricos de la materia (y que mejor que se haga con productos hechos en la FAR).
c. Conclusiones
Desde los primeros días de las computadoras modernas, la tecnología del hardware ha
progresado más rápido que el software que la acompaña. Por ejemplo, existen computadoras
que poseen un hardware con un funcionamiento veloz e increíble, pero el software (en específico
el sistema operativo) que estas máquinas poseen es tan pobre que son extremadamente difíciles
328
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Es por lo anterior que la industria del software debe ahora dedicar más tiempo y recursos para
el desarrollo. Una vez que la tecnología del software alcance el nivel de la tecnología del
hardware, los sistemas serán no sólo más prácticos, sino que utilizarán sus recursos de hardware
mucho más eficientemente.
Comprender a los sistemas operativos permite usar a la computadora de manera más efectiva,
además de ser un excelente ejemplo de consideraciones en el diseño de sistemas cuyos
resultados e ideas se aplican en otros campos. Un desarrollador que no ha estado en contacto
con proyectos grandes y complejos, tratará de solucionar el problema que se le presente de una
forma simple. Sin embargo, la misma aplicación puede tener implicaciones en el corto, mediano y
largo plazo; digamos al integrarse con otros sistemas o tratar de que la solución sea más amplia.
Ideas como aislar la configuración del software, modularizar los componentes de software, usar
protocolos estándares, etc., de alguna manera son herencia del desarrollo de sistemas
operativos. Por eso considero que un conocimiento integral del hardware y el software de base
permiten un mejor diseño e implementación de sistemas de alto nivel.
Una tendencia adicional esta vinculada a los sistemas distribuidos. En este escenario ya no solo
se requiere de software de base para un hardware específico, una interfaz de usuario amigable y
software de aplicación, sino que se requiere una infraestructura compleja de servicios en línea
que permitan explotar los recursos de todas las computadoras en red. Esto implica crear
abstracciones de alto nivel que aprovechen los recursos de los sistemas operativos locales. Hay
muchos proyectos de este tipo en desarrollo, por lo que hay que estar atentos de sus resultados.
329
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Cabe mencionar que para los desarrolladors de estos sistemas será necesario contar con una
amplia gama de conocimientos de técnicas de programación como el manejo de dispositivos a
bajo nivel, concurrencia, hilos, comunicación en redes, etc. , asi como de análisis y diseño de
software.
d. Perspectivas⊕
Por último solo queda establecer qué hay por hacer en el futuro.
Hay algunos temas que vale la pena desarrollar en relación a los sistemas operativos, entre
ellos:
⊕
Referencias: [9.1] [9.3]
330
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Tratar estos temas daría una perspectiva mucho más amplia de todo lo que debe tomarse en
cuenta para el desarrollo de futuros sistemas operativos.
Tambien me gustaría saber que es lo que hay detrás de la siguiente afirmación: "Alan Turing
proved that any OS can be ported to any computer architecture" [9.1]. Sería muy interesante
saber de donde salió esto, pues busque en algunos sitios dedicados a Turing, y no encontré
referencia alguna. De esto podría derivarse una metodología para portar sistemas ya existentes,
o unificar capacidades de diversos sistemas. En fin, es de las pocas dudas inducidas que dejare
pendientes.
Un punto para reflexionar es la automatización de las tares relacionadas con las computadoras.
Como se mencionó desde el primer capítulo, el operador experto encargado de alimentar a la
computadora on programas y datos, fue el primero en ser reemplazado. Durante la historia de la
computación, este mismo fenómeno se ha repetido en pro de la eficiencia de las organizaciones;
sistemas financieros, de manufactura y administrativos, han ido poco a poco desplazando a los
grupos de trabajo que realizaban las tareas ahora automatizadas, reduciendo su tamaño o
desapareciendolos definitivamente. Pero tambien aquellos que hacen los sistemas pagan un
precio: los nuevos sistemas configurables, multiplataforma y con estándares que permiten
integrarlos fácilmente con otros sistemas, requieren de menos programadores para su
mantenimiento o expansión, asi que ¿el futuro qué nos depara?
Por lo demás, me parece que hay muchas líneas de investigación que pueden desarrollarse y
actividades académicas que hacer. Sobre las líneas del trabajo que pueden ser exploradas, las
siguientes son interesantes:
• el modelo de procesador que puede ejecutar varios modelos de conjuntos de instrucciones,
puede ser ampliado con más conjuntos y probar si es posible ejecutar programas escritos en
diferentes ensambladores en un mismo ambiente, o incluso si es posible que un programa
contenga instrucciones de diversos conjuntos.
• implementar nuevos servicios de administración de los servicios expuestos (procesos,
memoria, dispositivos, etc.)
• implementar configuraciones distribuidas o puramente orientadas a objetos del sistema
operativo.
• generar distribuciones funcionales de las configuraciones implementadas en el simulador
• incurrir en el estudio de TSIAs, un nuevo soporte de ejecución que sirve como optimización
del sistema operativo y los compiladores.
• aplicar los conocimientos relacionados a los sistemas operativos en otras áreas. Por ejemplo,
el tipo de trabajo que realizarán el hardware y software de la quinta generación no solo en el
tratamiento de datos, sino en la adquisición de información y, a partir de los materiales y
estructuras de que dispone, en la elaboración de conocimientos, es decir, en la elaboración
inteligente del saber. Es decir se anuncia el aprovechamiento de la computadora para
adquirir conocimientos artificialmente, a través de las máquinas. A partir de esto, estas ya no
331
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
solo aportarán fuerza o habilidad, sino que también proveerán al hombre de un conocimiento
del mundo. ¿cómo será el sistema operativo de una de estas máquinas?
e. Referencias
[9.3] Burkhard D. Burow. DRAFT : Task System and Item Architecture (TSIA), March 1999.
http://www.tsia.org
332
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Bibliografía
[G1] Operating Systems concepts. Steve Ciarcia.
A. Silberschatz, J. Peterson, P. Galvin. Byte books/ McGraw-Hill. 1981.
Addison Wesley. 1991.
ISBN 0-201-54873-9 [G12] An Operating Systems Vade Mecum
Raphael A. Finkel.University of Wisconsin at Madison
[G2] Computer systems Prentice Hall
J. Stanley Warfold
Jones & Bartlett. 1999. [G13] Conceptos de sistemas operativos.
ISBN 0-7637-0794-5 José Torres Jiménez. Trillas.
ISBN 968-24-5959-1
[G3] Sistemas operativos. Diseño e implementación.
Andrew S. Tanenbaum. [G14] El proceso unificado de desarrollo de software
Prentice-Hall. 1988. Ivar Jacobson, Graidy Booch & James Rumbaugh
ISBN 968-880-153-4 Addison Wesley, 2000
ISBN 84-7829-036-2
[G4] Sistemas operativos. Conceptos y diseño.
Milan Milenkovic. McGraw-Hill. 1987. [G15] Inside Microsoft Windows CE
ISBN 0-07-041920-5 John Murray
Microsoft press. 1998.
[G5] Trends in operating system design. ISBN 1-57231-854-6
Peter D. Varhol.
Dr. Dobb's Journal, May 1994. [G16] Operating systems. A systematic view.
William S. Davis
[G6] RTMK: A real-time microkernel. Addison-Wesley publishing Co. 1987.
J.F. Bortolotti, P. Bernard and E. Bouchet. ISBN 0-201-11185-3
Dr. Dobb's Journal, May 1994.
[G17] Computer organization & design. The
[G7] MMURTL: Your own 32-bit operating system. hardware/software interface.
Richard Burgess. David A. Patterson & John L. Hennessy
Dr. Dobb's Journal, May 1994. Morgan Kaufmann Publishers. 1998.
ISBN 1-55860-428-6
[G8] Fundamentals of operating systems.
A. M. Lister. [G18] Introducción a la computación.
MacMillan Publishers. 1984. Jorge Vasconcelos Santillán.
ISBN 0-333-37097-X Publicaciones Patria Cultural. 1999.
ISBN 9684398735
[G9] Operating systems theory.
Edward G. Coffman Jr., Peter J. Denning. [G19] Diseño de un sistema de multiprogramación CPU.
Prentice-Hall. 1973. Héctor Bolívar Olmos Ramirez, Héctor Ruiz Barradas.
ISBN 0-13-637868-4 Universidad Autónoma Metropolitana – Azcapotzalco.
2000. ISBN 970-654-677-4
[G10] Distributed operating systems: The logical
design. [G20] Avances en informática y computación
A. Goscinski. Addison-Wesley. 1991. Editores: Juan Humberto Sossa Azuela, María de
ISBN 0-201-41704-9 Lourdes Sánchez Guerrero.
XV CONGRESO NACIONAL Y I CONGRESO
INTERNACIONAL DE INFORMÁTICA Y COMPUTACIÓN
[G11] Construya una microcomputadora basado en el
Z80. pp. 371-380. Octubre, 2002.
333
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
334
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Glosario
Algoritmo . El término algoritmo es un procedimiento o fórmula para resolver un problema. La
palabra se deriva del nombre del matemático árabe Al-Juarismi (825 DC). Un programa de
ordenador puede considerarse como un algoritmo elaborado. En matemáticas o ciencia
informática, un algoritmo generalmente es un pequeño procedimiento que resuelve un problema
recurrente.
BIOS . Basic Input Output System o Sistema Básico de Entrada y Salida. Pequeño programa que
controla las funciones más básicas de una computadora, se encarga entre otras cosas de bajar el
sistema operativo del disco duro hacia la memoria RAM y pasarle el control de la computadora a
este último. Se encuentra en la memoria ROM.
335
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
BUG . Literalmente significa bicho o insecto. En computación se refiere a alguna falla o defecto
de programación en la forma como debe operar una computadora con ciertas instrucciones, a
veces se presenta solo en determinadas circunstancias.
336
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Dirección . Un nombre, un número o una etiqueta que designa una posición particular en el
almacenamiento primario o secundario. Un identificador de localización para nodos en una red de
computadoras.
Emulación . Característica que permite a un dispositivo funcionar como si fuera otro distinto,
interoperando con otra PC. Por ejemplo, las PCs pueden emular el funcionamiento de
determinadas terminales que se conectan a mainframes y que funcionan de forma totalmente
diferente.
EEPROM . Electrically Erasable Programmable Read Only Memory. Chip de memoria que puede
ser borrado y sobre el que se puede escribir, pero que no pierde su contenido cuando no recibe
corriente. Se le llama ROM porque grabarle datos es mucho más tardado que con el RAM. Estos
chips pueden ser encontrados en los BIOS de módems y algunos otros dispositivos.
FAT . File Allocation Table. Tabla de Asignación de Archivos. Es un archivo situado en el sector 0
del disco duro con información de todos los archivos almacenados (localización, tamaño, etc.).
Internet . Es una red global que conecta millones de computadoras. En 1999, los usuarios
conectados a Internet se estimaban en más de 200 millones y este número está creciendo muy
rápidamente. A diferencia de otro tipo de servicios, controlados centralmente, Internet se
337
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
encuentra descentralizada por diseño. Cada computadora conectada a Internet (se denominan
hosts) es independiente. Sus operadores eligen qué servicios de Internet utilizar y qué servicios
locales hacer disponibles a la comunidad global. Sorprendentemente, esta anarquía por diseño
funciona extraordinariamente bien.
Intranet . Es una red basada en el protocolo TCP/IP, que pertenece a una organización,
normalmente una corporación, accesible únicamente para aquellos miembros de la organización,
empleados u otros con autorización para hacerlo. Los sitios de la Intranet lucen y funcionan como
cualquier otro sitio, pero un Firewall, rodeando la Intranet, la defiende de accesos no
autorizados. Al igual que Internet, una Intranet es utilizada para compartir información. Las
Intranets seguras son el segmento de Internet que está creciendo con mayor rapidez, ya que son
menos costosas de construir y mantener que las redes privadas.
NTFS . Sistema de archivos utilizado por Windows NT. Tiene la capacidad de recuperar datos
tras fallas del disco duro, puede utilizar nombres largos e los archivos, utiliza la tabla de código
Unicode pero debido a su complejidad no puede accesarse desde MS-DOS o Windows 3.x ó 9x.
338
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Red . Dos o más computadoras conectadas entre sí, permitiendo a sus usuarios compartir
archivos y recursos.
Registro del Sistema . Archivos que contienen información acerca del funcionamiento general
del equipo. Al registro es donde acude el sistema Windows cuando necesita saber alguna cosa
sobre el hardware y el software del equipo, así como sobre otros aspectos relacionados con la
configuración del sistema.
SDK . Software Development Kit. Conjunto de herramientas que facilitan el trabajo del
programador al escribir nuevas aplicaciones. Comúnmente está formado por iconos menús,
cuadros de diálogo, y todo aquello que permita que la interfaz de la nueva aplicación sea lo más
parecida posible al sistema operativo en el que se vaya a ejecutar.
Shell . Es un tipo de utilidad cuya finalidad consiste en hacer más fácil el manejo del sistema
operativo o de una aplicación por parte del usuario.
339
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
operativo para correr otros programas. Algunos de los sistemas operativos más comunes son
Windows, MS-DOS, MacOS, Linux, y Solaris.
Software . Los programas que se usan para dirigir las funciones de un sistema de computo.
X Window . Sistema desarrollado en el MIT que permite a los usuarios de UNIX correr
programas en otras máquinas pero manejando todo desde su propio monitor.
340
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Apéndices
El BIOS carga el sector de arranque en el desplazamiento lineal (linear offset) 0x7C00, y los
estados de los registros son:
56
Referencias:
(1)How It Works -- Master Boot Record. Version 1a. by Hale Landis
http://www.nondot.org/sabre/os/files/Booting/mbr.txt
(2) "Making plain binary files using a C compiler" by Cornelis Frank
http://www.nondot.org/sabre/os/files/Booting/CompilingBinaryFilesUsingACompiler.pdf
(3) Daniels NASM bootstrap tutorial - by Daniel Marjamäki
http://www.nondot.org/sabre/os/files/Booting/nasmBoot.txt
(4) Das Boot -- H. Gilbert
http://pclt.cis.yale.edu/pclt/BOOT/DEFAULT.HTM
(5) WRITING A BOOTSECTOR Jeff Weeks and Code X software. (c)1997
http://www.nondot.org/sabre/os/files/Booting/PolyOS.html
(6) My Experiences with the Boot Sector. Chris Lattner. 1994-8.
http://www.nondot.org/sabre/os/files/Booting/MyBootSector.html
(7) Bootsector authoring by Gareth Owen.
http://www.nondot.org/sabre/os/files/Booting/gbootsect.txt
341
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Así que en lugar de agregar una instrucción [ORG 7C00h] al principio del archivo, puede
agregarse:
lo que inicializará los registros de segmento para que apunten al inicio del sector de arranque.
La mayoría de los sectores de arranque, solo almacenan la unidad de arranque, cargan el kernel
del disco y saltan a él para comenzar la ejecución.
- Debe ser un archivo binario plano (sin redirecciones; ej. formato COM).
- El tamaño debe ser de 512 bytes.
- Losa últimos dos bytes deben ser 0AA55h
- Es cargado en la dirección de memoria 0x7C00.
Para generar el código ejecutable de los ejemplos aquí presentados use el ensamblador NASM
(gratuito) y la utilería de transferencia PartCopy.
hang:
jmp hang
times 512-($-$$)-2 db 0
dw 0AA55h
bits 16
org 0x7C00
start:
cli ; Disable interrupts
342
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
l1:
push ds
mov dl, 0 ; Reset disk controller
mov ax, 0
int 13h
pop ds
jc fail
push es
pop es
jc l1
fail:
jmp fail
times 512-($-$$)-2 db 0
dw 0AA55h
343
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
mov ds, ax
mov es, ax
putstr:
lodsb
or al,al
jz short putstrd
mov ah,0x0E
mov bx,0x0007
int 0x10
jmp putstr
putstrd:
retn
msg db 'JIPPIKAYE!',13,10,0
Por último, aquí esta el código para escribir el sector de arranque en un disco flexible (ha sido
compilado con el DJGPP para DOS).
#include <bios.h>
#include <stdio.h>
void main() {
FILE *in;
unsigned char buffer[520];
344
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Adicionalmente, he aquí otro caso más: un mini-kernel (muy similar al programa anterior), por
si alguien quiere seguir haciendo pruebas
[SEGMENT .text]
mov ax, 0x0100 ;location where kernel is
loaded
mov ds, ax
mov es, ax
cli
mov ss, ax ;stack segment
mov sp, 0xFFFF ;stack pointer at 64k limit
sti
_disp_str:
lodsb ; load next character
or al, al ; test for NUL character
jz .DONE
mov ah, 0x0E ; BIOS teletype
mov bh, 0x00 ; display page 0
mov bl, 0x07 ; text attribute
int 0x10 ; invoke BIOS
jmp _disp_str
.DONE:
ret
[SEGMENT .data]
strWelcomeMsg db "Welcome to JOSH!", 0x00
[SEGMENT .bss]
345
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Los conceptos en los que se baso este primer intento de simulación de un SO, se encuentran en
los capítulos 1 y 2. Los principales elementos modelados son los siguientes:
TestSimulator
/** Aplicación de prueba que integra todos los elementos del modelo.
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version 2001 (0.4)
*/
import java.io.*;
import java.util.*;
public TestSimulator() {
}
Registers
/** Operaciones con los registros del procesador
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version 2001
*/
346
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
import java.io.*;
import java.util.*;
interface Registers {
URMRegisters
/** Registros específicos del modelo URM
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version 2001
*/
import java.io.*;
import java.util.*;
public URMRegisters(){
this(5);
}
347
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
aRegisters[i]=0;
}
Processor
/** Interfaz de métodos para un procesador
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version 2001
*/
import java.io.*;
import java.util.*;
interface Processor {
/**
ciclo de "fetch" donde la instrucción a ejecutarse se trae
de memoria primaria y se coloca en el IR
El ciclo de Fetch
-Va al PC
-Va a la dirección que apunta el PC
-Hace IR = MEM[PC]
-Incrementa PC
*/
public void fetchInstruction(Memory m);
El ciclo de Ejecución
-Si tiene que ir a Memoria
-va a Memoria
-ejecuta instrucción
-almacena resultados.
*/
public void execInstruction();
348
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
URMProcessor
/** Procesador URM.
* Implementa la interfaz Processor
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version Marzo, 2001
*/
import java.io.*;
import java.util.*;
Registers urmRegs;
ALU urmALU;
int pc; //Program counter
String ir; //Instruction Register
//(donde se coloca la instrucción a ser decodificada por el CU)
boolean stop; // : boolean;
public URMProcessor () {
urmRegs=new URMRegisters();
urmALU=new ALU();
this.setPC(0);
stop=false;
}
349
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
private void J (int r1, int r2, int ins) { //; {Salto}
if (urmRegs.getReg(r2)==urmRegs.getReg(r1))
pc=ins;
}
//--------------------------------------------------------------
350
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
urmRegs=regs;
}
}
ALU
/**
* ALU para el procesador. Contiene las operaciones lógicas y aritméticas.
*
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version March, 2001
*/
public ALU() {
}
351
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
}
}
Memory
/** Interfaz para operaciones de una memoria
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version Marzo, 2001
*/
import java.io.*;
import java.util.*;
interface Memory {
public void setMemLoc(int adr, Object value);
public Object getMemLoc(int adr);
public void showMem();
}
URMMemory
/** Implementación de las operacione de memoria para el modelo URM
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version Marzo, 2001
*/
import java.io.*;
import java.util.*;
String mem[];
int memSize;
public URMMemory () {
this(10);
}
352
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
}
}
Monitor
/**
Monitor es la clase encargada de cargar un programa o un conjunto de programas en memoria
para luego ejecutarlos.
Este sería el equivalente a uno de los primeros sistemas operativos (se esta
automatizando la carga y ejecución de programas)
import java.io.*;
import java.util.*;
class Monitor {
Processor lp;
Memory lm;
JCLInterpreter jclinterp;
Loader
/**
Cargador de programas. El programa indicado por el nombre de
un archivo lo carga en memoria para su ejecución.
import java.io.*;
import java.util.*;
353
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
class Loader {
int startAdress;
Memory lm;
public Loader(Memory m) {
lm=m;
this.setStartAdress(0);
//debe quedar después del bloque que ocupa el SO
System.out.println("Iniciando cargador de programa....");
}
int c;
StringBuffer sline=new StringBuffer();
catch (FileNotFoundException e)
{
System.out.println(e.getMessage());
}
catch (IOException e)
{
System.out.println(e.getMessage());
}
}
/**
Carga una instrucción del archivo a memoria
*/
private void loadInstruction(String sline) {
354
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
lm.setMemLoc(startAdress++,sline);
System.out.println(sline);
}
}
JCLInterpreter
/**
* El interprete de Lenguaje de Control de Trabajos (JCL), es un programa
* que acepta instrucciones del usuario, y procesa cada una de forma
* secuencial, realizando la tarea indicada.
* El JCL propuesto es el siguiente:
*
* LOAD - carga un programa
* RUN - ejecuta un programa
* EOJ - Fin del trabajo (End Of Job)
* LDBATCH - Carga un archivo con comandos para procesarlos en lote
* SHUTDOWN - Apaga el SO
*
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version 2001 (0.4)
*/
import java.util.*;
/**
* Constructor
*/
public JCLInterpreter(Processor p, Memory m, Loader ld) {
lp=p;
lm=m;
loader=ld;
}
/**
Procesamiento de instrucciones del JCL
*/
public void doCommands(String sCommandLine) {
StringTokenizer stok= new StringTokenizer(sCommandLine);
System.out.println("Instrucción JCL:" + sCommandLine);
String scom=stok.nextToken();
if (scom.equals("LOAD")){
System.out.println("Cargando programa....");
this.doLoad(stok.nextToken());
return;
}
if (scom.equals("RUN")){
355
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
System.out.println("Ejecutando programa....");
this.doRun();
return;
}
if (scom.equals("SHUTDOWN")){
this.doShutDown();
return;
}
}
/**
El monitor recibe la orden de cargar un programa, y cede el
control al cargador para que lo haga.
*/
public void doLoad(String fSource) {
loader.setStartAdress(0);
loader.loadProgram(fSource);
}
/**
Ejecutar un programa previamente cargado en memoria
*/
public void doRun() {
lp.start(lm);
}
/**
Carga un conjunto de programas para que se ejecuten. Incluye el concepto
de PCL (Process Control Language) para el procesamiento en batch
*/
public void doBatch(String jobsFile) {
//this.loadProgram();
//this.execute();
}
}
356
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
• SimulationController.java
• ProgramGenerator.java
• Program.java
• Manager.java
• MainMemory.java
• Table.java
• DynamicPartitionTable.java
• FixedPartitionTable.java
• PRegister.java
• FPRegister.java
• DPRegister.java
Para ejecutar el simulador, se integran los archivos con la herramienta BlueJ en un proyecto, y
se crea una instancia de la clase SimulationController(pasando un parámetro numerico para
elegir el tipo de particiones a simular). Para iniciar la simulación debe accederse al método
simulate(), tantas veces como ciclos de simulación se deseen.
SimulationController
/**
* class SimulationController.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
import java.util.*;
/**
* Constructor
357
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
*/
public SimulationController(int m) {
//m=1 particiones fijas ; m=2 , dinámicas
modo=m;
pgen= new ProgramGenerator();
memman= new Manager(modo);
programs= new ArrayList();
}
/**
Ciclo de Simulación
*/
public void simulate() {
int i=3;
Random r= new Random();
ciclos++;
System.out.println("Ciclo de simulación: "+ ciclos + "---------------");
//se genera un programa de forma aleatoria
if (r.nextInt(4)==2) {
System.out.println("Programas generados: "+ (pos+1));
programs.add(pgen.generate());
memman.allocate((Program)programs.get(pos++));
}
//se ejecutan todos los programas en memoria
this.executePrograms(programs);
this.deallocation(programs);
memman.show();
/**
se simula la ejecución de los programas cargados en memoria
*/
private void executePrograms(List ps) {
Program p;
if (ps!=null)
for (Iterator i=ps.iterator();i.hasNext();) {
p=(Program)i.next();
if (p.isLoaded())
p.run();
}
}
/**
si alguno de los programas ha terminado de ejecutarse se
quita de la memoria y se limpia la tabla de asignaciones
*/
private void deallocation(List ps) {
Program p;
if (ps!=null)
for (Iterator i=ps.iterator();i.hasNext();) {
p=(Program)i.next();
if (p.isAlive()==false) {
358
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
memman.deallocate(p);
}
}
}
}
ProgramGenerator
/**
* class ProgramGenerator.
* Generador de datos relativos a los programas a cargar.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
import java.util.*;
/**
* Constructor
*/
public ProgramGenerator() {
idcounter=1;
}
Program
/**
* class Program.
* El programa que se llevará a memoria en el simulador
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
public class Program {
359
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/**
* Constructor
*/
public Program(int name, int psize, int msize, int time) {
id = name;
csize = psize;
xmsize = msize;
lifeTime=time;
}
/**
se determina si el programa está aun en ejecución
*/
public boolean isAlive() {
if (counter>lifeTime)
return false;
else
return true;
}
/**
se marca si el programa logró cargarse
*/
public void loadedOK() {
loaded=true;
}
/**
se determina si el programa está aun en ejecución
*/
public boolean isLoaded() {
return loaded;
}
360
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
11.3.3 Manager
/**
* class Manager.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
/**
* Constructor
*/
public Manager(int mode) {
mm = new MainMemory();
//particiones fijas
if (mode==1) {
table = new FixedPartitionTable();
int appStart=0;
initFixed(appStart);
}
if (mode==2) {
table = new DynamicPartitionTable(mm);
}
}
/**
inicialización de las particiones fijas
la distribución es de 3 pequeñas, 2 medianas
*/
public void initFixed(int startAdress) {
int adress=startAdress;
int size = mm.getSize();
System.out.println("Inicializando particiones...mem="+size);
table.add(adress, (size/3)/3);
adress+=(size/3)/3;
361
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
table.add(adress, (size/3)/3);
adress+=(size/3)/3;
table.add(adress, (size/3)/3);
adress+=(size/3)/3;
table.add(adress, size/3);
adress+=(size/3);
table.add(adress, size/3);
table.show();
}
/**
método para ejecutar el alojamiento en memoria de un programa
*/
public void allocate(Program p) {
//primero se trata de insertar la info. del programa en la tabla
if (table.insert(p.getId(), p.getSize())) {
//si es exitoso se marca el programa como cargado
p.loadedOK();
//se marca la memoria principal con el id del proceso cargado
int pHandler = table.getLastAdress();
int csize= p.getSize();
int id= p.getId();
for (int i=0; i<csize; i++)
mm.write(pHandler++,new Integer(id));
}
}
/**
método para ejecutar el desalojamiento en memoria de un programa
*/
public void deallocate(Program p) {
table.remove(p.getId());
}
MainMemory
/**
* class MainMemory.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
import java.util.*;
362
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/** Constructor */
public MainMemory() {
this(50);
}
/**
devuelve el tamaño de la memoria
*/
public int getSize() {
return this.memsize;
}
/**
devuelve cuantos elementos activos hay en la memoria
*/
public int getMemElements() {
return mem.size();
}
363
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Table
/**
* interface Table.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
DynamicPartitionTable
/**
* class DynamicPartitionTable.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
import java.util.*;
/**
* Constructor
*/
public DynamicPartitionTable(MainMemory mem) {
mm=mem;
ptable= new ArrayList();
}
/**
agrega un registro a la tabla
en este caso es una partición de tamaño variable
*/
public void add(int adress, int size) {
ptable.add(new DPRegister(adress, size));
364
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/**
registra un programa en la tabla de particiones
*/
public boolean insert(int id, int size) {
boolean assigned=false;
int adress= searchPartition(size);
//si hay espacio, crear la partición
if (adress!=-1)
this.add(adress, size);
/**
buscar un bloque del tamaño requerido para cargar el programa
y devuelve la dirección de inicio del bloque libre
*/
private int searchPartition(int size) {
//calcular a partir de los registros de la tabla que areas
//de la memoria están libres
int base=0; //dir. en memoria
int tidx=0; //indice de elementos de la tabla
System.out.println("searchp");
for (Iterator i=ptable.iterator(); i.hasNext();) {
DPRegister pr= (DPRegister)i.next();
tidx++;
int pa= pr.getStartAdress();
int pend= pa + pr.getPartitionSize();
//si la dir. base empata con una partición existente
//revisar el edo. de la partición, y si está ocupada
//asignar a la dir.base la dir. donde acaba el bloque
if ((base==pa)&&(pr.getPartitionStatus()!=0)) {
base=pend;
}
else {
//si no hay coincidencia, el espacio debe estar vacio
//pero hay que checar si hay una sig. partición
//y su dir. de inicio es mayor al espacio que se requiere
365
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
if (tidx<ptable.size()) {
pr= (DPRegister)i.next(); tidx++;
int paa= pr.getStartAdress();
if (pr.getStartAdress()>(base+size)) {
break;
}
}
}
}
if (mm.getSize()>(base+size)) {
lastUsedAdress=base;
return base;
}
else {
//no hay espacio disponible para crear la partición
System.out.println("(!) no hay espacio para crear la partición" +
mm.getSize() +"-"+ (base+size));
return -1;
}
}
/**
quita un programa y el registro de la partición
en la tabla de particiones
*/
public void remove(int id) {
for (Iterator i=ptable.iterator(); i.hasNext();) {
DPRegister fpr= (DPRegister)i.next();
//si el id del procesos es igual se libera la partición
if (fpr.getProcessId()==id) {
fpr.setProcessId(0);
fpr.setPartitionStatus(0);
//ptable.remove(ptable.indexOf(fpr));
break;
}
}
compactMem();
}
/**
puesto que si no hay mantenimiento en la tabla de particiones,
se comporta como la tabla de particiones fijas, se decició
agregar este método de optimización, encargado de compactar
los datos en memoria y actualizar la tabla de particiones
*/
public void compactMem() {
List newlst= new ArrayList();
int adress=0;
for (Iterator i=ptable.iterator(); i.hasNext();) {
366
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
adress=0;
//ahora hay que compactar los datos en la memoria
for (Iterator j=newlst.iterator(); j.hasNext();) {
DPRegister fpr= (DPRegister)j.next();
int csize= fpr.getPartitionSize();
int id= fpr.getProcessId();
for (int i=0; i<csize; i++)
mm.write(adress+i,new Integer(id));
adress += fpr.getPartitionSize();
}
ptable=newlst;
System.out.println("Compactación finalizada");
this.show();
mm.show();
}
/**
muestra el contenido de la tabla de asignaciones y sus registros
*/
public void show() {
System.out.println("Tabla de asignaciones de particiones dinámicas" );
for (Iterator i=ptable.iterator(); i.hasNext();) {
DPRegister fpr= (DPRegister)i.next();
fpr.show();
}
}
}
FixedPartitionTable
/**
* class FixedPartitionTable.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
import java.util.*;
367
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/** Constructor */
public FixedPartitionTable() {
ptable= new ArrayList();
lastUsedAdress=-1;
}
/**
agrega un registro a la tabla
en este caso es una partición de tamaño fijo
*/
public void add(int adress, int size) {
ptable.add(new FPRegister(adress, size));
}
/**
registra un programa en la tabla de particiones
*/
public boolean insert(int id, int size) {
boolean assigned=false;
//buscar en la tabla de particiones
for (Iterator i=ptable.iterator(); i.hasNext();) {
FPRegister fpr= (FPRegister)i.next();
//si el tamaño es adecuado y esta libre la partición
if ((size<=fpr.getPartitionSize()) &&
(fpr.getPartitionStatus()==0)) {
fpr.setProcessId(id);
fpr.setPartitionStatus(1);
assigned=true;
lastUsedAdress=fpr.getStartAdress();
break;
}
}
if (assigned==false) {
System.out.println("El programa "+id +" no pudo ser alojado");
}
return assigned;
}
368
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/**
muestra el contenido de la tabla de asignaciones y sus registros
*/
public void show() {
System.out.println("Tabla de asignaciones de particiones fijas" );
for (Iterator i=ptable.iterator(); i.hasNext();) {
FPRegister fpr= (FPRegister)i.next();
fpr.show();
}
}
}
PRegister
/**
* class PRegister.
*
* Registro de partición de memoria
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
/**
* Constructores
*/
public PRegister(int size) {
partitionSize=size;
partitionStatus=0;
processId=0;
}
369
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
FPRegister
/**
* class FPRegister.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
public class FPRegister extends Pregister {
/** Constructor */
public FPRegister() {
this(0);
}
370
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
DPRegister
/**
* class DPRegister.
*
* @author E.J. Hernández Valdelamar
* @version julio, 2002
*/
/** Constructores */
public DPRegister(int size) {
super(size);
}
371
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Para ejecutar el simulador, se integran los archivos con la herramienta BlueJ en un proyecto, y
se crea una instancia de la clase ProcessManager. Esto desplegará el estado inicial de la lista de
procesos (vacía; aunque el primer proceso es un proceso vacío en la posición 0). Adicionalmente
hay que crear algunos procesos para que se ejecuten en el simulador, llamando al método
createProcess(); y elegir la política de planificación a usar, invocando al método
makeFCFSSched() o al método makePrioritySched(). Para iniciar la simulación debe llamarse al
método run() lo que provocará la evaluación de los procesos durante 10 ciclos de simulación.
CPUnit
/** class CPUnit
*
El modelo del procesador.
import java.util.*;
372
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/** Constructor */
public CPUnit() {
regs = new ArrayList();
//asociando un timer
timer = new Timer();
}
373
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Timer
/** class Timer
*
Esta clase modela a un temporizador, un elemento de hardware que
puede ser programado para que cada determinado tiempo envíe señales
que permitan retomar el control al sistema operativo.
public Timer() {
}
374
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
ProcessManager
/**
* class ProcessManager .
*
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version 2001
*/
import java.util.*;
/** Constructor */
public ProcessManager() {
pid=0;
plist = new ProcessList();
plist.printState();
//plist.addPCB(new ProcessContext());
disp = new Dispatcher(plist);
disp.dispatchCPU(new CPUnit());
}
375
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
sched.relatedPList(plist);
}
/**
Para destruir un proceso se necesita su indice en
la lista de procesos.
Aqui, podría invocarse al adm. de memoria para que
se encargue de marcar el espacio ocupado por el programa
como libre, o hacer funciones de compactación.
*/
public void destroyProcess(int idx) {
//quitar el PCB del proceso de la lista
plist.removePCB(idx);
}
}
ProcessList
/**
* class ProcessList
*
Esta clase es un contenedor de Bloques de Control de Proceso (PCBs)
(aunque en el modelo la clase es ProcessContext).
import java.util.*;
/** Constructor */
public ProcessList() {
procs = new ArrayList();
376
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/**
* crea y agrega un proceso a la lista de procesos
* @param pcb el contexto de un proceso
**/
public void createPCB(int id, List regs) {
ProcessContext pcb=new ProcessContext(id,regs);
procs.add(pcb);
}
/**
* se agrega un proceso a la lista de procesos
* @param pcb el contexto de un proceso
**/
public void addPCB(Object pcb) {
procs.add(pcb);
}
/**
* se agrega un proceso a la lista de procesos
* @param pcb el contexto de un proceso
**/
public void removePCB(int idx) {
procs.remove(idx);
//procs.trimToSize();
}
/**
* se agrega un proceso a la lista de procesos
* @param index indice de la lista
**/
public Object getPCB(int index) {
return procs.get(index);
}
377
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
int idx=0;
ProcessContext
/**
* class ProcessContext
*
El contexto del proceso esta formado por la información
que los registros del procesador contienen al ejecutar un programa.
Para fines de diseño, puede modificarse esta clase para un PCB más
completo , o crear una subclase con dicho fin.
import java.util.*;
378
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/** Constructor */
public ProcessContext(int id, List regs) {
proc_id=id;
this.addRegs(regs);
}
public ProcessContext() {
proc_id=0;
}
Dispatcher
/**
* class Dispatcher
*
El despachador es el encargado de intercambiar el contexto del proceso
en ejecución, por un nuevo proceso a ejecutarse.
Para llevar a cabo esta función, debe asociarse una lista de procesos
al despachador para que pueda obtener el siguiente proceso.
379
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
* @version 2001
*/
/** Constructor */
public Dispatcher(ProcessList pl) {
plist=pl;
lastDispatchedId = -1; //ningun proceso despachado
}
/**
* Funcionamiento:
1. obtiene el contexto del proceso en ejecución
2. inserta el nuevo contexto en la lista de procesos, y cambia su estado
3. envia el contexto en espera de ejecución al procesador
para que se ejecute
*
* @param pcb contexto del proceso a ejecutar
*/
public void dispatch(ProcessContext pcb) {
/**
* Envia el contexto al procesador para ejecutar un nuevo proceso
*
* @param pcb contexto del proceso que estaba en el procesador
**/
private void sendContextToPList(ProcessContext pcb) {
System.out.println("From CPU to PList:"+pcb.getProcId());
plist.addPCB(pcb);
}
/**
380
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
return inExec;
}
/**
* envio del contexto de un proceso al procesador
*
* @param pcb contexto del proceso que estaba en espera y se va a ejecutar
**/
private void sendContextToCPU(ProcessContext pcb) {
//*en el caso del procesador, debe ejecutarse la instrucción que
//permite establecer los valores de los registros
localCPU.setProcId(pcb.getProcId());
localCPU.setProcPrior(pcb.getPriority());
localCPU.setRegisters(pcb.getRegs());
localCPU.setTimer(20);
localCPU.start();
}
}
ScheduleStrategy
/**
* abstract class ScheduleStrategy
*
* @author (Eugenio Jacobo Hernández Valdelamar)
* @version 2001
*/
ProcessList plist;
381
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
FCFSSchedule
/**
* class FCFSSchedule
*
Política First-Come, First-Served (FIFO) de planificación
/** Constructor */
public FCFSSchedule() {
//init(d);
System.out.println("FCFS Scheduler");
}
/**
* Se obtiene el primer elemento de la lista de procesos
* @param y a sample parameter for a method
*/
public Object scheduleProcess() {
return super.getProcess(0);
}
}
PrioritySchedule
/**
* class PrioritySchedule
*
Implementación de la planificación por prioridades.
Se elige al proceso en la lista de procesos preparados
con la mayor prioridad.
/** Constructor */
382
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
public PrioritySchedule() {
System.out.println("Process Priority Scheduler");
}
383
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
Como caso de estudio práctico, decidí incluir el código de la implementación del microkernel
RTMK (Real Time Micro-Kernel), basado en la especificación Screpte.
MANEJO DE TAREAS
State
SEÑALES
Send
Wait
Clear (reset)
Arrived
Hay que hacer notar que no se encuentran los servicios para realizar la exclusión mutua entre
los procesos (RTMK solo toma un subconjunto de la especificación para su implementación).
RTMKTYPE.H
RTMK.H
RTMK.C
TestRTMK.C
Cabe mencionar que existen librerías standart de C que simplifican la operación de cambio de
contexto (pues si no tendría que hacerse en ensamblador), en específico la librería setjmp.h, que
contiene las siguientes funciones:
57
Adaptado de [G6]
384
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
typedef struct {
unsigned j_sp, j_ss, unsigned j_flag, j_cs;
unsigned j_ip, j_bp;
unsigned j_di, j_es;
unsigned j_si, j_ds;
} jmp_buf[1];
Una llamada posterior a la función longjmp (setjmp siempre debe llamarse antes de longjmp)
con jmpb restaura el estado capturado de la tarea, y regresa de manera que setjmp regresa un
valor diferente de cero.
El estado de una tarea es lo suficientemente completo como para usar setjmp para implementar
corrutinas.
Una llamada a longjmp restaura el estado de la tarea capturado por la ultima llamada a setjmp
con el argumento jmpb. Entonces regresa de manera que parece que setjmp ha regresado con el
valor del parámetro retval.
/*
RTMKType.H
Definicion de la estructura del PCB de los procesos
Controlados por el kernel
*/
#include <setjmp.h>
385
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
struct PCS {
/* Contexto del microprocesador.*/
jmp_buf context;
/* Fin RTMKType.H */
/*
RTMK.H
Definicion de prototipos de funciones
*/
#include "rtmktype.h"
/* Fin RTMK.H */
/*
RTMK.C
Implementacion de los servicios del microkernel
*/
#include "rtmktype.h"
#include <dos.h>
#define NULL 0
#define PROCESS_STACK_SIZE 500 /*tama¤o del stack para cada proceso*/
386
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/*-------------------------------------------------------------*/
/*
create_process: declara el proceso donde p es el identificador
para el kernel y entry_point es la direccion del codigo del proceso.
*/
(pcs_tab[nbr_process].context)->j_sp=
(unsigned)stack+PROCESS_STACK_SIZE*(32-nbr_process);
(pcs_tab[nbr_process].context)->j_bp=
(pcs_tab[nbr_process].context)->j_sp;
(pcs_tab[nbr_process].context)->j_ds=FP_SEG((void far *)stack);
(pcs_tab[nbr_process].context)->j_ss=FP_SEG((void far *)stack);
nbr_process++;
}
}
/*
Scheduler: el contexto del proceso actual es salvado y el sistema cambia
al proceso listo. Si next_process=NULL el proceso listo con mayor
prioridad es buscado, de otra forma el proceso es el proceso listo.
if (setjmp(current_process->context)==0) {
if (next_process)
current_process=next_process;
else {
n=0;
i=0x80000000;
while (!(i&ready_process)) {
n++; i>>=1;
}
current_process=pcs_tab+n;
}
387
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
longjmp(current_process->context,1);
}
}
/* Manejo de señales.*/
/*
send: envia las señales del proceso que estan en (1) en signals_mask.
*/
void send (PROCESS proceso,SIGNALS signals_mask) {
proceso->received_signals|=signals_mask;
if (proceso->received_signals&proceso->expected_signals) {
ready_process|=proceso->pmask;
proceso->expected_signals=0;
if (current_process->priority < proceso->priority)
scheduler(proceso);
}
}
/*
wait: coloca al proceso actual en espera de que
signals_mask regrese las se¤ales recibidas.
*/
SIGNALS wait (SIGNALS signals_mask) {
if (!(current_process->received_signals&signals_mask)) {
current_process->expected_signals=signals_mask;
ready_process^=current_process->pmask;
scheduler(NULL); /*cambia al sig. proceso*/
}
return (current_process->received_signals);
}
/*
reset: pone a las se¤ales encendidas en signals_mask en cero
y regresa las se¤ales que han llegado
*/
SIGNALS reset (SIGNALS signals_mask) {
SIGNALS old_signals;
old_signals=current_process->received_signals;
current_process->received_signals=
current_process->received_signals&~signals_mask;
return (old_signals);
}
388
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
/*
Kernel:inicializa las variables del kernel y cambia al primer proceso
el ultimo ciclo es el proceso idle del sistema.
disable();
current_process_mask=0x80000000;
ready_process=0;
for (i=0;i<=nbr_process;i++) {
pcs_ptr=pcs_tab+i;
pcs_ptr->received_signals=0;
pcs_ptr->pmask=current_process_mask;
pcs_ptr->priority=nbr_process-i;
ready_process|=current_process_mask;
current_process_mask=current_process_mask>>1;
}
current_process=pcs_tab+nbr_process;
free_time=0;
scheduler(pcs_tab);
enable();
for(;;)
free_time++;
}
/* Fin RTMK.C */
/*
TestRTMK.C
Programa de prueba para el RTMK
*/
#include "RTMK.H"
#include <stdio.h>
#include <conio.h>
#include <dos.h>
#include <signal.h>
/*
Esta interrupción (1Ch- CLOCK TICK) es llamada al final de cada
operación de up-date de una rutina, y es redireccionada por el
programa para llamar a los procesos concurrentes por el kernel.
*/
389
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
#define IT 0x1C
#define VIDEO 0xB8000000 /* Memoria de video.*/
PROCESS p1,p2;
int i,j;
char far* p=(char far*)VIDEO+1; /* Apuntador a la mem. de video. */
/*-------------------------------------------------------------*/
far process1() {
while(1) {
p++;
*p++=0x31; /* caracter desplegado en pantalla (1) */
if (p>(char far *)VIDEO+25*80*2) /*si llega al final de la pantalla*/
p=(char far *) VIDEO+1; /* vuelve a posicionar al principio*/
wait(ANY_SIGNAL);
reset(ALL_SIGNALS);
}
}
far process2() {
static long n;
enable();
while(1) {
printf("process2 : esperando \t");
wait(1);
printf("process2 : reset a se¤ales \t");
reset(1);
printf("process2 : calculando ");
for (j=0;j<60;j++) {
for (n=0;n<100000;n++);
printf(".");
}
printf("calculo terminado \n");
sound(2000); delay(200);
nosound();
}
}
jmp_buf sys_context;
390
Diseño y simulación de sistemas operativos – Eugenio Jacobo Hernández Valdelamar
void terminate() {
longjmp(sys_context,1);
}
void main() {
clrscr();
create_process(&p1,process1);
create_process(&p2,process2);
old_vector=getvect(IT);
disable();
signal(SIGINT,terminate);
setvect(IT,clock_it);
if (!setjmp(sys_context))
run_kernel();
setvect(IT,old_vector);
}
/* Fin TestRTMK.C */
391