La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Diseño de sistemas operativos Tema 2 Gestión de procesos.

Presentaciones similares


Presentación del tema: "Diseño de sistemas operativos Tema 2 Gestión de procesos."— Transcripción de la presentación:

1 Diseño de sistemas operativos Tema 2 Gestión de procesos

2 Diseño de Sistemas Operativos 2 Índice Concepto de proceso y multiprogramación Implementación de procesos Operaciones sobre procesos Threads Planificación de procesos

3 Diseño de Sistemas Operativos 3 Concepto de proceso y multiprogramación Concepto clásico: Programa secuencial en ejecución Multiprogramación: Múltiples programas en ejecución S.O. reparte recursos entre procesos salvando/restaurando su contexto: –Programa cree que tiene una máquina dedicada –Proceso: Abstracción de un procesador virtual Beneficios de la multiprogramación: –Uso eficiente del procesador –Soporte de múltiples usuarios –Expresión del paralelismo de las aplicaciones

4 Diseño de Sistemas Operativos 4 Programa versus Proceso Programa (pasivo) != Proceso (activo) Múltiples procesos ejecutando el mismo programa (p.e. shell) En UNIX se aprecia claramente la diferencia: –FORK: Nuevo Proceso - Mismo Programa –EXEC: Mismo Proceso - Nuevo Programa –Un proceso puede ejecutar varios programas durante su vida En otros sistemas proceso asociado a programa de por vida En Win32: –CreateProcess: Nuevo Proceso - Nuevo Programa –En UNIX sería necesario: FORK + EXEC en hijo

5 Diseño de Sistemas Operativos 5 Implementación de procesos Explicación basada en modelo proceso/núcleo –S.O. no es un proceso: crea la abstracción de proceso S.O. pasivo: –Sólo activo en inicio hasta que crea 1º proc. y le cede control –1º proc. (init en UNIX) crea otros y éstos a su vez otros... Proceso única entidad activa –Siempre hay un proceso ejecutando (aunque sea el nulo) –Código del S.O. lo ejecutan los procesos Cuando se produce interrup., excepción o llamada al sistema

6 Diseño de Sistemas Operativos 6 Modos de ejecución de un proceso Proceso con dos modos de ejecución: usuario y núcleo Fase de usuario: –Ejecutando el programa correspondiente –Procesador en el nivel de usuario: privilegio restringido Fase de núcleo: –Ejecutando el S.O. (rutina de interrup., de excepción o llamada) –Procesador en el nivel de núcleo: privilegio total Proceso tiene asociadas dos pilas: –Pila de usuario: usada en fase de usuario –Pila del núcleo: usada en fase de núcleo excep., inter. y llamadas mientras proceso ejecuta usan esta pila

7 Diseño de Sistemas Operativos 7 Ejecución en modo núcleo 2 tipos de actividades: síncronas y asíncronas Actividades síncronas: –Asociadas a llamada al sistema o excepción –Ejecución en el contexto del proceso solicitante Actividades asíncronas: –Asociadas a interrupciones –Ejecución en contexto de proceso no relacionado con la interrup. Rutina de tratamiento no debe acceder a mapa de memoria de proceso actual ya que no está vinculado con interrup. S.O. puede considerarse dividido en 2 partes: –Capa superior que trata eventos síncronos –Capa inferior que trata eventos asíncronos

8 Diseño de Sistemas Operativos 8 Tipos de procesos Proceso de usuario –Ejecuta un programa, en modo usuario excepto cuando: Se inicia el proceso (véase creación de un proceso) Realiza una llamada al sistema Genera una excepción Se produce una interrupción mientras ejecuta Proceso de núcleo –Ejecuta sólo código del S.O., siempre en modo núcleo –Realiza labores del sistema que se hacen mejor en el contexto de un proceso independiente (operaciones de gestión de memoria) –En Linux: bdflush, kupdate, etc. –Normalmente, alta prioridad, pero no siempre (p.e. proceso nulo) –No confundir con procesos del sistema

9 Diseño de Sistemas Operativos 9 Procesos del sistema Procesos de usuario creados por el superusuario Ejecutan en modo usuario –Pero sus llamadas al sistema son siempre atendidas En sistemas monolíticos realizan labores del sistema como spooling o servicios de red (demonios de UNIX) En sistemas microkernel realizan funcionalidades clásicas del S.O. como p.e. la gestión de ficheros

10 Diseño de Sistemas Operativos 10 Vectores de interrupción Tabla de vectores de interrupción: –Contiene direcciones de rutinas del S.O. –Únicos puntos de entrada del S.O. –S.O. inicia contenido de la tabla en su arranque Interrupciones externas (de dispositivos): –Dispositivo proporciona vector (puede configurarse) –P.e. En Linux usan vectores de Excepciones (dividir por cero, instrucción privilegiada,...) –Vector predefinido por cada excepción –Ej. En Intel vector 0 corresponde con excep. por división por cero Llamadas al sistema: –Instrucción especial (en Intel INT): vector como operando –P.e. En LINUX sobre Intel se usa el vector 0x80

11 Diseño de Sistemas Operativos 11 Niveles de interrupción Mayoría de procesadores proporciona niveles de interrupción En cada momento UCP ejecuta en un nivel (Nivel UCP) –Sólo admite int. de nivel > Nivel UCP Cuando acepta int. de nivel N, automáticamente Nivel UCP=N Existen instrucciones para cambiar nivel de UCP –Prohíben ints. del mismo nivel o inferiores Algunos procesadores proporcionan instrucciones que causan interrupciones software –Interrupciones de mínima prioridad

12 Diseño de Sistemas Operativos 12 Tratamiento HW de int., exc. y llamadas Operaciones realizadas por HW cuando se activa inter., exc. o llamada –Si viene de modo usuario activa pila de núcleo del proceso –Salva algunos registros (típicamente PC y R.estado) en pila –Fija un nivel de ejecución de núcleo –Si se trata de interrupción Nivel UCP = Nivel interrup. –Salta a rutina almacenada en vector Entra el S.O. (SW) Fin del manejo de interr., exc. o llamada: –S.O. ejecuta instrucción de retorno correspondiente (p.e. RETI) –Restaura registros salvados en pila recuperando nivel de ejecución y estado de interrupciones previo

13 Diseño de Sistemas Operativos 13 Tratamiento de interrupciones Rutina en ensamblador: vector contiene dirección de comienzo Estructura típica: –Salvar registros en pila de núcleo –Invocar función donde se realiza tratamiento específico Normalmente está escrita en lenguaje de alto nivel –Restaurar registros de la pila del núcleo del proceso –RETI En sistemas con N niveles pueden anidarse N rutinas de interrup. En total hasta N+1 actividades del S.O. anidadas: –1 llamada al sistema + N rutinas de interrupción

14 Diseño de Sistemas Operativos 14 Tratamiento de excepciones Rutina en ensamblador: vector contiene dirección de comienzo Estructura típica: similar al tratamiento de interrupciones Se debe comprobar nivel previo de procesador: –Si era sistema: Pánico: Error en el código del S.O. Se muestra mensaje e info. de depuración y S.O. se para –Si era usuario: Error en programa de usuario Tratamiento dependiente de S.O. –En UNIX manda señal a proceso No siempre error: Puede tratarse de un fallo de página

15 Diseño de Sistemas Operativos 15 Tratamiento de llamadas (1/2) Típicamente un único vector de int. para todas las llamadas Cada llamada tiene asignado un número S.O. tiene definido un vector con direcciones de rutinas que llevan a cabo cada servicio S.O. recibe nº de llamada (normalmente en un registro): –S.O. indexa con él en el vector Parámetros de la llamada normalmente en pila de usuario –Linux usa registros (como mucho 6 parámetros) Resultado de la llamada se suele devolver en un registro

16 Diseño de Sistemas Operativos 16 Tratamiento de llamadas (2/2) Rutina en ensamblador: vector contiene dirección de comienzo Estructura típica similar a anteriores: –Salvar registros en pila de núcleo –Obtener número de llamada (N). –Invocar función indexando en tabla de llamadas resultado=(*tabla_servicios[N])(); la función obtiene y valida los parámetros de la llamada recibidos en pila de usuario –Devuelve resultado (puede devolverlo en un registro) –Restaurar registros de pila del núcleo del proceso –RETI

17 Diseño de Sistemas Operativos 17 Invocación de llamadas al sistema Interfaz a los programas: rutina de biblioteca –read(f, buf, tam) Programa se enlaza con biblioteca de llamadas Rutina de llamada codificada en ensamblador: read(){ PUSH parámetro MOVE R0, #NUM_READ INT 0x80 Valor devuelto está en R RET }

18 Diseño de Sistemas Operativos 18 Multiplexación de procesos Cambio de modo: –De usuario a núcleo (excepción, llamada o interrupción) –De sistema a usuario (RETI) No hay c. de contexto: Mismo proceso en distinto modo Multiprogramación implica reasignar el procesador cuando: –Proceso se bloquea –Es conveniente ejecutar otro proceso en vez del actual Necesidad salvar/restaurar información de los procesos –Info. del proceso Contexto del proceso

19 Diseño de Sistemas Operativos 19 Contexto de un proceso Información asociada con el proceso Almacenada en el Bloque de Control del Proceso (BCP) Tabla de procesos: Vector de BCPs (mejor lista de BCPs) Contenido típico: –Estado del proceso –Copia del contenido de los registros del procesador –Información de planificación (p.e. prioridad) –Información sobre el mapa de memoria del proceso –Información de ficheros y E/S –Información de contabilidad (p.e. tiempo de UCP usado) –Dueño del proceso (uid y gid en UNIX) –Punteros para construir listas de BCPs –Y muchos más: Relaciones entre procs., pid, señales, etc.

20 Diseño de Sistemas Operativos 20 Definición de BCP S.O. es sólo otro programa: Usa definiciones convencionales struct task_struct { long state; long priority; unsigned long signal; struct task_struct *next_run, *prev_run; /* filesystem information */ struct fs_struct *fs; /* open file information */ struct files_struct *files; /* memory management info */ struct mm_struct *mm; }

21 Diseño de Sistemas Operativos 21 Estado de un proceso Elemento del contexto del proceso Durante su vida el proceso pasa por varios estados: –En ejecución: UCP asignada Núm. Procesos en ejecución Núm. Procesadores –Listo para ejecutar: No hay procesador disponible para él –Bloqueado: Esperando un evento En sistemas con suspensión de procesos, estados adicionales: –Suspendido y listo: Expulsado pero listo para ejecutar –Suspendido y bloqueado: Expulsado y esperando un evento

22 Diseño de Sistemas Operativos 22 Transiciones entre estados Transición disparada siempre por activación del S.O. –No toda activación del S.O. implica c. de estado de un proceso. Posibles transiciones para modelo con 3 estados:

23 Diseño de Sistemas Operativos 23 Cambio de contexto Cambio del proceso asignado al procesador Activación del S.O. que cambia estado de dos procesos: –Proceso P pasa de en ejecución a listo o bloqueado –Proceso Q pasa de listo a en ejecución C. contexto: Cambio de proceso –Sólo cuando proceso está en modo núcleo –El propio proceso (P): cambia su estado activa el planificador selecciona Q salva su contexto en BCP restaura contexto de Q del BCP ya está ejecutando Q

24 Diseño de Sistemas Operativos 24 Cambio de contexto Cuando proceso P vuelva a ejecutar: –Seguirá en el punto donde estaba (después de c. contexto) Dificultad para entender el código de gestión de procesos No toda activación del S.O. implica c. contexto No es trabajo útil. Duración típica: decenas de microsegs. Código del c. contexto depende de arquitectura: –Escrito en ensamblador –En Linux switch_to(prev,next)

25 Diseño de Sistemas Operativos 25 Tipos de c. de contexto Cambio voluntario: –Proceso realiza llamada al sistema que implica esperar por evento –Transición de en ejecución a bloqueado –Ejemplos: leer del terminal o bajar un semáforo cerrado –Motivo: Eficiencia en el uso del procesador Cambio involuntario: –S.O. le quita la UCP al proceso –Transición de en ejecución a listo –Ejemplos: fin de rodaja de ejecución o pasa a listo proceso bloqueado de mayor prioridad –Motivo: Reparto del procesador

26 Diseño de Sistemas Operativos 26 Colas de procesos S.O. enlaza BCPs en colas BCP contiene punteros para permitir formar colas Algunos ejemplos: –Cola de procesos listos en muchos sistemas, proceso en ejecución también está en ella –Cola de procesos bloqueados esperando operación sobre un disco –Cola de procesos bloqueados en un semáforo –Cola de procesos esperando que transcurra un plazo de tiempo En Linux, colas de bloqueados: wait queues Un BCP debería estar en una sola cola en cada instante Cambio de estado implica pasar el BCP de una cola a otra

27 Diseño de Sistemas Operativos 27 Bloqueo de un proceso Bloquear (cola de bloqueo) { Estado de proceso actual = BLOQUEADO; NivelUCPPrevio = FijarNivelIntUCP(máximo); /* Prohibir interrupciones */ Mover BCP de cola de listos a cola del evento; nuevo_proceso = planificador( ); Cambio_contexto(proceso_actual, nuevo_proceso); FijarNivelIntUCP(NivelUCPPrevio); /* Por aquí continuará, restaurando nivel int. de UCP, cuando se desbloquee y sea elegido por planificador, mientras habrán ejecutado otros procesos */ } Bloquear no debe invocarse desde rutina de interrupción –Proceso actual no está relacionado con la interrupción

28 Diseño de Sistemas Operativos 28 Desbloqueo de un proceso Desbloquear (cola de bloqueo) { NivelUCPPrevio = FijarNivelIntUCP(máximo); /* Prohibir interrupciones */ Seleccionar proceso en la cola (primero si política FIFO); Estado de proceso elegido = LISTO; Mover BCP de proceso elegido de cola del evento a cola de listos; FijarNivelIntUCP(NivelUCPPrevio); } Desbloquear puede invocarse desde rutina de interrupción (p.e. del terminal) o desde llamada (p.e. subir un semáforo)

29 Diseño de Sistemas Operativos 29 C. de contexto voluntario Proceso en modo usuario invoca llamada con posible bloqueo sis_llamada_X () { Si (condición_1) Bloquear(cola de evento 1); Cuando se desbloquee seguirá por aquí Mientras ( ! condición_2) Bloquear(cola de evento 2); Cuando se desbloquee y se cumpla la condición seguirá por aquí }

30 Diseño de Sistemas Operativos 30 C. de contexto involuntario Rutina de int. o llamada puede desbloquear proceso más importante o indicar que proceso actual ha consumido su turno Situación puede ocurrir dentro de anidamiento de interrup. –Hay que esperar a que terminen Puede estar activa una llamada al sistema –Mayoría de SS.OO. esperan a que termine Véase sincronización dentro del S.O. Necesidad de diferir c. contexto hasta terminar trabajo de S.O. –Se indica que replanificación pendiente ( need_resched en Linux) –Se activa interrupción software Si UCP no tiene int. SW, se puede simular por software –Cuando termina actividad del S.O. (justo antes de volver proceso a modo usuario) se trata int. SW que realiza c. contexto

31 Diseño de Sistemas Operativos 31 C. c. involuntario por desbloqueo Llamada o rutina de int. que causa desbloqueo rutina_X () { Si (condición) Desbloquear(cola de evento); Si proceso desbloqueado más prioridad que actual { replanificación_pendiente = verdadero; Activar interrupción SW; } } Int. SW se tratará cuando acabe rutina_X y otras rutinas del S.O. anidadas, si las hay

32 Diseño de Sistemas Operativos 32 C. c. involuntario por fin de rodaja Interrupción de reloj que indica final de rodaja de p. actual rutina_int_reloj () { Si (--rodaja == 0) { replanificación_pendiente = verdadero; Activar interrupción SW; } } Int. SW se tratará cuando acabe rutina_int_reloj y otras rutinas del S.O. anidadas, si las hay

33 Diseño de Sistemas Operativos 33 Replanificación Tratamiento de int. SW rutina_int_SW () { Si (replanificación_pendiente) { replanificación_pendiente = falso; NivelUCPPrevio = FijarNivelIntUCP(máximo); /* Prohibir int. */ nuevo_proceso = planificador( ); Cambio_contexto(proceso_actual, nuevo_proceso); FijarNivelIntUCP(NivelUCPPrevio); /* Por aquí continuará cuando sea elegido de nuevo por planificador, mientras habrán ejecutado otros procesos */ }

34 Diseño de Sistemas Operativos 34 Sincronización dentro del S.O. (1/2) S.O. es un programa con alto grado de concurrencia: –Varias llamadas al sistema pueden ejecutarse concurrentemente –Puede activarse una interrupción mientras se sirve una llamada Problemas de sincronización complejos: –Es muy difícil asegurar que un S.O. funciona correctamente Ejemplos de problemas de sincronización: –Dos llamadas concurrentes para crear un proceso podrían elegir el mismo BCP para los dos nuevos procesos –Mientras una llamada manipula la cola de listos, se puede activar rutina de interrupción que también la cambie Es necesario secciones críticas dentro del S.O.

35 Diseño de Sistemas Operativos 35 Sincronización dentro del S.O. (2/2) Solución usada en la mayoría de sistemas (Linux, Windows,...): –Sincronización entre una llamada y una rutina de interrupción: código de la llamada prohíbe interrupciones durante s. crítica –P.e. cuando manipula cola procesos listos (bloquear/desbloquear) –Sincronización entre llamadas concurrentes: Limitar concurrencia dentro del S.O. Mientras proceso en modo núcleo no c. contexto involuntario: –Se difieren a que termine trabajo en modo núcleo (int SW) –Se tratan int. mientras proc. en modo núcleo pero sin c. contexto No hay concurrencia entre llamadas: –Más sencillo pero no apropiado para multiprocesadores o s. de tiempo real Para dar soporte SMP (Symmetric MultiProcessing) –Se debe permitir paralelismo en llamadas –Se usan spin-locks y semáforos para sincronización

36 Diseño de Sistemas Operativos 36 Aplazamiento de operaciones de int. Se debe minimizar duración de rutina de interrupción –Mientras prohibidas int. de ese nivel e inferiores En rutina de int. se realizan operaciones urgentes –Resto de operaciones (menos urgentes y más largas) se difieren –Las realiza rutina que ejecuta con int. habilitadas Se suele usar el mecanismo de int. SW –S.O. mantiene una lista de operaciones diferidas –Rutina de int. realiza operaciones urgentes, encola operaciones pendientes en la lista y activa interrupción SW –El tratamiento de int. SW realiza operaciones diferidas En Linux: bottom halves y task queues En Windows: DPCs (Deferred Procedure Calls)

37 Diseño de Sistemas Operativos 37 Tratamiento ampliado de int. SW Tratamiento de int. SW rutina_int_SW () { Mientras (tareas pendientes) Ejecutar siguiente tarea: Si (replanificación_pendiente) { Realiza c.c. involuntario (como se vio previamente) } Las tareas diferidas se ejecutan con ints. habilitadas, pero de manera asíncrona (p. actual no relacionado con ellas) –No deben llamar a bloquear ni acceder a mapa de proceso actual

38 Diseño de Sistemas Operativos 38 Creación de un proceso Operaciones típicas para modelo convencional (Win32) –Buscar entrada libre en tabla de procesos –Leer fichero ejecutable –Crear mapa de memoria a partir del ejecutable –Crear pila inicial de usuario con el entorno del proceso –Crear pila del núcleo con dir. del punto de arranque del programa Proceso comienza en modo núcleo haciendo RETI –Crear contexto inicial en BCP: Fijar valores iniciales de regs. PC inicial=dirección de código de S.O. que contiene RETI Estado = LISTO Incluir BCP en cola de listos En UNIX estas operaciones están repartidas entre: –FORK –EXEC

39 Diseño de Sistemas Operativos 39 Operaciones en la creación (UNIX) Operaciones en FORK –Buscar entrada libre en tabla de procesos –Copiar BCP del padre –Duplicar mapa de memoria del padre (incluyendo pilas) –Estado = LISTO + Incluir BCP en cola de listos –Otras: actualización de filp, etc. Operaciones en EXEC –Leer fichero ejecutable –Liberar mapa de memoria del proceso –Crear nuevo mapa de memoria a partir del ejecutable –Crear pila inicial de usuario con el entorno del proceso –Crear pila del núcleo con dir. del punto de arranque del programa –Crear contexto inicial en BCP: Fijar valores iniciales de regs. PC inicial= dirección de código de S.O. que contiene RETI –Otras: Gestión de señales, SETUID, CLOSE_ON_EXEC, etc.

40 Diseño de Sistemas Operativos 40 Terminación de un proceso Tipo de terminación: –Voluntaria: invoca llamada al sistema (EXIT en UNIX) –Error de ejecución: excepciones (división por cero,...) –Abortado: por un usuario u otro proceso UNIX unifica los dos últimos mediante el uso de señales ¿Qué ocurre con procesos hijos? –En UNIX pasan a depender del proceso init Influencia de la jerarquía: –UNIX: proceso terminado pasa a estado Zombie –Proceso no desaparece hasta que padre espera por él (WAIT)

41 Diseño de Sistemas Operativos 41 Operaciones implicadas en la terminación Operaciones típicas: –liberar mapa de memoria –cerrar ficheros y liberar otros recursos –eliminar BCP de cola de procesos listos –liberar entrada de tabla de procesos –activa planificador y realiza c. de contexto al proceso elegido En UNIX estas operaciones están repartidas entre: –EXIT: realiza la mayor parte de las operaciones –WAIT: libera entrada de tabla de procesos

42 Diseño de Sistemas Operativos 42 Threads Concepto moderno de proceso: –Contiene múltiples flujos de ejecución (threads o procs. ligeros) El proceso se corresponde con un entorno de ejecución: –Un mapa de memoria –Un conjunto de recursos asociados (ficheros, semáforos,...) –Un conjunto de threads Proceso tiene un thread implícito: el flujo de ejecución inicial Threads de un mismo proceso comparten: –Mapa de memoria (código, datos, zonas de mem. compartida,...) –Recursos asociados al proceso (ficheros, semáforos,...) Cada thread tiene recursos propios: –Una pila, un estado y una copia del contenido de los regs. Colas de listos y bloqueo contienen threads en vez de procesos

43 Diseño de Sistemas Operativos 43 Threads BCP sólo contiene info. gral. del proceso + lista de threads BCT (Bloque de Control de Thread): –Info. específica del thread (estado, copia de regs., pilas de usuario y núcleo, prioridad, puntero a BCP del proceso, etc.) Creación de un thread: –Crear pila de usuario con argumentos –Crear pila del núcleo con dir. inicial del thread –Crear contexto inicial en BCT: Fijar valores iniciales de regs. PC inicial=dirección de código de S.O. que contiene RETI Incluir BCT en cola de listos Ventajas del uso de threads vs. procesos convencionales: –Permiten expresar concurrencia ligera y fuertemente acoplada Ligera: C. de contexto más rápido Fuertemente acoplada: Mayor grado de compartición

44 Diseño de Sistemas Operativos 44 Threads de biblioteca Threads creados por biblioteca: S.O. no conoce su existencia Desventajas: –Llamada bloqueante de thread bloquea todo el proceso –No sacan provecho de múltiples procesadores Ventaja: gestión de threads no implica al S.O. –Más ligeros –BCTs no consumen memoria del S.O. –Posibilidad de crear programas con nº muy elevado de threads Existen esquemas híbridos (Solaris)

45 Diseño de Sistemas Operativos 45 Threads en Solaris S.O. gestiona LWPs Usuario crea threads de biblioteca Biblioteca se encarga de correspondencia entre LWPs y threads –En cada momento un LWP ejecuta thread asociado –Biblioteca multiplexa threads entre LWPs Nº de threads > Nº de LWPs –Cuando thread hace llamada bloqueante, LWP asociado se bloquea Biblioteca puede crear nuevo LWP Biblioteca ajusta dinámicamente nº de LWPs de manera que: –Sean suficientes para ejecutar threads activos –No gasten muchos recursos del S.O.

46 Diseño de Sistemas Operativos 46 Procesos de peso variable En Linux y UNIX BSD no hay soporte directo de threads, pero: –Se permite especificar qué recursos comparten padre/hijo Extensión de FORK –Peso variable: Más compartimiento más ligeros En Linux, CLONE permite especificar si comparten: –Info. sobre ficheros (directorio actual, ficheros abiertos,...) –Info. de mapa de memoria –Info. de manejo de señales BCP incluye punteros en vez de la propia información: –No hay BCTs, un BCP por proceso

47 Diseño de Sistemas Operativos 47 Planificación del procesador ¿Cómo seleccionar el mejor algoritmo? Diferentes criterios (incluso contrapuestos): Buscar compromiso –Maximizar grado de utilización de UCP –Maximizar rendimiento: nº de procesos terminados/u. de tiempo –Minimizar tiempo de espera de cada proceso: tiempo gastado esperando en cola de listos –Minimizar tiempo de respuesta de procesos interactivos: tiempo desde que usuario realiza petición hasta que el proceso empieza a responder Tendencia general: Favorecer trabajos más interactivos –Teoría de colas: servir primero peticiones más cortas Racha de UCP de un proceso: tiempo que va a usar la UCP hasta que se bloquee –Mayoría de SS.OO. favorecen procs. con mucha E/S aunque no sean interactivos

48 Diseño de Sistemas Operativos 48 Escenarios de c. de contexto Potenciales: Depende del algoritmo de planificación Posibles escenarios: 1) Proceso en ejecución finaliza 2) Proceso realiza llamada al sistema que lo bloquea 3) Proceso realiza llamada al sistema que desbloquea proceso más importante 4) Interrupción desbloquea proceso más importante 5) Se crea un proceso más importante que el que está en ejecución 6) Interrupción de reloj marca fin de rodaja de ejecución Dos tipos de algoritmos: –no expulsivos: sólo c. de contexto voluntarios (1 y 2) –expulsivos: además c. de contexto involuntarios (3, 4, 5 y/o 6)

49 Diseño de Sistemas Operativos 49 Algoritmos de planificación FIFO (o FCFS) Primero el más corto (SJF) Prioridad Round-Robin Colas multinivel Planificación por lotería Planificación en Linux

50 Diseño de Sistemas Operativos 50 Algoritmo FIFO Selección: Proceso que lleva más tiempo en cola de listos Algoritmo no expulsivo: –sólo se activa cuando proceso en ejecución se bloquea o termina Fácil de implementar: –Cola de listos gestionada en modo FIFO No válido para procesos interactivos Mal tiempo medio de espera en cola de listos: –Proceso con rachas de UCP más pequeñas puede tener que esperar –Mejor realizar antes servicios más cortos: Algoritmo primero el más corto (SJF, Shortest Job First)

51 Diseño de Sistemas Operativos 51 Algoritmo SJF Selección: Proceso en la cola de listos que tenga una próxima racha de UCP más corta Versión no expulsiva: –sólo se activa cuando proceso en ejecución se bloquea o termina Versión expulsiva: –también se activa cuando aparece un nuevo proceso en cola de listos (escenarios 3, 4 y 5) Se favorecen los procesos con más E/S ¿Cómo se conoce a priori la duración de la próxima racha? –Estimaciones a partir de las anteriores Puede producir inanición: –A un proceso con rachas muy largas se le cuelan todos

52 Diseño de Sistemas Operativos 52 Planificación por prioridad Cada proceso tiene asignada una prioridad Selección: Proceso en cola de listos que tenga mayor prioridad SJF es de este tipo: Prioridad depende de tamaño de racha Como SJF, existe versión no expulsiva y expulsiva Las prioridades pueden ser estáticas o dinámicas La prioridad de un proceso puede venir dada por factores: –externos: ¿quién es el usuario? ¿qué importancia asigna el usuario a este proceso (en UNIX nice)? –internos: comportamiento del proceso Puede producir inanición: –A un proceso con baja prioridad se le cuelan todos –Envejecimiento: Prioridad aumenta con el tiempo

53 Diseño de Sistemas Operativos 53 Algoritmo Round-Robin Algoritmo FIFO + cuanto de tiempo Cuando se asigna UCP a proceso se le da un cuanto de tiempo –Si lo gasta (racha>cuanto) es expulsado al final de cola de listos Algoritmo expulsivo pero sólo con fin del cuanto (escenario 6) Tiempo de respuesta acotado: –Si cuanto igual a C y N procesos listos: proceso no esperará más de (N-1)*C u. de tiempo Tamaño del cuanto: –grande: tiende a FIFO. Mal tiempo de respuesta –pequeño: demasiada sobrecarga Debe ser grande con respecto al tiempo de c. de contexto –Típico: milisegundos

54 Diseño de Sistemas Operativos 54 Colas multinivel Modelo más general: –Cola de listos organizada en múltiples niveles –P.ej. Dependiendo de la interactividad de los procesos Cada nivel puede tener su propio algoritmo: –P.ej. RR para niveles más interactivos y FIFO para los menos Existe un algoritmo para seleccionar entre niveles: –P.ej. Por prioridades, mayor los niveles más interactivos Realimentación: –Posibilidad de que los procesos cambien de nivel Deben existir criterios de cambio de nivel: –P.ej. Mover de nivel un proceso si tiende a aumentar o disminuir su interactividad

55 Diseño de Sistemas Operativos 55 Planificación por lotería Carácter aleatorio Cada proceso posee un billete de lotería Planificador: escoge billete y selecciona al premiado Procesos importantes pueden tener varios billetes Procesos cooperantes pueden intercambiarse billetes: –Proceso cliente una vez hecha la petición puede ceder sus billetes al servidor

56 Diseño de Sistemas Operativos 56 Planificación en Linux (1/2) Cumple estándar POSIX: soporta clases de planificación Clase de tiempo real (no crítico): –Proceso tiene asignada una prioridad –Dos clases de planificación: FIFO: ejecuta hasta que se bloquea Round-Robin: reparto UCP entre procesos de igual prioridad Clase de tiempo compartido: –Procesos de esta clase sólo ejecutan si no hay de tiempo real –Cada proceso tiene una prioridad estática (nice) –Algoritmo basado en créditos –En cada interrup. de reloj: proceso en ejecución pierde un crédito Si se queda sin créditos: se le revoca la UCP

57 Diseño de Sistemas Operativos 57 Planificación en Linux (2/2) Planificador selecciona proceso con más créditos –Si ningún proceso tiene créditos -> Reasignación de créditos. Reasignación de créditos: Para todo proceso del sistema: –créditos = créditos/2 + prioridad Propiedades: –Compagina la historia del proceso con su prioridad –Procesos que usan mucha UCP pierden rápido sus créditos –Procesos con mucha E/S acumulan créditos –Se favorecen procesos interactivos


Descargar ppt "Diseño de sistemas operativos Tema 2 Gestión de procesos."

Presentaciones similares


Anuncios Google