1. Objetivo
Analizar la estructura de los sistemas operativos,
procesos e hilos
2. Introducción
Los sistemas operativos han sufrido múltiples
cambios al paso de los años empezando desde los procesamientos por lotes
limitando al sistema a realizar una tarea a la vez, en la actualidad los sistemas
operativos trabajan con múltiples tareas a la vez haciendo de estos muy
eficientes.
3. Marco teórico
3.1 CONCEPTOS
DE LOS SISTEMAS OPERATIVOS
La mayoría de los sistemas
operativos proporcionan ciertos conceptos básicos y abstracciones tales como
procesos, espacios de direcciones y archivos, que son la base para comprender
su funcionamiento.
3.2 Procesos
Un concepto clave en todos los
sistemas operativos es el proceso. Un proceso es en esencia un programa en
ejecución. Cada proceso tiene asociado un espacio de direcciones, una lista de
ubicaciones de memoria que va desde algún mínimo (generalmente 0) hasta cierto
valor máximo, donde el proceso puede leer y escribir información. El espacio de
direcciones contiene el programa ejecutable, los datos del programa y su pila.
También hay asociado a cada proceso un conjunto de recursos, que comúnmente
incluye registros (el contador de programa y el apuntador de pila, entre ellos),
una lista de archivos abiertos, alarmas pendientes, listas de procesos
relacionados y toda la demás información necesaria para ejecutar el programa.
En esencia, un proceso es un recipiente que guarda toda la información
necesaria para ejecutar un programa.
Un proceso (suspendido)
consiste en su espacio de direcciones, que se conoce comúnmente como imagen de
núcleo (en honor de las memorias de núcleo magnético utilizadas antaño) y su entrada
en la tabla de procesos, que guarda el contenido de sus registros y muchos
otros elementos necesarios para reiniciar el proceso más adelante.
Figura 1: Proceso
3.3 Espacios
de direcciones
Cada computadora tiene cierta
memoria principal que utiliza para mantener los programas en ejecución.
En un sistema operativo muy
simple sólo hay un programa a la vez en la memoria. Para ejecutar un segundo programa
se tiene que quitar el primero y colocar el segundo en la memoria.
Los sistemas operativos más
sofisticados permiten colocar varios programas en memoria al mismo tiempo. Para
evitar que interfieran unos con otros (y con el sistema operativo), se necesita
cierto mecanismo de protección. Aunque este mecanismo tiene que estar en el
hardware, es controlado por el sistema operativo.
El anterior punto de vista se
relaciona con la administración y protección de la memoria principal de la
computadora. Aunque diferente, dado que la administración del espacio de
direcciones de los procesos está relacionada con la memoria, es una actividad
de igual importancia. Por lo general, cada proceso tiene cierto conjunto de
direcciones que puede utilizar, que generalmente van desde 0 hasta cierto valor
máximo. En el
caso más simple, la máxima cantidad de espacio de direcciones que tiene un
proceso es menor que la memoria principal. De esta forma, un proceso puede llenar
su espacio de direcciones y aun así habrá suficiente espacio en la memoria
principal para contener todo lo necesario.
Sin embargo, en muchas
computadoras las direcciones son de 32 o 64 bits, con lo cual se obtiene un
espacio de direcciones de 232 o 264 bytes, respectivamente.
Figura 2: Espacio de direcciones
3.4 Archivos
Una de las funciones
principales del sistema operativo es ocultar las peculiaridades de los discos y
demás dispositivos de E/S, presentando al programador un modelo abstracto
limpio y agradable de archivos independientes del dispositivo. Sin duda se
requieren las llamadas al sistema para crear los archivos, eliminarlos, leer y
escribir en ellos. Antes de poder leer un archivo, debe localizarse en el disco
para abrirse y una vez que se ha leído información del archivo debe cerrarse,
por lo que se proporcionan llamadas para hacer estas cosas.
Figura 3: Archivos
3.5 El
Shell
El sistema operativo es el
código que lleva a cabo las llamadas al sistema. Los editores, compiladores, ensambladores,
enlazadores e intérpretes de comandos en definitiva no forman parte del sistema
operativo, aun cuando son importantes y útiles.
shell aunque no forma parte del
sistema operativo, utiliza con frecuencia muchas características del mismo y,
por ende, sirve como un buen ejemplo de la forma en que se pueden utilizar las
llamadas al sistema. También es la interfaz principal entre un usuario sentado
en su terminal y el sistema operativo
3.6 LLAMADAS
AL SISTEMA
Los sistemas operativos tienen
dos funciones principales: proveer abstracciones a los programas de usuario y
administrar los recursos de la computadora. En su mayor parte, la interacción entre
los programas de usuario y el sistema operativo se relaciona con la primera
función: por ejemplo, crear, escribir, leer y eliminar archivos. La parte de la
administración de los recursos es en gran parte transparente para los usuarios
y se realiza de manera automática. Por ende, la interfaz entre los programas de
usuario y el sistema operativo trata principalmente acerca de cómo lidiar con
las abstracciones. Para comprender realmente qué hacen los sistemas operativos,
debemos examinar esta interfaz con detalle. Las llamadas al sistema disponibles
en la interfaz varían de un sistema operativo a otro (aunque los conceptos
subyacentes tienden a ser similares).
Figura 4: Llamada al sistema
3.7 ESTRUCTURA
DE UN SISTEMA OPERATIVO
3.7.1 Sistemas
monolíticos
Todo el sistema operativo se
ejecuta como un solo programa en modo kernel. El sistema operativo se escribe
como una colección de procedimientos, enlazados entre sí en un solo programa
binario ejecutable extenso.
Cuando se utiliza esta técnica,
cada procedimiento en el sistema tiene la libertad de llamar a cualquier otro,
si éste proporciona cierto cómputo útil que el primero necesita. Al tener miles
de procedimientos que se pueden llamar entre sí sin restricción, con frecuencia
se produce un sistema poco manejable y difícil de comprender.
Para construir el programa
objeto actual del sistema operativo cuando se utiliza este diseño, primero se
compilan todos los procedimientos individuales (o los archivos que contienen
los procedimientos) y luego se vinculan en conjunto para formar un solo archivo
ejecutable, usando el enlazador del sistema. En términos de ocultamiento de
información, en esencia no hay nada: todos los procedimientos son visibles para
cualquier otro procedimiento (en contraste a una estructura que contenga
módulos o paquetes, en donde la mayor parte de la información se oculta dentro
de módulos y sólo los puntos de entrada designados de manera oficial se pueden
llamar desde el exterior del módulo).
Sin embargo, hasta en los
sistemas monolíticos es posible tener cierta estructura. Para solicitar los
servicios (llamadas al sistema) que proporciona el sistema operativo, los
parámetros se colocan en un lugar bien definido (por ejemplo, en la pila) y
luego se ejecuta una instrucción de trap. Esta instrucción cambia la máquina
del modo usuario al modo kernel y transfiere el control al sistema operativo.
Figura 5: Sistema monolitico
3.7.2 Sistemas
de capas
El sistema operativo como una
jerarquía de capas, cada una construida encima de la que tiene abajo. El primer
sistema construido de esta forma fue el sistema THE, construido en Technische
Hogeschool Eindhoven en Holanda por E. W. Dijkstra (1968) y sus estudiantes. El
sistema THE era un sistema simple de procesamiento por lotes para una
computadora holandesa, la Electrologica X8, que tenía 32K de palabras de 27
bits El sistema tenía seis capas. El nivel 0 se encargaba de la asignación del
procesador, de cambiar entre un proceso y otro cuando ocurrían interrupciones o
expiraban los temporizadores.
La capa 1 se encargaba de la
administración de la memoria. Asignaba espacio para los procesos en la memoria
principal y en un tambor de palabras de 512 K que se utilizaba para contener partes
de procesos (páginas), para los que no había espacio en la memoria principal.
Por encima de la capa 1.
La capa 2 se encargaba de la
comunicación entre cada proceso y la consola del operador (es decir, el
usuario). Encima de esta capa, cada proceso tenía en efecto su propia consola
de operador.
La capa 3 se encargaba de administrar
los dispositivos de E/S y de guardar en búferes los flujos de información
dirigidos para y desde ellos. Encima de la capa 3, cada proceso podía trabajar
con los dispositivos abstractos de E/S con excelentes propiedades, en vez de
los dispositivos reales con muchas peculiaridades.
La capa 4 era en donde se encontraban los programas
de usuario. No tenían que preocuparse por la administración de los procesos, la
memoria, la consola o la E/S. El proceso operador del sistema se encontraba en
el nivel 5.
Figura 6: Sistema de capas
3.7.3 Microkernels
Con el diseño de capas, los
diseñadores podían elegir en dónde dibujar el límite entre kernel y usuario.
Tradicionalmente todos las
capas iban al kernel, pero eso no es necesario. De hecho, puede tener mucho
sentido poner lo menos que sea posible en modo kernel, debido a que los errores
en el kernel pueden paralizar el sistema de inmediato. En contraste, los
procesos de usuario se pueden configurar para que tengan menos poder, por lo
que un error en ellos tal vez no sería fatal.
Varios investigadores han
estudiado el número de errores por cada 1000 líneas de código. La densidad de
los errores depende del tamaño del módulo, su tiempo de vida y más, pero una
cifra aproximada para los sistemas industriales formales es de diez errores por
cada mil líneas de código. Esto significa que es probable que un sistema
operativo monolítico de cinco millones de líneas de código contenga cerca de
50,000 errores en el kernel.
La idea básica detrás del
diseño de microkernel es lograr una alta confiabilidad al dividir el sistema operativo
en módulos pequeños y bien definidos, sólo uno de los cuales (el microkernel)
se ejecuta en modo kernel y el resto se ejecuta como procesos de usuario
ordinarios, sin poder relativamente.
Figura 7: Microkernel
3.7.4 Modelo
cliente-servidor
Una ligera variación de la idea
del microkernel es diferenciar dos clases de procesos: los servidores, cada uno
de los cuales proporciona cierto servicio, y los clientes, que utilizan estos
servicios.
Este modelo se conoce como cliente-servidor.
A menudo la capa inferior es un microkernel, pero eso no es requerido. La
esencia es la presencia de procesos cliente y procesos servidor.
La comunicación entre clientes
y servidores se lleva a cabo comúnmente mediante el paso de mensajes. Para
obtener un servicio, un proceso cliente construye un mensaje indicando lo que desea
y lo envía al servicio apropiado. Después el servicio hace el trabajo y envía
de vuelta la respuesta.
Si el cliente y el servidor se
ejecutan en el mismo equipo se pueden hacer ciertas optimizaciones, pero en
concepto estamos hablando sobre el paso de mensajes.
Figura 8: Cliente-Servidor
3.7.5 Máquinas
virtuales
Las versiones iniciales del
OS/360 eran, en sentido estricto, sistemas de procesamiento por lotes.
Sin embargo, muchos usuarios
del 360 querían la capacidad de trabajar de manera interactiva en una terminal,
por lo que varios grupos, tanto dentro como fuera de IBM, decidieron escribir
sistemas de tiempo compartido para este sistema. El sistema de tiempo compartido
oficial de IBM, conocido como TSS/360, se liberó después de tiempo y cuando por
fin llegó era tan grande y lento que pocos sitios cambiaron a este sistema.
Figura 9: Maquina virtual
3.7.6 Exokernels
En vez de clonar la máquina
actual, como se hace con las máquinas virtuales, otra estrategia es
particionarla, en otras palabras, a cada usuario se le proporciona un subconjunto
de los recursos. Así, una máquina virtual podría obtener los bloques de disco
del 0 al 1023, la siguiente podría obtener los bloques de disco del 1024 al
2047 y así sucesivamente.
En la capa inferior, que se
ejecuta en el modo kernel, hay un programa llamado exokernel (Engler y
colaboradores, 1995). Su trabajo es asignar recursos a las máquinas virtuales y
después comprobar los intentos de utilizarlos, para asegurar que ninguna máquina
trate de usar los recursos de otra. Cada máquina virtual de nivel de usuario
puede ejecutar su propio sistema operativo, al igual que en la VM/370 y las
Pentium 8086 virtuales, con la excepción de que cada una está restringida a
utilizar sólo los recursos que ha pedido y que le han sido asignados.
La ventaja del esquema del
exokernel es que ahorra una capa de asignación. En los otros diseños, cada
máquina virtual piensa que tiene su propio disco, con bloques que van desde 0
hasta cierto valor máximo, por lo que el monitor de la máquina virtual debe
mantener tablas para reasignar las direcciones del disco (y todos los demás
recursos).
Figura 10: Exokernels
3.8. PROCESOS
E HILOS
El concepto más importante en
cualquier sistema operativo es el de proceso, una abstracción de un programa en
ejecución; todo lo demás depende de este concepto, por lo cual es importante que
el diseñador del sistema operativo (y el estudiante) tenga una comprensión
profunda acerca de lo que es un proceso lo más pronto posible.
Los procesos son una de las
abstracciones más antiguas e importantes que proporcionan los sistemas operativos:
proporcionan la capacidad de operar concurrentemente, incluso cuando hay sólo
una CPU disponible. Convierten una CPU en varias CPU virtuales. Sin la
abstracción de los procesos, la computación moderna no podría existir. En este
capítulo examinaremos con gran detalle los procesos y sus primeros primos.
Figura 11: Procesos e hilos
3.8.1 PROCESOS
Cuando se arranca el sistema se
inician muchos procesos en forma secreta, lo que a menudo el usuario desconoce Por
ejemplo, se podría iniciar un proceso para esperar el correo electrónico
entrante; otro que permite al antivirus comprobar periódicamente la
disponibilidad de nuevas definiciones de virus; algunos procesos de usuario
explícitos para, por ejemplo, imprimir archivos y quemar un CD-ROM, y todo esto
mientras el usuario navega por la Web. Toda esta actividad se tiene que
administrar, y en este caso un sistema de multiprogramación con soporte para
múltiples procesos es muy útil.
En cualquier sistema de
multiprogramación, la CPU conmuta de un proceso a otro con rapidez, ejecutando
cada uno durante décimas o centésimas de milisegundos: hablando en sentido
estricto, en cualquier instante la CPU está ejecutando sólo un proceso, y en el
transcurso de 1 segundo podría trabajar en varios de ellos, dando la apariencia
de un paralelismo.
Figura 12: Proceso
3.8.2 El
modelo del proceso
En este modelo, todo el
software ejecutable en la computadora, que algunas veces incluye al sistema operativo,
se organiza en varios procesos secuenciales (procesos, para abreviar). Un
proceso no es más que una instancia de un programa en ejecución, incluyendo los
valores actuales del contador de programa, los registros y las variables. En
concepto, cada proceso tiene su propia
CPU virtual; en la realidad, la
CPU real conmuta de un proceso a otro, pero para entender el sistema es mucho
más fácil pensar en una colección de procesos que se ejecutan en (pseudo)
paralelo, en vez de tratar de llevar la cuenta de cómo la CPU conmuta de
programa en programa. Esta conmutación rápida de un proceso a otro se conoce
como multiprogramación
3.8.3 Creación
de un proceso
Los sistemas operativos
necesitan cierta manera de crear procesos. En sistemas muy simples o sistemas diseñados
para ejecutar sólo una aplicación, es posible tener presentes todos los procesos
que se vayan a requerir cuando el sistema inicie.
Hay cuatro eventos principales
que provocan la creación de procesos:
1. El arranque del sistema.
2. La ejecución, desde un
proceso, de una llamada al sistema para creación de procesos.
3. Una petición de usuario para
crear un proceso.
4. El inicio de un trabajo por
lotes.
3.8.4 Terminación
de procesos
Una vez que se crea un proceso,
empieza a ejecutarse y realiza el trabajo al que está destinado. Sin embargo,
nada dura para siempre, ni siquiera los procesos. Tarde o temprano el nuevo
proceso terminará, por lo general debido a una de las siguientes condiciones:
1. Salida normal (voluntaria).
2. Salida por error
(voluntaria).
3. Error fatal (involuntaria).
4. Eliminado por otro proceso
(involuntaria).
La mayoría de los procesos
terminan debido a que han concluido su trabajo. Cuando un compilador ha
compilado el programa que recibe, ejecuta una llamada al sistema para indicar
al sistema operativo que ha terminado.
3.8.5 HILOS
En los sistemas operativos
tradicionales, cada proceso tiene un espacio de direcciones y un solo hilo de
control. De hecho, ésa es casi la definición de un proceso. Sin embargo, con
frecuencia hay situaciones en las que es conveniente tener varios hilos de
control en el mismo espacio de direcciones que se ejecuta en cuasi-paralelo,
como si fueran procesos separados
Figura 13: Hilos
3.8.6 Uso
de hilos
¿Por qué alguien querría tener
un tipo de proceso dentro de otro proceso? Resulta ser que hay varias razones
de tener estos mini procesos, conocidos como hilos. Ahora analizaremos algunos
de ellos. La principal razón de tener hilos es que en muchas aplicaciones se
desarrollan varias actividades a la vez. Algunas de ésas se pueden bloquear de
vez en cuando. Al descomponer una aplicación en varios hilos secuenciales que
se ejecutan en cuasi-paralelo, el modelo de programación se simplifica.
3.8.7 El
modelo clásico de hilo
Ahora que hemos visto por qué
podrían ser útiles los hilos y cómo se pueden utilizar, vamos a investigar la
idea un poco más de cerca. El modelo de procesos se basa en dos conceptos
independientes: agrupamiento de recursos y ejecución. Algunas veces es útil
separarlos; aquí es donde entran los hilos. Primero analizaremos el modelo
clásico de hilos; después el modelo de hilos de Linux, que desaparece la línea
entre los procesos y los hilos.
Una manera de ver a un proceso
es como si fuera una forma de agrupar recursos relacionados.
Un proceso tiene un espacio de
direcciones que contiene texto y datos del programa, así como otros recursos.
Estos pueden incluir archivos abiertos, procesos hijos, alarmas pendientes,
manejadores de señales, información contable y mucho más. Al reunirlos en forma
de un proceso, pueden administrarse con más facilidad.
4. Conclusión
La estructura de los sistemas
operativos nos ayuda a conocer de qué manera trabajan estos sistemas complejos,
los procesos e hilos permiten que la ejecución de programas sea rápida.
5. Bibliografía
Tanenbaum, A. 2009. Sistemas Operativos Modernos.
3 ed. México. D. F. PEARSON EDUCACIÓN
http://www.ditec.um.es/so/apuntes/teoria/tema2.pdf
http://sistop.gwolf.org/biblio/Sistemas_Operativos_-_Luis_La_Red_Martinez.pdf
