LICENCIATURA
EN SISTEMAS DE INFORMACIÓN
SISTEMAS
OPERATIVOS
MONOGRAFÍA GRUPO Nº 1
TEMA:
SOPORTE DEL SISTEMA
OPERATIVO
Alumnos integrantes:
¨
Barrios Mayra L.U.
Nº 34.102
¨
Cemborain Juan Martín L.U.
Nº 34.079
¨
Zamparo Fabio L.U.
Nº 33.708
¨
Altamirano Romina L.U.
Nº 33.109
¨
Billordo Rosa Adriana L.U.
Nº 32.701
¨
Valenzuela Juan Alberto L.U. Nº 31.003
¨
Montenegro Carmenia L.U.
Nº 30.658
¨
De los Reyes Leonardo L.U.
Nº 30.279
¨
Acosta Germán L.U.
Nº 30.011
¨
Leguisamón Miguel Adolfo L.U. Nº 29.209
¨
Cemborain Guillermo L.U.
Nº 26.913
ÍNDICE
ü
Nivel del Sistema Operativo
ü
Protección
ü
Procesos e Hilos
ü
Creación de un proceso nuevo
ü
Hilos
ü Arquitecturas para servidores multi-hilo
ü
Hilos dentro de los clientes
ü
Tiempos de vida de los hilos
ü
Planificación de hilos
ü
Primitivas de sincronización
ü
Prestaciones de la invocación
ü
Elección del protocolo
ü
Operación Asíncrona
ü
Arquitectura del Sistema Operativo
ü Algunas aproximaciones híbridas
Middlewere y Sistemas Operativos en Red.
En realidad, no se emplea ningún sistema
operativo distribuido, sino solo sistemas operativos en red del tipo de UNÍX,
MacOS y diferentes variantes de
Windows.
Esta situación tiende a mantenerse, por dos
razones:
✔
La
primera es que los usuarios ya han realizados grandes inversiones en su
software de aplicación, que normalmente resuelve sus problemas; por lo que no
cambiaran a un nuevo sistema operativo que es incapaz de ejecutar sus
aplicaciones, por muchas ventajas que ofrezca.
✔
La
segunda razón en contra, es que los usuarios prefieren tener autonomía en la
gestión de sus propias máquinas, incluso en organizaciones fuertemente
cohesionadas, para conseguir buenas prestaciones.
La combinación de middlewere y sistema
operativo en red proporciona un equilibrio aceptable entre los requisitos de
autonomía, por un lado, y la transparencia de red en el acceso a recursos, por
el otro.
¨
Los
sistemas operativos en red permiten a los usuarios ejecutar su procesador de
textos junto con otro tipo de aplicaciones (independiente).
¨
El
middlewere les permite acceder a los servicios que aparecen como disponibles en
el sistema distribuido.
El Nivel de Sistema
Operativo.
El middlewere se ejecuta en múltiples
combinaciones hardware/ sistema operativo, es decir, en múltiples plataformas
en los nodos de un sistema distribuido. El sistema operativo que se ejecuta en
un cierto nodo (un núcleo junto con los servicios asociados de nivel de
usuario, por ej., bibliotecas) proporciona dentro de ese nodo su propia imagen
sobre las abstracciones de los recursos hardware locales de procesamiento, de
almacenamiento y de comunicación.
El middlewere utiliza una combinación de esos
recursos locales para implementar los mecanismos de invocación remota entre
objetos o procesos en los nodos.
Computador
y hardware de red Procesos, hilos, comunicaciones,... Procesos, hilos, comunicaciones,... Computador
y hardware de red
Middlewere
Aplicaciones, servicios
OS1
OS2
Nodo 1 Nodo2
Niveles del sistema
La figura, muestra cómo el nivel de sistema
operativo en cada uno de los dos nodos soporta un nivel de middlewere común
para proporcionar una infraestructura distribuida para aplicaciones y
servicios.
Los núcleos y los procesos cliente y servidor
que se ejecutan son los principales componentes de la arquitectura sobre los
que trataremos.
Los núcleos y el proceso servidor son los
componentes que gestionan los recursos y los presentan a los clientes a través
de una interfaz de recursos. Esta debe tener las siguientes características:
R
Encapsulamiento: debe proporcionar un servicio de
interfaz útil sobre los recursos, conjunto de operaciones que cubra las
necesidades. Los detalles del tipo gestión de la memoria o dispositivos
utilizados para implementar los recursos deben ocultarse a los clientes.
R
Protección: los recursos deben protegerse de
los accesos no permitidos.
R
Procesamiento concurrente: los clientes pueden compartir
múltiples recursos y acceder a ellos concurrentemente. Los gestores de recursos
son los responsables de conseguir transparencia en la concurrencia.
Los clientes acceden a los recursos mediante,
por ejemplo, invocaciones a un método remoto de un objeto que reside en un
cierto servidor o bien mediante llamadas al sistema en el núcleo. Los
mecanismos de acceso a un recurso encapsulado se denominan mecanismo de invocación. Una combinación de bibliotecas, núcleos y servidores puede utilizarse
para realizar las siguientes tareas de invocación:
R
Comunicación:
los parámetros de operación y los resultados deben pasarse hacia y desde los
gestores de recursos, utilizando una red o bien dentro del computador.
R
Planificación:
cuando se invoca una cierta operación, su procesamiento debe planificarse
dentro del núcleo o del servidor.
Funcionalidad básica del sistema
operativo
La figura muestra la funcionalidad básica
del sistema operativo la cual está relacionada con. La gestión de procesos e
hilos, la gestión de la memoria, y la comunicación entre procesos en el mismo
computador (las divisiones horizontales indican dependencia). El núcleo
proporciona gran parte de esta funcionalidad.
El software del S.O. se diseña para
ser portable entre las diferentes arquitecturas de computadores, se codifica en
e un lenguaje de alto nivel, ya sea C, C++ o Modula-3, y que sus servicios se
organizan por niveles de forma que los componentes dependientes de la máquina
se reducen a un único nivel inferior.
Multiprocesadores
de memoria compartida
Los computadores multiprocesador de
memoria compartida se componen de varios procesadores que comparten uno o más
módulos de memoria (RAM). Los procesadores pueden tener también su propia
memoria privada. Se pueden construir de diferentes formas:
# Los más
simples y menos costosos están construidos incorporando una tarjeta que
contiene de 2 a 8 procesadores en un computador personal.
Los multiprocesadores en los
sistemas distribuidos son particularmente muy utilizados para la implementación
de servidores de alta prestaciones ya que el servidor puede ejecutar un único
programa con varios hilos los cuales gestionan varias solicitudes llegadas de
diferentes clientes de forma simultánea.
Los principales componentes de un sistema operativo son los siguientes:
✔ Gestor de procesos: gestiona la creación y las diferentes operaciones sobre procesos
(unidad de gestión de recursos que incluye un espacio de direcciones y uno o
más hilos).
✔ Gestor de hilos: incluye la creación, sincronización y planificación de hilos (son
actividades planificables asociadas a procesos).
✔ Gestor de las comunicaciones: comunicaciones entre hilos asociados a
diferentes procesos en un mismo computador. Algunos núcleos soportan
comunicación entre hilos asociados a procesos remotos. Otros no, de forma que
deben añadirse servicios adicionales para las comunicaciones externas.
✔ Gestor de memoria: gestión de memoria física y virtual.
✔ Supervisor: se ocupa de la resolución de interrupciones, interrupciones internas de
llamadas al sistema y otras, control de la unidad de gestión de memoria y de
las ante memoria (caché) hardware; manipulación de registros del procesador y
la unidad en punto flotante. A todo esto se llama Nivel de Abstracción del
hardware en Windows NT.
Protección:
Los
recursos necesitan protección contra los accesos no permitidos. Hay que tener
en cuenta que las amenazas a la integridad de un sistema no previenen
únicamente de código ideado de forma maliciosa. También un código bien
intencionado puede contener un error o puede tener un comportamiento no
esperado, provocando que parte del sistema se comporte a su vez de forma
incorrecta.
Para
comprender lo que se quiere decir con acceso ilegitimo a un recurso,
consideremos un archivo abierto para lectura y escritura. La protección del
archivo se puede descomponer en dos sub-problemas. El primero consiste a
asegurar que cada una de las dos operaciones sobre el archivo solo puede ser
realizada por clientes. Por ejemplo Gonzáles, que es el propietario del
archivo, tiene los derechos de lectura y escritura sobre el. Pérez solo
necesita acceder a la operación de lectura. En este caso se producirá un acceso
ilegitimo si Pérez intentara realizar una operación de escritura sobre el
archivo.
El otro
tipo de acceso ilegitimo, ocurre cuando un proceso se comporta de forma
errónea, esquivando operaciones que se exportan sobre un recurso. En nuestro ejemplo
esto ocurriría si Gonzáles o Pérez, de alguna forma, ejecutaran una operación
que no fuera lectura o escritura.
Podemos
proteger, los recursos, de invocaciones ilegitimas del tipo SET FILE POINT
ERRAND ONLY.
Una
posibilidad insiste en utilizar un lenguaje de programación con sistema de
tipos seguro como Java o Modula-3. Estos lenguajes no permiten que un modulo
acceda a otro modulo objeto a no ser que previamente obtenga una referencia a
este ultimo. Por el contrario, en C++ un programador puede realizar
asignaciones a un puntero a voluntad, realizando de esta forma invocaciones de
tipo inseguras
PROCESOS E HILOS
El concepto tradicional en los sistemas
operativos de que un proceso ejecuta una única actividad, ya se comprobó, en la
década de los ochenta, que era poco adecuado para las especificaciones de los
sistemas distribuidos; y también para ciertas aplicaciones sobre un solo
computador que necesitan concurrencia interna. El problema es que los procesos
realizan la comparición entre actividades
relacionadas de una forma difícil y cara.
La solución consistió en ampliar el concepto de proceso de forma que
pudiera asociarse a múltiples actividades. En la actualidad un proceso consiste
en un entorno de ejecución formado por uno o más hilos. Un hilo es una
abstracción del sistema operativo asociada a una actividad. Un Entorno de
ejecución equivale a una unidad de gestión de recursos: una colección de
recursos locales gestionados por el núcleo sobre los que tienen acceso los
hilos.
Un entorno de ejecución consiste básicamente de
los siguientes elementos:
-
Un
espacio de direcciones
-
Recursos
de comunicación y sincronización de hilos, como semáforos e interfaces de
comunicación.
-
Recursos
de alto nivel, como archivos abiertos y ventanas.
Los entornos de ejecución son caros en cuanto a
su creación y gestión, aunque sin embargo pueden ser compartidos por más de un
hilo, es decir, estos pueden compartir todos los recursos accesibles dentro de
cada entorno. Entonces, un entorno de ejecución representa el dominio de
protección en el que se ejecutan los hilos.
Los hilos pueden crearse y destruirse en forma
dinámica. El principal propósito para la existencia de múltiples hilos es
maximizar el grado de ejecución concurrente entre las diferentes operaciones,
permitiendo así habilitar el solapamiento de la computación con la entrada-
salida y el procesamiento concurrente en los multiprocesadores. Esto es
particularmente útil en los servidores
en los que el procesamiento concurrente de las solicitudes de los clientes
pueden reducir la tendencia de los servidores a convertirse en cuellos de botella.
Un entorno de ejecución proporciona protección
contra los hilos externos de forma que los datos y otros recursos contenidos en
el sean inaccesibles para los hilos residentes en otros entornos de ejecución.
Sin embargo ciertos núcleos permiten compartir en forma controlada recursos
entre entornos de ejecución diferentes residentes en el mismo computador.
ESPACIOS DE DIRECCIONES
Es una unidad de gestión de memoria virtual de
un proceso. Es grande y esta formado por una o mas regiones, separadas por
áreas de memoria virtual inaccesibles.
Una región es una zona de memoria virtual
contigua accesible por los hilos del proceso propietario. Las regiones no se
solapan. Hay que resaltar la distinción entre regiones y sus contenidos. Cada
región se caracteriza por las siguientes propiedades:
-
Su
tamaño
-
Los
permisos de lectura/ escritura/ ejecución para los hilos del proceso.
-
Una indicación
de crecimiento hacia arriba o hacia abajo.
Este modelo esta orientado a páginas. Las
regiones podrían eventualmente solaparse si su tamaño se extendiera. Entre las
regiones se dejan huecos para permitir
su crecimiento. Esta representación de un espacio de direcciones como un
conjunto disperso de regiones disjuntas es una generalización del espacio de
direcciones de UNÍX, el cual esta formado por tres regiones: una región de
texto de tamaño fijo y no modificable, que contiene el código del programa; un
montón (heap), parte del cual se inicializa con los valores almacenados en el
archivo binario con el programa, y que es ampliable hacia direcciones virtuales
crecientes; y una pila, que crecerá hacia direcciones virtuales decrecientes.
La existencia de un número determinado de
regiones tiene su razón de ser en varios factores. Uno de ellos es la necesidad
de que haya pilas separadas para cada hilo. La existencia de regiones de pila
distintas para cada hilo permite detectar los intentos de exceder el límite de
la pila y controlar el crecimiento de cada una de ellas. La memoria virtual no
utilizase halla debajo de cada región de pila y los intentos de acceder a esa
región generan excepciones. Una alternativa consiste en asignar la pila de cada
hilo en el montón, sin embargo en este caso ase hace difícil detectar cuando un
hilo excede el limite de su pila.
La necesidad de compartir memoria entre
procesos, o entre procesos y núcleo, es otro factor que deriva en la necesidad
de regiones adicionales en el espacio de direcciones. Una región de memoria
compartida es aquella en la que se asocia la misma memoria física a una o más
regiones pertenecientes a otros espacios de direcciones. Por lo tanto los
procesos acceden a los mismos
contenidos de memoria en las regiones compartidas mientras que sus regiones no
compartidas permanecen protegidas. Algunos usos de las regiones compartidas son
las siguientes:
-
bibliotecas: el código de las bibliotecas puede
llegar a ser muy grande y se desperdiciaría una cantidad considerable de
memoria si se cargaran de forma separada en cada proceso que las utilizase. Por
el contrario, varios procesos pueden compartir una sola copia del código de las
bibliotecas empleando una región compartida del espacio de direcciones.
-
Núcleo: frecuentemente el código y los
datos de los núcleos corresponden dentro del espacio de direcciones en las
mismas posiciones. Cuando un proceso realice una llamada al sistema, o bien
cuando se genere una excepción, no habrá necesidad de conmutar a un nuevo
conjunto de direcciones.
-
Compartir
datos y comunicación:
entre dos procesos, o bien entre un proceso y el núcleo, se puede necesitar
compartir datos para cooperar en la realización de cierta tarea. Es más
eficiente utilizar regiones de direcciones compartidas en lugar de intercambiar
los datos mediante mensaje.
Creación de un proceso Nuevo
Para un sistema distribuido el diseño de mecanismo de creación de un
proceso debe tener en cuenta la utilización de múltiples computadoras, de esta
forma la infraestructura de gestión de procesos se divide en servicios de
sistemas separados.
La creación de un proceso nuevo pude separarse
en dos aspectos:
La elección del computador destino: el nodo puede elegirse entre varios
de un grupo de computadoras que actúan como servidores, la elección del nodo
donde residirá el nuevo proceso es una cuestión política, los cuales se
distinguen las siguientes categorías de políticas para compartir el uso de la
carga.
- Política
de transferencia: decide si un proceso nuevo debe ubicarse en el nodo
local o en el remoto.
- Política
de ubicación: determina que nodos alojara un proceso nuevo seleccionado
para transferir.
A su vez estas políticas pueden ser estáticas o
adaptativos, los primeros operan sin tener una consideración del estado actual
del sistema, se basaron en análisis matemáticos orientados a la optimización de
ciertos parámetros, mientras que los segundos aplican reglas heurísticas para
tomar las decisiones de ubicación basándose en factores de tiempo de ejecución
no predecibles.
Los sistemas para compartir la carga pueden ser
centralizados, jerárquicos o descentralizados. En el primer caso existe un
gestor de carga, en el segundo existen varios.
En un sistema de uso compartido de carga
descentralizado los nodos intercambian información entre ellos directamente
para tomar las decisiones de localización.
En los algoritmos de uso compartido de la carga
iniciados por el emisor el nodo que solicita la creación del proceso es
responsable de iniciar la decisión de transferencia, en cambio en lo que son
iniciados por el receptor un nodo cuya carga esta por debajo de cierto umbral advierte sobre su
existencia a otros nodos con cargas
relativamente altas para que inicien las transferencia.
El otro aspecto que hay que tener encuentra en
la creación de un proceso nuevo es la creación de su entorno. Este esta
formado por un espacio de direcciones iniciados con una serie de contenidos.
Existen dos aproximaciones en las definiciones del espacio de direcciones, una
forma seria con un formato definirlo de forma estáticamente o bien definirlo
respecto de un entorno de ejecución existente, en cuyo caso cada región del
proceso puede ser heredado por el de su
hijo.
Una región heredada puede, o bien ser
compartida, o copiarse desde la región del padre. En el primer caso los marcos
de páginas pertenecientes a la región del padre concuerdan simultáneamente con
las correspondientes del hijo.
En el segundo caso, la región es copiada por
defecto, no se realiza copia física. Los marcos de página que componen la
región heredada se comparten entre los dos espacios de direcciones. Una
página de la región es copiada
físicamente únicamente cuando uno de los dos procesos intente modificarla.
HILOS
Es un aspecto
importante de los procesos, debido, entre otras cuestiones, porque define la
productividad máxima del servidor medida en solicitudes de cliente manejadas
por segundo.
Este número estará en
función del número de hilos que el servidor disponga.
Por ejemplo,
supongamos que en un computador servidor con un solo procesador cada solicitud
de cliente necesita 2 mlseg. de proceso y 8 mlseg. de entrada-salida sin caché
a disco.
Si solo dispone de un
hilo para realizar todo el proceso, el tiempo de retorno para una solicitud es
2+8 = 10 mlseg. promedio, o sea que
puede atender a 100 clientes/seg. Cualquier mensaje de solicitud que llegue
mientras el servidor está manejando una solicitud es insertado en la cola del
puerto del servidor.
Si en cambio dispone
de dos hilos que se manejen en forma independiente, es decir, cada uno se puede
planificar cuando el otro pasa a estado bloqueado por operaciones de E/S, se
incrementa la productividad del servidor. Si todas las solicitudes al disco se
envían en serie a 8 mlseg. por proceso, la productividad es 1.000/8 = 125
solicitudes/seg.
Si agregamos la
existencia de una caché de disco, el servidor mantiene los bloques leídos en
búfferes dentro de su espacio de direcciones; el hilo encargado de obtener
datos examina previamente la caché compartida evitándose el acceso a disco si
los datos están allí. Considerando una tasa de aciertos del 75%, el tiempo de
E/S por solicitud se reduce a 2 mlseg., incrementándose la productividad
teórica a 500 solicitudes/seg. Considerando que el tiempo de uso del procesador
se incrementa 2,5 mlseg. por búsquedas de datos en la caché, el procesador
puede gestionar 1.000/2,5 = 400 solic/seg.
La productividad se puede
incrementar por medio del uso de multiprocesadores de memoria compartida con
múltiples hilos planificados para procesadores múltiples.
Si el servidor del
ejemplo anterior se ejecuta en un multiprocesador con dos procesadores, con
hilos planificados independientemente sobre los procesadores, se podrán
procesar solicitudes en paralelo hasta un máximo de dos hilos. La productividad
aumenta en este caso a 444 solic/seg.
Arquitecturas para servidores
multi-hilo
Para vincular
solicitudes a hilos en un servidor se resume un informe de Schmidt de 1.998,
describiendo las arquitecturas basadas en hilos de diferentes implementaciones
del Agente de Solicitud de Objetos de CORBA llamado ORB, Object Request Broker.
Cada ORB procesa
solicitudes que llegan a través de un conjunto de sockets activos.
(La figura muestra
una de las posibles arquitecturas basadas en hilos, la Arquitectura de
Asociación de Trabajadores).
En la Arquitectura de
Asociación de Trabajadores, en su forma más simple, el servidor durante la inicialización,
crea un conjunto fijo de hilos de trabajadores para procesar solicitudes.
El módulo receptor y
gestor de cola se implementa normalmente como un hilo de E/S que recibe
solicitudes de un grupo de sockets o puertos y las sitúa en una cola para ser
recuperadas por los trabajadores. Puede que en ciertos casos sea necesario
manejar jerarquía de solicitudes, por ejemplo según el cliente que envíe la
solicitud. Esto se puede gestionar mediante múltiples colas, de forma que el
trabajador pueda examinar las colas en orden de prioridad.
Las desventajas de
esta arquitectura son su escasa flexibilidad y el alto nivel de conmutaciones
entre la E/S y los hilos de trabajo al
manejar la cola compartida.
En la Arquitectura de
Hilo-por-Solicitud, el hilo de E/S genera un nuevo hilo de trabajo para cada
solicitud y ese trabajador se elimina a sí mismo cuando ha procesado la
solicitud asociada a un objeto remoto. Esta arquitectura tiene la ventaja de
que los hilos no compiten por acceder a una cola compartida y la productividad
se maximiza dado que el hilo de E/S puede generar tantos trabajadores como
solicitudes tenga. Su desventaja es la sobrecarga debido a las operaciones de
creación y destrucción de hilos.
La Arquitectura de
Hilo-por-Conexión asocia un hilo por conexión. El servidor crea un hilo
trabajador cuando un cliente realiza una conexión y lo destruye cuando se
cierra la misma. En el intervalo, el cliente puede realizar múltiples
solicitudes sobre la conexión, cuyos destinos pueden ser uno o más objetos remotos.
La Arquitectura de
Hilo-por-Objeto asocia un hilo a cada objeto remoto. Un hilo de E/S recibe las
solicitudes y las inserta en las colas para los trabajadores, con la diferencia
de que en este caso existe una cola por cada objeto.
En cada una de las
dos últimas arquitecturas el servidor se beneficia de pequeñas sobrecargas en
la gestión de hilos en comparación con la de hilo-por-solicitud.
HILOS DENTRO DE LOS CLIENTES
Los hilos pueden ser tan útiles para los
clientes como para los servidores. Proceso
cliente con dos hilos: el primer hilo genera resultados que se van a enviar al
servidor mediante una invocación a método remoto, no necesitando, sin embargo
una respuesta. Las invocaciones a métodos remotos normalmente bloquean al que
invoca, incluso aunque no sea estrictamente preciso esperar. Este proceso
cliente puede añadir un segundo hilo, el cual realiza las invocaciones a los
métodos remotos y se bloque mientras el primer hilo puede continuar computando
nuevos resultados. El primer hilo deposita sus resultados en búferes que son
vaciados por el segundo hilo. Únicamente se bloquea cuando todos los búferes
estén llenos.
La cuestión de clientes multihilo es evidente
también en el ejemplo de los navegadores Web. El usuario sufre retardos
significativos mientras se cargan las paginas; es por lo tanto esencial para
los navegadores la gestión de múltiples solicitudes concurrentes a paginas Web.
HILOS FRENTE A MULTIPLES PROCESOS
La utilidad de los hilos permite que la
computación se solape con la entrada-salida y, para el caso de un
multiprocesador, con otros cómputos. Se puede obtener el mismo solapamiento
mediante la utilización de múltiples procesos mono-hilo. La razón por la cual
se prefiere el proceso multihilo es: la creación y gestión de los hilos es mas
barata que la de procesos y la de uso
compartido de recursos se puede conseguir de forma más eficiente entre hilos
que entre procesos ya que los hilos comparten entornos de ejecución.
Algunos de los principales componentes del estado
que deben gestionarse para entornos de ejecución e hilos: un entorno de
ejecución tiene un espacio de direcciones, interfaces de comunicación,
recu7rsos de alto nivel del tipo de archivos abiertos y objetos para la
sincronización de hilos como los semáforos; además debe mantener una relación
de los hilos que se asocian a dicho entorno. Un hilo tiene una prioridad de
planificación, un estado de ejecución (como bloqueado o preparado), los valores
almacenados correspondientes a los registros del procesador cuando el hilo esta
bloqueado y el estado relacionado con la gestión de interrupciones software del
hilo. Una interrupción software es un evento que provoca la interrupción del
hilo. Si el hilo tiene asignado un procedimiento de gestión se le transfiere el
control. Las señales en UNÍS son ejemplos de interrupciones software.
El entorno de ejecución y los hilos se asocian
con páginas que pertenecen al espacio de direcciones mantenido en memoria
principal, mientras que los datos e instrucciones se almacenan en el caché
hardware.
Comparación entre procesos e hilos:
-
la
creación de un nuevo hilo dentro de un proceso existente es mas barata que la
creación de un proceso.
-
La
conmutación a hilo diferente dentro del mismo proceso es mas barata que la
conmutación entre hilos de diferentes procesos.
-
Los
hilos dentro de un proceso pueden compartir datos y otros recursos de forma más
adecuada y eficiente que con procesos separados.
-
Sin
embargo, los hilos dentro de un proceso no están protegidos entre ellos.
Considérese el coste de creación de un nuevo
hilo dentro de un entorno de ejecución existente. La principal tarea consiste
en asignar una región para la pila y proporcionar los valores iniciales de los
registros del procesador y de al prioridad
y estado de ejecución del hilo. Debido a la existencia de un entorno de
ejecución solo se debe colocar un identificador para el en el registro que
describe al hilo. La sobrecarga asociada a la creación de un proceso es
considerablemente mayor que la asociada a la creación de un nuevo hilo. Es
preciso crear en primer lugar un entorno de ejecución, incluyendo las tablas
del espacio de direcciones. Anderson y
otro citan valores alrededor de 11 milisegundos para la creación de un proceso
UNÍS y sobre 1 milisegundo para la creación de un hilo sobre la misma
arquitectura de procesador CVAX ejecutando un núcleo Topaz; en cada caso el
tiempo medido supone que la entidad creada realiza exclusivamente una
invocación a un procedimiento vacío antes de terminar.
Cuando la nueva entidad realiza una tarea
significativa en lugar de la invocación al procedimiento nulo, se producen
costes a largo plazo que tienden a ser mayores para un nuevo proceso que para
un nuevo hilo dentro de un proceso ya existente. En un núcleo que soporte memoria
virtual, el nuevo proceso generara faltas de páginas según vaya accediendo por primera vez a datos e
instrucciones. Por otro lado para el caso de la ejecución de un hilo las
sobrecargas a largo plazo también pueden ocurrir, pero tienden a ser menores.
Cuando el hilo accede al código y a los datos que han sido utilizados
recientemente por otros hilos del mismo proceso, automáticamente se aprovecha
del hecho de que dichos datos ya residen en cada caché hardware o bien en la memoria principal.
La segunda ventaja de prestaciones de los hilos
se refiere a la conmutación entre hilos, es decir la sustitución de un hilo por
otro en un cierto procesador. Esto puede generarse varias veces durante la vida
del hilo. La conmutación entre hilos que comparten el mismo entorno de
ejecución es mas barata que la de los hilos que pertenecen a diferentes procesos. Las sobrecargas asociadas a la
conmutación de hilos corresponden a la planificación y al cambio de contexto.
Un contexto de procesador esta formado por los valores
de los registros del procesador como el contador del programa y el dominio de
protección actual del hardware: el espacio de direcciones y el modo de
protección del procesador. El cambio de contexto es la transición entre
contextos que ocurre cuando se conmuta entre hilos o cuando un único hilo
realiza una llamada al sistema o genera otro tipo de excepción. Supone realizar
las siguientes tareas:
-
almacenamiento
del registro de estado original del procesador y carga del nuevo estado.
-
En
algunas situaciones se realiza una transferencia a un nuevo dominio de
protección: a esto se lo llama transición de dominio
La conmutación al núcleo o a otro hilo que
pertenece al mismo entorno de ejecución a través del núcleo, supone la
realización de una transición de dominio. El coste es así mayor aunque, si el
núcleo esta vinculado al espacio de direcciones del cliente, es aun
relativamente bajo. Cuando se conmuta entre hilos que pertenecen a diferentes
entornos de ejecución se generan mayores sobrecargas. Los costes a largo plazo
debidos a la ocupación de las entradas del caché hardware y de las páginas de
memoria principal tienden a aplicarse cuando ocurre la mencionada transición de
dominio. Los valores presentados por Anderson
y otros son de 1.8 milisegundos para realizar una conmutación entre
procesos UNÍS y de 0.4 milisegundos para la conmutación entre hilos
pertenecientes al mismo entorno de ejecución realizada en el núcleo Topaz.
Del proceso clientes con dos hilos, el primer
hilo genera los datos y se los pasa al segundo hilo el cual genera una
invocación a un método remoto o bien una llamada a procedimiento remoto. Ambos
hilos pueden acceder a datos a través de variables compartidas. La ventaja esta
en la comodidad y eficiencia del uso compartido de datos. Los hilos que
comparten un espacio de direcciones y que no han sido codificados en un
lenguaje de tipos seguros no están protegidos entre ellos. Un hilo erróneo
puede modificar de forma arbitraria los datos de otro hilo, provocando que este
falle. Si se requiere protección, o bien se utiliza un lenguaje de tipos seguro
o bien es preferible utilizar múltiples procesos en lugar de múltiples hilos.
Programación de hilos
La programación de hilos
equivale a la programación concurrente, tal y como ha sido estudiada
tradicionalmente, por ejemplo, en el ámbito de los sistemas operativos. La
mayor parte de la programación de hilos se realiza en lenguajes de programación
convencionales como C aumentados con bibliotecas de hilos. Un ejemplo es el
paquete de Hilos para C (C Threads) desarrollado para el sistema operativo
Mach. Algunos lenguajes proporcionan un soporte directo para hilos, como Ada95,
Modula-3 y, de forma más reciente, Java (Oaks y Wong 1999). A continuación
explicaremos someramente los hilos de Java.
De la misma forma que
en cualquier implementación de hilos, Java proporciona métodos para la
creación, destrucción y sincronización de hilos. La clase de Java Thread
incluye el constructor y los métodos de gestión mostrados en la Figura 6.8. Los
métodos de sincronización Thready Object están en la Figura 6.9.
thread.join(int milisegundos)
Bloquea el hilo invocador durante el tiempo especificado hasta que el hilo haya terminado.
thread.interrup()
Interrumpe el hilo: le obliga a volver desde una llamada a método bloqueante como sleep().
objet.wait(long
milisegundos, int nanosegundos)
Bloquea el hilo invocador hasta que una llamada realizada a notify() o notifyAll() en el objeto despierte el hilo, o bien el hilo sea interrumpido, o bien el tiempo especificado sa haya cumplido.
objet.notify(),
objet.notifyAll()
Despierta, respectivamente, uno o todos los hilos que han invocado a wait() en el objeto.
Métodos constructor y de gestión hilos en Java.
Sincronización
de hilos
Cuando tenemos varios
hilos, muchas veces deseamos que éstos pueden compartir datos, por lo tanto, es
indispensable saber sincronizar sus actividades.
En muchas situaciones,
hilos que se ejecutan concurrentemente comparten información y deben considerar
el estado de las actividades de los demás hilos. Un modelo muy común de tales
conjuntos de hilos es conocido como escenarios de productor/consumidor, donde
el productor genera un flujo de datos que es consumido por un consumidor.
La programación de un
proceso multi-hilo debe realizarse de forma cuidadosa. La principal dificultad
consiste en el uso compartido de objetos y en las técnicas utilizadas para la
coordinación y cooperación de los hilos. Las variables locales de cada hilo en
sus métodos son privadas del hilo, es decir, los hilos tienen pilas privadas.
Los segmentos de
código dentro de un programa que accedan el mismo objeto desde hilos separados
(concurrentes) se llaman regiones críticas. Java provee algunos métodos más
para coordinar las actividades de los hilos, como notifyAll, wait, etc.
Suponga, por ejemplo,
las colas compartidas descritas previamente en esta sección, las cuales tienen
hilos de E/S e hilos de trabajo utilizados para transferir las solicitudes en
arquitecturas de servidores basadas en hilos. Pueden aparecer condiciones de
competencia (race conditions) cuando los hilos manipulan concurrentemente
estructuras de datos del tipo de colas. Las solicitudes que residen en las
colas pueden perderse o duplicarse. A no ser que los punteros de manipulación
de los hilos hayan sido cuidadosamente coordinados.
Java proporciona a
programadores la palabra clave synchronized para designar un monitor, que es un
recurso de sincronización de hilos muy conocido. Los programadores designan
métodos completos o bien bloques de código de tamaño arbitrario como
pertenecientes a un monitor asociado a un objeto individual. La garantía de un
monitor viene del hecho de que como máximo un hilo puede ejecutarse dentro de
un monitor en cualquier instante. Podríamos seriar las acciones de los hilos de
E/S y trabajadores en nuestro ejemplo designando los métodos añadirA() y eliminarDe() en la clase Cola como métodos synchronized. Todos los
accesos a variables dentro de dichos métodos se realizan con exclusión mutua
respecto a las invocaciones de estos métodos.
Java permite bloquear
y despertar hilos a través de objetos arbitrarios que actúan como variables de
condición. Un hilo que necesita bloquearse en espera de una cierta condición
invoca un método wait(). Todos los
objetos implementan este método, ya que pertenecen a la clase raíz de Java
llamada Objet. Otro hilo invocara notify()
para desbloquear como máximo un hilo, o
bien invocará a notifyAll() para desbloquear
todos los hilos en espera sobre el mismo objeto. Ambos métodos de
notificación pertenecen también a la clase Objet.
Como ejemplo, cuando
un hilo trabajador descubre que ya no hay mas solicitudes parar procesar,
invoca wait() en la instancia Cola.
Cuando posteriormente el hilo de E/S añada una solicitud a la cola, invocará el
método notify() de gestión de colas,
para despertar al trabajador.
Los métodos de
sincronización de Java se muestran en la Figura 6.9. Además de las primitivas
de sincronización mencionadas, el método join()
bloquea al que invoca hasta la terminación del hilo destino. El método interrupt() es útil para despertar
prematuramente un hilo en espera. Todas las primitivas estándar de
sincronización, como tos semáforos, pueden implementarse en Java. Sin embargo
es preciso hacerlo cuidadosamente ya que la garantía del monitor de Java se
aplica única mente a código de objetos declarado como synchronized: una clase
tendrá una mezcla de métodos synchronized y no-synchronized. Además el monitor
implementado en un objeto Java tiene una única variable de condición implícita
mientras que en general un monitor puede tener varias variables de condición.
