Concepto de proceso Rina Arauz

Definición de proceso Un proceso es un programa en ejecución Componentes: Código Datos Pila, etc. Ejemplo: Un compilador C NO es un proceso Un compilador C ejecutándose será un proceso para el sistema operativo Le asigna recursos (procesador, memoria, dispositivos, etc.) Controla su ejecución

Procesos y sistema operativo Los procesos se crean mediante llamadas al sistema: fork() sin parámetros en UNIX CreateProcess() con 10 parámetros y uno de ellos una estructura con 18 campos en WNT ¿Por qué múltiples procesos? Se aprovechan mejor los recursos físicos El rendimiento aumenta Es bueno poder navegar por Internet mientras se edita un documento y se escucha música

Estructura de un proceso UNIX int debug = 1; char *progname; main (int argc,char *argv[]) { int i; char *ptr,*malloc(); progname = argv[0]; printf("arg = %d\n",argc); for (i=1; i<argc; i++){ ptr = malloc(strlen(argv[i])+1); strcpy(ptr,argv[i]); if (debug) printf("%s\n",ptr); }

Estructura de un proceso UNIX Contexto de Usuario: representa todo aquello que es accesible por el usuario (código, datos, etc). Contexto del Núcleo: representa aquellas estructuras que solo son accesibles por el sistema operativo y que son necesarias para dar soporte a cada uno de los procesos (memoria asignada al proceso, prioridad, recursos asociados al proceso, etc).

Estructura de un proceso UNIX Contexto de usuario Contexto del núcleo Texto (código) Datos del núcleo Datos iniciados de sólo lectura Datos iniciados de lectura-escritura Datos no iniciados Área dinámica (heap) Pila

Bloque de control de procesos Por cada proceso en el sistema existe una estructura PCB; es la manifestación para el sistema operativo de que existe como proceso. Contiene información característica de cada proceso del sistema como: Estado actual del proceso Identificación unívoca del proceso Prioridad del proceso Puntero a la zona de memoria asignada Puntero a los archivos abiertos Punteros a los recursos asociados En Linux el PCB se conoce como task_struct, existe una matriz de punteros task (512) que apunta a cada task_struct.

Diagrama de estados Zombie Ejecución Espera Parado Listo Finalizar Dormir Ejecución Dormir Desalojar Espera Parado Despachar Despertar Listo Despertar

Los identificadores del proceso que se guardan en la task_struct son: Zombie: El proceso ha finalizado su ejecución pero todavía no se ha retirado su entrada de la tabla de control de procesos. Los identificadores del proceso que se guardan en la task_struct son: de proceso (pid) del padre (ppid) de usuario (uid) de grupo (gid)

HILOS CUENTO: Érase una vez un usuario que tenía un Smartphone. El usuario instala en su dispositivo una aplicación que es una enciclopedia. Al hacer clic sobre el cuadro de búsqueda y empezar a escribir, se lanza un hilo en segundo plano que muestra las sugerencias (SUGERENCIAS). Al escribir la palabra que quería, que era “pájaros”, la aplicación lanza otro hilo en segundo plano que se conecta a internet y descarga lo que necesite (Hilo en Segundo Plano DESCARGAR). Lo primero que hace este hilo es descargar las imágenes de los pájaros y las almacena en la memoria del teléfono al lanzar este hilo a un tercero también en segundo plano (Hilo en Segundo Plano BASE DE DATOS). Además, a la vez que descarga y almacena las imágenes, las convierte en más pequeñas para que ocupen menos, en un cuarto hilo en segundo plano (Hilo en Segundo Plano PROCESAR IMÁGENES). Al terminar de descargar las imágenes, se descarga el texto y este se manda al terminar el hilo de descarga (Hilo en Segundo Plano SUGERENCIAS) al hilo que almacena en la base de datos (Hilo en Segundo Plano BASE DE DATOS), por lo que este tenía que esperar a que acabara el anterior para poder continuar y acabar. Tiene un segundo problema el hilo que guarda la información (Hilo en Segundo Plano BASE DE DATOS), que también tiene que esperar a que el hilo que procesa las imágenes para que sean más pequeñas (Hilo en Segundo Plano PROCESAR IMÁGENES) también tiene que terminar, por lo que le toca esperar también a este. Por fin, ya tenemos todos los datos necesarios descargados, guardados en la base de datos, y las imágenes empequeñecidas para que no ocuparan tanto. Se lo mandamos todo colocado al usuario, para que lo vea en pantalla y terminamos. VIDEO…

Procesador de texto

Hilos (Threads) Objetivo: compartir recursos entre procesos cooperantes de forma cómoda Hilo = proceso ligero = lightweight process = LWP = unidad fundamental de uso de procesador Básicamente se compone de un CP, una serie de registros y un área de pila Cada hilo comparte con con los otros hilos cooperantes código, datos y recursos del SO El código, los datos y los recursos son poseídos por otra entidad conocida como tarea (task) Una tarea sin hilos no tiene capacidad de ejecución, sólo “posee” recursos

Hilos (Threads) Un proceso tradicional (proceso pesado) se compone de una tarea con un hilo de ejecución La conmutación de un hilo a otro en la misma tarea requiere un coste mínimo ya que solo es necesario salvar los registros y conmutar la pila Los threads son muy adecuadas para sistemas distribuidos y sistemas multiprocesador (cada hilo se puede ejecutar en un procesador) Cada hilo sólo puede pertenecer a una tarea

Hilos vs. procesos Los hilos se crean y se destruyen más rápidamente que los procesos Esto es así porque no es necesario asignarle recursos como la memoria El tiempo de conmutación entre hilos de la misma tarea es más rápida que la conmutación entre procesos Menor sobrecarga de comunicaciones debido a que todos los hilos de una tarea comparten memoria La programación con hilos debe hacerse cuidadosamente porque pueden producirse errores de sincronización

Los hilos pueden ser implementados en espacio de usuario o soportados por el núcleo Hilos soportados por el núcleo del SO: es el propio sistema operativo quien da soporte a los hilos estableciendo las estructuras de datos y la funcionalidad necesarias. La planificación de los hilos la realiza el SO. Hilos en espacio de usuario: Los hilos son soportados por una biblioteca que se ejecuta en espacio de usuario. La planificación de los hilos la realiza la propia aplicación.

Hilos en espacio de usuario Ventajas: La conmutación entre hilos se puede realizar rápidamente sin ayuda del S.O. La planificación puede hacerla la aplicación Portabilidad entre SO diferentes Inconvenientes: Si el S.O. no sabe de la existencia de hilos en una tarea, el bloqueo de un hilo produce el bloqueo del resto de hilos de la misma tarea Dos hilos de una misma tarea no se pueden ejecutar en procesadores diferentes

Hilos soportados por el S.O. Ventajas: Si el S.O. soporta hilos, el bloqueo de uno de ellos en una tarea no afecta al resto Inconvenientes: La conmutación de un hilo a otro se hace vía interrupciones (mayor sobrecarga) En ambos casos la planificación puede tener resultados desagradables ¿Que pasaría en el caso de tener hilos a nivel de usuario y a nivel de kernel si tenemos dos tareas, una con cuarenta hilos y otra con un único hilo?

Ejemplo de uso de hilos #include <pthread.h> void * periodic (void *arg) { int period; period = *((int *)arg); while (1) { printf("En tarea con periodo %d\n", period); sleep (period); } main() { pthread_t th1, th2; pthread_attr_t attr; int period1, period2; period1 = 2; period2 = 3;

Continuación del ejemplo if (pthread_attr_create (&attr) == -1) { perror (""); } if (pthread_create(&th1, attr, periodic, &period1) == -1) { perror(""); if (pthread_create(&th2, attr, periodic, &period2) == -1) sleep(30); printf("Salida del hilo principal\n"); exit(0);