36
Gestión de Procesos Realizado por: Kepa Bengoetxea [email protected]

Gestión de Procesos Realizado por: Kepa Bengoetxea [email protected]

Embed Size (px)

Citation preview

Page 1: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos

Realizado por: Kepa Bengoetxea

[email protected]

Page 2: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos

Referencias:-Descripción Funcional de los Sistemas Operativos.-Iñaki Alegria-UNIX.Programación Avanzada.-Manuel Márquez-http://www-gris.det.uvigo.es/~belen/pem/apuntes/node19.html

Page 3: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos

Un programa ejecutable es leído del disco por el kernel y es cargado en memoria para ejecutarse, convirtiéndose en un proceso.

Puede haber dos o más procesos asociados a la ejecución de un mismo programa. Es habitual que un proceso genere más procesos durante su ejecución.

En un proceso no sólo hay una cópia del programa, sino además el kernel le añade información adicional para poder manejarlo.

Page 4: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos Un proceso se compone de tres bloques fundamentales:

Segmento de texto: código de programa

Segmento de datos: variables globales y estáticas

Pila

Lo crea el kernel y su tamaño es gestionado dinámicamente por el.

Es una secuencia de bloques lógicos o stack frames Un stack frame se introduce o saca en función de si se

llama o se vuelve de la llamada a una función. Stack frame se compone de:

Las variables locales de función Parámetros de función Info. para volver al estado anterior de la llamada

Page 5: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos

Info. para volver al estado anterior de la llamada.

contador de programa puntero a pila al stack frame anterior

Los procesos pueden ejecutarse a nivel de usuario o kernel.

Cada modo maneja su propia pila o stack

stack del kernel: contiene los stack frames de las llamadas a sistema(funciones que se ejecutan en modo kernel)

stack del usuario: stack frames de funciones que se ejecutan en modo usuario

Page 6: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos UNIX/Linux es un sistema multiproceso que permite la

ejecución de varios procesos de forma simultánea.

El sistema operativo simula la existencia de N procesadores virtuales(procesos) a partir de una CPU o procesador físico. Cada procesador virtual ejecuta secuencialmente un único programa. Todos los procesos se ejecutan concurrentemente.

Ejecución secuencial: La ejecución de un proceso se dice que es secuencial porque sus operaciones son ejecutadas por la CPU una tras otra, en el orden que dicte el programa.

Ejecución concurrente: La ejecución de dos procesos se dice que es concurrente porque estos se pueden ejecutar en paralelo. Concurrencia real: Si cada proceso se ejecuta sobre una CPU. Concurrencia virtual: La CPU reparte su tiempo entre los procesos para simular su ejecución paralela.

Page 7: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos Requiere de otro programa llamado “Planificador o scheluder”

que permite gestionar que proceso entra a ejecutarse en cada instante en la CPU, ya que esta es un recurso limitado.

Todo proceso nace cuando algún otro proceso ejecuta la llamada al sistema clone. Una de las muchas formas de llamar a clone es a través de la función fork.

clone crea un duplicado idéntico del proceso que la ha llamado.

Page 8: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:clone

Nuestro nuevo proceso no verá el espacio de direcciones del proceso padre, ni viceversa.

Con mucha frecuencia, después del clone el proceso llama a exec para lanzar un programa nuevo.

La llamada a exec carga un programa en el espacio de direcciones del proceso y le pasa el control, perdiéndose el proceso llamante.

Si un proceso quiere lanzar un programa sin desaparecer, lo que hace es llamar a clone y que el hijo llame a exec.

Page 9: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:fork

Fork: Crea un proceso hijo. Devuelve 0 al proceso hijo y el PID del hijo al proceso padre. El proceso hijo creado es una copia exacta del padre, excepto que recibe un valor diferente de la llamada fork. Devuelve un valor -1 en caso de no poder crearse el proceso hijo.

ret=fork()

if (ret==-1) {printf(“ERROR”);}

else if (ret==0) {printf(“HIJO”);}

else printf(“PADRE”)

Page 10: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:fork

Todos los procesos tienen un único padre, pero un padre puede tener múltiples hijos.

Existe un proceso especial cuyo PID es 0, este se crea al arrancar el sistema y después de hacer una llamada fork se convierte en el proceso intercambiador (swapper), el proceso hijo se llama init y su PID vale 1. Este se encarga de arrancar los demás procesos que requiere el sistema.

Page 11: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:PID Cuando un proceso muere libera su pid y se puede asignar

a cualquier nuevo proceso.

En Linux 2.6 el PID se almacena en un entero y permite teoricamente hasta 2147483647(int 32bits=2^(31) +bit signo) procesos.

cat /proc/sys/kernel/pid_max ->32768 (por defecto)

echo 10000001 > /proc/sys/kernel/pid_max (hasta 1 Millón)

Con frecuencia se llega antes a la limitación de cota de descriptores, ya que cada proceso consume al menos 3 descriptores

cat /proc/sys/fs/file-max ->204166(por defecto)

Page 12: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:estados

El tiempo de vida de un proceso se puede dividir en un conjunto de estados.

En un sistema monoprocesador un proceso no esta continuamente ejecutándose, su estado irá cambiando según unas reglas bién definidas.

En el siguiente gráfico veremos cual es la transición de procesos en UNIX/Linux y procederemos a su explicación:

Page 13: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es
Page 14: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:estados1.-Ejecutándose en modo usuario: tiene el control del procesador mientras dura el quanto o no realice una llamada al sistema.

2.-Ejecutándose en modo kernel: Cuando el proceso realiza una llamada a sistema, el proceso cambia de estado y pasa ejecutar código de área de kernel. Cuando termina:

Termina la tarea interrupción (iret) vuelve a la siguiente instrucción que la llamó.

Si termina el quanto se hace un cambio de contexto, pasando el siguiente proceso a modo usuario

Si carece de algún recurso->Estado dormido

Si termina con exit->Estado zombi

Page 15: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:estados

3.-Planificado en memoria: tiene reservado los recursos de sistema que necesita. El proceso no se esta ejecutando, esta en cola de "listo para ejecutarse" esperando a que el planificador de tareas(scheluder) se lo permita.

4.-Dormido en memoria: El proceso esta durmiendo cargado en memoria, ya que esta esperando que se complete una operación (E/S,tiempo de espera(timer)(ejm:sleep 10),espera de recibir un evento o mensaje)

Nota: No puede haber un proceso, ejecutándose en modo usuario y kernel a la vez.

Page 16: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:estados5.-Planificado en swap: Esta en memoria secundaria,listo para ejecutarse, pero el intercambiador (proceso 0 ó swapper) debe cargar el proceso en memoria antes de que el planificador(scheluder) pueda ordenar que pase a ejecutarse.

6.-Dormido en swap: El proceso esta durmiendo y el intercambiador ha descargado el proceso hacia una memoria secundaria para dejar espacio en la memoria principal donde poder cargar otros procesos.

7.-El proceso esta volviendo del modo superusuario al modo usuario, pero el planificador se apropia del proceso y hace un cambio de contexto, pasando otro proceso a ejecutarse en modo usuario.

Page 17: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos:estados8.-El proceso acaba de ser creado(con fork) y está en un estado de transición; el proceso existe, pero ni está preparado para ejecutarse, ni durmiendo. Este estado es el inicial para todos los procesos, excepto el proceso 0.

9.-El proceso ejecuta la llamada exit y pasa al estado zombi. El proceso libera todos los recursos pero mantiene la entrada en la Tabla de Procesos. No termina de morir, esperando la notificación por parte del padre, de que ha recogido el registro que contiene el código de salida y su estado. Es un estado temporal. En caso de que el proceso padre muera antes de que finalice el hijo, será el proceso init quién asuma su paternidad.

Page 18: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: ciclo de vida

La vida de un proceso comienza con la llamada al sistema de fork, desde el shell por ejemplo con ./a.out :

1.-Con la llamada a fork se crea el proceso, iniciándose la información de contexto y asignando un PID al proceso hijo a.out. Su proceso padre será el "shell".( Un proceso no se crea si: no puede encontrar el programa, falta de memoria, se ha sobrepasado el número de procesos que se puede crear...)

2.-El proceso pasa a estado "listo para ejecutarse".

Page 19: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: ciclo de vida

3.-Existe una función "scheduler" o "planificador" que en función de la política , se encarga de seleccionar a un proceso de la lista de "listo para ejecutarse".

4.-Un vez seleccionado el proceso a ejecutarse por el "planificador", se llama a la función "dispatcher" que se encarga de pasar a estado de ejecución a dicho proceso, restaurando su información de contexto.

Page 20: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: ciclo de vida

5.-En ejecución se pasa de modo usuario a modo supervisor a través de una llamada a sistema o interrupción (cada vez que se necesita ejecutar alguna rutina del sistema operativo tal como una operación de E/S para escribir un mensaje en pantalla...). En modo usuario, se verifica la zona de memoria a la que se accede, no sobrepase su área de programa de usuario (zona datos e instrucciones) y no modifica el área del Sistema Operativo(virus). Una vez finalizada la ejecución de la rutina de E/S, el S.O devuelve el control al programa de usuario, pasando a modo usuario.

printf(“kaixo”) (modo ususario)->llamada a sistema write(modo kernel)

Page 21: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: ciclo de vida

6.-En caso de espera de un proceso por alguna operación de E/S , por un evento de otro proceso, o un timer(intervalo de tiempo), el planificador envía al proceso a “estado durmiendo”. Para lo cual el planificador selecciona el siguiente proceso a ejecutar y el dispatcher lo pasa a estado de ejecución. Una vez que la razón por el que un proceso esta "durmiendo" finalice el planificador pasa a estado "listo de ejecución".

7.-Los procesos tiene un quanto de tiempo de ejecución para el uso equitativo de la CPU. Sabiendo que los procesos más prioritarios tendrán mayor número de quantos.

Page 22: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: ciclo de vida

8.-En caso de que la memoria este saturada y haya necesidad de cargar un programa más prioritario en memoria, el swapper o intercambiador se encargará de pasar un proceso menos prioritario a memoria secundaria guardando la información necesaria para volverlo a cargar en memoria, y una vez finalizado la ejecución de un proceso, de pasarlo a memoria. Este trasiego de memoria a disco y disco a memoria se le denomina "swapping de procesos".

9.-Un proceso puede acabar su ejecución si :

llamada al sistema de fin_programa: exit

Otro proceso le manda un SEÑAL de SIGKILL: kill -9 nºPID

Page 23: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: ciclo de vida

En ambos casos pasa a estado zombi. El proceso ya no existe pero deja para su proceso padre un registro (código de salida y algunos datos estadíticos tales como tiempo de ejecución)

Para que un proceso pueda matar a otro es necesario que tenga privilegios, un proceso padre puede matar a sus procesos hijos.

Page 24: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: ciclo de vida

Los procesos se comunican habitualmente realizando llamadas a sistema de "esperar_hijo", que permite al proceso padre sincronizarse con la finalización de sus hijos y obtener la información de cómo han acabado los hijos por medio de algún tipo de código de retorno.

ret=fork()

if (ret==-1) {printf(“ERROR”);}

else if (ret==0) {printf(“HIJO”);}

else {wait(&estado);printf(“PADRE”)}

Page 25: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Tabla de Procesos

El sistema operativo mantiene una tabla de procesos, dentro de la cual se almacena un Bloque de Control de Proceso o PCB (Process Control Block). Un PCB tiene los siguientes campos:

Información de identificación:

PID(Process IDentifier) y PPID(Parent Process Identifier) para relaciones padre-hijo.

UID (User Identifier) y GID (Group Identifier) :determina los privilegios del proceso

Page 26: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Tabla de Procesos

Información de control para gestionar el proceso:

Planificación y estado:

Estado: TASK_RUNNING(ejecutándose o preparado) TASK_INTERRUPTIBLE(dormido, pero admite

cualquier señal) TASK_UNINTERRUPTIBLE ( dormido, pero

sólo responde a la señal que espera) TASK_STOPPED( stopped o traced) TASK_ZOMBIE(esperando un wait() )

Evento por el que espera si esta bloqueado

Page 27: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Tabla de Procesos

Información de control para gestionar el proceso:

Planificación y estado:

Temporizadores que contabilizan el tiempo de CPU utilizado en modo kernel y modo usuario

Descripción de los segmentos de memoria asignados al proceso.

Estado del procesador: valor de los registros de la cpu

Page 28: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Tabla de Procesos

Punteros para estructurar los procesos en colas. Para que el planificador las gestione.

Comunicación entre procesos:

Descriptores de eventos: Que eventos despertarán al proceso.

Campo de señales: enumera las señales recibidas pero todavía no tratadas.

Page 29: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Cambio de Contexto

Cuando se esta ejecutando un proceso, se dice que el sistema se esta ejecutándo en el contexto de un proceso.

Se denomina cambio de contexto a la acción de cargar el procesador con el contexto del proceso que pasa a ocupar la CPU, salvando previamente el contexto del proceso que abandona la CPU en su PCB.

Page 30: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Cambio de Contexto

Se provoca un cambio de contexto cuando:

fin quanto

finaliza el proceso

operación de sincronización-tenga que esperar

llamada al sistema (operación de entrada/salida) mediante el mecanismo trap (interrupción software) queda bloqueado a la espera de la operación finalizar la operación.

interrupción hardware que desbloquee un proceso más prioritario.

la llegada de un proceso más prioritario

Page 31: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Planificador de Procesos:Unix,tradicional

Los PCBs estarán ordenados en la colas de preparados de acuerdo a la política de planificación utilizada.

El planificador se encarga de decidir a quién dará la tajada (slice o quanto) de tiempo.

En Unix se utiliza el algoritmo de planificación que se denomina Round Robin Multinivel con Prioridades Dinámicas.

Page 32: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Planificador de Procesos:Unix,tradicional

1º aproximación: Algoritmo Round-Robin

Cola FIFO de procesos planificados

Funcionamiento: Se coge el proceso más antiguo y una vez ejecutado su quanto, vuelve a introducirse en la cola.

Ventaja: Es un algoritmo justo.

Desventaja: los procesos con mayor prioridad se ejecutarán con la misma frecuencia que los menos prioritarios

Page 33: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Planificador de Procesos:Unix,tradicional

2º aproximación: Algoritmo Round-Robin Multinivel

Diferentes colas FIFO, cada una para procesos de la misma prioridad.

Funcionamiento: Se coge el proceso más antiguo de la cola de mayor prioridad. Sólo si la cola de mayor prioridad esta vacía pasamos a la de siguiente menor prioridad.

Ventaja: Óptimo para sistemas de tiempo real

Desventaja: No justo, puede haber procesos que jamás se ejecuten.

Page 34: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Planificador: Unix tradicional

3º aproximación: Algoritmo Round-Robin Multinivel con

Prioridades Dinámicas

Diferentes colas FIFO, cada una para procesos de la misma prioridad. La prioridad tiene un componente estático ( nice de -20 a 19) y otro dinámico (según el proceso va ejecutando slices, su prioridad dinámica va cayendo, y sino emplea el procesador, su prioridad dinámica sube).

Funcionamiento: Por cada segundo de tiempo se recalculan las prioridades y se reajustan las colas. Se coge el proceso más antiguo de la cola de mayor prioridad. Solo si la cola de mayor prioridad esta vacía pasamos a la siguiente menor prioridad.

Ventaja: Es justo

Desventaja: El tiempo recalculando las prioridades dinámicas

Page 35: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Planificador:Unix,tradicional

3º aproximación: Algoritmo Round-Robin Multinivel con

Prioridades Dinámicas

Los procesos tienen prioridades.

Existe una cola para cada una de la prioridades.

Se atiende primeramente a los procesos de la cola -32, en caso de estar vacía se pasa al siguiente nivel hasta llegar a 31.

En caso de no haber procesos planificados, se ejecuta el proceso idle

Prioridad Total = Prioridad Base + ( uso de cpu/2) + Valor Nice

Prioridad Total se calcula cada segundo

La Prioridad Base será un valor negativo, si proceso se ejecuta en modo kernel y positivo si modo usuario, y depende de la prioridad del padre.

Page 36: Gestión de Procesos Realizado por: Kepa Bengoetxea jipbekok@vc.ehu.es

Gestión de Procesos: Planificador:Unix,tradicional

3º aproximación: Algoritmo Round-Robin Multinivel con

Prioridades Dinámicas.

El Valor Nice:

Es un valor comprendido entre -20 a 19. Por defecto es 0. Un usuario normal únicamente puede bajar la prioridad de

su proceso ejecutándolo:

nice -n 19 yes>/dev/null &

[1] 2546 Un superusuario puede aumentar/reducir la prioridad de un

proceso:

Cuando va a ejecutar 1º vez: nice -n -20 yes>/dev/null & Una vez en ejecución: renice -20 2546