Captulo 5 Soporte del Sistema Operativo

Sistemas Distribuidos

Universidad Nacional de Asuncin Facultad Politcnica Ingeniera Informtica

Profesor: Ing. Fernando Manca

Sistema Operativo

Facilita el encapsulamiento y proteccin de los recursos dentro de los servidores.

Soporta mecanismos de invocacin requerido para esos recursos, incluyendo comunicacin y planificacin.
La tarea de un S.O: proporcionar abstracciones, orientadas a un cierto problema, de los recursos fsicos subyacentes, entre los que estn el procesador, la memoria, las comunicaciones y los dispositivos de almacenamiento.

El nivel del sistema operativo

Los usuarios nicamente estarn satisfechos si la combinacin entre el middleware y el sistema operativo proporciona buenas prestaciones. El middleware se ejecuta en mltiples combinaciones hardware/sistema operativo, es decir, en mltiples plataformas en los nodos de un sistema distribuido. El sistema operativo que se ejecuta en un cierto Nodo (un ncleo junto con los servicios asociados de nivel de usuario, por ejemplo bibliotecas) proporciona dentro de ese nodo su propia imagen sobre las abstracciones de los recursos hardware locales de procesamiento, de almacenanamiento y de comunicacin. El middleware utiliza una combinacin de esos recursos locales para implementar los mecanismos de invocacin remota entre objetos o procesos en los nodos.

Figura 6.1 Niveles del sistema

Applications, services Middleware

OS: kernel, libraries & servers

OS1 Processes, threads, communication, ... Computer & network hardware Node 1

OS2 Processes, threads, communication, ... Computer & network hardware Node 2

Platform

Middleware comn para proporcionar infraestructura distribuida para aplicaciones y servicios.

Niveles del sistema

Los ncleos y el proceso servidor son los componentes que gestionan los recursos y los presentan a los clientes a travs de una interfaz de recursos. Esta interfaz debe tener al menos las siguientes caractersticas: Encapsulamiento: proporcionar un servicio de interfaz til sobre los recursos, un conjunto de operaciones que cubra las necesidades de los clientes. Los detalles del tipo de gestin de la memoria o dispositivos utilizados para implementar los recursos deben ocultarse a los clientes. Proteccin: los recursos deben protegerse de los accesos no permitidos; por ejemplo, los archivos se protegen contra la lectura por parte de usuarios que no tengan dicho permiso, los registros de los dispositivos se protegen de los procesos de usuario.

Procesamiento concurrente: clientes pueden compartir mltiples recursos y acceder concurrentemente. Los gestores de dichos recursos son los responsables de conseguir transparencia en la concurrencia.

Niveles del sistema

Los clientes acceden a los recursos mediante: invocaciones a un mtodo remoto de un objeto que reside en un servidor llamadas al sistema en el ncleo. El mecanismo de acceso a un recurso encapsulado se denomina mecanismo de invocacin, independientemente de cmo est implementado. Una combinacin de bibliotecas, ncleos y servidores pueden utilizarse para realizar las siguientes tareas de invocacin: Comunicacin: los parmetros de operacin y los resultados deben pasarse hacia y desde los gestores de recursos, respectivamente, utilizando una red o bien dentro del computador. Planificacin: cuando se invoca una cierta operacin, su procesamiento debe planificarse dentro del ncleo o del servidor.

Figura 6.2 Funcionalidad bsica del sistema operativo

Process manager

Communication manager

Thread manager Supervisor

Memory manager

Funcionalidad bsica del sistema operativo

Gestor de procesos: gestiona la creacin y las diferentes operaciones sobre procesos. Un proceso es una unidad de gestin de recursos que incluye un espacio de direcciones y uno o ms hilos. Gestor de hilos: incluye la creacin, sincronizacin y planificacin de hilos. Los hilos son actividades planificables asociadas a procesos. Gestor de las comunicaciones: comunicaciones entre hilos asociados a diferentes procesos en un mismo computador. Algunos ncleos tambin soportan comunicaciones entre hilos asociados a procesos remotos. Otros ncleos no manejan el concepto de computador remoto de forma que deben aadirse servicios adicionales para las comunicaciones externas.

Gestor de memoria: gestin de memoria fsica y virtual.

Funcionalidad bsica del sistema operativo

Supervisor: resolucin de interrupciones, interrupciones internas de llamada al sistema y excepciones; control de la unidad de gestin de memoria y de las antememorias (cach), hardware; manipulacin de registros del procesador y de la unidad en punto flotante. A todo se le llama Nivel de Abstraccin del Hardware en Windows NT.

Procesos e Hilos

Un proceso consiste en un entorno de ejecucin formado por uno o ms hilos.

Un hilo es una abstraccin del sistema operativo asociada a una actividad. Un entorno de ejecucin equivale a una unidad de gestin de recursos: una coleccin de recursos locales gestionados por el ncleo sobre los objetos que tienen acceso los hilos. Un entorno de ejecucin consiste bsicamente de los siguientes elementos: Un espacio de direcciones. Recursos de comunicacin y sincronizacin de hilos, como semforos e interfaces de comunicacin (por ejemplo, sockets). Recursos de alto nivel, como archivos abiertos y ventanas.

Procesos e Hilos

Los hilos pueden crearse y destruirse de forma dinmica, segn se necesite. El principal propsito para la existencia de mltiples hilos de ejecucin es maximizar el grado de ejecucin concurrente entre las diferentes operaciones, permitiendo as habilitar el solapamiento del cmputo con la entrada-salida y el procesamiento concurrente en los multiprocesadores.

til en los servidores en los que el procesamiento concurrente de las solicitudes de los clientes pueden reducir la tendencia de los servidores y convertirse en cuellos de botella. Por ejemplo, un hilo puede procesar una solicitud de un cliente mientras que un segundo hilo est sirviendo otra solicitud est esperando por la finalizacin de un acceso a disco para poder terminar.
Un entorno de ejecucin proporciona proteccin contra los hilos externos de forma que datos y otros recursos contenidos en l sean inaccesibles para los hilos residentes en otros entornos de ejecucin.

Figura 6.3 Espacios de direcciones

2N

Auxiliary regions

Stack

Heap

Text 0

Espacios de direcciones

Un espacio de direcciones, es una unidad de gestin de la memoria virtual de un proceso. Est formado por una o ms regiones, separadas por reas de memoria virtual inaccesibles. Una regin es una zona de memoria virtual contigua, accesible por los hilos del proceso propietario. Las regiones no se solapan. Hay que resaltar la distincin entre regiones y sus contenidos. Cada regin se caracteriza por las siguientes propiedades: . Su tamao (su direccin virtual ms baja y su tamao). . Los permisos de lectura/escritura/ejecucin para los hilos del proceso. . Una indicacin de crecimiento hacia arriba o hacia abajo.

Espacios de direcciones

Este modelo est orientado a pginas, no a segmentos. Las regiones, al contrario que los segmentos, podran eventualmente solaparse si su tamao se extendiera. Entre las regiones se dejan huecos para permitir su crecimiento. Un espacio de direcciones como un conjunto disperso de regiones disjuntas es una generalizacin del espacio de direcciones de UNIX, el cual est formado por tres regiones: una regin de texto de tamao fijo, y no modificable, que contiene el cdigo del programa; un montn (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 nmero indeterminado de regiones tiene su razn de ser en varios factores. Uno de ellos es la necesidad de que haya pilas separadas para cada hilo.

Espacios de direcciones

La necesidad de compartir memoria entre procesos, o entre procesos y el ncleo, es otro factor que deriva en la necesidad de regiones adicionales en el espacio de direcciones. Una regin de memoria compartida (abreviada regin compartida) es aquella en la que se asocia la misma memoria fsica a una o ms 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 los siguientes: Bibliotecas: el cdigo de las bibliotecas puede llegar a ser muy grande y se desperdicia cantidad considerable de memoria si se cargaran de forma separada en cada proceso que utilizase. Por el contrario, varios procesos pueden compartir una sola copia del cdigo de las bibliotecas empleando una regin compartida del espacio de direcciones.

Espacios de direcciones

Ncleo: frecuentemente el cdigo y los datos del ncleo se corresponden dentro del espacio direcciones en las mismas posiciones. Cuando un proceso realice una llamada al sistema, o si bien cuando se genere una excepcin, no habr necesidad de conmutar a un nuevo conjunto de direcciones.

Comparticin de datos y comunicacin: entre dos procesos, o bien entre un proceso y el ncleo, se puede necesitar compartir datos para cooperar en la realizacin de una cierta tarea. Es ms eficiente utilizar regiones de direcciones compartidas en lugar de intercambiar los datos mediante mensajes.

Creacin de un proceso nuevo

Para un sistema distribuido el diseo del mecanismo de creacin de un proceso debe tener en cuenta la utilizacin de mltiples computadores; de esta forma la infraestructura de gestin de procesos se divide en servicios de sistema separados. La creacin de un proceso nuevo puede separarse en dos aspectos independientes: La eleccin del computador destino. Por ejemplo, el nodo puede elegirse entre varios de un grupo (clster) de computadores que actan como servidores de computacin. La creacin de un entorno de ejecucin (y la de un hilo inicial en l).

Creacin de un proceso nuevo

Eleccin del nodo de proceso. En general, las polticas de localizacin de procesos varan desde aquellas que siempre lanzan los procesos nuevos en la estacin de trabajo originaria hasta aquellos que comparten la carga de procesamiento entre un conjunto de computadores. La poltica de transferencia decide si un proceso nuevo debe ubicarse en el nodo local o en un nodo remoto. Depender de la ocupacin del nodo local. La poltica de ubicacin determina qu nodo alojar un proceso nuevo seleccionado para transferirse. Esta decisin puede depender de las cargas relativas de los nodos, de su arquitectura y de algn recurso especfico que posea. El sistema V y Sprite proporcionan mandatos de usuario para lanzar programas en estaciones de trabajo ociosas elegidas por el sistema operativo. En el sistema Amoeba el servidor de ejecucin elige para cada proceso un nodo de entre un conjunto de procesadores compartidos.

Creacin de un proceso nuevo

Las polticas de localizacin de procesos pueden ser estticas o adaptativas.

Las primeras operan sin tener en consideracin el estado actual del sistema, aunque su diseo tiene en cuenta las caractersticas esperadas para el sistema a largo plazo.

Se basan en anlisis matemticos orientados a la optimizacin de ciertos parmetros como la productividad global de procesos. Pueden ser deterministas (el nodo A debe siempre transferir procesos al nodo B) o probabilsticos (el nodo A debe transferir procesos a cualquiera de los nodos B-E de forma aleatoria). Por otra parte las polticas adaptativas aplican reglas heursticas para tomar las decisiones de ubicacin basndose en factores de tiempo de ejecucin no predecibles, como la medida de la carga en cada nodo.

Creacin de un proceso nuevo

Los sistemas de comparticin de carga pueden ser centralizados, jerrquicos o descentralizados. En el primer caso existe un gestor de carga, mientras que en el segundo hay varios, organizados en una estructura arborescente. Los gestores de carga consiguen informacin sobre los nodos y la usan para asignar nuevos procesos a esos nodos. En los sistemas jerrquicos, estos gestores toman las decisiones de localizacin de procesos sobre aquellos nodos con mayor profundidad posible en el rbol; sin embargo los gestores pueden intercambiarse procesos a travs de un ancestro comn, aunque siempre bajo determinadas condiciones de carga. En un sistema de comparticin de carga descentralizado los nodos intercambian informacin entre ellos directamente para tomar las decisiones de localizacin.

Creacin de un proceso nuevo

Creacin de un nuevo entorno de ejecucin. Una vez que ha sido seleccionado el computador, el nuevo proceso necesita un entorno de ejecucin formado por un espacio de direcciones iniciado con una serie de contenidos (y probablemente otros recursos como archivos abiertos por defecto).

Dos definiciones e iniciacin de espacio de direcciones de un proceso creado:

Utilizado cuando el espacio de direcciones tiene un formato definido estticamente. Por ejemplo, puede contener nicamente la regin de texto de un programa, el montn y la pila. En este caso las regiones del espacio de direcciones se crean utilizando una lista donde se especifica su tamao. Las regiones del espacio de direcciones se inicializan utilizando el archivo ejecutable o bien con ceros, segn corresponda.

Creacin de un proceso nuevo

Alternativamente el espacio de direcciones puede definirse respecto a un entorno de ejecucin existente. Por ejemplo, para el caso de la semntica fork de UNIX, el proceso hijo que se acaba de crear comparte fsicamente la regin de texto del padre y tiene sus regiones montn y pila que son una copia de las correspondientes del padre en extensin (al igual que en sus contenidos iniciales). Este esquema se ha generalizado de forma que cada regin del proceso padre puede ser heredada por el proceso hijo. Una regin heredada puede, o bien ser compartida, o bien copiarse desde la regin del padre. Cuando el padre y el hijo comparten una regin, los marcos de pgina (unidades de memoria fsica que se corresponden con las pginas de memoria virtual) pertenecientes a la regin del padre concuerdan simultneamente con las correspondientes regiones del hijo.

Creacin de un proceso nuevo

Sean dos regiones RA y RB, cuya memoria es compartida a travs de copia en escritura entre dos procesos. Supongamos que el proceso A configura su regin RA para ser heredada en la copia por su hijo, el proceso B, y que la regin RB fue, por lo tanto, creada en el proceso B.
Suponemos, que las pginas que pertenecen a la regin A residen en memoria. Inicialmente todos los marcos de pgina asociados con las regiones se comparten mediante las tablas de pginas de los dos procesos. Las pginas estn inicialmente protegidas contra escritura a nivel del hardware incluso si pertenecen a regiones que tienen privilegios lgicos de escritura. Si un hilo en cualquier proceso intenta modificar los datos se genera una excepcin hardware llamada fallo o falta de pgina. Supongamos que el proceso B intent la escritura. El gestor de faltas de pginas localiza un nuevo marco para el proceso B y copia los datos del marco original en l byte a byte.

Creacin de un proceso nuevo

El nmero del marco antiguo es reemplazado por el nmero del nuevo marco en la tabla de pginas de un proceso y el nmero del marco antiguo se deja en la tabla de pginas del otro proceso. Las dos pginas equivalentes en los procesos A y B tienen ahora permisos de escritura al nivel de hardware. Tras las operaciones descritas, la instruccin de modificacin del proceso B puede continuar.

Figura 6.4 Copia en escritura

Process As address space

Process Bs address space

RA

RB copied from RA

RB

Kernel Shared frame B's page table

A's page table

a) Before write

b) After write

Figura 6.5 Clientes y servidores con hilos

Thread 2 makes requests to server Thread 1 generates results Receipt & queuing

Input-output

T1 Requests N threads Client Server

Hilos

El servidor tiene un conjunto formado por uno o ms hilos cada uno de los cuales, y de forma repetitiva, toma una solicitud de la cola de solicitudes recibidas y la procesa. Adems se supone, que cada hilo aplica el mismo procedimiento para procesar solicitudes. Supongamos que cada solicitud necesita, por trmino medio, 2 milisegundos de procesamiento y 8 milisegundos de entrada-salida para que el servidor realice las lecturas desde el disco (no existe cach). Supongamos adems temporalmente que el servidor se ejecuta en un computador con un nico procesador . Estudiemos la productividad mxima del servidor medida en solicitudes de cliente manejadas por segundo, en funcin del nmero de hilos. Si un nico hilo debe realizar todo el proceso el tiempo de retorno para manejar cualquier solicitud es de 2 + 8 = 10 milisegundos, por medio, de forma que este servidor podr atender a 100 clientes por segundo.

Hilos

Ahora considrese qu ocurre cuando el servidor dispone de dos hilos. Se asume que los hilos se pueden planificar de forma independiente, es decir, un hilo puede planificarse cuando otro pasa a estado bloqueado por una operacin de entradasalida. El hilo nmero dos puede procesar una segunda solicitud mientras el hilo nmero uno est bloqueado, y viceversa. Esto incrementa la productividad del servidor. Desgraciadamente, en nuestro ejemplo los hilos se bloquean sobre una nica unidad de disco. Si todas las solicitudes al disco se envan en serie y necesitan 8 milisegundos cada una, la productividad mxima resulta ser de

1.000/8 = 125 solicitudes por segundo

Hilos

Supngase ahora que existe una cach de bloques de disco. El servidor mantiene los datos ledos en bferes dentro de su espacio de direcciones; el hilo del servidor encargado de la obtencin de los datos examina previamente la cach compartida evitndose el acceso al disco si los datos se encuentran all. Si se consigue una tasa de aciertos del 75 %, el tiempo medio de E/S de cada solicitud se reduce a (0,75 x 0 + 0,25 x 8) = 2 milisegundos, y la productividad mxima terica se incrementa hasta 500 solicitudes por segundo. Sin embargo si el tiempo medio de procesador por cada solicitud se incrementa hasta 2,5 mili segundos por solicitud debido a la gestin de cach no se llega a la cantidad anterior. El servidor, limitado por el procesador, podr gestionar un mximo de 1.000/2,5 = 400 solicitudes por segundo.

Hilos

Arquitecturas para servidores multi-hilo. El multi-hilo permite a los servidores maximizar su productividad, medida como el nmero de solicitudes procesadas por segundo. La arquitectura de asociacin de trabajadores. En su forma ms simple, el servidor, durante la inicializacin, crea un conjunto fijo de hilos de trabajadores para procesar las solicitudes. El mdulo marcado como receptor y gestor de cola en la Figura 6.5 se implementa normalmente como un hilo de E/S, el cual recibe solicitudes desde una coleccin de sockets o puertos y las sita en una cola de solicitudes compartidas para ser recuperadas por los trabajadores. En ocasiones existe un requisito para tratar las solicitudes con prioridades cambiantes. Por ejemplo, un servidor web corporativo debiera procesar las solicitudes con diferentes prioridades en funcin del tipo de cliente del que se derive la solicitud.

Arquitecturas alternativas de servidor basadas en hilos

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 el acceso a una cola compartida y la productividad se puede maximizar potencialmente dado que el hilo de E/S puede crear tantos trabajadores como solicitudes pendientes existan. Su desventaja es la sobrecarga debida a las operaciones de creacin y destruccin de hilos.
La arquitectura de hilo-por-conexin asocia un hilo a cada conexin. El servidor crea un nuevo hilo trabajador cuando un cliente realiza una conexin y lo destruye cuando el cliente cierra dicha conexin. En el intervalo, el cliente puede realizar mltiples solicitudes sobre la conexin, cuyo destino puede ser uno o ms objetos remotos.

Figura 6.6 Arquitecturas alternativas de servidor basadas en hilos

workers I/O remote objects

per-connection threads

per-object threads I/O remote objects

remote objects

a. Thread-per-request

b. Thread-per-connection

c. Thread-per-object

Arquitecturas alternativas de servidor basadas en hilos

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 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 sobrecargas pequeas en la gestin de los hilos en comparacin con la arquitectura de hilo-por-solicitud. Su desventaja es que los clientes pueden sufrir retrasos si un hilo trabajador tiene varias solicitudes pendientes mientras que otro hilo puede estar parado sin trabajo que realizar.

Figura 6.7 Estado asociado con los entornos de ejecucin y los hilos

Programacin de hilos

Programacin de hilos. La programacin de hilos equivale a la programacin concurrente tal y como ha sido estudiada tradicionalmente, por ejemplo, en el mbito de sistemas operativos.
De la misma forma que en cualquier implementacin de hilos, Java proporciona mtodos para la creacin, destruccin y sincronizacin de hilos. La clase de Java Thread incluye los mtodos de gestin mostrados en la Figura 6.8. Los mtodos de sincronizacin estn en la Figura 6.9.

Figura 6.8 Mtodo constructor y de gestin de hilos Java

Thread(ThreadGroup group, Runnable target, String name) Creates a new thread in the SUSPENDED state, which will belong to group and be identified as name; the thread will execute the run() method of target. setPriority(int newPriority), getPriority() Set and return the threads priority. run() A thread executes the run() method of its target object, if it has one, and otherwise its own run() method (Thread implements Runnable). start() Change the state of the thread from SUSPENDED to RUNNABLE. sleep(int millisecs) Cause the thread to enter the SUSPENDED state for the specified time. yield() Enter the READY state and invoke the scheduler. destroy() Destroy the thread.

Figura 6.9 Llamadas de sincronizacin de hilos en Java

thread.join(int millisecs) Blocks the calling thread for up to the specified time until thread has terminated. thread.interrupt() Interrupts thread: causes it to return from a blocking method call such as sleep().

object.wait(long millisecs, int nanosecs) Blocks the calling thread until a call made to notify() or notifyAll() on object wakes the thread, or the thread is interrupted, or the specified time has elapsed.
object.notify(), object.notifyAll() Wakes, respectively, one or all of any threads that have called wait() on object.

Sincronizacin de hilos

La programacin de un proceso multi-hilo debe realizarse de manera cuidadosa. La principal dificultad radica en la comparticin de objetos y en las tcnicas utilizadas para la coordinacin y cooperacin de los hilos. Las variables locales de cada hilo en sus mtodos; son privadas del hilo, es decir, los hilos tienen pilas privadas. Sin embargo, los hilos no disponen de copias privadas de las variables (clases) estticas o de las variables instancia de objetos.

Suponga, por ejemplo, las colas compartidas descritas previamente, 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.

Planificacin de hilos

Una distincin importante entre modelos de planificacin de hilos es si es apropiativa o no apropiativa. En la planificacin apropiativa un hilo puede suspenderse en cualquier punto para dejar paso a otro hilo, incluso aunque el hilo pudiera seguir en ejecucin. En la planificacin no apropiativa (a veces llamada planificacin de corrutinas), un hilo se ejecuta hasta que l mismo realiza una invocacin al sistema de gestin de hilos (por ejemplo, una llamada al sistema), siendo en ese momento cuando el sistema puede desalojarle para planificar otro hilo. La ventaja de la planificacin no apropiativa es que cualquier seccin de cdigo que no contenga una llamada al sistema de gestin de hilos es automticamente una seccin crtica. As se pueden evitar cmodamente las condiciones de competencia.

Planificacin de hilos

Por otro lado, los hilos planificados de forma no apropiativa no pueden aprovechar los sistemas multiprocesador, ya que se ejecutan de forma exclusiva. al sistema de gestin de hilos. Es preciso tener cuidado con las secciones de cdigo grandes que no contengan llamadas al sistema. El programador puede necesitar insertar invocaciones a yield() cuya funcin es la de permitir que otros hilos puedan planificarse y progresar en su trabajo. Los hilos planificados de forma no apropiativa no son aptos para su uso en aplicaciones en tiempo real, ya que en stas los eventos llevan asociados tiempos absolutos en los que deben procesarse. Java no soporta, por defecto, el procesamiento en tiempo real, a pesar de que existen implementaciones de tiempo real [www.rtj.org].

Implementacin de hilos

Muchos ncleos dan soporte para procesos multi-hilo de forma nativa, incluyendo Windows NT, Solaris, Mach y Chorus. Estos ncleos proporcionan las llamadas al sistema de creacin y gestin de hilos, y planifican de forma individual los hilos. Otros ncleos disponen nicamente de la abstraccin de procesos monohilo. Los procesos multi-hilo deben entonces implementarse en una biblioteca de procedimientos enlazada a los programas de aplicacin. En estos casos el ncleo no conoce estos hilos de nivel de usuario y por lo tanto no puede planificarlos independientemente. Una biblioteca en tiempo de ejecucin de hilos organiza su planificacin. Un hilo podra bloquear el proceso, y por lo tanto todos los hilos dentro de l, si realiza una llamada bloqueante al sistema, de forma que debe usarse la entrada-salida asncrona (no bloqueante) del ncleo subyacente. Anlogamente la implementacin puede utilizar los temporizadores proporcionados por el ncleo y las posibilidades de interrupciones software para realizar una comparticin del tiempo entre hilos.

Implementacin de hilos

Cuando el ncleo no tiene soporte para procesos multi-hilo, las implementaciones al nivel de usuario de los hilos adolecen de estos problemas: Los hilos de un cierto proceso no pueden aprovecharse de la existencia de un multiprocesador. Un hilo que genera una falta de pgina bloquea el proceso completo y todos los hilos dentro de l. Los hilos de diferentes procesos no pueden planificarse de acuerdo a un nico criterio de prioridad relativa.

Implementacin de hilos

El ncleo es responsable de la asignacin de procesadores virtuales a procesos. El nmero de procesadores virtuales asignados a un proceso depende de diferentes factores como los requisitos de la aplicacin, prioridades relativas y la demanda total en los procesadores. En la Figura 6.10a se muestra un ejemplo de una mquina con tres procesadores en la que el ncleo asigna un procesador virtual un proceso A, ejecutando un trabajo de prioridad relativamente baja, y dos procesadores virtuales al proceso B. Se llaman procesadores virtuales porque el ncleo puede asignar procesadores fsicos diferentes a cada proceso a lo largo del tiempo, mientras se garantice el nmero de procesadores asignados. El nmero de procesadores virtuales asignados a un proceso puede variar. Los procesos pueden devolver un procesador virtual que han dejado de necesitar; adems pueden solicitar procesadores virtuales extra. Por ejemplo, si el proceso A ha solicitado un procesador virtual extra y B termina, entonces el ncleo asigna uno a A.

Figura 6.10 Activaciones del planificador

Process A

Process B Process Kernel

P added SA preempted SA unblocked SA blocked

Virtual processors

Kernel

P idle P needed

A. Assignment of virtual processors to processes

B. Events between user-level scheduler & kernel Key: P = processor; SA = scheduler activation

Implementacin de los hilos

En la Figura 6.10b se muestra que un proceso notifica al ncleo la ocurrencia de uno de estos dos tipos de eventos.

Adems la Figura 6.10b muestra que el ncleo notifica al proceso cundo ocurre un evento de entre cuatro posibles. Una activacin del planificador (SA) es una llamada desde el ncleo a un proceso que sirve para notificar al planificador del proceso la ocurrencia de un evento. La ejecucin de esta manera de cdigo desde un nivel inferior (el ncleo) es tambin conocida como retrollamada (upcall). El ncleo crea un SA cargando los registros fsicos del procesador con un contexto que provoca la ejecucin de cdigo en el proceso, en una direccin de procedimiento designada por el planificador de nivel de usuario. Una SA puede de esta forma considerarse como una unidad de asignacin de tiempo en un procesador virtual. El planificador de nivel de usuario tiene la tarea de asignar sus hilos PREPARADOS al conjunto de SA que en ese momento se estn ejecutando en l. El nmero de SA es como mximo el nmero de procesadores virtuales que el ncleo ha asignado al proceso.

Comunicacin e invocacin

Primitivas de sincronizacin. Algunos ncleos diseados para sistemas distribuidos han proporcionado primitivas de comunicacin similares a los tipos de invocacin RMI y RPC. Por ejemplo Amoeba proporciona hazOperacin, tomarPeticin y enviaRespuesta como primitivas. Amoeba, el sistema V y Chorus proporcionan primitivas de comunicacin en grupo. La insercin de funcionalidad de comunicacin de relativamente alto nivel en el ncleo tiene la ventaja de la eficiencia.

Si, por ejemplo, el middleware proporciona RMI sobre sockets (TCP) conectados en UNIX, entonces un cliente debe realizar dos llamadas al sistema de comunicaciones (write y read sobre un socket) para cada invocacin remota. Sobre Amoeba solamente se necesitara una nica llamada a hazOperacin. El ahorro en la sobrecarga de las llamadas al sistema tiende a ser mayor con la comunicacin en grupo.

Comunicacin e invocacin

En la prctica, es el middleware y no el ncleo el que proporciona la mayor parte de recursos de comunicacin de alto nivel que aparecen en los sistemas actuales, incluyendo RPC/RMI, notificacin de eventos y comunicacin de grupos. El desarrollo de este software tan complejo al nivel de usuario es mucho ms sencillo que desarrollarlo para el ncleo. Los programadores normalmente implementan el middleware sobre los sockets proporcionando acceso a los protocolos estndar de Internet, a menudo mediante sockets TCP pero a veces con sockets UDP no orientados a conexin. Las principales razones para la utilizacin de sockets son la portabilidad e interoperabilidad: el middleware debe operar sobre la mayor parte de los sistemas operativos ampliamente utilizados y todos los sistemas operativos comunes del tipo UNIX y de la familia Windows proporcionan un API de sockets similar proporcionando acceso a los protocolos TCP y UDP.

Comunicacin e invocacin

Protocolos y apertura. Uno de los principales requisitos de los sistemas operativos es el de proporcionar protocolos estndar que permitan la intercomunicacin entre implementaciones middleware sobre diferentes plataformas. Algunos ncleos de investigacin 80 incorporaban sus propios protocolos de red ajustados para las interacciones con RPC, siendo ejemplos notables Amoeba RPC [van Renesse y otros 1989], VMTP [Cheriton 1986] y Sprite RPC [Ousterhout y otros 1988]. Sin embargo, estos protocolos no fueron ampliamente usados fuera de sus entornos de investigacin nativos. Por el contrario, los diseadores de los ncleos Mach 3.0 y Chorus decidieron dejar la eleccin de los protocolos de red como una cuestin abierta. Estos ncleos proporcionan un sistema de paso de mensajes nicamente entre procesos locales y dejan el procesamiento del protocolo de red a un servidor que se ejecuta sobre el ncleo.

Comunicacin e invocacin

Dados los requisitos diarios de acceso a Internet, es necesario que los sistemas operativos sean compatibles al nivel de TCP y UDP para todo, excepto para los dispositivos de red ms pequeos. Adems el sistema operativo debe habilitar al middleware para que pueda sacar partido de los nuevos protocolos de bajo nivel.

Por ejemplo, los usuarios quieren beneficiarse de las tecnologas inalmbricas como las transmisiones por infrarrojos y por radiofrecuencia (RF), preferiblemente sin tener que actualizar sus aplicaciones. Esto supone que puedan integrarse los protocolos correspondientes, como IrDA para redes de infrarrojos y BlueTooth o HomeRF para las redes RF .

Prestaciones de la invocacin

Las prestaciones de la invocacin son un factor crtico en el diseo de sistemas distribuidos. Cuanto ms separan los diseadores de la funcionalidad entre espacios de direcciones, ms invocaciones remotas se necesitan. Los clientes y servidores pueden realizar millones de operaciones asociadas a invocaciones a lo largo de su vida, de forma que pequeas fracciones de mili segundos son relevantes en los costes de invocacin. Las tecnologas de red continan mejorando pero los tiempos de invocacin no han decrecido en proporcin con el incremento del ancho de banda de las redes. Las implementaciones de RPC y RMI han sido un tema de estudio debido a la amplia aceptacin de estos mecanismos para el procesamiento cliente-servidor de propsito general. Mucha de esta investigacin ha tenido como objetivo el estudio de las invocaciones en la red, y particularmente sobre cmo los mecanismos de invocacin pueden aprovecharse de las redes de altas prestaciones

Prestaciones de la invocacin

Costos de invocacin. La llamada y la invocacin a un procedimiento convencional, y a un mtodo convencional, respectivamente, la realizacin de una llamada al sistema, el envo de un mensaje, la invocacin a un procedimiento remoto y la invocacin a un mtodo remoto son ejemplos de mecanismos de invocacin. Cada mecanismo provoca que se ejecute cdigo fuera del mbito del procedimiento u objeto que invoca. Cada invocacin supone, en general, la comunicacin de argumentos a este cdigo y la devolucin de datos al que invoca. Los aspectos que afectan en mayor medida a las prestaciones de los mecanismos de invocacin, aparte de si son o no sncronos, son si stos suponen una transicin de dominio (es decir, si se cambia de espacio de direcciones), si implican comunicaciones a travs de la red y si suponen planificacin y conmutacin de hilos.

Figura 6.11 Invocaciones entre espacios de direcciones

(a) System call Control transfer via trap instruction Control transfer via privileged instructions User Kernel Protection domain boundary

Thread

(b) RPC/RMI (within one computer)

Thread 1

Thread 2

User 1
(c) RPC/RMI (between computers)

Kernel

User 2

Thread 1

Network

Thread 2

User 1 Kernel 1 Kernel 2

User 2

Prestaciones de la invocacin

Invocacin utilizando la red. Un RPC nulo (de igual modo, un RMI nulo) se define como un RPC sin parmetros que ejecuta un procedimiento nulo y no devuelve valores. Su ejecucin supone un intercambio de mensajes que lleva muy pocos datos de sistema y ningn dato de usuario. El tiempo necesario para un RPC nulo entre dos procesos de usuario ejecutndose en un PC de 500 MHz sobre una LAN a 100 megabits/segundo es del orden de decenas de milisegundos. A efectos de comparacin, una llamada a un procedimiento convencional nulo puede suponer una pequea fraccin de microsegundo.
En un RPC nulo se enva alrededor de un total de 100 bytes un ancho de banda de 100 megabits/segundo, el tiempo total de transferencia sobre la red es de alrededor de 0,01 mili segundos para esa cantidad de datos. Los costos de las invocaciones nulas (RPC, RMI) tienen mucha importancia ya que miden una sobrecarga fija, la latencia.

Prestaciones de la invocacin

Considrese un RPC que solicita una cierta cantidad de datos desde un servidor. Tiene un argumento entero de entrada que especifica el tamao de los datos solicitados. Tiene dos argumentos de salida, un entero que indica xito o fallo (el cliente puede haber proporcionado un tamao invlido) y, cuando la invocacin ha tenido xito, una serie de bytes desde el servidor. En la Figura 6.12 se muestra, de forma esquemtica, el retardo del cliente en comparacin con el tamao de los datos solicitados. El retardo es, aproximadamente, proporcional al tamao, hasta que este tamao alcanza un umbral del tamao del paquete de red. Por encima de este umbral debe enviarse al menos un paquete adicional para llevar los datos extra. En funcin del protocolo, puede usarse otro paquete ms para reconocer la llegada de este paquete extra. Los saltos en el grfico ocurren cada vez que se incrementa el nmero de paquetes.

Prestaciones de la invocacin

El retardo no es el nico valor de inters en una implementacin de RPC: tambin est implicado el ancho de banda de RPC ( o productividad) cuando hay que transferir datos en masa.Se trata de la tasa de transferencia de datos entre computadores en un nico RPC. Si examinamos la Figura 6.12 se puede observar que el ancho de banda es relativamente bajo para pequeas cantidades de datos, cuando las sobrecargas fijas de procesamiento predominan. Segn se incrementa la cantidad de datos, el ancho de banda tambin se incrementa ya que las sobrecargas pasan a ser menos significativas. Gokhale y Schmidt [1996] calcularon una productividad de alrededor de 80 megabits/segundo en la transferencia de 64 kilobytes en un nico RPC entre estaciones de trabajo sobre una red ATM con un ancho de banda nominal de 155 megabits/segundo. Para transferir 64 kilobytes se necesita alrededor de 0,8 milisegundos lo cual est en el mismo orden de magnitud que el tiempo calculado anteriormente para un RPC nulo sobre una red Ethernet a 100 megabits/segundo.

Figura 6.12 Retardo del RPC en funcin del tamao del parmetro

RPC delay

Requested data size (bytes) 0 1000 Packet size 2000

Prestaciones de la invocacin Invocacin dentro de un computador. Bershad y otros [ 1990] realizaron un estudio, mostraba que, en la instalacin examinada, la mayor parte de las invocaciones entre espacios de direcciones distintos se realizaban dentro de un computador y no, como es de esperar en una instalacin cliente-servidor, entre diferentes computadores. La tendencia de situar la funcionalidad del servicio dentro de servidores de nivel de usuario implica que cada vez ms invocaciones se realizarn a un proceso local. Esto se acenta con polticas de cach ms agresivas cuando sea factible que los datos requeridos por un cliente estn almacenados en un servidor local. El costo de un RPC dentro de un computador est tomando cada vez ms importancia como parmetro de prestaciones del sistema. Estas consideraciones sugieren que el caso local debera optimizarse. La Figura 6.11 sugiere que una invocacin a un espacio de direcciones diferente se implemente dentro de un mismo computador exactamente de la misma forma que entre computadores diferentes, excepto en que el sistema de paso de mensaje subyacente acta de forma local. Por lo tanto, ste ha sido a menudo el modelo implementado. Bershad y otros [ 1990] desarrollaron un mecanismo de invocacin ms eficiente, llamado RPC de peso ligero (LRPC, light weight RPC), para el caso de dos procesos en la misma mquina.

Prestaciones de la invocacin

El diseo de LRPC se basa en optimizaciones copia de datos y de la planificacin de los hilos. En primer lugar se dieron cuenta que debera ser ms eficiente la utilizacin de regiones de memoria compartida para la comunicacin cliente-servidor, con una regin (privada) diferente entre el servidor y cada uno de sus clientes. Esta regin contiene una o ms pilas A En lugar de parmetros RPC copindose entre el espacio de direcciones del ncleo y del usuario involucrado, el cliente y el servidor pueden pasarse argumentos y devolver valores directamente a travs de una pila A. Los resguardos del cliente y del servidor utilzan la misma pila. En LRPC, los argumentos se copian una sola vez: cuando son empaquetados en la pila A. En un RPC equivalente, son copiados cuatro veces: desde la pila del resguardo del cliente hacia un mensaje; desde el mensaje al bfer del ncleo; desde el bfer del ncleo al mensaje del servidor; desde el mensaje del servidor a la pila del resguardo del servidor.

Prestaciones de la invocacin

En la Figura 6.13 se muestra una invocacin. Un hilo cliente entra en el entorno de ejecucin del servidor realizando inicialmente una interrupcin software hacia el ncleo ya continuacin presentando al ncleo una capacidad. El ncleo lo comprueba y nicamente permite un cambio de contexto hacia un procedimiento vlido del servidor; si es vlido, el ncleo conmuta el contexto del hilo para llamar al procedimiento en el entorno de ejecucin del servidor. Cuando el procedimiento en el servidor termina, el hilo vuelve al ncleo, el cual conmuta el hilo hacia atrs, es decir, hacia el entorno de ejecucin del cliente. Hay que resaltar que tanto los clientes como el servidor emplean procedimientos resguardo para ocultar a los programadores de aplicaciones los detalles descritos

Figura 6.13 Una invocacin a procedimiento remoto de peso ligero

Client

Server

A stack

A 4. Execute procedure and copy results

1. Copy args

User Kernel

stub

stub

2. Trap to Kernel

3. Upcall

5. Return (trap)

Operacin asncrona

Realizando invocaciones concurrentemente. En el primer modelo el middleware proporciona nicamente invocaciones bloqueantes, sin embargo la aplicacin crea mltiples hilos para realizar estas invocaciones bloqueantes de forma concurrente. Un buen ejemplo de este tipo de aplicaciones son los navegadores web. Una pgina web normalmente contiene varias imgenes. El navegador debe pedir cada una de esas imgenes en solicitudes individuales de tipo HTTP GET (ya que los servidores web HTTP 1.0 estndar nicamente soportan solicitudes para recursos individuales). El navegador no necesita obtener las imgenes en una secuencia particular, de forma que realiza solicitudes concurrentes, normalmente hasta cuatroa la vez. De esta forma el tiempo empleado para completar todas las solicitudes de imgeneses normalmente menor que el retardo de hacer las mismas solicitudes en serie.

Operacin asncrona

En la Figura 6.14 se muestran los beneficios potenciales del entrelazado de las invocaciones(del tipo de solicitudes HTTP) entre un cliente y un nico servidor en una mquina monoprocesador. En el caso serializado, el cliente empaqueta los argumentos, invoca la operacin Enva y espera hasta que la respuesta del servidor llegue; cuando eso ocurra ejecuta Recibe, desempaqueta y finalmente procesa los resultados. Despus de todo esto, puede realizar una segunda invocacin

En el caso concurrente, el primer hilo cliente empaqueta los argumentos y llama a la operacin Envo. El segundo hilo inmediatamente realiza la segunda invocacin. Cada hilo espera la recepcin de sus resultados. El tiempo total necesario tiende a ser menor que en el caso serializado , como se muestra en la figura. Beneficios similares se obtienen si los hilos cliente realizan solicitudes concurrentes a diferentes servidores; y si el cliente se ejecuta en un multiprocesador entonces se puede conseguir potencialmente una mayor productividad ya que el procesamiento de los dos hilos se puede realizar de forma solapada.

Figura 6.14 Temporizacin para invocaciones serializadas y concurrentes.

Serialised invocations process args marshal Send Concurrent invocations

process args marshal Send transmission process args marshal Send Receive unmarshal execute request marshal Send Receive unmarshal process results Receive unmarshal process results Receive unmarshal execute request marshal Send

Receive unmarshal process results process args marshal Send

Receive unmarshal execute request marshal Send Receive unmarshal execute request marshal Send

time

Receive unmarshal process results Client Server Client Server

Arquitectura del sistema operativo

Ncleos monolticos y microncleos. Existen dos ejemplos clave en el diseo de los ncleos: la aproximacin monoltica y la aproximacin microncleo. Estos diseos difieren bsicamente en la decisin sobre qu funcionalidad pertenece al ncleo y qu se deja al proceso servidor que puede ser cargado dinmicamente para ejecutarse sobre l. Se dice que el ncleo del sistema operativo UNIX es monoltico. Este trmino intenta sugerir el hecho de que es masivo: realiza todas las funciones bsicas del sistema operativo necesitando para ello del orden de megabytes de cdigo y datos, y en su composicin es indistinguible: est codificado de una forma no modular. El resultado es que en gran medida resulta intratable: es difcil alterar cualquier componente software individual para adaptarlo a los requisitos cambiantes. Un ncleo monoltico puede contener algunos procesos servidores que se ejecutan dentro de su espacio de direcciones, incluyendo servidores de archivos y de red. El cdigo que ejecutan estos procesos es parte de la configuracin estndar del ncleo.

Arquitectura del sistema operativo

Por el contrario, para el caso de un diseo microncleo, el ncleo proporciona nicamente las abstracciones ms bsicas, principalmente espacios de direcciones, hilos y comunicacin local entre procesos; el resto de servicios del sistema vienen dados por servidores que se cargan dinmicamente, precisamente en aquellos computadores del sistema distribuido que los requieran. Los clientes acceden a esos servicios del sistema utilizando los mecanismos de invocacin basados en mensajes proporcionados por el ncleo.

Figura 6.15 Ncleo monoltico y microncleo

S4

....... S1 S2 S3 S4 .......

S1

S2

S3

.......

Key: Server:

Monolithic Kernel

Microkernel

Kernel code and data:

Dynamically loaded server program:

Arquitectura del sistema operativo

El microncleo aparece como un nivel entre hardware y el que forman los principales componentes del sistema, llamados subsistemas. Si las prestaciones son el principal objetivo, en lugar de la portabilidad, entonces el middleware puede utilizar directamente los servicios del microncleo. En otro caso, utiliza un lenguaje con un subsistema de soporte en tiempo de ejecucin, o bien una interfaz de sistema operativo de alto nivel proporcionado por un subsistema de emulacin de sistema operativo.
Puede existir ms de una interfaz de llamadas al sistema (ms de un sistema operativo) a disposicin del programador en la misma plataforma. Esta situacin es una reminiscencia de la arquitectura del IBM 370, cuyo sistema operativo VM puede presentar varias mquinas virtuales completas a diferentes programas que se ejecutan en el mismo computador (monoprocesador).

Figura 6.16 El papel del microncleo

Middleware Language support subsystem Language support subsystem Microkernel Hardware OS emulation subsystem

....

The microkernel supports middleware via subsystems