3.1 Procesos procesadores
No existe un acuerdo universal sobre una definición de proceso.
› Un programa que se está ejecutando
› Una actividad asíncrona
› El emplazamiento del control de un procedimiento que esta siendo ejecutado.
› Aquello que se manifiesta por existencia en el sistema operativo de un bloque de control de procesos.
El modelo de procesos posee las siguientes características:
› Todo el software ejecutable, inclusive el Sistema Operativo, se organiza en varios procesos secuenciales o procesos.
› Un proceso incluye al programa en ejecución y a los valores activos del contador, registros y variables del mismo.
› Conceptualmente cada proceso tiene su propia CPU virtual.
› Si la CPU alterna entre los procesos, la velocidad a la que ejecuta un proceso no será uniforme, por lo que es necesario aclarar lo siguiente:
› Que los procesos no deben programarse con hipótesis implícitas acerca del tiempo.
› Que normalmente la mayoría de los procesos no son afectados por la multiprogramación subyacente de la CPU o las velocidades relativas de procesos distintos.
› Un proceso es una actividad de un cierto tipo, que tiene un programa, entrada, salida y estado.
3.2 Hilos y Multihilos
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.
Formas de multi-hilos
Los sistemas operativos generalmente implementan hilos de dos maneras:
Multi-hilo 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.
Multi-hilo 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.
El soporte de hardware para multi-hilo desde hace poco se encuentra disponible. Esta característica fue introducida por Intel en el Pentium 4, bajo el nombre de Hyper Threading?.
Usos más comunes
Trabajo interactivo y en segundo plano
Por ejemplo, en un programa de hoja de cálculo un hilo puede estar visualizando los menús y leer la entrada del usuario mientras que otro hilo ejecuta las órdenes y actualiza la hoja de calculo. Esta medida suele aumentar la velocidad que se percibe en la aplicación, permitiendo que el programa pida la orden siguiente antes de terminar la anterior.
Procesamiento asíncrono
Los elementos asíncronos de un programa se pueden implementar como hilos. Un ejemplo es como los software de procesamiento de texto guardan archivos temporales cuando se está trabajando en dicho programa. Se crea un hilo que tiene como función guardar una copia de respaldo mientras se continúa con la operación de escritura por el usuario sin interferir en la misma.
Aceleración de la ejecución
Se pueden ejecutar, por ejemplo, un lote mientras otro hilo lee el lote siguiente de un dispositivo.
Implementaciones
Hay dos grandes categorías en la implementación de hilos:
Hilos a nivel de usuario
Hilos a nivel de Kernel
También conocidos como ULT (User Level Thread) y KLT (Kernel Level Thread)
Hilos a nivel de usuario (ULT) En una aplicación ULT pura, todo el trabajo de gestión de hilos lo realiza la aplicación y el núcleo o kernel no es consciente de la existencia de hilos. Es posible programar una aplicación como multihilo mediante una biblioteca de hilos. La misma contiene el código para crear y destruir hilos, intercambiar mensajes y datos entre hilos, para planificar la ejecución de hilos y para salvar y restaurar el contexto de los hilos.
Todas las operaciones descritas se llevan a cabo en el espacio de usuario de un mismo proceso. El kernel continua planificando el proceso como una unidad y asignándole un único estado (Listo, bloqueado, etc.).
Ventajas de los ULT
El intercambio de los hilos no necesita los privilegios del modo kernel, por que todas las estructuras de datos están en el espacio de direcciones de usuario de un mismo proceso. Por lo tanto, el proceso no debe cambiar a modo kernel para gestionar hilos. Se evita la sobrecarga de cambio de modo y con esto el sobrecoste.
Se puede realizar una planificación específica. Dependiendo de que aplicación sea, se puede decidir por una u otra planificación según sus ventajas.
Los ULT pueden ejecutar en cualquier sistema operativo. La biblioteca de hilos es un conjunto compartido. Desventajas de los ULT
En la mayoría de los sistemas operativos las llamadas al sistema (System calls) son bloqueantes. Cuando un hilo realiza una llamada al sistema, se bloquea el mismo y también el resto de los hilos del proceso.
En una estrategia ULT pura, una aplicación multihilo no puede aprovechar las ventajas de los multiprocesadores. El núcleo asigna un solo proceso a un solo procesador, ya que como el núcleo no interviene, ve al conjunto de hilos como un solo proceso.
Hilos a nivel de núcleo (KLT)
En una aplicación KLT pura, todo el trabajo de gestión de hilos lo realiza el kernel. En el área de la aplicación no hay código de gestión de hilos, únicamente un API (interfaz de programas de aplicación) para la gestión de hilos en el núcleo. Windows 2000, Linux y OS/2 utilizan este método. Linux utiliza un método muy particular en que no hace diferencia entre procesos e hilos, para linux si varios proceso creados con la llamada al sistema “clone” comparten el mismo espacio de direcciones virtuales el sistema operativo los trata como hilos y lógicamente son manejados por el kernel.
El Modelo de Estación de Trabajo
El sistema consta de estaciones de trabajo (PC) dispersas conectadas entre sí mediante una red de área local (LAN).
Pueden contar o no con disco rígido en cada una de ellas.
Los usuarios tienen:
· Una cantidad fija de poder de cómputo exclusiva.
· Un alto grado de autonomía para asignar los recursos de su estación de trabajo.
Uso de los discos en las estaciones de trabajo:
ü Sin disco:
· Bajo costo, fácil mantenimiento del hardware y del software, simetría y flexibilidad.
· Gran uso de la red, los servidores de archivos se pueden convertir en cuellos de botella.
ü Disco para paginación y archivos de tipo borrador:
· Reduce la carga de la red respecto del caso anterior.
· Alto costo debido al gran número de discos necesarios.
ü Disco para paginación, archivos de tipo borrador y archivos binarios (ejecutables):
· Reduce aún más la carga sobre la red.
· Alto costo y complejidad adicional para actualizar los binarios.
ü Disco para paginación, borrador, binarios y ocultamiento de archivos:
· Reduce aún más la carga de red y de los servidores de archivos.
· Alto costo.
· Problemas de consistencia del caché.
ü Sistema local de archivos completo:
· Escasa carga en la red.
· Elimina la necesidad de los servidores de archivos.
· Pérdida de transparencia.
El Modelo de la Pila de Procesadores
Se dispone de un conjunto de cpu que se pueden asignar dinámicamente a los usuarios según la demanda.
Los usuarios no disponen de estaciones de trabajo sino de terminales gráficas de alto rendimiento.
No existe el concepto de propiedad de los procesadores, los que pertenecen a todos y se utilizan compartidamente.
El principal argumento para la centralización del poder de cómputo como una pila de procesadores proviene de la teoría de colas:
· Llamamos “l” a la tasa de entradas totales de solicitudes por segundo de todos los usuarios combinados.
· Llamamos “m” a la tasa de procesamiento de solicitudes por parte del servidor.
• Modelo Híbrido:
– Los trabajos interactivos se ejecutan en las estaciones de trabajo mientras que los no interactivos se ejecutan en la pila de procesadores.
• El Modelo de las Estaciones de trabajo suele coincidir en la actualidad con la mayoría de las organizaciones.
ü –Cuando se utiliza este modelo hay una serie de aspectos a tener en cuenta:
• La asignación de Procesos a los Procesadores.
• Los Algoritmos de Distribución de la Carga.
ü La Planificación de los Procesos en un Sistema Distribuido.
Asignación de Procesadores
Son necesarios algoritmos para decidir cuál proceso hay que ejecutar y en qué máquina [25, Tanenbaum].
Para el modelo de estaciones de trabajo:
· Decidir cuándo ejecutar el proceso de manera local y cuándo es necesario buscar estaciones inactivas o no locales que tienen una conexión a la misma red pero fuera de ella.
Para el modelo de la pila de procesadores:
· Decidir dónde ejecutar cada nuevo proceso respecto de la misma maquina que es la tabla(lista) de los procesos que se crean dentro de la maquina.
Aspectos del Diseño de Algoritmos de Asignación de Procesadores
Los principales aspectos son los siguientes:
Algoritmos deterministas vs. heurísticos.
Algoritmos centralizados vs. distribuidos.
Algoritmos óptimos vs. subóptimos.
Algoritmos locales vs. globales.
Algoritmos iniciados por el emisor vs. iniciados por el receptor.
Los algoritmos deterministas son adecuados cuando se sabe anticipadamente todo acerca del comportamiento de los procesos, pero esto generalmente no se da, aunque puede haber en ciertos casos aproximaciones estadísticas. Los algoritmos heurísticos son adecuados cuando la carga es impredecible.
Los diseños centralizados permiten reunir toda la información en un lugar y tomar una mejor decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante su posible falla.
Generalmente los algoritmos óptimos consumen más recursos que los subóptimos, además, en la mayoría de los sistemas reales se buscan soluciones subóptimas, heurísticas y distribuidas.
Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en otra (política de transferencia):
La decisión se puede tomar “solo con información local” o “con información global”.
Los algoritmos locales son sencillos pero no óptimos.
Los algoritmos globales son mejores pero consumen muchos recursos.
El concepto de coplanificacion:
ü toma en cuenta los patrones de comunicación entre los procesos durante la planificación.
ü debe garantizar que todos los miembros del grupo se ejecuten al mismo tiempo.
ü se emplea una matriz conceptual donde:
· las filas son espacios de tiempo.
· las columnas son las tablas de procesos de los procesadores.
ü cada procesador debe utilizar un algoritmo de planificacion round robin:
· todos los procesadores ejecutan el proceso en el espacio “0” durante un cierto periodo fijo.
· todos los procesadores ejecutan el proceso en el espacio “1” durante un cierto periodo fijo, etc.
ü se deben mantener sincronizados los intervalos de tiempo.
ü todos los miembros de un grupo se deben colocar en el mismo n° de espacio de tiempo pero en procesadores distintos.
· La capacidad de procesamiento está distribuida entre varios computadores interconectados.
· Las actividades del sistema tienen requisitos de tiempo.
· Necesidad de sistemas distribuidos:
· /Requisitos de procesamiento.
· /Distribución física del sistema.
· /Fiabilidad: Tolerancia a fallos.
· Los sistemas distribuidos de tiempo real (SDTR) son complicados de realizar.
· Se consideran sistemas débilmente acoplados.
· Comunicación mediante mensajes
· El tiempo de comunicación es significativo.
· Ej. Sistemas multimedia, SCADA, aviónica, fabricación integrada, robótica.
· Distintos tipos de requisitos temporales
· Se consideran, fundamentalmente, sistemas críticos
