3.

1 Procesos Procesadores Conceptos Básicos

Esta definición varía ligeramente en el caso de sistemas operativos multihilo,

donde un proceso consta de uno o más hilos, la memoria de trabajo (compartida
por todos los hilos) y la información de planificación. Cada hilo consta de
instrucciones y estado de ejecución.
Los procesos son creados y destruidos por el sistema operativo, así como también
este se debe hacer cargo de la comunicación entre procesos, pero lo hace a
petición de otros procesos. El mecanismo por el cual un proceso crea otro proceso
se denomina bifurcación (fork). Los nuevos procesos pueden ser independientes y
no compartir el espacio de memoria con el proceso que los ha creado o ser
creados en el mismo espacio de memoria.
En los sistemas operativos multihilo es posible crear tanto hilos como procesos. La
diferencia estriba en que un proceso solamente puede crear hilos para sí mismo y
en que dichos hilos comparten toda la memoria reservada para el proceso.

Es el cerebro del computador, se encarga de convertir la materia prima de éste y

dar un producto que puede ser sometido a otro procesamiento o ser el producto
final del sistema o maquina. Realiza cálculos matemáticos a altísimas velocidades.

Una de las diferencias fundamentales entre los S.O.C. y los S.O.D. es que los
primeros son más orientados hacia el propósito general, mientras que los segundos
se diseñan para aplicaciones más específicas, o bien por su complejidad, más
limitadas en cuanto la variedad de ámbitos. Lo anterior nos dice que la ejecución de
procesos y la distribución de carga se ejecutan con mayor certeza, ya que se
conocen de antemano los tiempos, tamaños de códigos, flujos de datos y solicitudes
de servicios.

Un proceso en un S.O.D. es un conjunto formado por un programa, un registro de

su estado de ejecución, un espacio de memoria de trabajo, un conjunto de procesos
padres o hijos, y una máquina que lo atiende mediante una sesión, es decir una
conexión lógica. A diferencia de los S.O.C. en los que un procesador es un quantum
computacional, aquí un procesador es un sistema local independiente. Trasladar los
conceptos sobre administración de procesos a los ambientes distribuidos implica
considerar que las las prestaciones de servicio de la CPU se sujetan ademá a las
reglas de una arquitectura de red, como en el caso de crear sesiones para atender
procesos; por lo que las soluciones son similares en su concepto a una mezcla de
sistema multiusuario, multiproceso, multiprocesador y con accesos compartidos a
memoria y sistemas de archivo.
Tanto en los S.O.C como en los S.O.D. modernos se tiene un plataforma de varios
procesadores (lógicos y físicos respectivamente) para ejecutar un conjunto de
tareas comunes; entonces los algoritmos del planificador y del administrador de la
CPU resuelven problemas muy similares, excepto, como ya se dijo, por el débil
acoplamiento electrónico y porque los recursos requieren capas extras de
etiquetado para el direccionamiento (nombres, sesiones, dominios, etc.) uno de los
elementos que se alterarán sensiblemente es la Tabla de Procesos, ya que en un
ambiente distribuido la dispersión de las tareas de procesamiento es mucho mayor
e inherente a la arquitectura; pero conla ventaja de que la asignación de los
procesos en el sistema global está prevista y estructurada, a diferencia de un S.O.C.
donde existe una cierta competencia aleatoria por los recursos.

El trabajo de control entre procesos distribuidos usa las reglas del software de
aplicación, es decir en un esquema de alto nivel. Debido a su naturaleza, los S.O.D.
requieren de usar mejor algoritmos que sean deterministas, distribuidos, óptimos y
globales. Una noción importante es que en un S.O.D. elegimos una estrategia no
migratoria, ya que esto resulta indeseable en un ambiente distribuido, excepto en
aquellos caso sen que la planificación de la carga de trabajo tenga cierta
incertidumbre y se requiera balanceo dinámico de la carga; entonces el objetivo final
es lograr la transparencia en el balance, que consumirá recursos del sistema.
Como ya se dijo, los sistemas distribuidos tienen una planificación de carga certera,
es decir que se conoce razonablemente bien el tamaño del código y de los datos,
porque se trata de aplicaciones de propósito específico, sin embargo esto no
cancela la necesidad de hacer trabajos de medición de la carga, llevar conteo de
procesos, administrar sus estados de forma remota y llevar un seguimiento de la
fracción de tiempo en que se realiza; con la tarea extra de propagar esta información
de manera concurrente. Sin embargo la dispersión uniforme de estas tareas busca
hacerlas transparentes y eficientes.
En S.O.D. evitaremos a toda costa el consumo de recursos para recolectar medidas
y desplazar procesos, y trasladaremos esa tarea a la complejidad del software, que
consiste en un grupo de programas actuando de manera coordinada, procesando
datos tiempo real o a gran escala. Como las máquinas ejecutan sus algoritmos en
forma síncrona, el sistema presenta un cierto equilibrio entre demanda y resultado;
pero hay que considerar que la mayoría de los algoritmos que intercambian
información en una red de transporte funcionan correctamente sólo hasta después
de intercambiar la información y actualizado los registros; pero son poco confiables
mientras las tablas están en proceso de actualización, por eso los nodos de un S.D.
deben funcionar de manera soberana.

Un hilo de ejecución, en sistemas operativos, es una característica que permite a

una aplicación realizar varias tareas concurrentemente. Los distintos hilos de
ejecución comparten una serie de recursos tales como el espacio de memoria, los
archivos abiertos, situación de autenticación, etc. Esta técnica permite simplificar el
diseño de una aplicación que debe llevar a cabo distintas funciones
simultáneamente.
Los hilos de ejecución que comparten los mismos recursos, sumados a estos
recursos, son en conjunto conocidos como un proceso. El hecho de que los hilos de
ejecución de un mismo proceso compartan los recursos hace que cualquiera de
estos hilos pueda modificar éstos. Cuando un hilo modifica un dato en la memoria,
los otros hilos acceden e ese dato modificado inmediatamente.
Lo que es propio de cada hilo es el contador de programa, la pila de ejecución y el
estado de la CPU (incluyendo el valor de los registros).
El proceso sigue en ejecución mientras al menos uno de sus hilos de ejecución siga
activo. Cuando el proceso es terminado, todos sus hilos de ejecución también lo
son. Asimismo en el momento en el que todos los hilos de ejecución finalizan, el
proceso no existe más y todos sus recursos son liberados.
Algunos lenguajes de programación tienen características de diseño expresamente
creadas para permitir a los programadores lidiar con hilos de ejecución (como Java).
Otros (la mayoría) desconocen la existencia de hilos de ejecución y éstos deben ser
creados mediante llamadas de biblioteca especiales que dependen del sistema
operativo en el que estos lenguajes están siendo utilizados (como es el caso del C
y del C++).
Un ejemplo de la utilización de hilos es tener un hilo atento a la interfaz gráfica
(iconos, botones, ventanas), mientras otro hilo hace una larga operación
internamente. De esta manera el programa responde de manera más ágil a la
interacción con el usuario. También pueden ser utilizados por una aplicación
servidora para dar servicio a múltiples clientes.
Sincronización de hilos
Todos los hilos comparten el mismo espacio de direcciones y otros recursos como
pueden ser archivos abiertos. Cualquier modificación de un recurso desde un hilo
afecta al entorno del resto de los hilos del mismo proceso. Por lo tanto, es necesario
sincronizar la actividad de los distintos hilos para que no interfieran unos con otros
o corrompan estructuras de datos.
Una ventaja de la programación multihilo es que los programas operan con mayor
velocidad en sistemas de computadores con múltiples CPUs (sistemas
multiprocesador o a través de grupo de máquinas) ya que los hilos del programa se
prestan verdaderamente para la ejecución concurrente. En tal caso el programador
necesita ser cuidadoso para evitar condiciones de carrera (problema que sucede
cuando diferentes hilos o procesos alteran datos que otros también están usando),
y otros comportamientos no intuitivos. Los hilos generalmente requieren reunirse
para procesar los datos en el orden correcto. Es posible que los hilos requieran de
operaciones atómicas para impedir que los datos comunes sean cambiados o leídos
mientras estén siendo modificados, para lo que usualmente se utilizan los
semáforos. El descuido de esto puede generar interbloqueo.

Un proceso es un concepto manejado por el sistema operativo que consiste en el

conjunto formado por: Las instrucciones de un programa destinadas a ser
ejecutadas por el microprocesador

Los procesadores distribuidos se pueden organizar de varias formas:

 Modelo de estación de trabajo.

 Modelo de la pila de procesadores.
 Modelo híbrido.
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.
El gestor de una arquitectura Cliente/Servidor se implementa en una capa
intermedia o del lado del cliente, y administra recursos en una cardinalidad n:n.
En cambio un gestor tipo UNIX admistra recursos bajo la jerarquía de root (aunque
puede trabajar como cliente -servidor). Por su parte en un gestor Orientado a
Objetos cada recurso es visto como un objeto, unívocamente identificado, y móvil,
mediante la nomenclatura de clases.
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 clusters homogéneos
(máquinas con software o hardware semejantes) y no al contrario.
El objetivo de un método de distribución de carga por gestión de recursos es
efectuar el balanceo de carga en sistemas de cómputo distribuido, empleando
técnicas propias de la computación paralela o multiprocesador.
Para diseñar u operar un Gestor de Recursos, vale la pena distinguir entre los
diversos tipos de cluster existentes con el fin de entender su funcionamiento
básico para así verificar si es posible implementarlos o combinarlos.
El Gestor de Recursos tiene dos funciones generales:
1.- Planificación Global.
2.- Planificación Interna.
Adicionalmente puede ejecutar tareas de migración de procesos e identificación
de nodos desocupados, siendo más un coordionador, ya que cada nodo se
encarga de gestionar sus propias comunicaciones.
Según algunos autores, existen dos formas de balanceo de carga: balanceo de
carga estático y balanceo de carga dinámico. En el primer caso, la distribución de
las tareas se realiza al comienzo de la computación, lo cual permite al nodo
maestro participar en las tareas de procesamiento de datos una vez que haya
asignada una fracción del trabajo a cada nodo esclavo. La asignación de tareas se
puede realizar de una sola vez o de manera periódica. El segundo caso, el
balanceo de carga dinámico, es muy útil cuando el número de tareas es mayor
que el número de procesadores disponibles o cuando el número de tareas es
desconocido al comienzo de la aplicación. Una característica importante del
balanceo de carga dinámico es la capacidad que tiene la aplicación de adaptarse
a los posibles cambios del sistema, no sólo a la carga de los procesadores sino
también a posibles reconfiguraciones de los recursos del sistema.
Si se tiene esta característica, por ejemplo un cluster puede responder bastante
bien cuando se produce el fallo de algún nodo, ya que el proceso de reasignación
de su carga es rutinario; esto simplifica la creación de aplicaciones tolerantes a
fallos que sean capaces de sobrevivir cuando se pierde algún esclavo o incluso el
maestro.
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
las tareas se integran bajo el concepto de trabajos, que mide el procesamiento por
unidad 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, en 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 qué 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 número 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.
Un ejemplo ilustrará mejor cómo funcionan los multihilos, supongamos que
tenemos una aplicación servidor, que tiene un hilo-recpetor que coloca todas
peticiones entrantes en una cola que es atendida por los hilos-trabajadores.
Supongamos que cada solicitud toma 2ms para ser procesada y 8ms de
Entrada/Salida. SI tenemos un sólo hilo-trabajador, entonces el máximo flujo de
salida de peticiones atendidas es de 100 por segundo; ya que cada solicitud tarda
2ms + 8ms = 10mseg, en ser atendida.
Si el mismo sistema lo atiende un servidor multihilos, consideremos que pasaría si
agregamos un hilo más (2 hilos -trabajadores en total)
El segundo hilo puede procesar una segunda solicitud mientras el primero está
bloqueado esperando la respuesta; en el mejor de los casos, éste segundo hilo
puede ejecutar sus 2ms de procesamiento mientras el primer huilo espera los 8
segundos de entrada/salida.
Al calcular el flujo de salida, consideramos que los 2ms de procesamiento ocurren
de manera concurrente, entonces en promedio cada solicitud toma en promedio
8ms, lo cual da un flujo de 125 peticiones por segundo.
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 ejemplo
algunos Navegadores WEB, porque muchos casos una página WEB consiste de
un texto plano con múltiples figuras de contenido distribuido; entonces, con
frecuencia el navegador, establece la conexión con el servidor, recupera y
comienza a desplegar la página HTML (incluso se permite al usuario el
desplazamiento dentro de la página en carga) mientras el navegador continua
recuperando otros archivos que conforman la página.
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.
Vale la pena preguntarse cómo se programa, por ejemplo un servidor de archivos
en la ausencia de hilos. Veamos que el servidor recibe las peticiones, las examina
y las trata de resolver antes de recibir la siguiente petición. Mientras espera al
disco duro, el servidor está ocioso y no procesa otra petición. Se procesan menos
peticiones por segundo (throughput), en cambio con los hilos se gana un
rendimiento considerable.