2 Procesos e Hilos

Sistemas Operativos PROCESOS E HILOS

Definición de Proceso Proceso para un Sistema Operativo Operativo no es más que un Programa en ejecución. En cualquier sistema de multiprogramación un CPU conmuta de un proceso a otro con rapidez, ejecutando cada uno durante décimas o centésimas de milisegundos. Un CPU solo puede trabajar con un proceso, pero en un segundo trabaja con varios de ellos, aparentando paralelismo o pseudoparalelismo.

Definición de Proceso Proceso para un Sistema Operativo Operativo no es más que un Programa en ejecución. En cualquier sistema de multiprogramación un CPU conmuta de un proceso a otro con rapidez, ejecutando cada uno durante décimas o centésimas de milisegundos. Un CPU solo puede trabajar con un proceso, pero en un segundo trabaja con varios de ellos, aparentando paralelismo o pseudoparalelismo.

El modelo del Proceso Multiprogramación Multiprogr amación de 4 programas. Cada uno se ejecuta por separado. Solo hay un programa activo a la vez.

El modelo del Proceso Todo el Software de la computadora, incluyendo el Sistema Operativo, se organiza en procesos secuenciales. Cada proceso tiene su propia CPU virtual, es decir, es atendido exclusivamente durante una fracción de milisegundos. La conmutación de un proceso a otro se conoce como multiprogramación.

Creación de un Proceso Hay 4 eventos que provocan la creación de procesos: 1.

El arranque del sistema.

2.

La ejecución, desde un proceso, de una llamada al sistema para creación de procesos.

3.

Una petición de usuario para crear un proceso.

4.

El inicio de un trabajo por lotes.

Creación de un Proceso Procesos en primer plano: Procesos que están en ejecución e interactúan con los usuarios (humanos) y realizan trabajos para ellos. Procesos en segundo plano : Procesos que no están asociados con usuarios específicos sino con una función específica. ◦

◦

Ejemplo: Proceso que recibe mensajes de correo electrónico, está inactivo hasta que recibe un mensaje. Los procesos en segundo plano se llaman demonios (daemons).

Creación de un Proceso En sistemas interactivos un proceso se origina cuando el usuario escribe un comando o haciendo doble clic en un icono. En mainframes los procesos se crean al iniciarse un trabajo por lotes en el sistema. En UNIX la llamada fork crea un clon exacto del proceso que hizo la llamada, los dos procesos (padre e hijo) tienen la misma imagen de memoria. En Windows la función Win32 crea procesos.

Terminación de Procesos Un proceso inicia, se ejecuta, realiza el trabajo asignado y termina en general debido a las siguientes condiciones: 1.

Salida normal (voluntaria).

2.

Salida por error (voluntaria).

3.

Error fatal (involuntaria).

4.

Eliminado por otro proceso (involuntaria). La mayoría de los procesos terminan debido a que han concluido su trabajo.

Terminación de Procesos En UNIX un proceso indica que ha terminado con la llamada Exit mientras que en Windows se usa Exitprocess. Para terminar un proceso voluntariamente en UNIX se utiliza la llamada kill y en Windows la función de Win32 es TerminateProcess. El proceso que termina a otro proceso debe tener los permisos necesarios para el caso. En algunos sistemas al terminar un proceso se eliminan los que creó, no en UNIX o Windows.

Jerarquía de Procesos En algunos sistemas un proceso crea a otros procesos, el proceso hijo a su vez puede crear más, esto forma una  jerarquía de procesos. En UNIX un proceso init lee un archivo que lee las terminales que hay, luego se usa  fork para crear un procesos por terminal. Todos los procesos forman un árbol con init en la raíz. Windows no tiene jerarquías, un proceso recibe un token (manejador) que utiliza para controlar al proceso hijo.

Estados de un Proceso Un proceso puede pasar por 3 estados: 1.

En ejecución (está usando la CPU en ese instante).

2.

Listo (ejecutable, se detuvo temporalmente, deja que se ejecute otro proceso).

3.

Bloqueado (no puede ejecutarse sino hasta que ocurra cierto evento externo).

Implementación de Procesos El Sistema Operativo mantiene una tabla de procesos, con un registro por proceso o bloques de control de procesos. Cada registro contiene información del proceso: ◦

Contador de programa.

◦

Apuntador de pila.

◦

Asignación de memoria.

◦

Estados de sus archivos abiertos.

◦

Información de contabilidad.

◦

Planificación.

Implementación de Procesos Contenido de la tabla de procesos:

Implementación de Procesos Existe un vector de interrupciones que utiliza el S.O. para saber de los procesos y controlarlos. Ejemplo de un proceso en ejecución:

Modelación de la Multiprogramación Un proceso típico no ocupa la CPU todo el tiempo, por lo que pueden ejecutarse otros procesos mientras se usa la memoria. Con n procesos en memoria a la vez, la probabilidad de que todos los n procesos estén esperando la E/S (en cuyo caso la CPU estará inactiva) es  pn. Entonces, el uso de la CPU se obtiene mediante la fórmula: Uso de la CPU = 1 - p n

Modelación de la Multiprogramación Gráfica de la multiprogramación, uso de la CPU en función de n:

Modelación de la Multiprogramación Ejemplo: ◦

◦

◦

Una computadora tiene 512 Mb de memoria, el S.O. ocupa 128 Mb y cada programa de usuario 128 Mb. Puede haber 3 programas de usuario a la vez. Con un promedio de 80% de espera de E/S, la utilización del CPU es de 1 0.83 o de 49%.  – 

◦

Si al sistema se el agregan 512 Mb más de memoria, en lugar de tener multiprogramación de 3 puede aumentar a multiprogramación de 7 con un uso de CPU de 79%.

◦

En resumen, aumentar 512 Mb incrementa el rendimiento 30%.

◦

Con 512 Mb más aumenta de 79% a 91%, solo 12%.

Hilos En los S.O. tradicionales cada proceso tiene un espacio de direcciones y un solo hilo de control. En ocasiones es conveniente tener varios hilos de control en el mismo espacio de direcciones que se ejecutan casi en paralelo porque comparten direcciones. Un hilo es un proceso.

Uso de Hilos La razón de tener hilos es porque en muchas aplicaciones se desarrollan varias actividades a la vez que pueden bloquearse de vez en cuando. Un hilo es más ligero que un proceso, son fáciles de crear y destruir, la creación es de 10 a 100 veces más rápida que la de un proceso. Los hilos no producen aumento en el rendimiento cuando están ligados a la CPU.

Uso de Hilos Un documento en un procesador de textos utiliza dos hilos, uno interactúa con el usuario mientras el otro le da formato a todo el documento. Un tercer hilo respalda todo el documento mientras el usuario escribe.

Uso de Hilos En un servidor Web, un hilo recibe las peticiones de trabajo en red y le envía la solicitud a otro hilo para que las procese, este a su vez despierta a un tercer hilo que revisa si la solicitud puede satisfacerse desde la memoria caché del servidor.

Modelo clásico de Hilo Un proceso es un hilo de ejecución. El hilo tiene un contador de programa que lleva el registro de cuál instrucción se va a ejecutar, registro a sus variables de trabajo, historial de ejecución en una pila, los valores utilizados en cada procedimiento llamado. Los hilos permiten llevar varias ejecuciones en el mismo entorno de proceso. Los hilos tienen algunas propiedades de los procesos y a veces se llaman procesos ligeros.

Modelo clásico de Hilo Multihilamiento (multithreading) es la ejecución de varios hilos en el mismo proceso. Los hilos de un proceso pueden operar en espacios de direcciones distintos o compartir el mismo espacio de direcciones.

Modelo clásico de Hilo La CPU conmuta rápidamente entre un hilo y otro aparentando que se ejecutan en paralelo, esto es multihilamiento. Los hilos que comparten el mismo espacio de memoria pueden escribir, leer o borrar la pila de otro hilo. Por otra parte, si los hilos comparten la memoria pueden trabajar juntos para llevar a cabo una tarea.

Modelo clásico de Hilo Los procesos no comparten áreas de memoria con otros procesos y son propiedad del usuario que los ejecutó. Un hilo también puede estar en ejecución, listo o bloqueado.

Modelo clásico de Hilo Cada hilo tiene su propia pila que contiene un conjunto de valores para cada procedimiento llamado.

Uso de Hilos Cuando hay multihilamiento (multithreading), un proceso empieza con un hilo que a su vez puede crear más hilos: ◦

◦

◦

◦

 thread_create crea hilos mediante la llamada a un procedimiento de biblioteca.  thread_exit termina un hilo.  thread_join bloquea al hilo llamador hasta que el hilo en ejecución haya terminado.  thread_yield permite que un hilo entregue la CPU para dejar que otro hilo se ejecute.

Hilos en POSIX Estándar IEEE 1003.1c donde los hilos son conocidos como Pthreads: Cada hilo tiene un identificador, un conjunto de registros (incluyendo el contador de programa) y un conjunto de atributos.

Implementación de Hilos Hay dos formas de implementar un paquete de hilos: 1. En espacio de usuario. 2. En el Kernel.

Hilos en espacio de usuario Cada proceso necesita su propia tabla de hilos privada que lleva la cuenta de hilos por proceso. La tabla de hilos contiene información de hilos listos o bloqueados. El planificador de hilos permite controlarlos localmente, esto para algunas aplicaciones es ventaja porque no se requieren llamadas al kernel. La desventaja es que un hilo puede bloquear la ejecución de otros y al sistema.

Hilos en Kernel El kernel sabe de los hilos y los administra. No hay una tabla de hilos en cada proceso. El kernel lleva la cuenta de todos los hilos del sistema, Para crear o destruir hilos se hace una llamada al kernel. El kernel según decida puede ejecutar hilos del mismo proceso o de un proceso distinto. Los hilos a nivel de usuario ejecutan sus propios hilos hasta que el kernel quita la CPU.

Implementaciones Híbridas Una forma de tener todas las ventajas es combinar hilos a nivel kernel y multiplexar con los hilos a nivel usuario. El kernel planifica solo sus hilos, que a su vez pueden tener hilos de usuario que se ejecutan sin capacidad de multihilamiento.

Activaciones del Planificador Los hilos de kernel son mejores que los de usuario pero son más lentos. El planificador imita las funciones de hilos kernel pero con el mejor rendimiento y flexibilidad de los hilos de usuario. Con el planificador, cuando un hilo kernel se bloquea debido a E/S se notifica al proceso en ejecución , a esto se le conoce como llamada ascendente ( upcall ).

Activaciones del Planificador Una vez notificado, el sistema en ejecución puede replanificar sus hilos. Cuando el kernel detecta que el hilo original puede ejecutarse de nuevo, realiza otra llamada para informar del evento. El sistema en ejecución puede reiniciar el hilo bloqueado o colocarlo en la lista de hilos listos para ejecutarlo más tarde. Al ocurrir otra interrupción de hardware mientras un hilo de usuario se ejecuta, la CPU se interrumpe y pasa a modo kernel.

Hilos emergentes Un proceso o hilo, que esta bloqueado, recibe un mensaje que desempaqueta y lo procesa. Un hilo emergente ( pop-up thread ) es un hilo que se crea para manejar el mensaje entrante.

Hilos emergentes Un hilo emergente se ejecuta en el kernel en lugar que en el espacio de usuario, puede acceder a las tablas del kernel y a los dispositivos de E/S. Un hilo de kernel con errores puede hacer más daño que un hilo en espacio de usuario, por ejemplo, si se ejecuta por demasiado tiempo y no puede quitarse, los datos entrantes de un dispositivo se perderán.

Conversión a multihilamiento Un proceso que contiene un solo hilo puede trabajar con más hilos, es decir, convertirse a multihilamiento. Hay variables locales que usa cada hilo, pero hay variables globales que utilizan varios. En UNIX la variable errno es global y puede crear conflictos.

Conversión a multihilamiento Hay varias posibles soluciones para evitar conflictos con las variables globales. Una solución es tener variables locales y otros elementos para cada hilo, el problema ahora es que los datos no pueden ser usados por otros hilos para trabajar en conjunto.

Conversión a multihilamiento Una solución es poner un bit para marcar que las variables están en uso y bloquear a los hilos que tratan de utilizarlas. Otra solución es usar señales pero el problema es dirigir cada una al hilo correspondiente sobre todo cuando el kernel no sabe de la existencia de hilos de usuario. Un problema adicional es la administración de las pilas por cada hilo, un proceso con varios hilos maneja varias pilas.

Comunicación entre Procesos Dos procesos que solicitan imprimir un archivo lo registran en la fila o directorio de spooler  en la misma posición. Al proceso A y al proceso B se les asigna el mismo lugar para imprimir. Cuando el control regresa al proceso B, pone el nombre del archivo en el spooler . Más adelante el proceso A hace lo mismo y coloca su archivo a imprimir en la misma posición del spooler sobre el del proceso B.

Comunicación entre Procesos El demonio de impresión imprime el archivo del proceso A, el del proceso B se pierde. El uso de datos compartidos y dependencias se conoce como condiciones de carrera.

Regiones críticas Para solucionar problemas de condiciones de carrera se puede hacer exclusión mutua. La memoria compartida por dos procesos se conoce como región o sección crítica. Para que los procesos cooperen deben: 1.

No puede haber dos procesos de manera simultánea dentro de regiones críticas.

2.

No puede haber suposiciones sobre velocidades o número de CPUs.

3.

Ningún proceso ejecutado fuera de la región crítica debe bloquear a otros procesos.

4.

Ningún proceso debe esperar por siempre para entrar a la región crítica.

Regiones críticas Exclusión mutua mediante regiones críticas:

Exclusión con espera ocupada Mientras un proceso está actualizando la memoria compartida en su región crítica, ningún otro puede entrar y dar problemas: ◦

◦

Deshabilitando interrupciones: En un sistema con un CPU un proceso deshabilita todas las interrupciones al entrar a su región crítica y las habilitar al salir. Variables de candado: En el software se habilita un candado cuando el proceso entra a la región crítica y se deshabilita cuando sale.

Exclusión con espera ocupada ◦

◦

Alternancia estricta: Mediante programación se crea una variable turno, con valor 0 el proceso entra a la región crítica, el valor cambia a 1. El evaluar el cambio en la variable se le conoce como espera ocupada y al candado se le llama candado de giro. Solución de Peterson : Es una mezcla de candado y alternancia. Un proceso solicita entrar a la región crítica y obtiene un turno. Al estar disponible se asigna la región y se pone el candado. Cuando el proceso sale de la región, se quita el candado y se asigna al siguiente proceso en turno.

Dormir y despertar La solución de Peterson es correcta pero se requiere de una espera ocupada. Se desperdicia CPU al esperar turno y se complica cuando los procesos tienen prioridades. Un proceso con prioridad que entra en la región crítica y no sale de ahí porque hay procesos en ejecución en el CPU, detiene a los demás, esto se llama problema de inversión de prioridades.

Dormir y despertar La solución es una llamada al sistema sleep que hace que un proceso sea bloqueado hasta que otro proceso lo despierta con una llamada wakeup . El problema del productor consumidor o problema de búfer limitado se produce cuando se comparte un búfer común de tamaño fijo.  – 

Un proceso (productor) coloca información en el búfer y otro proceso (consumidor) la saca.

Dormir y despertar El problema se hace mayor al haber m productores y n consumidores. Cuando un productor desea colocar un nuevo elemento en el búfer que está lleno, se pone a dormir (se desactiva) y se despierte hasta que un consumidor vacía el búfer. Un consumidor que desea sacar algo del búfer que se encuentra vacío se pone a dormir, cuando se llena el búfer se despierta.

Semáforos Un semáforo funciona con el mismo principio de dormir y despertar. En este caso, cuando el semáforo está en down un proceso se pone a dormir dor mir hasta que la operación se haya completado o bloqueado. El proceso dormido es despertado y el semáforo se pone en up, los procesos en espera a ser seleccionados tienen semáforos en down.

Semáforos productorconsumidor Los semáforos resuelven el problema de pérdidas de señales de despertar. Para que funcionen los semáforos se deben deshabilitar Para todas las interrupciones mientras m ientras se evalúan los semáforos. Es posible usar varios semáforos y lograr la sincronización para que no existe existen n procesos bloqueados para siempre. En este caso el productor deja de ejecutarse con búfer lleno y el consumidor con búfer vacío.

Mútex Un mútex mútex es una variable variable que puede estar en dos estados: estados: abierto (desbloqueado) o cerrado (bloqueado). El código mutex_lock se genera cuando un proceso entra a la región crítica, mutex_unlock cuando sale de esta. Cuando un hilo no puede entrar a la región y adquirir un mutex_lock , llama a thread_yield para entregar entregar el CPU a otro hilo.

Mutex en Pthreads Pthreads proporciona varias funciones para sincronizar hilos:

Mutex en Pthreads Además de los mutexes, Pthreads ofrece otro mecanismo de sincronización con variables de condición:

Monitores Para evitar la complicación del uso de semáforos y mútexes se creó el monitor. Un monitor es una colección de procedimientos, variables y estructuras de datos que se agrupan en un tipo especial de módulo o paquete. Los monitores sirven para hacer la exclusión mutua de hilos. Las variables de condición wait y signal permiten que un proceso sea bloqueado o no.

Pasaje de mensajes Este método de comunicación entre procesos utiliza send y receive como llamadas al sistema. El problema con los mensajes es que pueden perderse ocasionando que un proceso esté bloqueado esperando recibir uno. Un proceso puede recibir mensajes sin datos o enviar mensajes que no sean recibidos. Los mensajes tienen más desventajas que usar semáforos o monitores.

Pasaje de mensajes En un sistema productor consumidor, si el productor trabaja más rápido que el consumidor todos los mensajes se enviarán al consumidor hasta que el productor sea bloqueado.  – 

Por otra parte, si el consumidor trabaja más rápido que el productor, los mensajes estarán vacíos esperando que el productor los llene, el consumidor se bloquea. El pasaje de mensajes se utiliza en sistemas de programación en paralelo como MPI (Message Passing Interface).

Barreras Las barreras sincronizan grupos de procesos en lugar de solo dos procesos. Ningún proceso puede continuar a la siguiente fase hasta que todos los procesos estén listos para hacerlo. La barrera se coloca al final de cada fase.

Planificación Cuando una computadora tiene multiprogramación, varios procesos o hilos compiten por la CPU al mismo tiempo. La parte del S.O. que decide que proceso pasa a la CPU es el planificador de procesos utilizando un algoritmo de planificación. Además de elegir el proceso correcto que se va a ejecutar, el planificador tiene que preocuparse por hacer uso eficiente de la CPU.

Comportamiento de un Proceso Los procesos alternan uso de la CPU con peticiones de E/S. Algunos procesos hacen más cálculos que otros y usan más tiempo a la CPU, otros procesos pasan más tiempo esperando E/S.

Cuando planificar Procesos Hay una variedad de situaciones que necesitan planificación. Cuando se crea un nuevo proceso se debe decidir que se ejecute el proceso padre o el proceso hijo. Cuando un proceso termina se debe elegir a uno de los procesos listos. Si un proceso depende de otro, el planificador a veces no tiene la información para tomar en cuenta la dependencia.

Cuando planificar Procesos Al liberarse un dispositivo de E/S el proceso que lo ocupaba pasa a listo, el planificador debe decir si ejecuta este o si pasa a la CPU otro que estaba listo previamente. El algoritmo de planificación selecciona un proceso y deja que se ejecute por un máximo tiempo fijo, si sigue en ejecución el proceso se suspende y el planificador selecciona otro para ejecutarlo.

Algoritmos de Planificación Hay 3 entornos que se deben planificar: 1.

Procesamiento por lotes.

2.

Interactivo.

3.

De tiempo real.

En procesamiento por lotes (cálculo de una nómina) no existe alternancia y el proceso se deja hasta que termina. En entornos interactivos se limita el uso de la CPU para que de servicio a otros procesos.

Algoritmos de Planificación En sistemas de tiempo real, los procesos trabajan para lograr un trabajo común, por lo que se bloquean rápidamente. En un buen algoritmo de planificación, debe existir equidad, la CPU debe dar servicio a todos los procesos. Otra meta es mantener a la CPU y a los dispositivos de E/S siempre ocupados. El rendimiento es el número de trabajos por hora que completa un sistema.

Algoritmos de Planificación Metas del algoritmo de planificación:

Planificación de sistema lotes Primero en entrar, primero en ser atendido. El trabajo por lotes más corto va primero.

El menor tiempo restante va a continuación.

Planificación sistemas interactivos Procesos en turno circular (round robin), a cada proceso se le asigna un tiempo conocido como quántum. Una vez que un proceso utiliza su quántum aunque no haya terminado, la CPU pasa al siguiente.

Planificación sistemas interactivos Planificación por prioridad.

Múltiples filas. El proceso más corto a continuación.

Planificación de sistemas interactivos Planificación garantizada según los usuarios conectados. Planificación por sorteo. Planificación por partes equitativas, primero el usuario con menos procesos. Depende de los objetivos del sistema interactivo, ya sea un tiempo de respuesta rápido o atender a mas usuarios, se usa un método de planificación adecuado.

Planificación de tiempo real El tiempo real duro es aquel en que se asigna un tiempo absoluto por cumplir. El tiempo real suave se puede fallar en ocasiones en cumplir con un tiempo límite. Un sistema en tiempo real puede responder a eventos periódicos (que suceden a intervalos regulares) o no periódicos (que ocurren de forma impredecible). Los algoritmos de planificación estáticos son fijados antes de que el sistema se ejecute y los dinámicos van cambiando durante la ejecución.

Política contra mecanismo A menudo sucede que un proceso padre tiene muchos procesos hijo, como en una base de datos. El padre no puede decidir que proceso hijo es más importante, el planificador no acepta propuestas de los procesos. Se debe separar el mecanismo de planificación de la política de planificación. El kernel puede planificar a los procesos, pero el padre controla a sus hijos en un proceso de usuario.