Sistemas Operativos

Ing. Jorge Orellana A. 13

Tema II GESTIN DE PROCESOS

2.1. PROCESO. Todos los computadores pueden hacer varias cosas a la vez, mientras est ejecutando un programa de usuario puede perfectamente tambin estar leyendo de un disco e imprimiendo texto en una pantalla o una impresora. En un sistema multiprogramado la CPU (Unidad Central de Proceso) tambin conmuta de unos programas a otros, ejecutando cada uno de ellos durante decenas o cientos de milisegundos. Aunque, estrictamente hablando, en cualquier instante de tiempo la CPU slo est ejecutando un programa, en el transcurso de 1 segundo ha podido estar trabajando sobre varios programas, dando entonces a los usuarios la impresin de un cierto paralelismo (pseudoparalelismo), en contraste con el autntico paralelismo del hardware de los sistemas multiprocesador (que tienen dos o ms CPUs compartiendo la misma memoria fsica). Seguir la pista de mltiples actividades paralelas resulta muy complicado, por ese motivo los diseadores de los sistemas operativos han desarrollado un modelo conceptual evolucionado (el de los procesos secuenciales) que permite tratar el paralelismo de una forma ms fcil.

En este modelo, todo el software ejecutable en el ordenador, incluyendo a veces al propio sistema operativo, se organiza en un nmero de procesos secuenciales, o simplemente procesos. Un proceso es justamente un programa en ejecucin, incluyendo los valores actuales del contador de programa, registros y variables. Conceptualmente cada proceso tiene su propia CPU virtual. En realidad, la CPU real conmuta sucesivamente de un proceso a otro. Esta rpida conmutacin de un proceso a otro en algn orden se denomina multiprogramacin.

Debe hacerse una distincin entre un programa y un proceso. Un programa es una entidad estatica constituida por sentencias de programa que definen la conducta del proceso cuando se ejecutan utilizando un conjunto de datos. Un proceso es una entidad dinmica que ejecuta un programa sobre un conjunto de datos utilizando los recursos del sistema operativo. Dos o mas procesos podran estar ejecutando el mismo programa, empleando sus propios datos y recursos, por ejemplo, si dos o ms usuarios estn usando simultneamente el mismo editor de texto. El programa es el mismo, pero cada usuario tiene un proceso distinto (y con distintos datos). Por analoga al preparar una receta de una torta. El programa es la receta, el proceso es la actividad que consiste en leer la receta, mezclar los ingredientes y hornear la torta. 2.1.1. Creacin de Procesos Los sistemas operativos necesitan asegurar de alguna forma que puedan existir todos los procesos requeridos, entonces es necesaria alguna manera de poder crear y destruir los procesos segn sea necesario durante la operacin del sistema. Los cuatro principales sucesos que provocan la creacin de nuevos procesos son: La inicializacin del sistema La ejecucin por parte de un proceso (en ejecucin) de una llamada al sistema de creacin

de un nuevo proceso. La peticin por parte del usuario de la creacin de un nuevo proceso. El inicio de un trabajo en batch (lotes). Cuando un sistema operativo arranca, se crean tpicamente varios procesos. Algunos de esos procesos son procesos foreground (en primer plano), esto es, procesos que interactan con los usuarios y realizan trabajo para ellos. Otros son procesos background (en segundo plano), que no estn asociados con usuarios particulares, sino que tienen alguna funcin especfica. Los procesos que se ejecutan como procesos background para llevar a cabo alguna actividad tal como el correo electrnico, las pginas web, las news o la impresin de ficheros de salida, etc, se denominan demonios en Unix o servicios en Windows. Los sistemas grandes tienen comnmente docenas de ellos. En UNIX, el programa ps puede utilizarse para listar los procesos que estn en marcha. En Windows se utiliza el administrador de tareas.

Sistemas Operativos

Ing. Jorge Orellana A. 14

Adicionalmente a los procesos creados en el momento del arranque, tambin pueden crearse nuevos procesos despus. A menudo un proceso en ejecucin puede hacer llamadas al sistema para crear uno o ms procesos nuevos para que le ayuden en su trabajo. En sistemas interactivos los usuarios pueden arrancar un programa tecleando un comando o haciendo clic (dos veces) con el ratn sobre un icono. Realizando cualquiera de esas acciones se consigue que comience un nuevo proceso y se ejecute el programa correspondiente. En sistemas UNIX basados en comandos y ejecutando X-Windows, el nuevo proceso creado se ejecuta sobre la ventana en la cual se le activ. En Windows, cuando un proceso comienza no tiene ninguna ventana asignada, aunque puede crear una o ms. En ambos sistemas, los usuarios pueden tener mltiples ventanas abiertas a la vez, cada una de ellas ejecutando algn proceso. Utilizando el ratn, el usuario puede seleccionar una ventana e interactuar con el proceso, por ejemplo, proporcionando datos de entrada cuando sean necesarios. La ltima situacin que provoca la creacin de procesos se aplica slo a los sistemas en batch que podemos encontrar en los grandes mainframes. En esos sistemas los usuarios pueden lanzar (submit) al sistema trabajos en batch (posiblemente de forma remota). Cuando el sistema operativo detecta que dispone de todos los recursos necesarios para poder ejecutar otro trabajo, crea un nuevo proceso y ejecuta sobre l el siguiente trabajo que haya en la cola de entrada. En UNIX slo existe una llamada al sistema para crear un nuevo proceso: fork. Esta llamada crea un clon (una copia exacta) del proceso que hizo la llamada. Despus del fork, los dos procesos, el padre y el hijo, tienen la misma imagen de memoria, las mismas variables de entorno y los mismos ficheros abiertos. Eso es todo lo que hay. Usualmente, a continuacin el proceso hijo ejecuta execve o una llamada al sistema similar para cambiar su imagen de memoria y pasar a ejecutar un nuevo programa. En Windows, una nica llamada al sistema de Win32, CreateProcess, realiza tanto la creacin del proceso como la carga del programa correcto dentro del nuevo proceso. Tanto en UNIX como en Windows, despus de crear un proceso, tanto el padre como el hijo cuentan con sus propios espacios de direcciones disjuntos. 2.1.2. Terminacin de Procesos Tras la creacin de un proceso comienza su ejecucin realizando el trabajo que se le ha encomendado. Sin embargo pronto o tarde el nuevo proceso debe terminar, usualmente debido a una de las siguientes causas: El proceso completa su trabajo y termina (voluntariamente). El proceso detecta un error y termina (voluntariamente). El sistema detecta un error fatal del proceso y fuerza su terminacin. Otro proceso fuerza la terminacin del proceso (por ejemplo en UNIX mediante la llamada al

sistema kill). La mayora de los procesos terminan debido a que han completado su trabajo. Cuando un compilador ha compilado el programa que se le ha dado, el compilador ejecuta una llamada al sistema para decirle al sistema operativo que ha finalizado. Esta llamada es exit en UNIX y ExitProcess en Windows. Los programas orientados a la pantalla soportan tambin la terminacin voluntaria. Los procesadores de texto, navegadores y programas similares cuentan siempre con un icono o una opcin de men para que el usuario pueda elegir con el ratn indicndole al proceso que borre cualquier archivo temporal que est abierto y a continuacin termine. La segunda causa de terminacin es que el proceso descubra un error fatal. Por ejemplo, si un usuario teclea un comando incorrecto. La tercera causa de terminacin es la aparicin de un error causado por el proceso, a menudo debido a un error de programacin. Algunos ejemplos son: la ejecucin de una instruccin ilegal, una referencia a una posicin de memoria inexistente, o una divisin por cero. La cuarta razn por la cual un proceso puede terminar, es que un proceso ejecute una llamada al sistema dicindole al sistema operativo que mate a algn otro proceso. En UNIX esta llamada al sistema es kill. La funcin Win32 correspondiente es TerminateProcess. En ambos casos el proceso asesino debe contar con la debida autorizacin.

Sistemas Operativos

Ing. Jorge Orellana A. 15

2.1.3. Estado de los procesos Durante su existencia un proceso pasa por una serie de estados discretos, siendo varias las circunstancias que pueden hacer que el mismo cambie de estado:

Nuevo (new). Ejecutndose (running). El proceso est siendo ejecutado en la CPU. Por lo tanto a lo

ms un proceso puede estar en este estado en un computador uniprocesador. Listo para ejecutar (ready). El proceso est en condiciones de ejecutarse, pero debe

esperar su turno de CPU. Bloqueado o En espera (waiting) El proceso no est en condiciones de ejecutarse.

Est esperando que algn evento ocurra, como la finalizacin de una operacin de E/S. Tambin se dice que est suspendido o en espera.

Terminado (terminated) Se puede establecer una cola de Listos para los procesos listos y una cola de Bloqueados para los bloqueados. La cola de Listos se mantiene en orden prioritario y la cola de Bloqueados est desordenada, ya que los procesos se desbloquean en el orden en que tienen lugar los eventos que estn esperando. Al admitirse un trabajo en el sistema se crea un proceso equivalente y es insertado en la ltima parte de la cola de Listos. La asignacin de la CPU al primer proceso de la cola de Listos se denomina Despacho, que es ejecutado por una entidad del Sistema Operativo llamada Despachador (dispatcher). El Bloqueo es la nica transicin de estado iniciada por el propio proceso del usuario, puesto que las otras transiciones son iniciadas por entidades ajenas al proceso.

2.1.4. Implementacin de procesos El sistema operativo mantiene para cada proceso un bloque de control de proceso o process control block (PCB), donde se guarda para cada proceso la informacin necesaria para reanudarlo si es suspendido, y otros datos. Estado: Puede ser nuevo, listo, en ejecucin, en espera, detenido, etctera Contador de programa: El contador indica la direccin de la siguiente instruccin que se

ejecutar para este proceso. Registros de CPU: El nmero y el tipo de los registros vara dependiendo de la arquitectura

del computador. Los registros incluyen acumuladores, registros ndice, punteros de pila y registros de propsito general, as como cualquier informacin de cdigos de condicin que haya. Junto con el contador de programa, esta informacin de estado se debe guardar cuando ocurre una interrupcin, para que el proceso pueda continuar correctamente despus.

Informacin para planificacin: Esta informacin incluye una prioridad del proceso, punteros a colas de planificacin y cualquier otro parmetro de planificacin que haya.

Informacin para administracin de memoria: Esta informacin puede incluir datos tales como el valor de los registros de base y lmite, las tablas de pginas o las tablas de segmentos, dependiendo del sistema de memoria empleado por el sistema operativo.

Sistemas Operativos

Ing. Jorge Orellana A. 16

Informacin de estado de E/S: La informacin incluye la lista de dispositivos de E/S asignadas a este proceso, una lista de archivos abiertos, etctera.

Estadsticas y otros: tiempo real y tiempo de CPU usado, identificador del proceso, identificador del dueo, tiempo real consumido, lmites de tiempo, nmeros de cuenta, nmeros de trabajo o proceso, y dems.

Cuando el Sistema Operativo cambia la atencin de la CPU entre los procesos, utiliza las reas de preservacin del PCB para mantener la informacin que necesita para reiniciar el proceso cuando consiga de nuevo la CPU.

2.1.5. Cambios de contexto (context switch) Cuando el sistema operativo entrega la CPU a un nuevo proceso, debe guardar el estado del proceso que estaba ejecutando, y cargar el estado del nuevo proceso. El estado de un proceso comprende el PC (Contador del programa), y los registros de la CPU. Adems, si se usan las tcnicas de administracin de memoria que veremos ms adelante, hay ms informacin involucrada. Este cambio, que demora de unos pocos a mil microsegundos, dependiendo del procesador, es puro overhead o sobrecosto, puesto que entretanto la CPU no hace trabajo til (ningn 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 ms procesos que conjuntos de registros, igual hay que apoyarse en la memoria. Por ser un cuello de botella tan importante para el desempeo del sistema operativo se emplean estructuras nuevas (hilos) para evitarla hasta donde sea posible. 2.1.6. Jerarquia de procesos La secuencia de creacin de procesos genera un rbol de procesos. Para referirse a las relaciones entre los procesos de la jerarqua se emplean los trminos de padre, hermano o abuelo. Cuando el proceso A solicita al sistema operativo que cree el proceso B, se dice que A

Sistemas Operativos

Ing. Jorge Orellana A. 17

es padre de B y que B es hijo de A. Bajo esta ptica, la jerarqua de procesos puede considerarse como un rbol genealgico. Algunos sistemas operativos, como Unix, mantienen de forma explcita esta estructura jerrquica de procesos (un proceso sabe quin es su padre), mientras que otros sistemas operativos como el Windows NT no la mantienen. Por ejemplo, en Unix, cuando se carga el sistema operativo, se inicializa un proceso init. Este proceso lee un archivo que dice cuntos terminales hay, y crea un proceso login para cada terminal, que se encarga de solicitar nombre y contrasea. Cuando un usuario entra, login determina qu shell le corresponde al usuario, y crea otro proceso para ejecutar esa shell. A su vez, la shell crea ms procesos segn los comandos que ejecute el usuario, generndose as todo un rbol de procesos: cada proceso tiene cero o ms hijos, y exactamente un padre (salvo init, que no tiene padre). Haciendo una analogia en Windows, aun cuando este sistema operativo no mantiene esta jerarquia y todos son iguales, unos de los primeros procesos seria System, luego Winlogon para crear una sesion y sobre ella crea su shell que es el Explorer, en el cual se ejecutaran todos los demas programas como hijos de este proceso. 2.2. PROCESOS LIVIANOS, HILOS, HEBRAS O THREADS En los sistemas operativos tradicionales, cada proceso tiene su propio espacio de direcciones y un nico flujo (hilo) de control. Sin embargo, frecuentemente hay situaciones en las que es deseable contar con mltiples hilos de control (threads) en el mismo espacio de direcciones ejecutndose quasi-paralelamente, como si fueran procesos separados (excepto que comparten el mismo espacio de direcciones).

Una hebra (thread, hilo o proceso liviano) es un hilo de control dentro de un proceso. Un proceso tradicional tiene slo una hebra de control. Si usamos threads, entonces podemos tener varias hebras dentro de un proceso. Cada hebra representa una actividad o unidad de computacin dentro del proceso, es decir, tiene su propio PC, conjunto de registros y stack, pero comparte con las dems hebras el espacio de direccionamiento y los recursos asignados, como archivos abiertos y otros.

En muchos aspectos los procesos livianos son similares a los procesos pesados, comparten el tiempo de CPU, y a lo ms un thread est activo (ejecutando) a la vez, en un monoprocesador. Los otros pueden estar listos o bloqueados. Pero los procesos pesados son independientes, y el sistema operativo debe proteger a unos de otros, lo que acarrea algunos costos. Los procesos livianos dentro de un mismo proceso pesado no son independientes, cualquiera puede acceder a

Sistemas Operativos

Ing. Jorge Orellana A. 18

toda la memoria correspondiente al proceso pesado. En ese sentido, no hay proteccin entre threads, nada impide que un thread pueda escribir, por ejemplo, sobre el stack de otro.

2.2.1. Comparando hebras con procesos El cambio de contexto entre hebras de un mismo proceso es mucho ms barato que el

cambio de contexto entre procesos; gracias a que comparten el espacio de direccionamiento, un cambio de contexto entre threads no incluye los registros y tablas asociados a la administracin de memoria.

La creacin de threads tambin es mucho ms barata, ya que la informacin que se requiere para mantener un thread es mucho menos que un PCB. La mayor parte de la informacin del PCB se comparte entre todos los threads del proceso.

El espacio de direccionamiento compartido facilita la comunicacin entre las hebras y el compartimiento de recursos.

2.2.2. Implementacin de hebras Hay libreras de hebras que permiten implementar hebras dentro de procesos normales o pesados sin apoyo del sistema operativo. La planificacin y manejo de las hebras se hace dentro del proceso. El sistema operativo no tiene idea de las hebras; slo ve y maneja un proceso como cualquier otro. La alternativa es que el propio sistema operativo provea servicios de hebras; as como se pueden crear procesos, se pueden tambin crear nuevas hebras dentro de un proceso, y stos son administrados por el sistema operativo. La ventaja del primer esquema respecto del segundo, es que los cambios de contexto entre hebras de un mismo proceso son extremadamente rpidos, porque ni siquiera hay una llamada al sistema de por medio. La desventaja es que si una de las hebras hace una llamada bloqueante (Ej., solicita E/S), el sistema operativo bloquea todo el proceso, an cuando haya otras hebras listos para ejecutar. En el caso de sistemas operativos de servidores, cada hebra puede manejar una solicitud. El diseo es ms sencillo y este esquema mejora la productividad, porque mientras unos hilos esperan, otros pueden hacer trabajo til. Por ejemplo servidor de archivos, que recibe solicitudes para leer y escribir archivos en un disco. Para mejorar el rendimiento, el servidor mantiene un

Sistemas Operativos

Ing. Jorge Orellana A. 19

cach con los datos ms recientemente usados, en la eventualidad que reciba algn requerimiento para leer esos datos, no es necesario acceder el disco. Cuando se recibe una solicitud, se le asigna a un thread para que la atienda. Si ese thread se bloquea porque tuvo que acceder el disco, otros threads pueden seguir atendiendo otras solicitudes. La clave es que el buffer debe ser compartido por todos los threads, lo que no podra hacerse si se usa un proceso pesado para cada solicitud. POSIX (Linux) especifica una serie de polticas de planificacin, aplicables a procesos y procesos ligeros, que debe implementar cualquier sistema operativo que ofrezca esta interfaz. En Windows la unidad bsica de ejecucin es el proceso ligero y, por tanto, la planificacin se realiza sobre este tipo de procesos. 2.3. PLANIFICACIN (SCHEDULING) DE PROCESOS En un ambiente de multiprogramacin es frecuente que en un momento dado haya mltiples procesos compitiendo por el uso de la CPU al mismo tiempo. Esta situacin se da siempre que dos o ms procesos estn simultnemente en el estado preparado. Si slo hay una CPU disponible, es necesario hacer una eleccin para determinar cual de esos procesos ser el siguiente que se ejecute. La parte del sistema operativo que realiza esa eleccin se denomina el planificador (scheduler), y el algoritmo que se utiliza para esa eleccin se denomina el algoritmo de planificacin. Existen diferentes algoritmos de planificacin que deben cumplir con criterios basicos, como: Maximizar el uso de la CPU (que se mantenga ocupada el mayor tiempo posible). Maximizar la Productividad (throughput), considerando que productividad (o rendimiento) es

el nmero de procesos que se ejecutan por unidad de tiempo. Minimizar el Tiempo de retorno (turn around time), que es el tiempo transcurrido desde que

el proceso ingresa hasta que termina, sumando espera para entrar en memoria, en cola de procesos listos, ejecutndose en CPU y haciendo E/S.

Minimizar el Tiempo de espera (waiting time), que es el tiempo que el proceso est en la cola de listos.

Minimizar el Tiempo de respuesta (response time), que es el tiempo que transcurre desde que se presenta una solicitud hasta que se tiene respuesta. Es el tiempo que tarda en comenzar a responder, no incluyendo el tiempo de la respuesta en s.

La equidad (Justicia), que todos los procesos tienen que ser tratados de igual forma y a todos se les debe dar la oportunidad de ejecutarse.

Recursos equilibrados, que la poltica de planificacin que se elija debe mantener ocupados los recursos del sistema, favoreciendo a aquellos procesos que no abusen de los recursos asignados, sobrecargando el sistema y bajando la performance general.

En un sistema operativo los recursos compartidos exigen la organizacin en colas de las solicitudes pendientes. Tenemos colas para la planificacin del uso de la CPU como tambin colas para el uso de dispositivos (device queues), que son utilizadas para ordenar los requerimientos que varios procesos pueden tener sobre un dispositivo especfico. Al ser creados, los procesos se colocan en la cola de trabajos, formada por los procesos que an no residen en la memoria principal, pero listos para su ejecucin. La residencia en memoria es imprescindible para la ejecucin de un proceso. La cola de trabajos listos (ready queue) es aqulla formada por los procesos que estn listos para la ejecucin, en memoria principal. Son los procesos que compiten directamente por CPU. Los elementos de cualquiera de estas colas no son los procesos en s, sino sus PCBs, que estn en memoria. La cola de procesos listos (ready queue) se almacena como una lista enlazada donde la cabecera (header) de la ready queue tiene punteros al primer y al ltimo PCB de los procesos de la lista. Cada PCB apunta al prximo en la lista.

2.3.1. Procesos orientados a la E/S y procesos orientados a la CPU En un sistema hay procesos con mayor proporcin de rfagas E/S (I/O bound process) y otros con mayor necesidad de CPU que de E/S (CPU bound process). Si cuando se seleccionan procesos para ejecutar se eligieran todos I/O bound, tendramos las colas de dispositivo llenas

Sistemas Operativos

Ing. Jorge Orellana A. 20

de solicitudes y, probablemente, la CPU ociosa. Si se eligen muchos procesos limitados por CPU la cola de listos estar llena y las colas de dispositivo, vacas. Por eso es muy importante de qu manera se realiza la seleccin de trabajos para mantener el sistema en equilibrio. Esta seleccin la realizan los planificadores o schedulers.

El planificador (scheduler) forma parte del ncleo del sistema operativo. Entra en ejecucin cada vez que se activa el sistema operativo y su misin es seleccionar el proceso que se ha de ejecutar a continuacin. El activador (dispatcher) tambin forma parte del sistema operativo y su funcin es poner en ejecucin el proceso seleccionado por el planificador. Debe ser muy rpido pues una de sus funciones es encargarse del cambio de contexto (context switch). Al tiempo entre detener un proceso y comenzar a correr otro se le llama dispatch latency. El dispatcher es tambin el que se encarga de pasar a modo usuario el proceso que esta activando y saltar a la direccin de la instruccin que comienza la ejecucin del programa. 2.3.2. Temporizador de Intervalos o Reloj de Interrupcin El proceso al cual est asignada la CPU se dice que est en ejecucin y puede ser un proceso de Sistema Operativo o de usuario. El Sistema Operativo dispone de mecanismos para quitarle la CPU a un proceso de usuario para evitar que monopolice el sistema. El Sistema Operativo posee un reloj de interrupcin o temporizador de intervalos para generar una interrupcin, en algn tiempo futuro especfico o despus de un transcurso de tiempo en el futuro; la CPU es entonces despachada hacia el siguiente proceso. En cada interrupcin del reloj el Sistema Operativo decide si el proceso que se est ejecutando contina o si el proceso agot su tiempo de CPU y debe suspenderse y ceder la CPU a otro proceso. Un proceso retiene el control de la CPU hasta que ocurra alguna de las siguientes situaciones:

La libera voluntariamente. El reloj la interrumpe. Alguna otra interrupcin atrae la atencin de la CPU.

El reloj de interrupcin ayuda a garantizar tiempos de respuesta razonables a usuarios interactivos, ya que evita que el sistema se cuelgue a un solo usuario en un ciclo infinito y permite que los procesos respondan a eventos dependientes del tiempo. 2.3.3. Niveles de Planificacin del Procesador Se consideran tres niveles importantes de planificacin: Planificacin de alto nivel (largo plazo o long term). Determina a qu trabajos se les va a

permitir competir activamente por los recursos del sistema, lo cual se denomina Planificacin de admisin.

Sistemas Operativos

Ing. Jorge Orellana A. 21

Planificacin de nivel intermedio (mediano plazo o medium term). Determina a qu procesos se les puede permitir competir por la CPU. Responde a fluctuaciones a corto plazo en la carga del sistema y efecta suspensiones y activaciones (reanudaciones) de procesos. Debe ayudar a alcanzar ciertas metas en el rendimiento total del sistema.

Planificacin de bajo nivel (corto plazo o short term). Determina a qu proceso listo se le asigna la CPU cuando esta queda disponible y asigna la CPU al mismo, es decir que despacha la CPU al proceso. La efecta el Despachador del Sistema Operativo.

Los distintos Sistemas Operativos utilizan varias Polticas de Planificacin, que se instrumentan mediante Mecanismos de Planificacin.

2.4. ALGORITMOS DE PLANIFICACIN En entornos diferentes se necesitan algoritmos de planificacin diferentes. Esto se debe a que cada rea de aplicacin (y cada tipo de sistema operativo) tiene objetivos diferentes. En otras palabras, lo que el planificador debe optimizar no es lo mismo en todos los sistemas. Es necesario distinguir aqu tres entornos:

Batch (lotes) Interactivo Tiempo Real.

En los sistemas en batch, no existen usuarios que estn esperando impacientemente por una rpida respuesta ante sus terminales. En consecuencia, son aceptables los algoritmos no expulsores, o los algoritmos expulsores con largos periodos de tiempo para cada proceso. Con este enfoque se reduce el nmero de cambios de proceso, mejorando por tanto el rendimiento. En un entorno con usuarios interactivos es indispensable que haya expulsiones para impedir que un proceso acapare la CPU, negando cualquier servicio de la CPU a los dems. Incluso aunque ningn proceso tenga intencin de ejecutarse eternamente, es posible que debido a un error en el programa un proceso mantenga parados a todos los dems indefinidamente. La expulsin es necesaria para impedir ese comportamiento. En los sistemas con restricciones de tiempo real, por extrao que parezca, la expulsin es algunas veces innecesaria debido a que los procesos saben que no pueden ejecutarse durante largos periodos de tiempo y usualmente hacen su trabajo y rpidamente se bloquean. La diferencia con los sistemas interactivos es que los sistemas en tiempo real slo ejecutan programas pensados como parte de una misma aplicacin. Los sistemas interactivos por el contrario son sistemas de propsito general y pueden ejecutar programas arbitrarios no cooperantes o incluso maliciosos. 2.4.1. Planificacin en Sistemas en Batch 2.4.1.1. FCFS (first-come, first-served) Primero en llegar, primero en ser atendido.

Sistemas Operativos

Ing. Jorge Orellana A. 22

Se le asigna la CPU al proceso que la requiri primero. Se maneja a travs de una cola FIFO (First In First Out), y cuando un proceso requiere CPU, su PCB se coloca la final de la cola. Cuando se debe elegir un proceso para asignarle CPU se elige el proceso cuya PCB esta primera en la cola. Es un algoritmo que no usa expropiacin, y atiende a los procesos por estricto orden de llegada a la cola de listos (READY). Cada proceso se ejecuta hasta que termina, o hasta que hace una llamada bloqueante (de E/S), o sea, ejecuta su fase de CPU completa. El cdigo para implementar este algoritmo es simple y comprensible. Pero el tiempo promedio de espera puede ser largo.

Considerando que los procesos P1, P2 y P3 estn LISTOS para ejecutar su siguiente fase de CPU, cuya duracin ser de 24, 3 y 3 milisegundos, respectivamente. Si ejecutan en el orden P1, P2, P3, entonces los tiempos de espera son: 0 para P1, 24 para P2 y 27 para P3, o sea, en promedio, 17 ms. Pero si se ejecutan en orden P2, P3, P1, entonces el promedio es slo 3 ms. En consecuencia, FCFS no asegura para nada que los tiempos de espera sean los mnimos posibles; peor an, con un poco de mala suerte pueden llegar a ser los mximos posibles. Suponiendo que se tiene un proceso intensivo en CPU (CPU bound) y varios procesos intensivos en E/S (I/O bound). Entonces podra pasar lo siguiente: El proceso intensivo en CPU toma la CPU por un perodo largo, suficiente como para que todas las operaciones de E/S pendientes se completen. En esa situacin, todos los procesos estn LISTOS, y los dispositivos desocupados. En algn momento, el proceso intensivo en CPU va a solicitar E/S y va a liberar la CPU. Entonces van a ejecutar los otros procesos, pero como son intensivos en E/S, van a liberar la CPU muy rpidamente y se va a invertir la situacin: todos los procesos van a estar BLOQUEADOS, y la CPU desocupada. Este fenmeno se conoce como efecto convoy, y se traduce en una baja utilizacin tanto de la CPU como de los dispositivos de E/S. Obviamente, el rendimiento mejora si se mantienen ocupados la CPU y los dispositivos (o sea, conviene que no haya colas vacas). 2.4.1.2. SJF (Shortest-job-first Scheduling). Primero el trabajo ms corto. Este algoritmo elige entre los procesos de la cola de listos, aquel que tenga la prxima rfaga de CPU mas corta. Para ello este dato debe ser conocido. Es un algoritmo que permite que el tiempo de espera promedio sea bajo. Se puede utilizar en planificadores de largo plazo, pero no en los de corto plazo pues no hay manera de conocer la medida de la prxima rfaga. Se podra aproximar considerando el valor de la previa. Suponiendo que se tiene tres procesos cuyas prximas fases de CPU son de a, b y c milisegundos de duracin. Si ejecutan en ese orden, el tiempo medio de espera es: (0 + a + (a + b))/3 = (2a+b)/3 El primer proceso que se ejecute es el que tiene mayor incidencia en el tiempo medio, y el ltimo, tiene incidencia nula. En conclusin, el tiempo medio se minimiza si se ejecuta siempre el proceso con la menor prxima fase de CPU que est LISTO. Adems, es una buena manera de prevenir el efecto convoy. Lo malo es que para que esto funcione, hay que adivinar el futuro, pues se requiere conocer la duracin de la prxima fase de CPU de cada proceso. Lo que se hace es predecir la prxima fase de CPU en base al comportamiento pasado del proceso, usando un promedio exponencial. Suponiendo que la prediccin para la n-sima fase es Tn, entonces, se actualiza el estimador para predecir Tn+1

Sistemas Operativos

Ing. Jorge Orellana A. 23

Tn+1= (1-alpha) Tn + alpha Tn El parmetro alpha, entre 0 y 1, controla el peso relativo de la ltima fase en relacin a la historia pasada. Tn+1 = (1-alpha) Tn + alpha(1-alpha) Tn-1 + ... + alphaj(1-alpha) Tn-j + ... + alphan+1 T0 Mientras ms antigua la fase menos incidencia tiene en el estimador. Un valor atractivo para alpha es 1/2, ya que en ese caso slo hay que sumar los valores y dividir por dos. 2.4.2. Planificacin en Sistemas Interactivos 2.4.2.1. Round-Robin Scheduling (RR). Planificacin por turno circular o Carrousel. Se la asigna a cada proceso de la cola de listos un intervalo de tiempo de CPU. Ese intervalo es llamado time slice o quantum. Para implementar este algoritmo la cola de listos se mantiene como una cola FIFO, y la CPU se va asignando dndole un mximo de un quantum a cada proceso. Si el proceso no va a usar todo ese tiempo, usa lo necesario y libera la CPU. Se elige entonces otro proceso de la cola. Si excede el quantum, se produce una interrupcin. En ambos casos al dejar la CPU hay un cambio de contexto. El tiempo promedio de espera puede ser largo. Su performance depende fuertemente de la eleccin del quantum. Y el tiempo gastado en el cambio de contexto es una variable que se debe tener muy en cuenta. Se debe determinar un quantum que sea mucho mayor que el tiempo de cambio de contexto. Se utiliza en los sistemas de tiempo compartido (time-sharing). El punto interesante es encontrar el quantum adecuado. Si es muy grande, se degenera en FCFS, pero tampoco puede ser demasiado pequeo, porque entonces el costo en cambios de contexto es preponderante. Por ejemplo, si un cambio de contexto toma 5 ms, y se fija el quantum en 20 ms, entonces 20% del tiempo de la CPU se perder en sobrecosto. Un valor tpico es 100 ms. Una regla que suele usarse es que el 80% de las fases de CPU deben ser de menor duracin que un quantum. Con respecto a FCFS, se mejora el tiempo de respuesta y la utilizacin de la CPU, ya que se mantienen ms balanceadas las colas listos (READY) y bloqueadas (BLOCKED). Pero RR tampoco asegura que los tiempos de espera sean los mnimos posibles. Usando el mismo ejemplo anterior, y considerando un quantum de 4ms, pero sin considerar costos de cambio de contexto, si el orden es P1, P2, P3 entonces el tiempo medio de espera es 5.66ms (P1 espera 6ms, P2 espera 4ms. y P3 espera 7ms.)

2.4.2.2. Planificacin por prioridad Se le asocia un valor a cada proceso que representa la prioridad, y se le asigna la CPU al proceso de la cola de listos (ready) que tenga la mayor prioridad. Los valores asociados a la prioridad son un rango fijo de 0 a N, segn cada sistema. Tambin lo determina cada sistema si el nmero mas bajo es la ms alta o la ms baja prioridad. La prioridad puede ser fija o variable, externa o interna. Si es fija, ese valor no varia en el ciclo de vida del proceso. Si es variable, significa que ese valor puede cambiar dinmicamente de manera tal que haya factores, por ejemplo, el tiempo que lleva esperando en colas, que puedan ayudar a que haya un mejor nivel de competencia elevando la prioridad de procesos postergados

Sistemas Operativos

Ing. Jorge Orellana A. 24

y evitar una situacin indeseable llamada starvation (inanicin). A la tcnica de elevar la prioridad a un proceso de acuerdo al tiempo que hace que esta en el sistema se le llama envejecimiento (aging). Si la prioridad es interna, es determinada en funcin del uso de los recursos (memoria, archivos abiertos, tiempos). Si es externa, puede decidirse darle alta prioridad a un proceso de importancia, a consideracin del operador. POSIX (Linux) y Win32 (Windows) proporcionan planificacin basada en prioridades. Hay muchos criterios para definir la prioridad, por ejemplo:

Segn categora del usuario. Segn tipo de proceso: sistema, interactivo, o por lotes; o bien, intensivo en CPU o

intensivo en E/S. Segn cuanto hayan ocupado la CPU hasta el momento Para evitar que un proceso de baja prioridad sea postergado en demasa, aumentar

prioridad mientras ms tiempo lleve esperando: envejecimiento (aging). Para evitar que un proceso de alta prioridad ejecute por demasiado tiempo, se le puede

ir bajando la prioridad. 2.4.2.3. Colas multinivel (Mltiples colas) En un sistema conviven procesos mixtos. Puede haber requerimientos de tiempo de respuesta distintos si conviven procesos interactivos con procesos batch (o para aquellos que provienen del Unix, procesos en foreground y procesos en background). Para complicar ms la cosa, se puede agrupar los procesos en distintas clases, y usar distintos algoritmos de planificacin intra-clase, ms algn algoritmo inter-clases. Por ejemplo, los procesos interactivos y los procesos por lotes tienen distintos requerimientos en cuanto a tiempos de respuesta. Entonces, se puede planificar los procesos interactivos usando RR, y los procesos por lotes segn FCFS, teniendo los primeros prioridad absoluta sobre los segundos. Existen algoritmos que contemplan esta situacin dividiendo la cola de listos (ready) en distintas colas segn el tipo de proceso, estableciendo una competencia entre las colas y entre los procesos del mismo tipo entre si. Por ejemplo, se puede tener una cola para

Procesos de sistema. Procesos interactivos. Procesos de los alumnos. Procesos por lotes.

Cada cola usa su propio algoritmo de planificacin, pero se necesita un algoritmo de planificacin entre las colas. Una posibilidad es prioridad absoluta con expropiacin. Otra posibilidad: asignar tajadas de CPU a las colas. Por ejemplo, a la cola del sistema se le puede dar el 60% de la CPU para que haga RR, a la de procesos por lotes el 5% para que asigne a sus procesos segn FCFS, y a las otras el resto.

Sistemas Operativos

Ing. Jorge Orellana A. 25

Por otra parte, se podra hacer que los procesos migren de una cola a otra. Por ejemplo: varias colas planificadas con RR, de prioridad decreciente y quantum creciente. La ltima se planifica con FCFS. Un proceso en la cola i que no termina su fase de CPU dentro del quantum asignado, se pasa al final de la siguiente cola de menor prioridad, pero con mayor quantum. Un proceso en la cola i que s termina su fase de CPU dentro del quantum asignado, se pasa al final de la siguiente cola de mayor prioridad, pero con menor quantum. Ejemplo:

Cola 0: quantum=10 ms, 40% de CPU. Cola 1: quantum=20 ms, 30% de CPU. Cola 2: quantum=35 ms, 20% de CPU. Cola 3: FCFS, 10% de CPU.

En este modelo con retroalimentacin, un proceso puede moverse entre colas, es decir, segn convenga puede llegar a asignarse a otra cola. Los procesos se separan de acuerdo a la rfaga de CPU que usan. Si esta usando mucha CPU se lo baja a una cola de menor prioridad. Se trata de mantener los procesos interactivos y de mucha E/S en las colas de mayor prioridad. Si adems un proceso estuvo demasiado tiempo en una cola de baja prioridad puede moverse a una cola de mayor prioridad para prevenir inanicin (starvation).

2.4.3. Planificacin en Sistemas de Tiempo Real Un sistema de tiempo real es uno en el cual el tiempo juega un papel esencial. Tpicamente, se tiene uno o ms dispositivos fsicos externos al ordenador que generan estmulos a los cuales debe reaccionar el ordenador de la manera apropiada y dentro de un plazo de tiempo prefijado. Por ejemplo, el computador interno de un reproductor de discos compactos recibe los bits tal y como salen de la unidad y debe convertirlos en msica en un intervalo de tiempo muy ajustado. Si el clculo tarda demasiado, la msica sonar rara. Otros sistemas en tiempo real monitorizan pacientes en la unidad de cuidados intensivos de un hospital, controlan el piloto automtico de

Sistemas Operativos

Ing. Jorge Orellana A. 26

un avin y controlan los robots en una fbrica automatizada. En todos estos casos, producir la respuesta correcta demasiado tarde es a menudo tan malo como no producir ninguna respuesta. Los sistemas en tiempo real se clasifican generalmente en sistemas de tiempo real estricto (hard real time) y sistemas de tiempo real moderado (soft real time). En los sistemas de tiempo real estricto hay plazos absolutos que deben cumplirse, pase lo que pase. En los sistemas de tiempo real moderado el incumplimiento ocasional de un plazo aunque es indeseable, es sin embargo tolerable. En ambos casos, el comportamiento en tiempo real se logra dividiendo el programa en varios procesos cuyo comportamiento es predecible y conocido por adelantado. Generalmente, tales procesos son cortos y pueden terminar su trabajo en mucho menos de un segundo. Cuando se detecta un suceso externo, el planificador debe planificar los procesos de tal modo que se cumplan todos los plazos. Los algoritmos de planificacin para tiempo real pueden ser estticos o dinmicos. Los primeros toman sus decisiones de planificacin antes de que el sistema comience a ejecutarse. Los segundos toman las decisiones en tiempo de ejecucin. La planificacin esttica slo funciona si se est perfectamente informado por anticipado sobre el trabajo que debe realizarse y los plazos que deben cumplirse. Los algoritmos de planificacin dinmica no tienen estas restricciones. 2.4.4. Planificacin apropiativa, expropiativa o expulsiva (Preemptive Scheduling) Hay que considerar en el esquema de planificacin en que momento se realiza la seleccin. Un algoritmo no apropiativo es aquel que una vez que le da la CPU a un proceso se ejecuta hasta que termina o hasta que se bloquea hasta la ocurrencia de determinado evento. En cambio, un algoritmo apropiativo es aquel en que un proceso que se esta ejecutando puede ser interrumpido y pasado a cola de listos (ready queue) por decisin del sistema operativo. Esta decisin puede ser porque llego un proceso de mayor prioridad, por ejemplo. Si bien los algoritmos apropiativos tienen un mayor costo que los no apropiativos, el sistema se ve beneficiado con un mejor servicio pues se evita que algn proceso pueda apropiarse de la CPU. No obstante si se utilizaran algoritmos apropiativos debe considerarse si el sistema operativo esta preparado para desplazar en cualquier momento un proceso. Por ejemplo, si ese proceso en ese momento, a causa de una llamada al sistema (system call) esta modificando estructuras de kernel y se lo interrumpe, esas estructuras pueden quedar en un estado inconsistente. O puede ocurrir con procesos que comparten datos y uno de ellos esta modificndolos al ser interrumpido. En Unix, por ejemplo se espera que se termine de ejecutar el system call para permitir apropiacin.

Relacionemos la idea de apropiacin con los diferentes algoritmos vistos.

FCFS es no apropiativo. Cuando se le da la CPU a un proceso, este la mantiene hasta que decide liberarla, porque termino, o porque requiere I/O.

SJF puede ser apropiativo o no. Si mientras se esta ejecutando un proceso llega uno cuya prxima rfaga de CPU es mas corta que lo que queda de ejecutar del activo, puede existir la decisin de interrumpir el que se esta ejecutando o no. Al SJF apropiativo, se le llama shortest-remaining-time-first. (primero el de tiempo restante ms corto).

Prioridades puede ser apropiativo o no. Si mientras se esta ejecutando un proceso llega a la cola de ready un proceso de mayor prioridad que el que se esta ejecutando puede existir la decisin de interrumpir el que se esta ejecutando o no. Si es no apropiativo, en lugar de darle la CPU al nuevo proceso, lo pondr primero en la cola de ready.

RR es apropiativo pues si el proceso excede el tiempo asignado, hay una interrupcin para asignarla la CPU a otro proceso.

Sistemas Operativos

Ing. Jorge Orellana A. 27

2.5. LA PLANIFICACIN DE PROCESOS EN AMBIENTES MULTIPROCESADOR Cuando hay varias CPUs (y una memoria comn), la planificacin tambin se hace ms compleja. Se podra asignar una cola de listos (READY) a cada procesador, pero se corre el riesgo de que la carga quede desbalanceada; algunos procesadores pueden llegar a tener una cola muy larga de procesos para ejecutar, mientras otros estn desocupados (con la cola vaca). Para prevenir esta situacin se usa una cola comn de procesos listos, para lo cual hay dos opciones: Cada procesador es responsable de su planificacin, y saca procesos de la cola listos

(READY) para ejecutar. El problema es que hay ineficiencia por la necesaria sincronizacin entre los procesadores para acceder la cola. En el caso en que los procesadores son idnticos, cualquier procesador disponible puede usarse para atender cualquier proceso en la cola. No obstante, debemos tener en cuenta que puede haber dispositivos asignados de manera privada o nica a un procesador, y si un proceso quiere hacer uso de ese dispositivo deber ejecutarse en ese procesador. Otra ventaja es implementar load sharing (carga compartida), permitiendo que si un procesador esta ocioso puedan pasarse procesos de la cola de otro procesador a este, o hacer una cola comn, y la atencin se realiza de acuerdo a la actividad de cada uno.

Dejar que slo uno de los procesadores planifique y decida qu procesos deben correr los dems: multiprocesamiento asimtrico. Se asume una estructura de procesadores master-slave que asigna a un procesador la toma de decisiones en cuanto a scheduling y otras actividades, dedicndose los otros procesadores a ejecutar cdigo de usuario. La ventaja es que solo el procesador master accede a estructuras del kernel, evitando inconsistencias.

2.6. PLANIFICACIN EN WINDOWS (Win32) Y LINUX (POSIX) El kernel de Windows est diseado utilizando POO. Posee una capa de abstraccin de hardware (HAL), la cual es la nica que se comunica directamente con el procesador; el resto del kernel est diseado para utilizar la interfaz de la HAL. La unidad mnima de ejecucin no es el proceso sino el hilo. Un hilo puede estar en alguno de estos seis estados: listo, standby (siguiente a ejecutar), en ejecucin, en espera, en transicin (un nuevo hilo) y terminado. Windows utiliza una planificacin basada en colas mltiples de prioridades. Posee 32 niveles de colas, clasificadas en clase de Tiempo Real fija (16-31) y prioridad dinamica (0-15). Las colas se recorren de mayor a menor ejecutando los hilos asociados. Cada cola es manejada por medio de un algoritmo de RR, aun as, si un hilo de mayor prioridad llega, el procesador le es asignado a ste. La prioridades ms altas son favorecidas. La prioridades de un thread no pueden ser reducidas. Los procesos en Linux pueden ser divididos en tres categoras, relacionadas con la prioridad: interactivos, por lotes y de tiempo real. Los procesos TR son manejados bien por un algoritmo FIFO o RR. Los dems procesos son despachados utilizando planificacin RR con un sistema de envejecimiento basado en crditos, donde el siguiente proceso a ejecutar es aquel que ms crditos posea. Los procesos TR son considerados prioritarios sobre cualquier otro proceso en el sistema, por lo que sern ejecutados antes que los dems. Algunos aspectos de la estructura interna del kernel que caben destacarse son: La PCB est representada por la estructura task_struct. sta indica el tipo de planificacin

(FIFO,RR) por medio del campo policy, la prioridad (priority), el contador del programa (counter), entre otros.

La funcin goodness otorga una calificacin al proceso pasado como parmetro. Dicha puntuacin oscila entre -1000 (no elegible) y +1000 (TR). Los procesos que comparten una zona de memoria ganan una puntuacin equivalente a su prioridad.

El quantum vara segn el proceso y su prioridad. La duracin base es de aprox. 200ms. La funcin switch_to es la encargada de salvar la informacin de un proceso y cargar el

siguiente.

Sistemas Operativos

Ing. Jorge Orellana A. 28

Las funciones sched_{get/set}scheduler se refieren al mecanismo de planificacin asociado a ese proceso.

Una nueva copia del proceso actual es creada mediante la llamada al sistema fork. Para ejecutar un nuevo programa se utiliza la funcin execve.

Las prioridades bajas son favorecidas. La mayora de los procesos usan polticas de prioridad dinmica. El valor nice establece la prioridad base de un proceso. Los valores de nice van desde -20 a +20 (ms grande = menor prioridad). Los usuarios no privilegiados slo pueden especificar valores de nice positivos. Los procesos normales se ejecutan slo cuando no quedan procesos de tiempo real (de prioridad fija) en la cola de listos.