3.2. Métodos de distribución de carga (hilos, tareas, procesos)
Un elemento que hemos ido delineando para los S.O.D., como alternativa al uso del administrador de procesos es un módulo que haga las veces de éste; lo denominaremos Gestor de recursos, es el módulo que atiende y administra un conjunto de recursos de un tipo particular. Para cada conjunto de recursos existe un número de políticas diferentes, pero tambien características comunes, de tal suerte que pueden agruparse en tareas de éste gestor
Hay en la actualidad varios modelos establecidos de gestión de recursos, Cliente/Servidor, tipo UNIX y el gestor por Modelo orientado a Objetos.
En la actualidad el problema del balanceo de carga ha sido abordado desde diferentes enfoques, con el propósito de disminuir al máximo el tiempo de ejecución de las aplicaciones ejecutadas. Aunque la carga de trabajo en un S.O.D. está planificada de antemano, sigue siendo un problema complejo, debido a la dificultad para lograr que las propuestas en las distribuciones de carga de trabajo sean fácilmente escalables, o que puedan correrse sobre sistemas heterogéneos. En general se recurre a la simplificación de trabajar con cluster's homogéneos (máquinas con software o hardware semejantes) y no al contrario.
El Gestor de Recursos tiene dos funciones generales:
1.- Planificación Global.
2.- Planificación Interna.
Tareas y procesos en sistemas distribuidos.
La planificación del procesador consiste de las técnicas para decidir los tiempos de CPU y la asignación de procesos en bloque, conocidos como tareas. A su vez la s tareas se integran bajo el concepto de trabajos, que mide el procesamiento porunidad de tiempo. Como puede verse estos conceptos corresponden a 3 Niveles de planificación, que tienen una naturaleza simbólica creciente. Generalmente se identifican tres niveles: el alto, em medio y el bajo. El nivel alto decide cómo poner a trabajar los conjuntos de procesos (tareas), escogiendo aquellos en una competencia por los recursos del sistema; el nivel intermedio decide que procesos se suspenden o reanudan para lograr ciertas metas de rendimiento, mientras que el planificador de bajo nivel es el que decide que proceso listo (y que en algún momento paso por los otros dos planificadores) es al que le toca pasar a ejecución.
Una estrategia de planificación busca que a los procesos les toquen sus turnos de ejecución oportunamente, sin que esto signifique una sobrecarga de trabajo para el planificador mismo. en otras palabras tenemos que limitar la complejidad del planificador a riesgo de que consuma tantos recursos que degraden las prestaciones del sistema. En general, se tienen cinco objetivos:
Justicia o Imparcialidad en el acceso a recursos. Todos los procesos deben ser tratados de la misma forma, y en algún momento obtienen su turno de ejecución o ventanas sucesivas periódicas de tiempo de ejecución hasta su terminación exitosa.
Maximizar la el procesamiento de datos de la aplicación. El sistema debe de finalizar el mayor numero posible de transacciones u operaciones por unidad de tiempo.
Maximizar el Tiempo de Respuesta: Cada usuario o proceso debe observar que el sistema les responde tarde o temprano a sus requerimientos.
Evitar el aplazamiento indefinido o ejecuciones inviables. Los procesos deben terminar en un plazo finito de tiempo.
Que el sistema sea predecible. Ante cargas de trabajo ligeras el sistema debe responder rápido y con cargas pesadas debe ir degradándose según cálculos establecidos. Otro punto de vista de esto es que si se ejecuta el mismo proceso en diversos nodos del sistema, la respuesta en todos los casos debe ser similar.
HILOS EN SISTEMAS DISTRIBUIDOS.
En los S.O.C. cada proceso tiene un espacio de memoria asignado y un flujo simple de control de ejecución, pero en un S.O.D. se prefiere tener múltiples flujos de ocntrol compartiendo un espacio de direccionamiento de recursos, corriendo en un esquema cuasi paralelo; por ello es apropiado hacer una implementación usando hilos y multihilos.
Un aspecto importante es que si un hilo de un programa necesita un dato para continuar ejecutándose, está en situación de hacer una llamada bloqueante, por cuya respuesta tendrá que esperar sin poder hacer nada mientras tanto. Por el contrario uha llamadas no bloqueantes al sistema consiste en que éste devuelve una especie de excepción indicando cuándo la información solicitada no está disponible; mas esto no es 100% seguro, porque aunque la aplicación no se detiene, la llamada se atenderá por completo en un momento futuro y solicitará la recepción de la respuesta al proceso en forma asíncrona, que es a fin de cuentas un bloqueo parcial, o en una llamada bloqueante, que detendrá el proceso.
Esta propiedad vuelve a los hilos particularmente atractivos para su uso dentro de sistemas distribuidos. Una llamada bloqueante se queda esperando a ser atendida es como una llamada telefónica, en cambio llamada no bloqueante es como un mensaje de correo, y esto opera en ambos sentidos de la comunicación.
Un hilo es un segmento de código que se ejecuta en forma paralela o cocuncurrente con el programa que lo mandó llamar, lo que le permite llevar a cabo tareas de software de manera independiente, sin distraer el flujo de ejecución de los módulos principales del programa, sino que se delega en subrutinas que corren en su propio contexto, paralelo e independiente; por lo tanto no son afectadas por el overhead de la aplicación principal.
Los HiIos también son conocidos como procesos ligeros o contextos de ejecución. Típicamente, cada Hilo controla un único aspecto dentro de un programa; pero todos los hilos pueden compartir recursos, al contrario de los esquemas monolíticos de administración de procesos en donde cada uno tiene su propia copia de código y datos.
Los sistemas operativos generalmente implementan hilos de dos maneras:
1.- Multihilo Apropiativo.
Permite al sistema operativo determinar cuándo debe haber un cambio de contexto.
La desventaja de esto es que el sistema puede hacer un cambio de contexto en un momento inadecuado, causando un fenómeno conocido como inversión de prioridades y otros problemas.
2.- Multihilo Cooperativo.
Depende del mismo hilo abandonar el control cuando llega a un punto de detención, lo cual puede traer problemas cuando el hilo espera la disponibilidad de un recurso.
Clientes Multihilos.
Sirven para esconder la latencia de comunicación a través de la red. Por
Desarrollar navegadores multihilos simplifica este hecho de forma considerable. Tan pronto como llega la página principal se pueden activar hilos que se encarguen de recuperar las demás partes. Cada hilo establece su propia conexión con el servidor. Mientras tanto el usuario advierte el retardo en las imágenes pero puede ir explorando el documento; pero si el servidor está saturado o es lento no se observarán mejoras notables en el rendimiento.
Cuando se usan clientes multihilos cada conexión puede ir a una réplica diferente del mismo servidor.
En este caso los distintos archivos se transmiten en paralelo asegurando que la página WEB completa se despliega en un tiempo más corto.
Servidores Multihilos.
El principal uso de la tecnología multihilos está del lado del servidor. Básicamente buscan mejorar el desempeño
(aún en servidores monoprocesador) y la forma cómo se estructura el servidor. Por ejemplo, en general un servidor de archivos espera una petición de entrada para una operación de archivo, posteriormente ejecuta la petición (operación bloqueante al disco) y luego envía la respuesta de regreso. Tenemos la alternativa del Modelo Servidor/Trabajador; Las peticiones son enviadas por los clientes hasta el servidor. Después de examinar la petición el hilo servidor elige un hilo trabajador sin utilizar y le encarga la petición. El hilo trabajador realiza la lectura, lo cual puede provocar que se suspenda hasta que los datos sean recuperados. Si el hilo se suspende, el procesador, selecciona otro para su ejecución.