Hilos y SMP

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 25

Hilos, SMP y

micronúcleos

Luis Enrique Aguilar Ferrera Administración de Sistemas Operativos II


PROCESOS E HILOS
se ha presentado el concepto de un proceso como poseedor de dos
características:

• Propiedad de recursos. Un proceso incluye un espacio de direcciones virtuales para el manejo de la


imagen del proceso; como ya se explicó en el Capítulo 3 la imagen de un proceso es la colección de
programa, datos, pila y atributos definidos en el bloque de control del proceso. De vez en cuando a un
proceso se le puede asignar control o propiedad de recursos tales como la memoria principal, canales
E/S, dispositivos E/S y archivos. El sistema operativo realiza la función de protección para evitar
interferencias no deseadas entre procesos en relación con los recursos.
• Planificación/ejecución. La ejecución de un proceso sigue una ruta de ejecución (traza) a través de
uno o más programas. Esta ejecución puede estar intercalada con ese u otros procesos. De esta
manera, un proceso tiene un estado de ejecución (Ejecutando, Listo, etc.) y una prioridad de activación
y ésta es la entidad que se planifica y activa por el sistema operativo.

2
MULTIHILO
capacidad de un sistema operativo de dar
soporte a múltiples hilos de ejecución en un solo
proceso. El enfoque tradicional de un solo hilo de
ejecución por proceso, en el que no se identifica
con el concepto de hilo, se conoce como
estrategia monohilo. Un ejemplo de sistema
operativo que soporta un único proceso de
usuario y un único hilo es el MSDOS.
MULTIHILO
El entorno de ejecución de Java es un ejemplo de
sistema con un único proceso y múltiples hilos. Lo
interesante en esta sección es el uso de múltiples
procesos, cada uno de los cuales soporta múltiples
hilos. Este enfoque es el de Windows, Solaris, Mach, y
OS/2 entre otros. En esta sección se ofrece una
descripción general del mecanismo multihilo; más
adelante en este capítulo se discuten los detalles de los
enfoques de Windows, Solaris y Linux.
En un entorno multihilo, un proceso se define como la unidad de asignación de recursos y una unidad de
protección. Se asocian con procesos los siguientes:

• Un espacio de direcciones virtuales que soporta la imagen del proceso.


• Acceso protegido a procesadores, otros procesos (para comunicación entre procesos), archivos y recursos
de E/S (dispositivos y canales).

Dentro de un proceso puede haber uno o más hilos, cada uno con:

• Un estado de ejecución por hilo (Ejecutando, Listo, etc.).


• Un contexto de hilo que se almacena cuando no está en ejecución; una forma de ver a un hilo es como un
contador de programa independiente dentro de un proceso.
• Una pila de ejecución.
• Por cada hilo, espacio de almacenamiento para variables locales.
• Acceso a la memoria y recursos de su proceso, compartido con todos los hilos de su mismo proceso.

En un entorno multihilo, sigue habiendo un único bloque de control del proceso y un espacio de direcciones de
usuario asociado al proceso, pero ahora hay varias pilas separadas para cada hilo, así como un bloque de
control para cada hilo que contiene los valores de los registros, la prioridad, y otra información relativa al
estado del hilo.

5
Mientras el proceso está ejecutando, los registros del
procesador se controlan por ese proceso y, cuando el proceso no
se está ejecutando, se almacena el contenido de estos registros.
De esta forma, todos los hilos de un proceso comparten el
estado y los recursos de ese proceso, residen en el mismo
espacio de direcciones y tienen acceso a los mismos datos.
Cuando un hilo cambia determinados datos en memoria, otros
hilos ven los resultados cuando acceden a estos datos. Si un hilo
abre un archivo con permisos de lectura, los demás hilos del
mismo proceso pueden también leer ese archivo.

Los mayores beneficios de los hilos provienen de las consecuencias del rendimiento:
1. Lleva mucho menos tiempo crear un nuevo hilo en un proceso existente que crear un proceso totalmente
nuevo. Los estudios realizados por los que desarrollaron el sistema operativo Mach muestran que la creación de
un hilo es diez veces más rápida que la creación de un proceso en UNIX [TEVA87].
2. Lleva menos tiempo finalizar un hilo que un proceso.
3. Lleva menos tiempo cambiar entre dos hilos dentro del mismo proceso
4. Los hilos mejoran la eficiencia de la comunicación entre diferentes programas que están ejecutando. En la
mayor parte de los sistemas operativos, la comunicación entre procesos independientes requiere la intervención
del núcleo para proporcionar protección y los mecanismos necesarios de comunicación. Sin embargo, ya que los
hilos dentro de un mismo proceso comparten memoria y archivos, se pueden comunicar entre ellos sin
necesidad de invocar al núcleo.

6
Los hilos, al igual que los procesos, tienen estados de ejecución y se pueden sincronizar entre ellos. A
continuación se analizan estos dos aspectos de las funcionalidades de los hilos.

Estados de los hilos. Igual que con los procesos, los principales estados de los hilos son: Ejecutando, Listo y Bloqueado.
Generalmente, no tiene sentido aplicar estados de suspensión a un hilo, ya que dichos estados son conceptos de nivel de
proceso. En particular, si se expulsa un proceso, todos sus hilos se deben expulsar porque comparten el espacio de
direcciones del proceso.
Hay cuatro operaciones básicas relacionadas con los hilos que están asociadas con un cambio de estado del hilo
[ANDE97]:

• Creación. Cuando se crea un nuevo proceso, también se crea un hilo de dicho proceso. Posteriormente, un hilo del
proceso puede crear otro hilo dentro del mismo proceso, proporcionando un puntero a las instrucciones y los argumentos
para el nuevo hilo. Al nuevo hilo se le proporciona su propio registro de contexto y espacio de pila y se coloca en la cola de
Listos.
• Bloqueo. Cuando un hilo necesita esperar por un evento se bloquea, almacenando los registros de usuario, contador de
programa y punteros de pila. El procesador puede pasar a ejecutar otro hilo en estado Listo, dentro del mismo proceso o en
otro diferente.
• Desbloqueo. Cuando sucede el evento por el que el hilo está bloqueado, el hilo se pasa a la cola de Listos.
• Finalización. Cuando se completa un hilo, se liberan su registro de contexto y pilas.

7
HILOS DE NIVEL DE USUARIO Y DE NIVEL DE NÚCLEO

Existen dos amplias categorías de implementación de hilos: hilos de nivel de usuario (userlevel threads, ULT) e
hilos de nivel de núcleo (kernellevel threads, KLT)4.Los últimos son también conocidos en la literatura como hilos
soportados por el núcleo (kernelsupported threads) o procesos ligeros (lightweight processes).

• Hilos de nivel de usuario. En un entorno ULT puro, la aplicación gestiona todo el trabajo de los hilos y el
núcleo no es consciente de la existencia de los mismos.
Por defecto, una aplicación comienza con un solo hilo y ejecutando en ese hilo. Esta aplicación y su hilo se
localizan en un solo proceso gestionado por el núcleo. En cualquier momento que la aplicación esté ejecutando
(el proceso está en estado Ejecutando), la aplicación puede crear un nuevo hilo a ejecutar dentro del mismo
proceso. La creación se realiza llamando a la utilidad de creación en la biblioteca de hilos. Se pasa el control a
esta utilidad a través de una llamada a procedimiento. La biblioteca de hilos crea una estructura de datos para el
nuevo hilo y luego pasa el control a uno de los hilos de ese proceso que esté en estado listo, utilizando algún
algoritmo de planificación. Cuando se pasa el control a la biblioteca, se almacena el contexto del hilo actual, y
cuando se pasa el control de la biblioteca al hilo, se recupera el contexto de ese hilo. El contexto tiene
esencialmente el contenido de los registros del usuario, el contador que programa, y los punteros de pila.

8
HILOS A NIVEL DE NÚCLEO.

En un entorno KLT puro, el núcleo gestiona todo el trabajo de gestión de hilos. No hay código de
gestión de hilos en la aplicación, solamente una interfaz de programación de aplicación (API) para
acceder a las utilidades de hilos del núcleo. Windows es un ejemplo de este enfoque.

Cualquier aplicación puede programarse para ser multihilo. Todos los hilos de una aplicación se
mantienen en un solo proceso. El núcleo mantiene información de contexto del proceso como una
entidad y de los hilos individuales del proceso. La planificación realizada por el núcleo se realiza a nivel
de hilo. Este enfoque resuelve los dos principales inconvenientes del enfoque ULT. Primero, el núcleo
puede planificar simultáneamente múltiples hilos de un solo proceso en múltiples procesadores.
Segundo, si se bloquea un hilo de un proceso, el núcleo puede planificar otro hilo del mismo proceso.
Otra ventaja del enfoque KLT es que las rutinas del núcleo pueden ser en sí mismas multihilo.

9
ENFOQUES COMBINADOS.

Algunos sistemas operativos proporcionan utilidades combinadas ULT/KLT. Solaris es el principal


ejemplo de esto. En un sistema combinado, la creación de hilos se realiza por completo en el espacio
de usuario, como la mayor parte de la planificación y sincronización de hilos dentro de una aplicación.
Los múltiples ULT de una aplicación se asocian en un número (menor o igual) de KLT. El programador
debe ajustar el número de KLT para una máquina y aplicación en particular para lograr los mejores
resultados posibles.

En los enfoques combinados, múltiples hilos de la misma aplicación pueden ejecutar en paralelo en
múltiples procesadores, y una llamada al sistema bloqueante no necesita bloquear el proceso
completo. Si el sistema está bien diseñado, este enfoque debería combinar las ventajas de los
enfoques puros ULT y KLT, minimizando las desventajas.

10
11
Relación muchosamuchos: La idea de tener una relación muchosamuchos entre hilos y procesos ha
sido explorada en el sistema operativo experimental TRIX [SIEB83,WARD80].

Relación unoamuchos. En el campo de los sistemas operativos distribuidos (diseñados para controlar
sistemas de computadores distribuidos), ha habido interés en el concepto de un hilo como una entidad
que se puede mover entre espacios de direcciones.
Desde el punto de vista del usuario, un hilo en Clouds es una unidad de actividad. Un proceso es un
espacio de direcciones virtual con un bloque de control de proceso asociado. Una vez creado, un hilo
comienza ejecutando en un proceso a través de la invocación de un punto de entrada de un programa
en ese proceso. Los hilos se pueden mover de un espacio de direcciones a otro, incluso fuera de los
límites de la máquina (es decir, moverse de un computador a otro). Según se mueve el hilo, debe
llevarse determinada información con él, tal como el controlador de terminal, los parámetros globales y
las guías de planificación (por ejemplo, prioridad).

12
MULTIPROCESAMIENTO SIMÉTRICO

Tradicionalmente, el computador ha sido visto como


una máquina secuencial. La mayor parte de los
lenguajes de programación requieren que el
programador especifique algoritmos como una
secuencia de instrucciones. Un procesador ejecuta
programas a través de la ejecución de instrucciones
máquina en secuencia y de una en una. Cada
instrucción se ejecuta como una secuencia de
operaciones
MULTIPROCESAMIENTO SIMÉTRICO

A medida que ha evolucionado la tecnología de los


computadores y el coste del hardware ha descendido, los
diseñadores han visto cada vez más oportunidades para el
paralelismo, normalmente para mejorar el rendimiento y, en
algunos casos, para mejorar la fiabilidad. En este libro,
examinamos los dos enfoques más populares para
proporcionar paralelismo a través de la réplica de
procesadores: multiprocesamiento simétricos (SMP) y
clusters.
ARQUITECTURA SMP

Es útil ver donde encaja la arquitectura SMP dentro de las categorías de procesamiento paralelo. La forma
más común de categorizar estos sistemas es la taxonomía de sistemas de procesamiento paralelo
introducida por Flynn [FLYN72]. Flynn propone las siguientes categorías de sistemas de computadores:

• Única instrucción, único flujo de datos – Single instruction single data (SISD) stream. Un solo procesador
ejecuta una única instrucción que opera sobre datos almacenados en una sola memoria.
• Única instrucción, múltiples flujos de datos – Single instruction multiple data (SIMD) stream. Una única
instrucción de máquina controla la ejecución simultánea de un número de elementos de proceso. Cada
elemento de proceso tiene una memoria de datos asociada, de forma que cada instrucción se ejecuta en un
conjunto de datos diferente a través de los diferentes procesadores. Los procesadores vectoriales y
matriciales entran dentro de esta categoría.
• Múltiples instrucciones, único flujo de datos – Multiple instruction single data (MISD) stream. Se transmite una
secuencia de datos a un conjunto de procesadores, cada uno de los cuales ejecuta una secuencia de
instrucciones diferente. Esta estructura nunca se ha implementado.
• Múltiples instrucciones, múltiples flujos de datos – Multiple instruction multiple data (MIMD) stream. Un
conjunto de procesadores ejecuta simultáneamente diferentes secuencias de instrucciones en diferentes
conjuntos de datos.

15
ARQUITECTURA SMP

En un multiprocesador simétrico (Symmetric Multiprocessor, SMP), el núcleo puede ejecutar


en cualquier procesador, y normalmente cada procesador realiza su propia planificación del
conjunto disponible de procesos e hilos. El núcleo puede construirse como múltiples procesos
o múltiples hilos, permitiéndose la ejecución de partes del núcleo en paralelo. El enfoque SMP
complica al sistema operativo, ya que debe asegurar que dos procesadores no seleccionan un
mismo proceso y que no se pierde ningún proceso de la cola. Se deben emplear técnicas para
resolver y sincronizar el uso de los recursos.

El diseño de SMP y clusters es complejo, e involucra temas relativos a la organización física,


estructuras de interconexión, comunicación entre procesadores, diseño del sistema operativo
y técnicas de aplicaciones software.

16
ORGANIZACIÓN SMP

Existen múltiples procesadores, cada uno de los cuales


contiene su propia unidad de control, unidad aritméticológica
y registros. Cada procesador tiene acceso a una memoria
principal compartida y dispositivos de E/S a través de algún
mecanismo de interconexión; el bus compartido es común a
todos los procesadores. Los procesadores se pueden
comunicar entre sí a través de la memoria (mensajes e
información de estado dejados en espacios de memoria
compartidos). Los procesadores han de poder intercambiarse
señales directamente. A menudo la memoria está organizada
de tal manera que se pueden realizar múltiples accesos
simultáneos a bloques separados.

17
CONSIDERACIONES DE DISEÑO DE SISTEMAS OPERATIVOS MULTIPROCESADOR

Las principales claves de diseño incluyen las siguientes características:

• Procesos o hilos simultáneos concurrentes. Las rutinas del núcleo necesitan ser reentrantes para permitir que
varios procesadores ejecuten el mismo código del núcleo simultáneamente. Debido a que múltiples
procesadores pueden ejecutar la misma o diferentes partes del código del núcleo, las tablas y la gestión de las
estructuras del núcleo deben ser gestionas apropiadamente para impedir interbloqueos u operaciones
inválidas.

• Planificación. La planificación se puede realizar por cualquier procesador, por lo que se deben evitar los
conflictos. Si se utiliza multihilo a nivel de núcleo, existe la posibilidad de planificar múltiples hilos del mismo
proceso simultáneamente en múltiples procesadores.

18
• Sincronización. Con múltiples procesos activos, que pueden acceder a espacios de direcciones compartidas
o recursos compartidos de E/S, se debe tener cuidado en proporcionar una sincronización eficaz. La
sincronización es un servicio que fuerza la exclusión mutua y el orden de los eventos. Un mecanismo común
de sincronización que se utiliza en los sistemas operativos multiprocesador son los cerrojos.

• Gestión de memoria. La gestión de memoria en un multiprocesador debe tratar con todos los aspectos
encontrados en las máquinas uniprocesador, que se verán en la Parte Tres. Además, el sistema operativo
necesita explotar el paralelismo hardware existente, como las memorias multipuerto, para lograr el mejor
rendimiento. Los mecanismos de paginación de los diferentes procesadores deben estar coordinados para
asegurar la consistencia cuando varios procesadores comparten una página o segmento y para decidir sobre
el reemplazo de una página.

• Fiabilidad y tolerancia a fallos. El sistema operativo no se debe degradar en caso de fallo de un procesador. El
planificador y otras partes del sistema operativo deben darse cuenta de la pérdida de un procesador y
reestructurar las tablas de gestión apropiadamente.

19
MICRONÚCLEOS

Un micronúcleo es la pequeña parte central de un sistema operativo que proporciona las bases para
extensiones modulares.

Sin embargo, el término es algo confuso, y hay varias cuestiones relacionadas con los micronúcleos
con respuestas distintas por parte de diferentes equipos de diseño de sistemas operativos. Estas
cuestiones incluyen, cómo de pequeño debe ser un núcleo para denominarse micronúcleo, cómo
diseñar manejadores de dispositivos para obtener el mejor rendimiento a la vez que se abstraen sus
funciones del hardware, si ejecutar operaciones que no pertenecen al núcleo dentro de éste o en el
espacio de usuario, y si mantener el código de subsistemas existentes (por ejemplo, una versión de
UNIX) o empezar de cero.

20
ARQUITECTURA MICRONÚCLEO

Los primeros sistemas operativos desarrollados a mediados y finales de los años 50 fueron diseñados
sin preocuparse por su arquitectura. Nadie tenía la experiencia necesaria en construcción de sistemas
software realmente grandes, y los problemas causados por la dependencia mutua e interacción no se
tenían en cuenta. En estos sistemas operativos monolíticos, de prácticamente cualquier procedimiento
se podía llamar a cualquier otro. Esta falta de estructura se hizo insostenible a medida que los
sistemas operativos crecieron hasta proporciones desmesuradas. Por ejemplo, la primera versión de
OS/360 contenía más de un millón de líneas del código; Multics, desarrollado más tarde, creció hasta
20 millones de líneas del código [DENN84].
La filosofía existente en el micronúcleo es que solamente las funciones absolutamente esenciales del
sistema operativo estén en el núcleo. Los servicios y aplicaciones menos esenciales se construyen
sobre el micronúcleo y se ejecutan en modo usuario. Aunque la filosofía de qué hay dentro y qué hay
fuera del micronúcleo varía de un diseño a otro, la característica general es que muchos servicios que
tradicionalmente habían formado parte del sistema operativo ahora son subsistemas externos que
interactúan con el núcleo y entre ellos mismos; algunos ejemplos son: manejadores de dispositivos,
servidores de archivos, gestores de memoria virtual, sistemas de ventana y servicios de seguridad.

21
ARQUITECTURA MICRONÚCLEO

Los componentes del sistema operativo externos


al micronúcleo se implementan como servidores
de procesos; interactúan entre ellos dos a dos,
normalmente por paso de mensajes a través del
micronúcleo. De esta forma, el micronúcleo
funciona como un intercambiador de mensajes:
válida mensajes, los pasa entre los componentes,
y concede el acceso al hardware. El micronúcleo
también realiza una función de protección;
previene el paso de mensajes a no ser que el
intercambio esté permitido.

22
BENEFICIOS DE UNA ORGANIZACIÓN MICRONÚCLEO

En la literatura se pueden encontrar una serie de


ventajas del uso de los micronúcleos (por
ejemplo, [FINK97], [LIED96a], [WAYN94a]. Estas
incluyen:

• Interfaces uniformes
• Extensibilidad
• Flexibilidad
• Portabilidad
• Fiabilidad
• Soporte de sistemas distribuidos
• Soporte de sistemas operativos orientados a
objetos (OOOS)

23
RENDIMIENTO DEL MICRONÚCLEO

Una potencial desventaja que se cita a menudo de los


micronúcleos es la del rendimiento. Lleva más tiempo
construir y enviar un mensaje a través del micronúcleo, y
aceptar y decodificar la respuesta, que hacer una simple
llamada a un servicio. Sin embargo, también son
importantes otros factores, de forma que es difícil
generalizar sobre la desventaja del rendimiento, si es que
la hay.

Hay mucho que depende del tamaño y de la funcionalidad


del micronúcleo. [LIED96a] resume un número de
estudios que revelan una pérdida sustancial del
rendimiento en los que pueden ser denominados
micronúcleos de primera generación. Estas pérdidas
continúan a pesar de los esfuerzos realizados para
optimizar el código del micronúcleo.

24
RENDIMIENTO DEL MICRONÚCLEO

Una potencial desventaja que se cita a menudo de los


micronúcleos es la del rendimiento. Lleva más tiempo
construir y enviar un mensaje a través del micronúcleo, y
aceptar y decodificar la respuesta, que hacer una simple
llamada a un servicio. Sin embargo, también son
importantes otros factores, de forma que es difícil
generalizar sobre la desventaja del rendimiento, si es que
la hay.

Hay mucho que depende del tamaño y de la funcionalidad


del micronúcleo. [LIED96a] resume un número de
estudios que revelan una pérdida sustancial del
rendimiento en los que pueden ser denominados
micronúcleos de primera generación. Estas pérdidas
continúan a pesar de los esfuerzos realizados para
optimizar el código del micronúcleo.

25

También podría gustarte