Resumen de la
clase dictada 11,18 y 25 noviembre y 2
de diciembre 2015
1.
INTRODUCCIÓN
Los sistemas
operativos han tenido avances agigantados desde sus inicios, sus estructuras
nos muestra sistema tales como, los sistemas monolíticos que son sistemas que
se ejecutan en un solo núcleo es decir un proceso a la vez, también sistemas por
capas que realizan sus tareas por partes, hasta los sistemas servidores que nos
permiten compartir información y tenerla más segura. Lo que en si la estructuras
de los SO nos ayuda es a comprender para que sirve cada uno de estos, como se
utiliza y que comparten.
Dentro de
los sistemas operativos se realizan procesos que se dan a través de intrusiones
que el usuario ordene y que pueden ser manejadas por hilos para realizar el
proceso de una manera rápida.
2. OBJETIVO
Conocer la
estructura, Procesos e Hilos en los sistemas operativos.
3. MARCO TEÓRICO
3.1.
ESTRUCTURA DE UN SISTEMA OPERATIVO
3.1.1.COMPONENTES DE UN SISTEMA OPERATIVO
Administración
de procesos
Administración
de memoria
Subsistema
de entrada/salida
Administración
de almacenamiento secundario
Subsistema
de archivos
Sistemas
de protección
Figura 1. Estructura de los Sistemas Operativos
3.2.
SISTEMAS MONOLÍTICOS
En
este diseño, que hasta ahora se considera como la organización más común, 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,.
Después el sistema operativo obtiene los parámetros y determina cuál es la
llamada al sistema que se va a llevar a cabo. Después la indiza en una tabla
que contiene en la ranura k un apuntador al procedimiento que lleva a
cabo la llamada al sistema k .
Esta
organización sugiere una estructura básica para el sistema operativo:
1.
Un programa principal que invoca el procedimiento de servicio solicitado.
2.
Un conjunto de procedimientos de servicio que llevan a cabo las llamadas al
sistema.
3.
Un conjunto de procedimientos utilitarios que ayudan a los procedimientos de
servicio
Figura 2. Sistema Monolitico
3.3.
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 (los bits eran costosos en aquel entonces).
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. Por encima del nivel 0, el sistema consistía en procesos
secuenciales, cada uno de los cuales e podía programar sin necesidad de
preocuparse por el hecho de que había varios procesos en ejecución en un solo
procesador. En otras palabras, el nivel 0 proporcionaba la multiprogramación
básica de la CPU.
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, los procesos no
tenían que preocuparse acerca de si estaban en memoria o en el tambor; el software
de la capa 1 se encargaba de asegurar que las páginas se llevaran a memoria
cuando se requerían.
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.
Una
mayor generalización del concepto de capas estaba presente en el sistema
MULTICS. En vez de capa, MULTICS se describió como una serie de anillos
concéntricos, en donde los interiores tenían más privilegios que los exteriores
(que en efecto viene siendo lo mismo). Cuando un procedimiento en
un anillo exterior quería llamar a un procedimiento en un anillo interior,
tenía que hacer el equivalente de una llamada al sistema; es decir, una
instrucción TRAP cuyos parámetros se comprobara cuidadosamente que fueran
válidos antes de permitir que continuara la llamada.
Aunque
todo el sistema operativo era parte del espacio de direcciones de cada proceso
de usuario en MULTICS, el hardware hizo posible que se designaran procedimientos
individuales (en realidad, segmentos de memoria) como protegidos contra
lectura, escritura o ejecución.
Mientras
que en realidad el esquema de capas de THE era sólo una ayuda de diseño, debido
a que todas las partes del sistema estaban enlazadas entre sí en un solo programa
ejecutable, en MULTICS el mecanismo de los anillos estaba muy presente en
tiempo de ejecución y el hardware se encargaba de implementarlo. La ventaja del
mecanismo de los anillos es que se puede extender fácilmente para estructurar
los subsistemas de usuario. Por ejemplo, un profesor podría escribir un programa
para evaluar y calificar los programas de los estudiantes, ejecutando este
programa en el nillo n, mientras que los programas de los estudiantes se
ejecutaban en el anillo n _ 1 y por ende no podían cambiar sus
calificaciones.
Figura 3. capas del Sistema Operativo por Capas
3.4. MICROKERNELS
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.
En
especial, al ejecutar cada driver de dispositivo y sistema de archivos como un
proceso de usuario separado, un error en alguno de estos procesos puede hacer
que falle ese componente, pero no puede hacer que falle todo el sistema. Así,
un error en el driver del dispositivo de audio hará que el sonido sea confuso o
se detenga, pero la computadora no fallará. En contraste, en un sistema
monolítico con todos los drivers en el kernel, un driver de audio con errores
puede hacer fácilmente referencia a una dirección de memoria inválida y llevar
a todo el sistema a un alto rotundo en un instante.
Figura 4. sistema MicroKernel
3.5. 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 5. Sistema Servidor
3.6. PROCESOS E HILOS
3.6.1. PROCESO
Un proceso es cualquier programa en ejecución. Este
necesita ciertos recursos para realizar satisfactoriamente su tarea:
- Tiempo de CPU.
- Memoria.
- Archivos.
- Dispositivos de E/S.
Las obligaciones del SO como gestor de procesos
son:
- Creación y eliminación de procesos.
- Planificación de procesos (procurando la ejecución de múltiples procesos maximizando la utilización del procesador).
- Establecimiento de mecanismos para la sincronización y comunicación de procesos.
- Manejo de bloqueos mutuos.
3.6.1.1. ESTADOS DE UN PROCESO
A medida
que un proceso se ejecuta cambia de estado. Cada proceso puede estar en uno de
los estados:
- Nuevo (new): el proceso se está creando.
- En ejecución (running): el proceso está en la CPU ejecutando instrucciones.
- Bloqueado (waiting, en espera): proceso esperando a que ocurra un suceso (ej. terminación de E/S o recepción de una señal).
- Preparado (ready, listo): esperando que se le asigne a un procesador. Terminado (terminated): finalizó su ejecución, por tanto no ejecuta más instrucciones y el SO le retirará los recursos que consume.
3.6.2. HILOS
Los hilos
son un concepto relativamente nuevo de los SO. En este contexto, un proceso
recibe el nombre de proceso pesado, mientras que un hilo recibe el nombre de
proceso ligero. El término hilo se refiere sintáctica y semánticamente a hilos
de ejecución.
El término multihilo hace referencia a la capacidad de un SO para mantener varios hilos de ejecución dentro del mismo proceso.
Figura 6. Hilos
3.6.2.1. ESTADOS
DE UN HILO
Los principales estados de un hilo son: ejecución,
preparado y bloqueado; y hay cuatro operaciones básicas
relacionadas con el cambio de estado de los hilos:
- Creación: En general, cuando se crea un nuevo proceso se crea también un hilo para ese proceso. Posteriormente, ese hilo puede crear nuevos hilos dándoles un puntero de instrucción y algunos argumentos. Ese hilo se colocará en la cola de preparados.
- Bloqueo: Cuando un hilo debe esperar por un suceso, se le bloquea guardando sus registros. Así el procesador pasará a ejecutar otro hilo preparado.
- Desbloqueo: Cuando se produce el suceso por el que un hilo se bloqueó pasa a la cola de listos.
- Terminación: Cuando un hilo finaliza, se liberan su contexto y sus pilas.
Un punto importante es la posibilidad de que el
bloqueo de un hilo lleve al bloqueo de todo el proceso. Es decir, que el
bloqueo de un hilo lleve al bloqueo de todos los hilos que lo componen, aun
cuando el proceso está preparado.
4. CONCLUSIÓN
La estructura de los sistemas operativos es de
importancia ya que este nos ayuda a comprender cuales son los componentes y los
servicios que estos dan al usuario es decir para que sirve que es lo que
controla, los procesos son programas en ejecución es decir instrucciones que el
usuario le ordena al computador en los procesos se pueden llevar varios hilos a
la ves esto quiere decir que si tenemos un programa en ejecución el sistema operativo va crear varios hilo, uno
para guardar, otro que va permitir escribir dentro del programa, entre otros, en si lo que los hilos ayudan en un proceso es
que se realicen de manera más ligera los procesos.
5. BIBLIOGRAFÍA
Abreu, J.2012. Procesos vs hilos.
(En Línea). Consultado el 6 de Dic. 2015. Formato HTML. Disponible en: http://systope.blogspot.com/2012/05/procesos-e-hilos.html
Tanenbaum, A. 2009. Sistemas
Operativos Modernos. 3 ed. México. D. F. PEARSON EDUCACIÓN. p. 62-79
