Capítulo 4: hilos.

Presentación del tema: "Capítulo 4: hilos."— Transcripción de la presentación:

1 Capítulo 4: hilos

2 hilos Programa: Todos los posibles caminos
Una Aplicación puede tener varios hilos en ejecución: Alternadamente (si hay una CPU) Paralelamente (si hay varias CPUs) Programa: Todos los posibles caminos Proceso: Todas las instrucciones que se van ejecutando, con toda la memoria y archivos que se van usando. Se dice que un proceso es la unidad de Posesión de Recursos hilos Hilo: Un conjunto de instrucciones particulares que se ejecutan, debido a una opción elegida, con el entorno de pila y variables locales. Se dice que un hilo es la unidad de ejecución

3 capítulo 4: hilos Perspectiva
El viejo concepto de proceso supone que se trata de una instancia de un programa en ejecución con un solo hilo de control. Modelos multihilos Ahora, la mayoría de los sistemas operativos modernos proporcionan características que permiten que un proceso tenga múltiples hilos de control. Biblioteca de hilos Consideraciones sobre los hilos Ejemplos de sistemas operativos Hilos en Windows XP Hilos en Linux

4 Objetivos Introducir la noción de un hilo (una unidad básica de utilización de la CPU que constituye las bases de un sistema de computación multihilos) Explicar las APIs para las bibliotecas de hilos: Pthreads, Win32 y Java Examinar las cuestiones relacionadas con la programación multihilo

5 Qué es un hilo? Un hilo es la unidad básica de utilización de la cpu;
Comprende: un número identificador único de hilo, un contador del programa, un conjunto de registro y una pila. Comparte con otros hilos que pertenecen al mismo proceso: la sección de código, la sección de datos y otros recursos del sistema operativo: como los archivos abiertos y las señales. Un proceso tradicional (un proceso pesado) tiene un solo hilo de control. Si un proceso tiene, por el contrario, múltiples hilos de control, puede realizar más de una tarea al mismo tiempo.

6 Procesos con único hilo y multihilos

7 Beneficios del Multithreading
Muchos paquetes de software que se ejecutan en los PC modernos son multihilos. Una aplicación que se implementa como un solo proceso con varios hilos de control. Por ejemplo: un explorador web puede tener: un hilo para mostrar imágenes o texto mientras que otro hilo puede recuperar datos de la red. Un procesador de textos puede tener: un hilo para mostrar gráficos, otro hilo para responder a las pulsaciones de teclado del usuario un tercer hilo para el corrector ortográfico y gramatical que se ejecuta en segundo plano.

8 Beneficios del Multithreading
Otro ejemplo: una misma aplicación puede tener que realizar varias tareas similares: un servidor web acepta solicitudes de los clientes que piden páginas web, imágenes, sonido, etc. Un servidor web sometido una gran carga puede tener varios (quizás miles) de clientes accediendo de forma concurrente a él. Si el servidor web funcionara como un proceso tradicional de un solo hilo, sólo podrían dar servicio a un cliente cada vez y la cantidad de tiempo que un cliente podría tener que esperar para que su solicitud fuera servida podría ser enorme. Si el servidor funcionara como un solo proceso que acepta Solicitudes. Y Cuando ha recibido una solicitud, crea otro proceso para dar servicio a dicha solicitud. Así se resolvía antes. La creación de proceso lleva tiempo y hace un uso intensivo de los recursos. Si el nuevo proceso va a realizar las mismas tareas que los procesos existentes, ¿por qué realizar todo ese trabajo adicional? Es más eficiente usar un proceso que contenga múltiples hilos. Según este método, lo que se hace es dividir en múltiples hilos el proceso servidor web. El servidor crea un hilo específico para escuchar las solicitudes de cliente y cuando llega una solicitud, en lugar de crear otro proceso, el servidor crea otro hilo para dar servicio a la solicitud

9 Arquitectura de un servidor mutihilado
Y Crea un nuevo hilo para atender la solicitud Solicita Un hilo escucha las Solicitudes que pudieran llegar Y el hilo continúa escuchando las solicitudes que pudieran llegar

10 Beneficios del Multithreading
Capacidad de respuesta: Por tener siempre un hilo para la atención del usuario ya que los otros pueden estar bloqueados Compartición de recursos: los hilos comparten la memoria y los recursos del proceso al que pertenecen. La ventaja de compartir el código y los datos es que permite que una aplicación tenga varios hilos de actividad diferentes dentro del mismo espacio de direcciones. Economía: Es más rápido el cambio de contexto entre uno y otro hilo, que entre procesos. (cambio de contexto vs cambio de proceso) Utilización sobre arquitecturas multiprocesador: en un arquitectura multiprocesador, donde los hilos pueden ejecutarse en paralelo en los diferentes procesadores.

11 Modelo de Hilos Desde el punto de vista práctico, el soporte para hilos puede proporcionarse en el nivel de usuario (para los hilos de usuario) El soporte para los hilos de usuario se proporciona por encima del kernel y los hilos se gestionan sin soporte del SO. el nivel del kernel (para los hilos del kernel). El sistema operativo gestiona directamente los hilos en el kernel. Casi todos los sistemas operativos actuales, incluyendo Windows xp, Linux, Mac osx, solaris etc. soportan los hilos del kernel. Pero siempre debe existir una relación entre los hilos de usuario y los hilos del kernel; veremos tres formas de establecer esta relación:

12 Modelos multihilos: Muchos a uno
Muchos hilos a nivel del usuario son “mapeados” a un único hilo del kernel ejemplos: Solaris Green Threads GNU Portable Threads

13 Modelos multihilos: Uno a uno
Cada hilo a nivel de usuario mapea a un hilo del kernel ejemplos Windows NT/XP/2000 Linux Solaris 9 y posteriores

14 Modelos multihilos: muchos a muchos
Permite que muchos hilos a nivel de usuario sean mapeados a muchos hilos del kernel Permite que el sistema operativo cree un número suficiente de hilos del kernel Solaris (Desde la versión 1 hasta la 9) Windows NT/2000 con el paqueteThreadFiber

15 Modelo de dos niveles Similar a muchos a muchos, salvo que este permite también que un hilo de usuario se relacione con un hilo del kernel Ejemplos IRIX HP-UX Tru64 UNIX Solaris 8 y anteriores

16 Biblioteca de hilos La biblioteca de hilos provee una API al programador para crear y administrar hilos 2 maneras básicas de implementación La biblioteca completa está en espacio de usuario: Todas las estructuras de datos y el código de la biblioteca se encuentran en espacio de usuario. Esto significa que invocar a una función de la biblioteca es como realizar una llamada una función local en el espacio de usuario y no una llamada al sistema. hilos en POSIX (Pthreads) hilos en Java Hay una biblioteca a nivel del kernel soportada por el sistema operativo: Implementar una biblioteca en el nivel del kernel, soportada directamente por el sistema operativo. El código y las estructuras de datos de la biblioteca se encuentran en espacio del kernel. Invocar a la función en la API de la biblioteca normalmente da lugar a que se produzca una llamada al sistema dirigida a el kernel. hilos en Win32

17 Pthreads Puede proveer, ya sea hilos a nivel usuario o hilos a nivel del kernel El estándar POSIX (IEEE c) de APIs se estableció para la creación y sincronización de hilos La biblioteca de API especifica el comportamiento de los hilos, desde su implementación y hasta el desarrollo Es común en sistemas operativos del tipo UNIX (Solaris, Linux, Mac OS X)

18 Hilos en Java Los hilos en Java son administrados por la JVM
Implementados típicamente usando el modelo de hilos provistos por su sistema operativo subyacente Los hilos en Java pueden ser creados por: La clase extendida de hilo (Thread) Implementando la interfaz en tiempo de ejecución

19 Consideraciones sobre los hilos
La semántica de las llamadas al sistema fork() y exec() cambia en los programas multihilos. Si un hilo de un programa llama a fork(), ¿duplica todo los hilos el nuevo proceso o se genera un proceso de un solo hilo?. Algunos sistemas unix disponen de dos tipos de operaciones de fork: una que duplica todos los hilos y otra que sólo duplica el hilo que invocó la llamada sistema fork. En la llamada al sistema exec(), el programa especificado en el parámetro del exec() reemplazará al proceso completo, incluyendo todos los hilos. Elegir cuál de las versiones de fork dependerá de la aplicación. Si se llama a exec() inmediatamente después de fork, entonces resulta innecesario duplicar todos los hilos, ya que el programa especificado en el parámetro de exec() reemplazará al proceso existente. En este caso, lo apropiado es duplicar sólo el hilo que hace la llamada.

20 La terminación de un hilo
Cancelando un hilo antes que éste finalice Dos enfoques generales: La cancelación asincrónica termina al hilo inmediatamente. Puede traer graves consecuencias: Si el hilo está actualizando una base de datos y a medio hacer se lo cancela. El sistema operativo por lo general, no logra sacarle todos los recursos que usaba. Por lo que puede llevarse el recurso “a la tumba”. La cancelación diferida (muerte anticipada) permite que el hilo objetivo compruebe periódicamente si debe terminar. Por lo que termina por sí mismo de una forma ordenada.

21 Tratamiento de señales
Una señal se usa en los sistemas unix para notificar a un proceso que se ha producido un determinado suceso. Una señal puede recibirse síncrona o asíncronamente, dependiendo del origen y de la razón por la que el suceso debe ser señalizado. Todas las señales, sean síncronas o asíncronas, siguen el mismo patrón: Una señal se genera debido a que se produce un determinado suceso. La señal generada se suministra a un proceso. Una vez suministrada, la señal debe ser tratada (se debe ejecutar un código) Síncronas: Como ejemplos de señales sincrónicas podemos citar los accesos ilegales a memoria y la división por cero. Si un programa en ejecución realiza una de estas acciones, se genera una señal. Las señales síncronas se proporcionan al mismo proceso que realizó la operación que causó la señal (esa es la razón por la que se consideran síncronas).

22 Tratamiento de señales
Asíncronas: Cuando una señal se genera por un suceso externo a un proceso de ejecución, dicho proceso recibe la señal en modo asíncrono. Ejemplo: la terminación de un proceso mediante la pulsación de teclas específicas, como <control-C>, y el fin de tiempo de un temporizador. Normalmente, las señales asíncronas se envían a otro proceso. Cada señal puede ser tratada por una de 2 posibles rutinas de tratamientos: Una rutina de tratamiento de señal predeterminada. Una rutina de tratamiento de señal definida por el usuario. Cada señal tiene una rutina de tratamiento de señal predeterminada que el kernel ejecuta cuando trata dicha señal. Esta acción predeterminada puede ser sustituida por una rutina de tratamiento o de señal definida por el usuario a la que se llama para tratar las señal. Las señales pueden tratarse de diferentes formas: algunas señales (tales como la de cambio en el tamaño de una ventana) simplemente pueden ignorarse; otras son obligatorias (como un acceso ilegal la memoria) pueden tratarse mediante la terminación del programa.

23 Tratamiento de señales
El tratamiento de señales en programas de un solo hilo resulta sencillo; las señales siempre se suministran a un proceso. Sin embargo suministrar las señales en los programas multihilos es más complicado, ya que un proceso puede tener varios hilos. ¿a quién, entonces, debe suministrarse la señal? En General, hay disponible las siguientes opciones: Suministrar la señal al hilo elegido que le sea aplicable la señal. Suministrar la señal para todos los hilos del proceso. Suministrar la señal a determinados hilos del proceso. Asignar un hilo específico para recibir todas las señales del proceso. El método para suministrar una señal depende del tipo de señal generada. Por ejemplo, las señales síncronas tienen que suministrarse al hilo que causó la señal y no a los otros hilos del proceso. Sin embargo, la situación con las señales asíncronas no están claras. Algunas señales asíncronas, como una señal de terminación de un proceso (por ejemplo, control-C) deberían enviarse a todos los hilos.

24 Procesos ligeros o LWP Muchos sistemas que implementan el modelo muchos-a-muchos o el modelo de dos niveles, colocan una estructura de datos intermedia entre los hilos de usuario y del kernel. Esta estructura de datos es conocida normalmente con el nombre de proceso ligero o LWP. Para las bibliotecas de hilos de usuario, el proceso ligero se parece a un procesador virtual en el que la aplicación puede hacer que se ejecute un hilo de usuario. Cada LWP se asocia a un hilo del kernel, y es este hilo del kernel, el que el sistema operativo ejecuta en los procesadores físicos. Si un hilo del kernel será bloqueado (por ejemplo, mientras espera que se complete una operación de entrada/salida), el proceso ligero LWP se bloquea también. Por último el hilo de usuario asociado al LWP también se bloquea. En una aplicación que haga un uso intensivo de las operaciones de entrada/salida puede requerir ejecutar múltiples procesos LWP. Normalmente, se necesita un proceso ligero por cada llamada concurrente al sistema que sea del tipo bloqueante. Por ejemplo, suponga que se solicitan simultánemente cinco lecturas de archivos diferente; se necesitarán cinco procesos ligeros, ya que todos podrán tener que esperar a que completen la operación de entrada/salida del kernel. Si un proceso tiene sólo cuatro LWP, entonces la quinta solicitud tendrá que esperar a que uno de los procesos LWP vuelva del kernel.

25 Hilos en Windows XP Implementa un mapeo uno a uno con nivel del kernel
Cada hilo contiene Un identificador de hilo Un grupo de registros Pilas separadas de usuario y kernel Un área de almacenamiento privado Las principales estructuras de datos de un hilo son: ETHREAD (bloque de hilo en el ejecutivo) KTHREAD (bloque de hilo en el kernel) TEB (bloque de entorno del hilo, en espacio de usuario) Contexto del hilo

26 Hilos en Windows XP

27 Hilos en Linux Linux no diferencia entre procesos e hilos. Por eso a ambos se refiere como una tarea: al flujo de control dentro de un programa. La creación de hilos es hecha a través de la llamada al sistema clone(), donde se especifica un conjunto de indicadores, que determina el grado de compartición entre las tareas padre e hijo. Permite a una tarea-hijo compartir o no el espacio de direcciones de la tarea de su padre (proceso) El nivel variable de compartición se puede hacer porque existe una estructura de datos del kernel específica (struct task_struct) para cada tarea del sistema. Quien contiene punteros a otras estructuras: lista de archivos abiertos, tratamiento de señales , memoria virtual, etc.

28 Parámetros de clone() en Linux