El documento describe los conceptos de procesos, estados de procesos, implementación de procesos, comunicación entre procesos, secciones críticas y exclusión mutua. Un proceso es un programa en ejecución que puede estar en los estados de ejecutando, listo, bloqueado o muerto. El sistema operativo mantiene información sobre cada proceso en una tabla de procesos. Los procesos se comunican para transferir información y deben coordinarse para evitar condiciones críticas cuando comparten recursos.

1. 2.- ADMINISTRACION DE PROCESOS Proceso Un proceso es un programa en ejecución , el cual incluye los valores actuales del contador de programa, registros y variables. Un programa por si s ó lo no es un proceso; un programa es una entidad pasiva, mientras que un proceso es una entidad activa. (a) Proceso secuencial E s aquél que está compuesto por un conjunto de operaciones en estricto orden secuencial en el tiempo, las cuales son ejecutadas por un único procesador . Esto significa que en cualquier instante de tiempo , a lo sumo una instrucción del proceso es ejecutada. A pesar de que dos procesos pueden estar a sociados con el mismo programa, se deben considerar como dos secuencias de ejecución disjuntas. (b) Proceso concurrente Es aquél en el cual sus operaciones están mezcladas en el tiempo, existiendo un único procesador para ejecutar las operaciones.El traslapo en las operaciones se refiere a que el procesador atiende a más de un proceso pero no simultáneamente. (c ) Proceso paralelo Es aquél en el que sus operaciones se pueden ejecutar (si la lógica del proceso así lo permite) por varios procesadores simultáneamente en el tiempo.

2. E stados de un proceso Un proceso puede estar en uno de los siguientes cuatro estados: Ejecutando (running) : sus instrucciones están siendo ejecutadas por la CPU. Por lo tanto, a lo más un proceso puede estar en este estado en un sistema uniprocesador. Bloqueado (blocked) : el proceso no está en condiciones de ejecutarse. E stá esperando la ocurrencia de algún evento (por ejemplo la terminación de una entrada/salida) para salir de este estado . Listo (ready) : el proceso está en condiciones de ejecutarse (temporalmente detenido) pero está esperando que se le asigne la CPU . En abrazo mortal (deadlock): el proceso está esperando por un evento que nunca ocurrirá. Transiciones Running  Blocked : ocurre cuando un proceso detecta que no puede continuar y debe esperar un evento para salir del estado Blocked. Running  Ready : ocurre cuando el administrador de procesos decide que el proceso en ejecución ha permanecido un cierto tiempo utilizando la CPU y es el momento de dejar que otro proceso haga uso de ella. Ready  Running : ocurre cunado los otros procesos han utilizado la CPU y es el tiempo que el primer proceso use nuevamente la CPU. Blocked  Ready : ocurre cuando llega un evento externo que un proceso estaba esperando. Si ningún otro proceso está en ejecución en ese instante, entonces la transición Ready  Running puede ser activada rápidamente y el proceso comenzará su ejecución. De otra manera, el proceso debe esperar en el estado READY hasta que la CPU esté disponible. Blocked  Deadlock : ocurre cuando un proceso no puede acceder a un recurso, y otros procesos tampoco pueden acceder a dicho recurso

3. RUNNING READY BLOCKED DEADLOCK INTERRUPCION ASIGNAR CPU ESPERAR EVENTO OCURRENCIA DE EVENTO NUEVO PROCESO PROCESO FINALIZADO

5. El manejo de una rutina de interrupción se puede resumir en la siguiente secuencia: - se almacena el contador de programa (CP) y otras variables - se carga un nuevo CP desde el Vector de Interrupciones - una rutina R (en código de máquina) guarda los registros y luego construye un nuevo stack - una rutina T (en código de alto nivel) marca el proceso de interrupción como READY - el administrador de procesos decide qué proceso se ejecutará a continuación - la rutina T retorna a la rutina R - la rutina R activa al proceso actual Cambios de contexto Cuando el sistema operativo asigna la CPU a un nuevo proceso, se debe guardar el estado del proceso que estaba ejecutando, y cargar el estado del nuevo proceso. El estado de un proceso comprende el PC, y los registros de la CPU. Además, si se usan las técnicas de administración de memoria, hay más información involucrada. Este cambio, que demora unos pocos mi li segundos, dependiendo del procesador, es overhead o sobrecosto, puesto que entretanto la CPU no hace trabajo útil (ningún proceso avanza). Considerando que la CPU hace varios cambios de contexto en un segundo, su costo es relativamente alto. Algunos procesadores tienen instrucciones especiales para guardar todos los registros de una vez. Otros tienen varios conjuntos de registros, de manera que un cambio de contexto se hace simplemente cambiando el puntero al conjunto actual de registros. El problema es que si hay más procesos que conjuntos de registros, igual hay que apoyarse en la memoria. Como sea, los cambios de contexto involucran un costo importante, que hay que tener en cuenta.

6. Comunicación entre procesos Frecuentemente, los procesos necesitan comunicarse con otros procesos para transferir información que unos y otros requieren. Por ejemplo, cuando un "proceso_usuario" desea leer desde un archivo, éste debe informarle a un "proceso_archivo" la acción que intenta realizar. El "proceso_archivo" debe enviar a un "proceso_disco" una indicación de lectura del bloque correspondiente. La información leída es transferida a la salida del "proceso_usuario" a través de los procesos mencionados anteriormente. PROCESO_USUARIO PROCESO_ARCHIVO PROCESO_DISCO

7. Condiciones Críticas En general, los procesos comparten almacenamiento común de modo que cada uno de ellos pueda leer o escribir. En esta compartición, los procesos deben comunicarse con el sistema operativo para transferir o requerir información. En el siguiente ejemplo se describe el proceso de impresión de archivos destacando la comunicación entre procesos y las consecuencias que ésto conlleva. Cuando un proceso desea imprimir un archivo, éste incorpora el "nombre del archivo" en un directorio especial. Otro proceso (denominado proceso_impresor), chequea periódicamente si existen archivos a ser impresos. Si hay archivos ya impresos entonces remueve sus nombres del directorio. Supongamos que este directorio dispone de una gran cantidad de "ranuras" numeradas 0,1,2,3,4,.....N, donde cada una es capaz de almacenar un "nombre de archivo". Supongamos, además, que existen 2 variables IN , OUT que son compartidas por todos los procesos, tal que OUT apunta al próximo archivo a ser impreso e IN apunta a la próxima "ranura" libre en el directorio. Si en un cierto instante, las ranuras 0,1,2,3 están vacías (los archivos ya han sido impresos) y las ranuras 4,5,6 están ocupadas (con los nombres de los archivos por imprimir), y los procesos A y B deciden imprimir, entonces la situación que resulta es la siguiente: - el proceso A lee la variable IN y almacena el valor 7 en una variable local "prox_ranura_libre". Justo en ese instante el Sistema Operativo decide llevar al estado READY al proceso A y al estado RUNNING al proceso B. - el proceso B también lee la variable IN y también obtiene 7, almacenando su nombre de archivo en la ranura 7 y actualiza IN con el valor 8. Luego el proceso B continua con la ejecución del código. - eventualmente, el proceso A será ejecutado nuevamente, partiendo del punto en que había quedado anteriormente. Cuando el proceso A emplee la variable "prox_ranura_libre", encuentra un 7 y escribe su nombre de archivo en la ranura 7, borrando el nombre que el proceso B había grabado allí. Entonces incrementa "prox_ranura_libre", y pone 8 en IN.

8. - El directorio ahora está internamente consistente, de modo que el "proceso_impresor" no notará nada erróneo......! pero el proceso B nunca podrá imprimir ! Situaciones como la anterior donde existen dos o más procesos que están leyendo o escribiendo sobre algunas variables comunes y el resultado final depende de qué proceso se ejecute, se denominan CONDICIONES CRITICAS PROG1.C PROG2.PAS PROG3.BAS 1 2 3 4 5 6 7 8 N 7 4 IN OUT PROCESO A PROCESO B

9. Sección Crítica En los Sistemas Operativos, parte del tiempo los procesos están ocupados ejecutando cálculos internos y otras tareas que no conducen a "condiciones críticas". Sin embargo, algunas veces un proceso puede acceder a compartir archivos, memoria o realizar acciones que pueden tender a condiciones críticas . El trozo de código de un proceso donde se comparten recursos que pueden llevar a condiciones críticas se denomina SECCION CRITICA o REGION CRITICA. Para tener un conjunto de procesos concurrentes compartiendo recursos de manera correcta y eficiente deben cumplirse las siguientes condiciones: (a) Sólo un proceso puede estar simultáneamente dentro de una sección crítica (b) Un proceso permanece dentro de una sección crítica por un tiempo finito (c) Cuando un proceso desea entrar a una sección crítica, debe habilitar la sección en un tiempo finito Los criterios (a) y (c) imponen las siguientes restricciones sobre el "Administrador de Secciones Críticas" asociados con un determinado proceso: - Cuando ningún proceso está dentro de una sección crítica , un proceso puede entrar a esta sección inmediatamente. - Cuando un proceso está dentro de una sección crítica , otros procesos que tratan de entrar a esta sección serán retardados para su ejecución - Cuando un proceso deja una sección crítica mientras otros procesos están tratando de entrar, uno de los procesos será habilitado a proceder dentro de su sección. - Alguna regla de prioridad utilizada para seleccionar un proceso retardado deber se "equitativa", esto es, un proceso no puede ser retardado indefinidamente a favor de procesos más urgentes.

10. Exclusión Mutua La clave para evitar las condiciones críticas es encontrar una técnica que asegure que si un proceso está usando un recurso compartido, los otros procesos sean excluidos de hacer lo mismo "simultáneamente". A esta técnica se la denomina EXCLUSION MUTUA. Aunque existen varias proposiciones que permiten la realización de la exclusión mutua, analizaremos una solución propuesta por G.L. Peterson (1981). Consideremos dos procesos que desean compartir variables. Antes de usar tales variables, cada proceso debe invocar a una rutina denominada "Entrar_Region", con su propio número de proceso (sea éste 0 o 1) como parámetro. Esta llamada causará una espera, si es necesario, hasta estar seguro que se puede entrar a la región. Después que se han utilizado las variables compartidas, el proceso debe invocar a la rutina "Salir_Region" para indicar que ya se dejó de utilizar las variables, permitiendo que otro proceso entre a su región crítica, si lo desea. En un seudo-lenguaje, las rutinas mencionadas se escriben como sigue: CONST True=1; False=0; int ACTIVO; int INTERESADO[2]; /* inicialmente contiene solo valores 0 */ Entrar_Region (int num_proceso) /* el Nº del proceso es 0 o 1 */ { int otro_proc; /* indica el Nº del otro proceso */ otro_proc = 1 - num_proceso; /* el proceso opuesto */ INTERESADO[num_proceso] = True; /* el proceso "num_proceso" está interesado en ingresar */ /* a la region crítica */ ACTIVO = num_proceso; /* marcar proceso que entra */ while ( (ACTIVO == num_proceso) & (INTERESADO[otro_proc] == True) ) ; }

11. Salir_Region (int num_proceso) { INTERESADO[num_proceso] = False; /* indica la salida de la región crítica */ } Inicialmente ningún proceso está en su región crítica. Supongamos que el proceso 0 llama a "Entrar_Region". Este proceso indica su interés por alterar el valor del arreglo INTERESADO y poner un 0. Ya que el proceso 1 no está interesado, entonces "Entrar_Region" retorna inmediatamente. Si el proceso 1 ahora llama a "Entrar_Region" entonces quedará esperando hasta que INTERESADO[0] contenga False, un evento que sólo ocurrirá cuando el proceso 0 invoque a "Salir_Region". Consideremos ahora que ambos procesos llamen a "Entrar_Region" "simultáneamente". Ambos almacenarán su número de proceso en la variable ACTIVO pero sólo uno de ellos hará la asignación al último (recordar que se dispone de una única CPU en este caso). Supongamos que el proceso 1 almacena al último (ésto es, ACTIVO=1). Cuando ambos procesos vayan a ejecutar la instrucción "while (...) ", el proceso 0 la ejecutará 0 veces y entrará a su región crítica. El proceso 1, por otra parte, realizará el ciclo varias veces y no entrará a su región crítica. Ejemplo Se tiene un sistema que administra un conjunto de bloques de memoria usando un STACK para almacenar las direcciones de los bloques libres de memoria. Se pide implementar las rutinas abajo indicadas utilizando el código para proteger las secciones críticas. Suponer que la estructura de datos STACK nunca está vacía. Obtener_Bloque(dir) { dir = Sacar(tope); tope = tope -1; } Liberar_Bloque(dir) { tope = tope +1; Poner(tope,dir); } tope : variable global Sacar (X): función que retorna el contenido de lo apuntado por X en el stack Poner (X,Y): función que almacena Y en lo apuntado por X en el stack

12. Solución Si las rutinas "Obtener_Bloque" y "Liberar_Bloque" son invocadas desde procesos concurrentes que comparten la variable "tope" y la estructura "stack", puede ocurrir cualquier secuencia entremezclada de instrucciones como la siguiente: tope = tope +1; /* liberar un bloque */ dir = Sacar(tope); /* obtener un bloque... se obtiene aquí un valor indefinido */ tope = tope -1; /* obtener un bloque */ Poner(tope,dir); /^* liberar un bloque.....se está borrando una dirección válida */ En la situación anterior, el sistema puede quedar en "estados inválidos". La idea entonces es que "Obtener_Bloque" y "Liberar_Bloque" deben ejecutarse de manera INDIVISIBLE, lo que implica que debe existir "exclusión mutua" entre ambas rutinas. Luego, la implementación de las secciones críticas es: Obtener_Bloque (dir) { Entrar_Region(nproc); dir = Sacar(tope); tope = tope -1; Salir_Region(nproc); } Liberar_Bloque (dir) { Entrar_Region(nproc); tope = tope +1; Poner(tope,dir); Salir_Region(nproc); } nproc : variable global que indica el Nº del proceso que desea ingresar a la región crítica

13. Semáforos Otra solución más general al problema de la exclusión mutua entre procesos (propuesta por Dijkstra, 1965) consiste en utilizar una herramienta de sincronización del acceso a la sección crítica denominada SEMAFORO. Un semaforo S es una variable entera que, aparte de su inicialización, sólo se puede tener acceso a ella a través de dos operaciones básicas indivisibles : WAIT y SIGNAL. También estas operaciones se las conoce como P (&quot;proberen&quot;) y V (&quot;verhogen&quot;). Las definiciones básicas de WAIT y SIGNAL son las siguientes: WAIT (S) { while (S <= 0) ; S = S -1; } SIGNAL (S) { S = S + 1; } Si S= 0 hay un proceso en su región crítica Si S = 1 ningún proceso está en su región crítica Si S < 0 hay un proceso en su región crítica y hay | S | procesos esperando entrar a sus regiones críticas. Las modificaciones de la variable S, en WAIT y SIGNAL, son ejecutadas de manera INDIVISIBLE, esto es, cuando un proceso modifica el valor del semáforo, ningún otro proceso puede simultáneamente modificar el mismo valor del semáforo. En el caso de un sistema con N procesos, cada proceso que comparte un semáforo S común tiene un código como el siguiente: while (True) { WAIT(S); ......... /* región crítica */ SIGNAL(S); }

14. La principal desventaja de las definiciones anteriores de WAIT y SIGNAL y de exclusión mutua es que ellas implican un gasto inútil de tiempo de CPU . Cuando un proceso está en su sección crítica, cualquier otro proceso que trate de entrar en su sección crítica debe esperar (en un ciclo), haciendo uso de la CPU (&quot;busy-waiting&quot;). Una forma más eficiente de uso de la CPU, consiste en hacer que el proceso pase al estado BLOCKED (por sí mismo). Una operación básica BLOCK( ) ubica al proceso en ese estado y transfiere el control al &quot;Administrador de Procesos&quot;, el cual selecciona otro proceso a ejecutar. A un proceso que está bloqueado, esperando en un semáforo S, se le puede cambiar al estado READY mediante otra operación básica denominada WAKEUP( ). Las operaciones WAIT y SIGNAL pueden ahora redefinirse con la suposición que se dispone de una estructura de datos como la siguiente (S es un semáforo): El semáforo S tiene una variable entera (VALOR) y un arreglo de enteros (PROCESOS), que almacenan los identificadores de proceso. Cuando un proceso debe esperar en un semáforo (WAIT), el identificador del proceso se agrega al arreglo PROCESOS. Una operación SIGNAL remueve un proceso del arreglo PROCESOS y lo despierta. Las operaciones WAIT y SIGNAL se implementan entonces ahora como: VALOR PROCESOS 1 2 3 N S { int VALOR; int PROCESOS[N]; }

15. WAIT (S) { S.VALOR = S.VALOR -1; if (S.VALOR < 0) { Agregar(id_proc,S.PROCESOS); Block (id_proc); } } SIGNAL (S) { S.VALOR = S.VALOR + 1; if (S.VALOR <= 0) { Remover(id_proc,S.PROCESOS); WakeUp (id_proc); } }

18. Problemas clásicos de sincronización de procesos (a) Problema de la Cena de los Filósofos Existen N filósofos sentados alrededor de una mesa circular. Cada filósofo tiene un plato de &quot;spaguetti especial&quot; el cual sólo puede ser comido con dos tenedores a la vez . Entre cada plato se dispone de un tenedor. La vida de cada filósofo consiste en periodos alternados de comer y pensar (otras necesidades son ignoradas para este problema). Cuando un filósofo tiene hambre, trata de tomar el tenedor de la izquierda y el de la derecha, uno a la vez y en cualquier orden. Si tiene éxito en tomar los dos tenedores entonces come durante algunos instantes. Luego deja los tenedores y sigue pensando. El problema que surge es: ¿cómo podrá programarse cada filósofo de modo que todos puedan comer ? 1ª Solución (trivial) Esperar hasta que un tenedor específico esté disponible y entonces utilizarlo. El problema que podría ocurrir es que todos los filósofos tomen su tenedor izquierdo &quot;simultáneamente&quot; => ninguno podrá tomar su tenedor derecho ==> deadlock 2ª Solución Después de tomar el tenedor izquierdo, el filósofo verifica si el tenedor derecho está disponible. Si éste no lo está entonces el filósofo deja el tenedor izquierdo, espera algún tiempo y luego repite todo el procedimiento anterior. El problema en este caso, es que todos los filósofos podrían partir con su procedimiento &quot;simultáneamente&quot;, tomando sus tenedores izquierdos; viendo que sus tenedores derechos estén disponibles; dejando sus tenedores izquierdos; esperando tomar sus tenedores izquierdos; etc... ==> procedimientos continuan realizando indefinidamente sin ningún progreso ==> inanición (starvation).

19. 3ª Solución (mediante semáforos) Se definen las variables globales: N (número de filósofos), PENSANDO (filósofo está pensando), HAMBRIENTO (filósofo está tratando de tomar un tenedor), COMIENDO (filósofo está comiendo), ESTADO [N] (arreglo que almacena el estado de los filósofos), S [N] (arreglo de semáforos) , REG (semáforo utilizado para exclusión mutua). El código asociado a esta solución es el siguiente: int N; int PENSANDO = 0; int HAMBRIENTO = 1; int COMIENDO = 2; int ESTADO[N]; Semaforo S[N]; /* se supone que existe una estructura de datos denominada Semaforo */ Semaforo REG; izq ( K) /* Función que retorna el vecino izquierdo del filósofo K */ { /* Suponer que el vecino izquierdo del filósofo N-1 es 0 */ return( K +1); } der ( K) /* Función que retorna el vecino izquierdo del filósofo K */ { /* Suponer que el vecino derecho del filósofo 0 es N - 1 */ return(K-1); }

20. filósofo ( j ) { while (True) { Pensar( ); /* filósofo está pensando */ Tomar_Tenedor( j ); /* filósofo j está tratando de tomar dos tenedores */ Comer( ); /* filósofo está comiendo */ Poner_Tenedor( j ); /* poner ambos tenedores en la mesa */ } } Tomar_Tenedor ( j ) /* filósofo j trata de tomar ambos tenedores */ { WAIT(REG); /* entrar a región crítica */ ESTADO[ j ] = HAMBRIENTO; /* almacenar el hecho que el filósofo j está hambriento */ Tratar( j ); /* tratar de tomar dos tenedores */ SIGNAL(REG); /* salir de la región crítica */ WAIT(S[ j ]); /* bloquear el proceso si los tenedores no pudieron ser tomado */ } Poner_Tenedor ( j ) /* filósofo j pone tenedores en la mesa */ { WAIT(REG); /* entrar a región crítica */ ESTADO[ j ] = PENSANDO; /* filósofo j terminó de comer */ Tratar( izq ( j ) ); /* ver si el vecino izquierdo puede ahora comer */ Tratar( der ( j ) ); /* ver si el vecino derecho puede ahora comer */ SIGNAL(REG); /* salir de la región crítica */ }

21. Tratar ( j ) /* filósofo j trata de tomar dos tenedores. Si no puede, queda bloqueado */ { if ( (ESTADO[ j ] == HAMBRIENTO ) & ( ESTADO[ izq ( j ) ] != COMIENDO) & (ESTADO[ der ( j ) ] != COMIENDO) ) { ESTADO[ j ] = COMIENDO; /* filósofo j logró tomar ambos tenedores y puede comer */ SIGNAL(S[ j ]); /* desbloquear el proceso si los tenedores no pudieron ser tomado */ } } (b) Problema del Consumidor-Productor Dos procesos comparten un área de memoria (buffer) común de tamaño fijo. Uno de ellos (PRODUCTOR) escribe información hacia el buffer y el otro (CONSUMIDOR) la lee. Los problemas surgen cuando el PRODUCTOR desea escribir en el buffer y éste está lleno o bien el CONSUMIDOR lee información y el buffer está vacío. Solución mediante semáforos Se define la variable global N (nº de ranuras en el buffer), y los semáforos REG (controla el acceso a la región crítica), VACIO (cuenta el nº de ranuras vacías en el buffer), y LLENO (cuenta el nº de ranuras llenas en el buffer). Las rutinas del PRODUCTOR-CONSUMIDOR son las siguientes:

22. Productor ( ) { int info; while (True) { Producir_Informacion( info ); /* función para generar información en la variable local &quot;info&quot; */ WAIT(VACIO); /* decrementar el nº de ranuras vacías */ WAIT(REG); /* entrar a región crítica */ Poner_Buffer(info); /* escribir &quot;info&quot; a una ranura del buffer */ SIGNAL(REG); /* salir de region crítica */ SIGNAL(LLENO); /* incrementar nº ranuras llenas */ } } Consumidor ( ) { int info; while (True) { WAIT(LLENO); /* decrementar el nº de ranuras llenas */ WAIT(REG); /* entrar a región crítica */ Sacar_Buffer(info); /* leer información desde el buffer hacia &quot;info&quot; */ SIGNAL(REG); /* salir de region crítica */ SIGNAL(VACIO); /* incrementar nº ranuras vacias */ Consumir_Informacion( ); /* función para recuperar información desde el buffer */ } }

23. Características de la administración de procesos Uno de los conceptos importantes en Sistemas Operativos es MULTIPROGRAMACION. La idea de Multiprogramación es simple: varios procesos son mantenidos en memoria al mismo tiempo. Cuando un proceso tiene que esperar, el Sistema Operativo &quot;toma el control&quot; de la CPU y se la asigna a otro proceso. La idea de administrar la CPU eficientemente está enfocada en dos aspectos: el primero es la cantidad de procesos por unidad de tiempo que se pueden ejecutar en un sistema; y el segundo, el que importa más al usuario, es el tiempo de respuesta de esos procesos. - Cantidad de Procesos por Unidad de Tiempo (throughput) - Tiempo de Respuesta (turnaround time) La idea de repartir el recurso CPU entre distintos procesos se debe a que tenemos la posibilidad de utilizar el tiempo de CPU abandonado por un proceso para que lo pueda usar otro, o sea, aprovechar los tiempos muertos de un determinado proceso para que se puedan ejecutar otros. Estos tiempos muertos se producen porque existen otras actividades que están desarrollándose sobre cierto proceso. Esas otras actividades generalmente son de E/S, y ésto es posible porque existe algo que está ayudando a realizar esa E/S, es decir, existen canales o procesadores de E/S que ayudan a descargar la CPU de esa actividad. El siguiente ejemplo ilustra la diferencia que existe al emplear o no Multiprogramación. Dado dos procesos A y B , cada uno de los cuales ejecuta código durante 1 seg. y entonces espera el ingreso de datos por 1 seg. Esto se repite por varios segundos hasta finalizar los procesos.

24. PROCESO A PROCESO B ESPERA UNA ENTRADA DE DATOS EJECUCION DE CÓDIGO PROCESO A PROCESO B SIN MULTIPROGRAMACION CON MULTIPROGRAMACION PROCESO A PROCESO B PROCESO B DEBE ESPERAR ESTE TIEMPO

25. Niveles de administración de procesos Existen tres niveles importantes de administración de procesos: (a) Administración de alto nivel - Determina a qué procesos se les va a permitir competir activamente por los recursos del sistema (b) Administración de nivel intermedio - Determina a qué procesos se les va a permitir competir por la CPU - Responde a fluctuaciones de corto plazo en la carga del sistema (efectua &quot;suspensiones&quot; y &quot;activaciones&quot; de procesos). - Debe ayudar a alcanzar ciertas metas en el rendimiento total del sistema (c ) Administración de bajo nivel - Determina a qué proceso en estado READY se le asigna la CPU cuando ésta queda disponible (&quot;despacha&quot; la CPU al proceso) - Esta administración la efectua el &quot;Despachador&quot; (dispatcher) del S.O.: opera muchas veces por seg. y reside siempre en memoria principal.

26. Componentes básicos de un Administrador de Procesos CPU : debe responder a errores de hardware, requerimientos de los procesos y a interrupciones de E/S. READY QUEUE : los procesos que están en estado READY y esperando ser ejecutados, son mantenidos en una estructura de datps especial denominada READY QUEUE la cual puede ser implementada como cola FIFO, una cola de prioridad, un árbol, etc. DEVICE QUEUE : corresponde a una lista de procesos que esperan por un requerimiento de un dispositivo de E/S. Cada dispositivo tiene su propia DEVICE QUEUE. I/O : corresponde al dispositivo físico (controlador). READY QUEUE CPU DEVICE QUEUE DEVICE QUEUE DEVICE QUEUE DEVICE QUEUE I/O I/O I/O I/O LLEGADAS SALIDAS

28. La distinción fundamental entre estos dos administradores es la &quot;frecuencia&quot; de su ejecución. El administrador (b) debe seleccionar y asignar la CPU a un proceso de manera muy rápida: un proceso puede ejecutar su código sólo durante unos milisegundos. El administrador (a) tiene menor frecuencia de ejecución, ya que pueden existir varios minutos entre la llegada de nuevos procesos al sistema. Este administrador controla el &quot;grado de multiprogramación&quot; (Nº de procesos en memoria). Si este grado se mantiene estable en el tiempo entonces la &quot;tasa promedio de llegadas&quot; de los procesos que entran al sistema es igual a la &quot;tasa promedio de salida&quot; de los procesos que dejan el sistema. READY QUEUE CPU DEVICE QUEUE I/O LLEGADAS SALIDAS LONG-TERM SCHEDULER SHORT-TERM SCHEDULER

29. Algunos aspectos de Teoría de Colas (a) Supuestos - Llegadas al sistema se generan una por vez, sin colisiones -Las llegadas se producen en tiempos aleatorios: t 0 < t 1 < t 2 ........< t N - Se puede definir el tiempo entre llegadas como: t = t k - t k-1 k > 0 (b) Tiempo entre llegadas Proceso de Poisson para situaciones con llegadas aleatorias P( t  t) = 1 - e -  t t  0 ,  : número de llegadas promedio por unidad de tiempo Valor esperado: T = 1/  La probabilidad que lleguen k trabajos en un intervalo de tiempo de tamaño t es: P(k) = (1/ k !)  (   t) k  e -  t , t  0 , k=0,1,2,3,..... Valor esperado: N =   t (c) Tiempo de servicio - Es el tiempo requerido para atención de un proceso por la CPU. Este tiempo involucra sólo la atención y no el tiempo de espera en la cola. - Si s es el tiempo de servicio entonces P ( s  t) = 1 - e -  t t  0 ,  : es la tasa de servicio y representa el Nº de procesos atendidos por unidad de tiempo. En este caso el valor esperado resulta ser: S = 1/  número de llegadas promedio por unidad de tiempo.

30. - Si se cumplen que  <  entonces se habla de un &quot;sistema estable&quot;. De otro modo se está en presencia de un &quot;sistema inestable&quot; (d) Tiempo total en el sistema (tiempo de respuesta) Si  es el tiempo esperado de respuesta y W es el tiempo esperado en la cola entonces se satisface la relación:  = W + 1/  (e) Formula de Little N =    N es el Nº esperado de procesos en el sistema. Al estar un proceso un tiempo  en el sistema, entonces al salir de éste, habrán llegado    procesos. Políticas de asignación de CPU Los criterios para seleccionar un algoritmo de asignación de la CPU deben responder lo mejor posible a lo siguiente : - Máxima utilización del procesador - Cantidad de trabajos por unidad de tiempo (throughput) - Tiempo desde que ingresa un proceso hasta que termina (tiempo de Ejecución) - Permanencia en la cola de procesos en estado READY (tiempo de espera) - Tiempo de Respuesta en obtener un resultado

31. (a) Primero en llegar, primero en ser atendido (FCFS: First Come First Serve) Se trata de atender en orden de llegada (mediante una cola FIFO), por lo que el tiempo de espera de un proceso es independiente de su tiempo de servicio. Una vez que el proceso se le asigna la CPU, éste la utiliza hasta terminar. Esta es una política no apropiativa Problemas: no se discrimina entre procesos largos y cortos ==> perjudicar a procesos cortos. Tampoco garantiza &quot;buenos&quot; tiempos de respuesta interactivos. Si tenemos que los procesos largos tienen los parámetros (  1 ,  1 ) y los procesos cortos (  2 ,  2 ) donde se cumple que 1/  1 >>> 1/  2 entonces el valor esperado del tiempo de servicio S, de los procesos largos y cortos es: S = 1/  = (  1 /  )  (1/  1 ) + (  2 /  )  (1/  2 ) = (1/  )  (  1 /  1 +  2 /  2 ) (1) donde:  =  1 +  2 (esta es una propiedad de los procesosde Poisson)  1 /  : probabilidad de llegada de los proces os largos  2 /  : probabilidad de llegada de los procesos cortos 1/  1 : tasa de servicio de los procesos largos 1/  2 : tasa de servicio de los procesos cortos Si se define  =  /  como la tasa de utilización del sistema entonces según (1) se cumple que:  =  1 +  2 COLA DE ESPERA CPU LLEGADAS SALIDAS

32. (b) Round Robin Para mejorar el problema anterior, ahora asignamos la CPU a un proceso sólo por un tiempo fijo (&quot;quantum&quot;). Si el proceso termina en ese lapso entonces sale del sistema. De lo contrario, es enviado de vuelta a la cola para su posterior atención. Problema: existen más llegadas a la cola ya que tenemos los procesos externos y los procesos reciclados. Si el quantum es q y el tiempo esperado de servicio es 1/  entonces para un proceso que necesite k quantums de tiempo se tendrá que 1/  = k  q ===> el proceso deberá volver k veces en promedio a la cola. En este caso los procesos cortos resultan menos perjudicados. Un problema no considerado en este análisis es el tiempo gastado en &quot;desasignar la CPU&quot; a un proceso y asignarla a otro. En FCFS esto ocurre una vez por proceso; en Round Robin esto ocurre por cada quantum de tiempo . Si hay procesos largos y cortos, conviene escoger q de modo que los procesos cortos alcancen a terminar en ese intervalo de tiempo. Este tipo de asignación es efectiva en ambientes de tiempo compartido. COLA DE ESPERA CPU LLEGADAS SALIDAS

33. Tamaño del quantum La determinación del tamaño del quantum es decisiva para la operación efectiva de un sistema computacional. Surgen interrogantes como: ¿el quantun debe ser pequeño o grande ? ¿ el quantum debe ser fijo o variable ? ¿ el quantum debe ser igual para todos los procesos de los usuarios o debe ser determinado por separado para cada uno de ellos ? Si el quantum se hace muy grande entonces cada proceso recibe todo el tiempo necesario para llegar a su término. En este caso, se tiene que la política de asignación Round Robin degenera a una del tipo FCFS. Si el quantum se hace muy pequeño se tienen las siguientes situaciones: - la sobrecarga del intercambio de contexto se convierte en un factor dominante. - el rendimiento del sistema se degrada: la mayor parte del tiempo de CPU, se invierte en el intercambio de CPU y por lo tanto los procesos del usuario disponen de muy poco tiempo de CPU. Solución : el quantum debe ser lo suficientemente grande como para permitir que la gran mayoría de las peticiones interactivas requieran de menos tiempo que la duración del quantum. Por ésto, el tiempo transcurrido desde el otorgamiento de la CPU a un proceso hasta que genera una petición de E/S debe ser menor que el quantum establecido. Ocurrida la petición, la CPU pasa a otro proceso. Como el quantum es mayor que el tiempo transcurrido hasta la petición de E/S entonces los procesos operan muy rápidos; se minimiza la sobrecarga de apropiación y se maximiza la utilización de la E/S. En general el quantun varía de un sistema a otro. En la práctica se utiliza un valor de quantum q = 100 ms