Gestión de Procesos

Gestión de Procesos
Capítulo que describe cómo un sistema operativo realiza la gestión
de los procesos en ejecución en un sistema informático. Se
comenzará con una introducción a los procesos en un sistema
operativo y a los hilos de ejecución. Posteriormente se verá la
planificación de la CPU y las diferentes estrategias de planificación,
haciendo una comparativa de sus ventajas y desventajas. Se
finalizará viendo la planificación en entornos multiprocesador.
Gestión de Procesos by Rafael Lozano is licensed under a Creative Commons ReconocimientoNoComercial-CompartirIgual 3.0 España License.
Tabla de contenidos
Tabla de contenido
1 Procesos............................................................................................................................................... 1
1.1 Administración de procesos.....................................................................................................................2
1.1.1 Creación de procesos............................................................................................................................... 2
1.1.2 Terminación de procesos......................................................................................................................... 3
1.1.3 Estado de un proceso............................................................................................................................... 3
1.2 Multiprogramación......................................................................................................................................3
1.3 Bloque de control de proceso..................................................................................................................4
2 Hilos de ejecución.............................................................................................................................. 5
2.1 Implementación a nivel de usuario.........................................................................................................6
2.2 Implementación a nivel de kernel...........................................................................................................6
3 Planificación de la CPU......................................................................................................................7
3.1 Colas de planificación.................................................................................................................................8
3.2 Cambio de contexto....................................................................................................................................9
3.3 Comportamiento de un proceso.............................................................................................................9
4 Algoritmos de planificación............................................................................................................10
4.1 Objetivos de los algoritmos de planificación......................................................................................10
4.2 Planificación FCFS. Servicio por orden de llegada............................................................................12
4.3 Planificación SJF. Tiempo de ejecución más breve...........................................................................14
4.4 Planificación SRTN. El menor tiempo restante..................................................................................15
4.5 Planificación por prioridades..................................................................................................................16
4.6 Planificación por turno circular..............................................................................................................17
5 Planificación por niveles.................................................................................................................19
5.1 Planificación de colas de múltiples niveles con realimentación....................................................20
6 Planificación de múltiples procesadores....................................................................................21
7 Planificación de hilos.......................................................................................................................22
8 Bibliografía......................................................................................................................................... 23
Índice I
Rafael Lozano
Gestión de Procesos
Gestión
de procesos
1 Procesos
Una de las principales funciones de un sistema operativo es gestionar los procesos que se
ejecutan en el sistema informático en un momento dado. Se utiliza el término programa y proceso
como sinónimos cuando realmente son conceptos diferentes. En un capítulo anterior vimos la
definición de programa:
Un programa es un conjunto finito de instrucciones que realizan una tarea concreta.
El conjunto de instrucciones del programa se almacenan en forma de archivos ejecutables que
pueden ser invocados por el usuario para comenzar su ejecución.
Un proceso es un programa en ejecución junto con su entorno asociado formado por
los datos que emplea y otros que el sistema operativo utiliza para su gestión, como el
valor actual del contador de programa, registros y variables.
Si nos fijamos atentamente en las definiciones anteriores, un programa es un ente pasivo, ya
que es solo código, mientras que un proceso es activo y dinámico, ya que varía con el tiempo.
Un programa puede originar varios procesos. Por ejemplo, un usuario puede estar ejecutando
diferentes instancias del mismo programa simultáneamente. En este caso, varios procesos estarían
ejecutando el mismo programa.
Los procesos necesitan recursos hardware para su ejecución, como la CPU, espacio en
memoria, archivos y dispositivos de E/S. Estos recursos son asignados por el sistema operativo al
proceso en el momento de crearlo, es decir, cuando comienza su ejecución, o mientras se está
Página 1
Rafael Lozano
Gestión de procesos
ejecutando, ya que las necesidades de recursos hardware por parte de los procesos puede cambiar
durante su ejecución.
En la mayoría de los sistemas operativos el proceso es la unidad de trabajo, es decir, los
sistemas consisten en un conjunto de procesos. Los procesos del SO ejecutan el código del sistema y
los procesos de los usuarios ejecutan el código del usuario. En potencia, todos estos procesos
pueden ejecutarse concurrentemente, y la CPU o varias de ellas se multiplexan entre ellos. Al
conmutar la CPU entre procesos, el SO puede hacer más productivo al ordenador.
1.1 Administración de procesos
El SO es responsable de las siguientes actividades relacionadas con la administración de
procesos: la creación y eliminación de procesos tanto del sistema como de los usuarios, la
planificación de procesos y el suministro de mecanismos para la sincronización, comunicación y
manejo de bloqueos mutuos entre procesos.
1.1.1 Creación de procesos
En un sistema informático de propósito general se necesita cierta forma de crear y terminar
procesos según sea necesario durante la operación del sistema. Hay cuatro eventos principales que
provocan la creación de procesos:
1. Durante el arranque del sistema.
2. La ejecución, desde un proceso, de una llamada al sistema para creación de procesos.
3. Una petición de usuario para crear un proceso.
4. El inicio de un trabajo por lotes.
Generalmente, cuando se arranca un sistema operativo se crean varios procesos y en función
de su interactividad con el usuario, estos pueden ser:
✔
Procesos en primer plano.- Son procesos que interactúan con los usuarios y realizan trabajo
para ellos.
✔
Procesos en segundo plano.- No están asociados con usuarios específicos sino con una
función específica.
En un proceso en segundo plano no hay intervención del usuario y generalmente se ejecuta sin
que éste se de cuenta. Por ejemplo, un proceso en segundo plano puede aceptar el correo
electrónico entrante, que permanece inactivo la mayor parte del día pero que se activa cuando llega
un mensaje. Otro proceso en segundo plano acepta peticiones entrantes para las páginas Web
hospedadas en ese equipo, que despierte cuando llegue una petición para darle servicio.
Los procesos que permanecen en segundo plano para manejar ciertas actividades como correo
electrónico, páginas Web, noticias, impresiones de documentos, etc, se conocen como demonios
(daemons). Los sistemas grandes tienen comúnmente docenas de ellos. En Linux/UNIX podemos
utilizar el comando ps para listar los procesos en ejecución. En Windows podemos usar el
administrador de tareas.
En los sistemas interactivos, los usuarios pueden iniciar un programa escribiendo un comando
Página 2
Rafael Lozano
Gestión de Procesos
o haciendo doble clic en un icono. Cualquiera de estas dos acciones inicia un proceso y ejecuta el
programa seleccionado. En los sistemas operativos con GUI la mayoría de estos procesos se cargarán
en una ventana y los usuarios pueden tener varias ventanas abiertas a la vez, cada una ejecutando
algún proceso. Mediante el ratón, el usuario puede seleccionar una ventana e interactuar con el
proceso.
1.1.2 Terminación de procesos
Una vez creado un proceso, empieza a ejecutarse y realiza el trabajo al que está destinado.
Tarde o temprano, el proceso terminará debido a una de las siguientes condiciones:
1. Salida normal.
2. Salida por error.
3. Error fatal.
4. Eliminado por otro proceso.
La mayoría de los procesos terminan debido a que han concluido su trabajo. Las aplicaciones
de usuario siempre tienen un icono u opción de menú en el que el usuario puede hacer clic para
indicar al proceso que elimine todos los archivos temporales que tenga abiertos y después termine.
La segunda razón de terminación es que el proceso descubra un error. Los procesos
interactivos no suelen terminar cuando reciben algún dato incorrecto. En su lugar aparece un cuadro
de diálogo y se le pide al usuario el reintento de alguna acción.
La tercera razón de terminación es un error fatal producido por el proceso, a menudo debido a
un error en el programa como por ejemplo ejecutar una instrucción ilegal, hacer referencia a una
parte de memoria no existente o la división entre cero.
1.1.3 Estado de un proceso
Al ejecutarse un proceso, éste cambia de estado. El estado de un proceso se define en parte
por la actividad de este proceso, y cada proceso puede encontrarse en uno de los tres estados
siguientes:
✔
En ejecución.- Las instrucciones del proceso se están ejecutando.
✔
En espera.- El proceso está esperando a que ocurra algún suceso (como la conclusión de una
E/S).
✔
Listo.- El proceso está esperando que se le asigne a un procesador.
Es importante observar que en un momento determinado sólo un proceso puede encontrarse
en ejecución, aunque varios procesos pueden estar listos o en espera.
1.2 Multiprogramación
Debido a la velocidad a la que operan la CPU, un solo usuario nunca puede mantener la CPU o
los dispositivos de E/S ocupados constantemente. La multiprogramación es un método para
maximizar el empleo de la CPU disponiendo en todo momento de algo que la CPU pueda ejecutar.
Página 3
Rafael Lozano
Gestión de procesos
La idea básica consiste en mantener permanentemente ocupada la CPU ejecutando algún
proceso. El SO toma uno de los procesos y empieza a ejecutarlo. En algún momento, este proceso
tendrá que esperar por algún motivo, como por ejemplo una operación de entrada de datos, que se
teclee una información desde teclado o se complete una operación de salida a disco. En un sistema
sin multiprogramación, la CPU permanecería inactiva. En un sistema con multiprogramación, el SO
sencillamente cambiará a otro proceso y lo ejecutará. Cuando este último deba esperar, la CPU
pasará a ejecutar otro proceso y así sucesivamente. Finalmente, el primer proceso habrá acabado su
espera y obtendrá la CPU de nuevo. En la medida en que siempre haya algún proceso por ejecutar, la
CPU nunca permanecerá inactiva.
Los sistemas operativos multiprogramados son bastantes sofisticados. Tener varios procesos
dispuestos para su ejecución, supone mantenerlos simultáneamente en memoria. Tener varios
programas en memoria al mismo tiempo requiere una gestión de memoria que estudiaremos más
adelante. Además, si hay varios procesos dispuestos para ejecución al mismo tiempo, el sistema
operativo tiene que decidir cuál de ellos prosigue con su ejecución. Esta es la función principal de la
planificación de la CPU.
1.3 Bloque de control de proceso
El sistema operativo necesita conocer en todo momento los procesos que hay en el sistema
para su gestión. Para ello mantiene una tabla donde cada elemento contiene toda la información
relativa a un proceso. Cada uno de estos elementos se denomina Bloque de Control de Proceso
(PCB).
En el SO, cada proceso se representa por medio de un bloque de control de proceso. Un PCB
es un bloque o registro de datos que contiene diversa información relacionada con un proceso
concreto, incluyendo:
✔
Estado del proceso.- El estado puede ser nuevo, listo, en ejecución, en espera o detenido.
✔
Contador del programa.- El contador indica la dirección de la siguiente instrucción que este
proceso ejecutará.
✔
Registros de la CPU.- Los registros varían en número y tipo, dependiendo de la arquitectura
del ordenador. Incluyen acumuladores, registro índice, apuntadores de pila y registros de
propósito general. Esta información debe guardarse, junto con el contador del programa,
cuando ocurre una interrupción para así permitir que después el proceso continúe
correctamente.
✔
Información de la planificación de la CPU.- Esta información incluye una prioridad del proceso,
punteros a las colas de planificación y otros parámetros de planificación.
✔
Información de administración de memoria.- Esta información incluye registros límites o tablas
de páginas, es decir, información sobre donde se almacena el proceso en memoria y la
información generada por él.
✔
Información contable.- Esta información incluye la cantidad de tiempo real y de la CPU
utilizado, límites de tiempo, números de cuenta, números de proceso, etc.
✔
Información del estado de la E/S.- La información incluye solicitudes de E/S pendientes,
Página 4
Rafael Lozano
Gestión de Procesos
dispositivos de E/S asignados a este proceso, una lista de archivos abiertos, etc.
2 Hilos de ejecución
Habitualmente, las instrucciones de un proceso se ejecutan secuencialmente, una detrás de
otra. Es posible que durante la ejecución del código del proceso haya saltos que provoquen una
ruptura de la secuencia de instrucciones, pero básicamente en un momento dado solo se ejecuta una
instrucción del proceso.
Sin embargo, los procesos también se pueden ejecutar concurrentemente, es decir, puede
haber múltiples procesos ejecutándose a la vez. En esta situación:
✔
Si la CPU es de un único núcleo, la concurrencia será lógica, no real, ya que existen varios
procesos para un solo procesador.
✔
En CPUs con múltiples núcleos, la concurrencia es real, ya que al existir varias unidades de
ejecución, eventualmente pueden estar todas ellas ocupadas ejecutando algún proceso en un
momento dado.
Sin embargo, el modelo anterior puede afinarse aún más dividiendo los procesos en unidades
de ejecución más pequeñas que pueden ejecutarse en paralelo. Estas unidades más pequeñas se
denominan hilos de ejecución.
Un hilo de ejecución, hebra o subproceso es la unidad de procesamiento más pequeña que
puede ser planificada por un sistema operativo. Un hilo es simplemente una tarea que puede ser
ejecutada al mismo tiempo con otra tarea. La creación de un nuevo hilo es una característica que
permite a una aplicación realizar varias tareas a la vez. Los distintos hilos de ejecución comparten una
serie de recursos tales como el espacio de memoria, los archivos abiertos, etc. Esta técnica permite
simplificar el diseño de una aplicación que debe llevar a cabo distintas funciones simultáneamente.
En los sistemas operativos multihilo, donde un proceso consta de uno o más hilos, la memoria
asignada al proceso y la información de planificación es compartida por todos los hilos.
De lo anterior se deduce que un proceso está formado por todos sus hilos de ejecución y los
recursos que utilizan y comparten. El hecho de que los hilos de ejecución de un mismo proceso
compartan los recursos hace que cualquiera de estos hilos pueda modificar éstos. Cuando un hilo
modifica un dato en la memoria, los otros hilos acceden a ese dato modificado inmediatamente. Lo
que es propio de cada hilo es el contador de programa, la pila de ejecución y el estado de la CPU,
incluyendo el valor de los registros.
El proceso sigue en ejecución mientras al menos uno de sus hilos de ejecución siga activo.
Cuando el proceso finaliza, todos sus hilos de ejecución también han terminado. Asimismo en el
momento en el que todos los hilos de ejecución finalizan, el proceso no existe más y todos sus
recursos son liberados.
Hay dos formas principales de implementar un sistema de hilos: en espacio de usuario y en el
kernel. La elección es un poco controvertida y también es posible una implementación híbrida. Ahora
describiremos estos métodos.
Página 5
Rafael Lozano
Gestión de procesos
2.1 Implementación a nivel de usuario
El primer método es colocar el paquete de hilos completamente en espacio de usuario, es decir,
los programas de usuario admiten hilos, pero el kernel no tiene procesos con hilos. Además, el kernel
no sabe nada acerca de la existencia de hilos en el espacio de usuario. En lo que al kernel concierne,
está administrando procesos ordinarios con un solo hilo. La primera ventaja, la más obvia, es que un
paquete de hilos de nivel usuario puede implementarse en un sistema operativo que no acepte hilos.
Todos los sistemas operativos solían entrar en esta categoría e incluso hoy en día algunos todavía lo
están.
Figura 1.- Hilos en el espacio de usuario
Cuando los hilos se administran en espacio de usuario, cada proceso es el responsable de
gestionar sus hilos. Para ello, tiene su propia tabla de hilos privada para llevar la gestión de los hilos
en ese proceso. Esta tabla es similar a la tabla de procesos del kernel, excepto porque sólo contiene la
información de sus hilos, como el contador de programa, registros, estado, etc. La tabla de hilos es
administrada por el sistema en tiempo de ejecución.
2.2 Implementación a nivel de kernel
Ahora vamos a considerar el caso en que el kernel sabe acerca de los hilos y los administra. No
se necesita un sistema en tiempo de ejecución para ninguna de las dos acciones. Además, no hay
tabla de hilos en cada proceso. En vez de ello, el kernel tiene una tabla de hilos que lleva la cuenta de
todos los hilos en el sistema. Cuando un hilo desea crear un nuevo hilo o destruir uno existente,
realiza una llamada al kernel, la cual se encarga de la creación o destrucción mediante una
actualización en la tabla de hilos del kernel.
La tabla de hilos del kernel contiene los registros, el estado y demás información de cada hilo.
Esta información es la misma que con los hilos de nivel usuario, pero ahora se mantiene en el kernel,
en vez de hacerlo en espacio de usuario (dentro del sistema en tiempo de ejecución). Esta
información es un subconjunto de la información que mantienen tradicionalmente los kernels acerca
de sus procesos con un solo hilo; es decir, el estado del proceso. Además, el kernel también mantiene
la tabla de procesos tradicional para llevar la gestión de los procesos.
Página 6
Rafael Lozano
Gestión de Procesos
Figura 2.- Implementación a nivel de kernel
Cuando un hilo se bloquea por E/S, el kernel, según lo que decida, puede ejecutar otro hilo del
mismo proceso (si hay uno listo) o un hilo de un proceso distinto. Con los hilos de nivel usuario, el
sistema en tiempo de ejecución ejecuta hilos de su propio proceso hasta que el kernel le quita la CPU.
3 Planificación de la CPU
El objetivo de la multiprogramación es que en todo momento se ejecute un proceso para
maximizar la utilización de la CPU. En un sistema con una sola CPU nunca habrá más de un proceso
en ejecución. Si hay más procesos tendrán que esperar a que la CPU esté libre y pueda volver a
asignarse.
El concepto de multiprogramación es bastante sencillo: un proceso se ejecuta hasta que tenga
que esperar, generalmente a que termine una solicitud de E/S. En un sistema de computación
sencillo, la CPU permanecería inactiva; todo este tiempo de espera se desperdicia sin efectuar
ninguna actividad útil. Con la multiprogramación tratamos de emplear productivamente este tiempo.
Varios procesos se conservan en memoria a la vez, y cuando uno de ellos tiene que esperar, el SO le
quita la CPU al proceso y se la da a otro; este modelo continúa. Cada vez que un proceso tiene que
esperar, otro puede utilizar la CPU.
Los beneficios de la multiprogramación son un aumento de la utilización de la CPU y una mayor
productividad. La productividad es la cantidad de trabajo desarrollada en un intervalo de tiempo.
Cuando un sistema informático es multiprogramado, con frecuencia tiene varios procesos o
hilos que compiten por la CPU al mismo tiempo. Esta situación ocurre cada vez que dos o más de
estos procesos se encuentran al mismo tiempo en el estado listo. Si sólo hay una CPU disponible, hay
que decidir cuál proceso se va a ejecutar a continuación. La parte del sistema operativo que realiza
esa decisión se conoce como planificador de procesos y el algoritmo que utiliza se conoce como
algoritmo de planificación.
Página 7
Rafael Lozano
Gestión de procesos
3.1 Colas de planificación
Conforme los procesos entran en el sistema, se colocan en una cola de trabajos formada por
todos los procesos que residen en el disco esperando la asignación de la memoria principal. Los
procesos que residen en la memoria principal y que están listos y esperando su ejecución se
mantienen en una lista llamada cola de procesos listos.
Figura 3.- Cola de procesos listos
Esta cola tiene un encabezado que apunta al primer y último PCB de la lista. Cada PCB tiene un
campo puntero que indica el siguiente proceso en la cola de procesos listos.
También hay otras colas en el sistema. Cuando la CPU se asigna a un proceso, se ejecuta
durante un tiempo y después termina o espera a que ocurra un suceso determinado, como la
conclusión de una solicitud de E/S en disco. Puesto que en el sistema hay varios procesos, el disco
puede estar ocupado con la solicitud de E/S de otro proceso, por lo que el proceso tendrá que
esperar al disco. La lista de procesos que espera a un dispositivo de E/S determinado se denomina
cola del dispositivo, y cada dispositivo tiene su propia cola.
En el transcurso de su vida, un proceso transita entre las distintas colas de planificación, y el SO
de alguna manera debe seleccionar procesos de estas colas. Esta actividad de selección es realizada
por el planificador. El planificador a corto plazo, o planificador de la CPU, selecciona uno de los
procesos listos para su ejecución y le asigna la CPU.
Figura 4.- Cola de procesos en espera de dispositivo
El planificador a corto plazo debe seleccionar con mucha frecuencia un nuevo proceso para la
CPU, y el proceso quizá se ejecute únicamente durante unos milisegundos antes de esperar una
solicitud de E/S; en muchos casos, este planificador de la CPU se ejecuta por lo menos una vez cada
10 milisegundos. Debido al breve lapso de tiempo entre ejecuciones, el planificador de la CPU debe
ser muy rápido. Si cuesta un milisegundo decidir la ejecución de un proceso de 10 milisegundos,
entonces el 9% del tiempo de la CPU se desperdicia para que la planificación funcione.
Página 8
Rafael Lozano
Gestión de Procesos
3.2 Cambio de contexto
Para cambiar la CPU a otro proceso se requiere guardar el estado del proceso anterior y cargar
el estado guardado para el nuevo proceso. Esta tarea se conoce como cambio de contexto. El tiempo
de cambio de contexto es un puro gasto adicional, y varía de una máquina a otra, dependiendo de la
velocidad de la memoria, del número de registros y de la existencia de instrucciones especiales, como
una sola instrucción para cargar o almacenar todos los registros. Típicamente se encuentra en el
intervalo de uno a cien microsegundos.
Los tiempos de cambio de contexto dependen en gran medida del apoyo del hardware; por
ejemplo, algunos procesadores ofrecen varios conjuntos de registros, y un cambio de contexto
implica únicamente cambiar el puntero al conjunto actual de registros. Por supuesto, si hay más
procesos activos que conjuntos de registros, el sistema copia los datos usando la memoria, como se
mencionó antes. Además, cuanto más complejo sea el SO, más trabajo hay que realizar durante un
cambio de contexto. Como veremos en capítulos posteriores, las técnicas avanzadas de
administración de memoria pueden requerir que con cada contexto se cambien otros datos
adicionales.
3.3 Comportamiento de un proceso
El éxito de la planificación de la CPU depende de la siguiente propiedad observada de los
procesos: la ejecución de un proceso consiste en un ciclo de ejecución de la CPU y espera de E/S, y los
procesos se alternan entre estos dos estados. La ejecución del proceso se inicia con una ráfaga de
CPU; a ésta le siguen una ráfaga de E/S, otra ráfaga de CPU, una más de E/S, etc. Finalmente, la última
ráfaga de CPU terminará con una solicitud al sistema para que concluya la ejecución, en vez de otra
ráfaga de E/S.
Figura 5.- Ráfagas de uso de la CPU y la E/S
Si observamos la figura anterior vemos que un proceso con ráfagas de CPU y E/S en (a) utilizan
ráfagas de CPU largas y poca E/S. Esto significa que invierten la mayor parte del tiempo en hacer
cálculos, mientras que (b) tienen ráfagas de CPU cortas y hacen un uso más intensivo de la E/S.
Las duraciones de estas ráfagas de CPU se han medido, y aunque varían considerablemente de
un proceso a otro y entre ordenadores, se caracterizan en que suele haber un gran número de
ráfagas de CPU de corta duración y un pequeño número de ráfagas de larga duración. Un programa
Página 9
Rafael Lozano
Gestión de procesos
limitado por E/S normalmente tendrá muchas ráfagas de CPU breves, mientras que un programa
limitado por la CPU tendrá pocas ráfagas de muy larga duración. Esta distribución puede ser muy
importante al seleccionar un algoritmo adecuado para la planificación de la CPU.
4 Algoritmos de planificación
Un algoritmo de planificación define la estrategia que sigue el planificador de la CPU para
seleccionar el siguiente proceso de la cola de procesos listos al que se le asignará la CPU. Cuando hay
más de un proceso que está en condiciones de ejecutarse, se debe escoger alguno. El encargado de
tomar esta decisión es el planificador y el algoritmo que se usa se llama algoritmo de planificación.
Distintos entornos requieren diferentes algoritmos de planificación. Esto se debe a que las
diferentes áreas de aplicación, y por ende los distintos tipos de sistemas operativos, tienen objetivos
diferentes. Es decir, lo que el planificador debe optimizar no es lo mismo en todos los sistemas.
Mientras que en entornos con procesos por lotes no hay usuarios esperando impacientemente
una respuesta rápida, en los entornos con usuarios interactivos la apropiación de la CPU es esencial
para evitar que un proceso acapare su uso y niegue el servicio a los demás. Aunque no hubiera un
proceso que se ejecutara indefinidamente de manera intencionada, podría haber un proceso que
debido a un error de programa continuará su ejecución indefinidamente. La apropiación es necesaria
para evitar este posible comportamiento. Los servidores también entran en esta categoría, ya que por
lo general dan servicio a varios usuarios remotos, todos los cuales siempre tienen mucha prisa.
4.1 Objetivos de los algoritmos de planificación
Para diseñar un algoritmo de planificación, es necesario tener en mente los objetivos que debe
alcanzar un buen algoritmo de planificación. Algunos objetivos dependen del entorno (procesamiento
por lotes o interactivo), pero hay también algunos que son deseables en todos los casos:
✔
Equidad.- Otorgar a cada proceso una parte justa del tiempo de la CPU.
✔
Rendimiento.- Maximizar el número de trabajos terminados por unidad de tiempo.
✔
Tiempo de respuesta.- Minimizar el tiempo de respuesta a los usuarios interactivos.
✔
Tiempo de espera.- Minimizar el tiempo de espera de los procesos.
✔
Utilización de la CPU.- Mantener ocupada la CPU todo el tiempo.
Los distintos algoritmos de planificación tienen propiedades diferentes y pueden favorecer a un
tipo de proceso en lugar de a otro, así que al elegir qué algoritmo se aplicará en una situación
determinada debemos considerar las propiedades de los diversos algoritmos.
Para comparar los algoritmos de planificación de la CPU se han propuesto varios criterios, y las
características que se utilicen para la comparación pueden representar diferencias considerables en
la determinación del mejor algoritmo. Los criterios que se emplean incluyen los siguientes:
✔
Utilización de la CPU.- Queremos que la CPU se mantenga tan ocupada como sea posible.
✔
Productividad.- Si la CPU se encuentra ocupada, se está efectuando algún trabajo. Una medida
del trabajo es el número de procesos que se completan por unidad de tiempo, llamada
Página 10
Rafael Lozano
Gestión de Procesos
productividad.
✔
Tiempo de espera.- El algoritmo para la planificación de la CPU no afecta realmente a la
cantidad de tiempo durante el cual un proceso se ejecuta o lleva a cabo la E/S. El algoritmo
afecta únicamente a la cantidad de tiempo que el proceso espera en la cola de procesos listos,
de modo que en vez de tener en cuenta el tiempo de retorno, podemos considerar sólo el
tiempo de espera para cada proceso.
✔
Tiempo de respuesta.- En un sistema interactivo, es posible que el tiempo de retorno no sea el
mejor criterio. Con frecuencia un proceso puede producir alguna salida en los primeros
instantes y continuar calculando nuevos resultados mientras se presentan al usuario los
resultados anteriores. Por esto, otra medición es el tiempo transcurrido desde la presentación
de una solicitud hasta que se produce la primera respuesta. Esta medición, llamada tiempo de
respuesta, es la cantidad de tiempo para comenzar a responder, pero no el tiempo necesario
para mostrar esa respuesta. El tiempo de retorno generalmente se encuentra limitado por la
velocidad del dispositivo de salida.
Es deseable maximizar la utilización de la CPU y la productividad, y minimizar los tiempos de
retorno, de espera y de respuesta.
El modo de decisión especifica los instantes de tiempo en que se aplica la función de selección.
Hay dos categorías generales:
✔
No apropiativo.- En este caso el proceso dispondrá de la CPU una vez se la haya asignado el
sistemas operativo y este no podrá apropiarse de esta hasta que termine o se bloquee en
espera de una operación de E/S.
✔
Apropiativo.- El proceso que se está ejecutando puede ser interrumpido por el SO y pasar al
estado de listos.
Las políticas apropiativas suponen un mayor coste que las no apropiativas pero en general,
aumentan el rendimiento global del sistema ya que evitan el monopolio por parte de un único
proceso.
A medida que analicemos los distintos algoritmos para la planificación de la CPU, ilustraremos
su funcionamiento. Una ilustración precisa podría incluir muchos procesos, y cada uno de ellos una
secuencia de centenares de ráfagas de CPU y de E/S. Para simplificar las ilustraciones, en nuestros
ejemplos consideramos sólo una ráfaga de CPU, en milisegundos.
No existe un algoritmo de planificación óptimo ya que los resultados dependerán de factores
como la duración de su ráfaga, el instante de llegada, prioridad, etc. Para estudiar el comportamiento
de cada algoritmo vamos a utilizar dos medidas que nos indicarán como el proceso ha sido tratado
por la planificación: el tiempo de servicio y el tiempo de espera. Calcularemos estas dos medidas para
cada proceso y luego haremos un promedio para el conjunto de procesos de la cola. Para calcular
estos tiempos necesitaremos los siguientes factores:
✔
Llamaremos t al tiempo que un proceso necesita la CPU para su ejecución (suponiendo que
solamente constara de una ráfaga de CPU).
✔
Tiempo de retorno.- Desde el punto de vista de un proceso en particular, el criterio más
Página 11
Rafael Lozano
Gestión de procesos
importante es cuanto tiempo tarda en ejecutarse ese proceso. El intervalo entre el momento
de ofrecerlo hasta el momento en que termina es el tiempo de retorno, es decir, la suma de
los periodos transcurridos esperando entrar en la memoria, esperando en la cola de procesos
listos, ejecutándose en la CPU y efectuando la E/S.
✔
Llamaremos ti es el instante en que el proceso comienza su ejecución
✔
Llamaremos tf es el instante en que el proceso termina su ejecución.
✔
Llamaremos p a la prioridad del proceso. Es un entero que indica la prioridad del proceso a la
hora de asignarle la CPU. El valor 0 indica prioridad máxima.
Con estos factores definimos:
✔
Tiempo de servicio (T) es el que necesitaría un proceso para ejecutarse. T = tf – ti
✔
Tiempo de espera (E) es el tiempo que un proceso permanece en la cola de procesos listos
esperando que se le asigne la CPU. E = T - t
A modo de ejemplo vamos a utilizar en todos los algoritmos de planificación la siguiente cola de
procesos listos
Proceso
P1
P2
P3
P4
P5
P6
Duración (t)
16
3
2
5
1
3
Llegada (ti)
0
1
5
6
7
9
Prioridad
1
1
0
0
2
0
A partir de ahora se presentan los diferentes algoritmos de planificación y con estos datos
haremos los cálculos necesarios para obtener T y E.
4.2 Planificación FCFS. Servicio por orden de llegada
Este algoritmo se emplea en sistemas con procesamiento por lotes (no hay interacción con el
usuario) y es probablemente el más simple de todos. El FCFS (First Come, First Served) es no apropiativo
y consiste en asignar la CPU a los procesos en el orden en que la solicitan. Solo hay una cola de
procesos listas y cuando se asigna la CPU a un proceso se le permite ejecutarse todo el tiempo que
desee. No se interrumpe debido a que se ha ejecutado demasiado tiempo. A medida que van
entrando otros trabajos se colocan al final de la cola. Si el proceso en ejecución se bloquea por E/S, el
primer proceso en la cola se ejecuta a continuación. Cuando un proceso bloqueado pasa al estado de
listo, al igual que un proceso recién llegado, se coloca al final de la cola. En la política FCFS el tiempo
promedio de espera puede ser bastante largo.
Para mostrar el comportamiento del sistema durante el tiempo que duren los procesos
anteriores vamos a emplear un diagrama de Gantt.
P6
P5
P4
P3
Página 12
Rafael Lozano
Gestión de Procesos
P2
P1
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Hemos sombreado los instantes de tiempo que los procesos están en la cola de procesos listos.
Los instantes coloreados representan a los procesos con la CPU asignada. Ahora podemos calcular
los tiempos de espera y retorno de cada proceso
Proceso
Duración (t)
Llegada (ti)
T = tf - ti
E=T-t
P1
16
0
16 – 0 = 16
16 – 16 = 0
P2
3
1
19 – 1 = 18
18 – 3 = 15
P3
2
5
21 – 5 = 16
16 – 2 = 14
P4
5
6
26 – 6 = 20
20 – 5 = 15
P5
1
7
27 – 7 = 20
20 – 1 = 19
P6
3
9
30 – 9 = 21
21 – 3 = 18
Promedio
T̄ =
18,5
16 +18+16+20+ 20+21
=18,5
6
Ē=
13,5
0+15+ 14+15+19+18
=13,5
6
Los resultados de esta política de planificación pueden variar mucho en función de la
distribución de los procesos. Consideremos el mismo ejemplo anterior pero variando los instantes de
llegada.
Proceso
P1
P2
Llegada (ti) 7
P3
0
2
P4
3
P5
5
P6
6
En este caso tendríamos el siguiente diagrama temporal
P6
P5
P4
P3
P2
P1
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Volemos a calcular los tiempos de espera y retorno de cada proceso
Proceso
Duración (t)
Llegada (ti)
T = tf - ti
E=T-t
P1
16
7
30 – 7 = 23
23 – 16 = 7
P2
3
0
3–0=3
3–3=0
P3
2
2
5–2=3
3–2=1
P4
5
3
10 – 3 = 7
7–5=2
P5
1
5
11 – 5 = 6
6–1=5
Página 13
Rafael Lozano
P6
Gestión de procesos
3
6
Promedio
T̄ =
23+ 3+3+7+6 +8
=8,33
6
Ē=
14 – 6 = 8
8–3=5
8,33
3,33
7+ 0+1+2+5+5
=3,33
6
Nótese como han bajado los tiempos de respuesta y espera de los procesos y los promedios.
Además, consideremos el rendimiento de la planificación FCFS en una situación dinámica.
Suponga que tenemos un proceso limitado por la CPU y varios procesos limitados por E/S. Al pasar
los procesos por el sistema, se puede presentar la siguiente situación: el proceso limitado por la CPU
obtendrá la CPU y la retendrá; durante este tiempo, todos los demás procesos terminarán su E/S y
pasarán a la cola de procesos listos, en espera de la CPU. Mientras esperan en la cola de procesos
listos, los dispositivos de E/S permanecen inactivos. Finalmente, el proceso limitado por la CPU
termina su ráfaga de CPU y pasa a un dispositivo de E/S. Todos los procesos limitados por E/S, que
tienen ráfagas de CPU breves, se ejecutan rápidamente y regresan a las colas de dispositivos de E/S.
En este momento la CPU está inactiva. El proceso limitado por la CPU regresará a la cola de procesos
listos y se le asignará la CPU. Una vez más, los procesos limitados por E/S se encuentran en la cola de
procesos listos esperando a que termine el proceso limitado por la CPU. Esto se conoce como efecto
convoy, ya que todos los demás procesos esperan a que un proceso de gran tamaño salga de la CPU.
Este efecto provoca que la CPU y los dispositivos se aprovechen menos que si se permitiera que los
procesos más cortos pasaran antes.
El algoritmo de planificación FCFS es no apropiativo. Una vez que se ha asignado la CPU a un
proceso, éste la conserva hasta que desee liberarla, ya sea por terminación o por solicitud de E/S. El
algoritmo FCFS es especialmente problemático en los sistemas de tiempo compartido, donde es
importante que cada usuario reciba una porción de la CPU a intervalos regulares. Sería desastroso
permitir que un proceso retuviera la CPU por un periodo largo.
4.3 Planificación SJF. Tiempo de ejecución más breve
Ahora vamos a analizar otro algoritmo de procesamiento por lotes no apropiativo, el cual
supone que los tiempos de ejecución se conocen de antemano. El algoritmo “ primero el trabajo más
breve” o SJF (Shortest Job First) asigna la CPU al proceso que tiene la ráfaga siguiente de CPU más
pequeña. Si dos procesos tienen la misma longitud para la siguiente ráfaga de CPU, se utiliza la
planificación FCFS para romper el empate. Vamos a analizar nuestro conjunto de procesos de ejemplo
con este algoritmo. El diagrama de Gantt sería el siguiente
P6
P5
P4
P3
P2
P1
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Los tiempos de espera y retorno serían los siguientes
Proceso
Duración (t)
Llegada (ti)
T = tf - ti
Página 14
E=T-t
Rafael Lozano
Gestión de Procesos
P1
16
0
16 – 0 = 16
16 – 16 = 0
P2
3
1
22 – 1 = 21
21 – 3 = 18
P3
2
5
19 – 5 = 14
14 – 2 = 12
P4
5
6
29 – 6 = 23
23 – 5 = 18
P5
1
7
17 – 7 = 10
10 – 1 = 9
P6
3
9
25 – 9 = 16
16 – 3 = 13
Promedio
T̄ =
16 +21+14+23+ 10+16
=16,67
6
16,67
Ē=
11,67
0+18+ 12+ 18+9+13
=11,67
6
Puede comprobarse que el algoritmo SJF es óptimo, ya que ofrece el mínimo tiempo promedio
de espera para un conjunto de procesos dado. La comprobación muestra que poniendo un proceso
breve antes de uno largo se reduce el tiempo de espera del proceso corto más de lo que aumenta el
tiempo de espera del proceso largo. Por tanto, se reduce el tiempo de espera promedio.
El problema real con el algoritmo SJF es conocer la longitud de la siguiente solicitud de la CPU y
su dificultad para estimarla. No hay manera de conocer la longitud de la siguiente ráfaga de CPU, pero
se puede tratar de efectuar una aproximación a la planificación SJF. Aunque no conocemos la longitud
de la siguiente ráfaga de CPU, podemos predecir su valor, esperando que sea de longitud similar a las
anteriores. Así, al calcular una aproximación de la longitud de la siguiente ráfaga de CPU podemos
elegir el proceso con la ráfaga de CPU prevista más breve.
4.4 Planificación SRTN. El menor tiempo restante
La alternativa se plantea cuando un nuevo proceso llega a la cola de procesos listos mientras se
está ejecutando otro proceso. El nuevo proceso puede tener una ráfaga de CPU menor que lo que
resta de proceso que se ejecuta en ese momento. Un algoritmo SJF apropiativo desplazará al proceso
que se ejecuta, mientras que un algoritmo SJF no apropiativo permitirá que el proceso que se ejecuta
termine su ráfaga de CPU. La planificación SJF apropiativa en ocasiones se denomina planificación
“primero el que tenga el menos tiempo restante” o SRTF (Shortest Remaining Time First).
Vamos a analizar nuestro conjunto de procesos de ejemplo con este algoritmo. El diagrama de
Gantt sería el siguiente
P6
P5
P4
P3
P2
P1
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Los tiempos de espera y retorno serían los siguientes
Proceso
Duración (t)
Llegada (ti)
T = tf - ti
Página 15
E=T-t
Rafael Lozano
Gestión de procesos
P1
16
0
30 – 0 = 30
30 – 16 = 14
P2
3
1
4–1=3
3–3=0
P3
2
5
7–5=2
2–2=0
P4
5
6
16 – 6 = 10
10 – 5 = 5
P5
1
7
8–7=1
1–1=0
P6
3
9
12 – 9 = 3
3–3=0
Promedio
T̄ =
30+ 3+2+10+1+3
=8,16
6
Ē=
8,16
3,67
14+ 0+0+5+ 0+0
=3,67
6
La bajada de los tiempos de espera y retorno es evidente y sus promedios son óptimos.
4.5 Planificación por prioridades
La idea básica es simple: a cada proceso se le asigna una prioridad y el proceso al que se le
asigna la CPU es el que tiene la prioridad más alta. Los procesos con igual prioridad se planifican en
orden FCFS.
Incluso hasta en un PC con un solo usuario puede haber varios procesos, algunos de ellos más
importantes que los demás. Por ejemplo, un proceso demonio que envía correo electrónico en
segundo plano debería recibir una menor prioridad que un proceso que muestra una película de
vídeo en la pantalla en tiempo real.
Estamos analizando la planificación en términos de una alta prioridad y una baja prioridad. Las
prioridades generalmente corresponden a un intervalo fijo de números, como 0 a 7 o 0 a 4095. Sin
embargo, no existe ningún consenso respecto a si 0 es la prioridad más alta o la más baja. Algunos
sistemas emplean números bajos para representar una prioridad baja; otros utilizan números bajos
para representar una prioridad alta. Esta diferencia puede prestarse a confusiones. En este tema
supondremos que los números bajos representan prioridades altas.
A los procesos se les asigna prioridad de forma estática o dinámica. Cuando un usuario inicia un
proceso, este puede tener una prioridad en función del tipo de usuario y en el sistema operativo
Linux/Unix existe un comando que permite reducir la prioridad de un proceso lanzado por un
usuario, aunque nadie lo usa.
El sistema también puede asignar las prioridades en forma dinámica para lograr ciertos
objetivos. Por ejemplo, algunos procesos están muy limitados a E/S y gastan la mayor parte de su
tiempo esperando a que la E/S se complete. Cada vez que un proceso de este tipo necesita la CPU,
debe recibirla de inmediato para dejar que inicie su siguiente petición de E/S, que a su vez puede
proceder en paralelo con otro proceso que se encuentre realizando cálculos. Hacer que el proceso
limitado a E/S espere mucho tiempo por la CPU sólo significa que estará ocupando memoria por un
tiempo innecesariamente largo.
La planificación por prioridades puede ser apropiativa o no apropiativa. Cuando un proceso
llega a la cola de procesos listos, su prioridad se compara con la del proceso en ejecución. Un
algoritmo apropiativo para la planificación por prioridades se apropiará de la CPU si la prioridad del
Página 16
Rafael Lozano
Gestión de Procesos
proceso recién llegado es mayor que la del proceso en ejecución. Un algoritmo no apropiativo para la
planificación por prioridades únicamente dejará al nuevo proceso al inicio de la cola de procesos
listos.
Vamos a estudiar nuestro ejemplo con una política por prioridades apropiativa. En principio, hay
que asignar prioridades a los procesos, indicada en la columna Prioridad. El diagrama de Gantt sería el
siguiente
P6
P5
P4
P3
P2
P1
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Los tiempos de espera y retorno serían los siguientes
Proceso
Prioridad
Duración (t)
P1
1
16
P2
2
P3
Llegada (ti)
T = tf - ti
E=T-t
0
25 – 0 = 25
25 – 16 = 9
3
1
28 – 1 = 27
27 – 3 = 24
2
2
5
30 – 5 = 25
25 – 2 = 23
P4
0
5
6
11 – 6 = 5
5–5=0
P5
0
1
7
12 – 7 = 5
5–1=4
P6
0
3
9
15 – 9 = 6
6–3=3
Promedio
T̄ =
25+ 27+25+5+5+ 6
=15,5
6
Ē=
15,5
10,5
9+ 24+23+ 0+ 4 +3
=10,5
6
Un serio problema de los algoritmos para la planificación por prioridades es el bloqueo
indefinido o inanición. Un proceso que está listo para ejecutarse pero no obtiene la CPU puede
considerarse bloqueado, en espera de la CPU. Un algoritmo para la planificación por prioridades
puede dejar a un proceso de baja prioridad esperando indefinidamente a la CPU. En un sistema de
computación con gran carga, un flujo constante de procesos de alta prioridad puede evitar que un
proceso de baja prioridad obtenga la CPU. Por lo general sucederá una de estas dos cosas: o el
programa finalmente se ejecuta, cuando disminuye la carga del sistema, o el sistema de computación
falla y pierde todos los procesos de baja prioridad.
Una solución para el problema del bloqueo indefinido de los procesos de baja prioridad es el
envejecimiento, técnica por la cual aumenta gradualmente la prioridad de los procesos que esperan
durante mucho tiempo en el sistema, a intervalos de tiempo regulares.
4.6 Planificación por turno circular
Uno de los algoritmos más antiguos, simples, equitativos y de mayor uso es el de turno circular.
El algoritmo de planificación circular o RR (round-robin) está diseñado especialmente para sistemas
Página 17
Rafael Lozano
Gestión de procesos
interactivos de tiempo compartido. Se define una pequeña unidad de tiempo, llamada quántum
(cuanto de tiempo o porción de tiempo), que generalmente varia entre 10 y 100 milisegundos. La cola
de procesos listos se trata como una cola circular, el planificador de la CPU la recorre asignando la
CPU a cada proceso por un intervalo de hasta un cuanto de tiempo.
Para poner en práctica la planificación RR, mantenemos la cola de procesos listos como una
cola “primero que entra, primero que sale” (FIFO). Los nuevos proceso se agregan al final de la cola de
procesos listos. El planificador de la CPU toma el primer proceso de la cola, programa un cronómetro
para que interrumpa después de un cuanto de tiempo y despacha el proceso.
Entonces sucederá una de estas dos cosas: el proceso puede tener una ráfaga de CPU menor
que un cuanto de tiempo, en cuyo caso el proceso liberará voluntariamente a la CPU y el planificador
continuará con el siguiente proceso de la cola de procesos listos. Por otra parte, si la ráfaga de la CPU
del proceso en ejecución es mayor que un cuanto de tiempo, el cronómetro se activará y provocará
una interrupción para el SO. Se ejecutará un cambio de contexto y el proceso se colocará al final de la
cola de procesos listos. El planificador de la CPU seleccionará entonces el siguiente proceso de la cola.
En el algoritmo de planificación RR, la CPU no se asigna a ningún proceso por más de un
quántum consecutivo de tiempo. Si la ráfaga de la CPU de un proceso excede de un quántum, se
expulsa y regresa a la cola de procesos listos. El algoritmo de planificación RR es apropiativo.
Si existen n procesos en la cola de procesos listos y el cuanto de tiempo es q, cada proceso
recibe 1/n de tiempo de la CPU en trozos de q unidades de tiempo como máximo. Ningún proceso
debe esperar más de (n – 1)· q unidades de tiempo antes de recibir su siguiente cuanto. Por ejemplo,
si hay cinco procesos, con un cuanto de tiempo de 20 milisegundos, entonces cada proceso recibirá
hasta 20 milisegundos cada 100 milisegundos.
Vamos a estudiar nuestro ejemplo con esta política. Supongamos que definimos un quántum
de 5mseg. El diagrama de Gantt sería el siguiente
P6
P5
P4
P3
P2
P1
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Los tiempos de espera y retorno serían los siguientes
Proceso
Duración (t)
Llegada (ti)
T = tf - ti
0 30 – 0 = 30
E=T-t
P1
16
P2
3
1
8–1=7
7–3=4
P3
2
5
10 – 5 = 5
5–2=3
P4
5
6
15 – 6 = 9
9–5=4
P5
1
7
16 – 7 = 9
9–1=8
P6
3
9 19 – 9 = 10
10 – 3 = 7
Página 18
30 – 16 = 14
Rafael Lozano
Gestión de Procesos
Promedio
T̄ =
30+ 7+5+9+ 9+10
=11,67
6
11,67
Ē=
6,67
14+ 4+ 3+4 +8+7
=6,67
6
La única cuestión interesante con el algoritmo de turno circular es la longitud del quántum. Para
conmutar de un proceso a otro se requiere cierta cantidad de tiempo para realizar el cambio de
contexto (guardar y cargar tanto registros como mapas de memoria, actualizar varias tablas y listas,
vaciar y recargar la memoria caché, etc). Supongamos que este cambio de contexto requiere 1 mseg y
que el quántum se establece a 4 mseg. Con estos parámetros, después de realizar 4 mseg de trabajo
útil, la CPU tendrá que gastar (es decir, desperdiciar) 1 mseg en el cambio de contexto. Es decir, se
pierde un 20% por carga administrativa. Sin duda, esto es demasiado.
Para mejorar la eficiencia de la CPU, podríamos establecer el quántum de por ejemplo 100
mseg. Ahora el tiempo desperdiciado es sólo de 1%. Pero considere lo que ocurre en un sistema
servidor si llegan 50 peticiones dentro de un intervalo de tiempo muy corto y con requerimientos muy
variables de la CPU. Se colocarán cincuenta procesos en la lista de procesos ejecutables. Si la CPU
está inactiva, el primero empezará de inmediato, el segundo tal vez no inicie sino hasta 100 mseg
después y así en lo sucesivo. El último desafortunado tal vez tenga que esperar 5 segundos para
poder tener una oportunidad, suponiendo que los demás utilizan sus quántums completos. La
mayoría de los usuarios percibirán como lenta una respuesta de 5 segundos a un comando corto.
Esta situación es muy mala si algunas de las peticiones cerca del final de la cola requirieron sólo unos
cuantos milisegundos de tiempo de la CPU. Con un quántum corto, hubieran obtenido un mejor
servicio.
Otro factor es que si al quántum se le asigna un tiempo más largo que la ráfaga promedio de la
CPU, la apropiación no ocurrirá con mucha frecuencia. En vez de ello, la mayoría de los procesos
realizarán una operación de bloqueo antes de que el quántum se agote, ocasionando una
conmutación de proceso. Al eliminar la apropiación mejora el rendimiento, debido a que los cambios
de contexto sólo ocurrirán cuando sea lógicamente necesario; es decir, cuando un proceso se
bloquee por E/S y no pueda continuar.
La conclusión a la que se llega es que si se establece el quántum demasiado corto se producen
demasiadas conmutaciones de procesos y se reduce la eficiencia de la CPU, pero si se establece
demasiado largo se puede producir una mala respuesta a las peticiones interactivas cortas. A
menudo, un quántum con un valor entre 20 y 50 mseg constituye una solución razonable.
5 Planificación por niveles
Se ha creado otra clase de algoritmos de planificación para aquellas situaciones donde los
procesos se pueden clasificar fácilmente en distintos grupos. Por ejemplo, una división habitual
consiste en diferenciar los procesos de primer plano (interactivos) de los procesos de segundo plano
(por lotes). Estos dos tipos de procesos tienen requisitos de tiempo de respuesta bastante diferentes,
por lo que pueden presentar distintas necesidades de planificación. Además, los procesos de primer
plano pueden tener una prioridad superior (definida externamente) a la de procesos de segundo
plano.
Un algoritmo de planificación de colas de múltiples niveles divide la cola de procesos listos en
diversas colas. Los procesos se asignan en forma permanente a una cola, generalmente a partir de
Página 19
Rafael Lozano
Gestión de procesos
alguna propiedad del proceso, como puede ser el tamaño de la memoria o el tipo de proceso. Cada
cola tiene su propio algoritmo de planificación; por ejemplo, pueden emplearse colas distintas para
los procesos de primer y segundo planos. La cola de primer plano puede planificarse con un
algoritmo RR, mientras que la de segundo plano se planifica con un algoritmo FCFS.
Debe existir además una planificación entre las colas, la cual generalmente es una planificación
apropiativa de prioridad fija. Por ejemplo, la cola de procesos de primer plano puede tener prioridad
absoluta sobre la cola de procesos de segundo plano.
Veamos un ejemplo de algoritmo de planificación de colas de múltiples niveles con tres colas:
✔
Procesos del sistema
✔
Procesos interactivos
✔
Procesos por lotes
Cada cola tiene prioridad absoluta sobre las colas de menor prioridad. Por ejemplo, no podría
ejecutarse ningún proceso de la cola de procesos por lotes a menos que las colas de procesos del
sistema y procesos interactivos estuvieran vacías. Si un proceso interactivo de edición entrara en la
cola de procesos listos durante la ejecución de un proceso por lotes, este último se expulsaría.
Otra posibilidad es utilizar una porción de tiempo para las colas. Cada cola recibiría cierta
porción del tiempo de la CPU, la cual se planificaría entre los procesos de su cola. Por ejemplo, en el
caso de las colas de primer y segundo planos, la cola de primer plano puede recibir el 80% del tiempo
de la CPU para la planificación RR de sus procesos, mientras que la cola de segundo plano recibe el
20% de la CPU para distribuirlo entre sus procesos de manera FCFS.
5.1 Planificación de colas de múltiples niveles con realimentación
En un algoritmo para la planificación de colas de múltiples niveles normalmente los procesos se
asignan de manera permanente a una cola al entrar al sistema y no se mueven a otras colas. Por
ejemplo, si hay colas diferentes para los procesos de primer y segundo planos, no cambian de una
cola a otra, ya que los procesos no modifican su naturaleza de primer a segundo plano. Esta
configuración tiene la ventaja de provocar poco gasto de procesamiento adicional durante la
planificación, pero es inflexible.
Sin embargo, la planificación de colas de múltiples niveles con realimentación permite a un
proceso moverse de una cola a otra. La idea es separar los procesos con diferentes características en
cuanto a ráfagas de la CPU. Si un proceso utiliza demasiado tiempo de la CPU, se pasará a una cola de
menor prioridad. Este esquema deja a los procesos limitados por E/S y a los procesos interactivos en
las colas de mayor prioridad. De igual manera, si un proceso espera demasiado tiempo en una cola de
menor prioridad se puede mover a una de mayor prioridad. Esta es una forma de envejecimiento que
evitaría el bloqueo indefinido.
Por ejemplo, consideremos un planificador de colas de múltiples niveles con realimentación con
tres colas, numeradas del 0 al 2. El planificador ejecutará primero todos los proceso de la cola 0. Sólo
cuando ésta se encuentre vacía, se ejecutarán los procesos de la cola 1. En forma similar, los procesos
de la cola 2 sólo se ejecutarán si las colas 0 y 1 están vacías. Un proceso que llegue a la cola 1
expulsará a un proceso de la cola 2. A su vez, un proceso de la cola 1 será expulsado por un proceso
Página 20
Rafael Lozano
Gestión de Procesos
que llegue a la cola 0.
A los procesos que entran en la cola de procesos listos se les coloca en la cola 0, y se les asigna
un cuanto de tiempo de ocho milisegundos. Si no terminan en este lapso, se mueven al final de la cola
1; si la cola 0 está vacía, se asigna un cuanto de tiempo de 16 milisegundos al proceso que se
encuentra al inicio de la cola 1. Si no termina, es expulsado y pasa a la cola 2. Los procesos de esta
cola se ejecutan sobre una base FCFS, únicamente cuanto estén vacías las colas 0 y 1.
Este algoritmo de planificación da mayor prioridad a cualquier proceso con una ráfaga de CPU
de ocho milisegundos o menos. Este proceso recibirá rápidamente la CPU, terminará su ráfaga de
CPU y pasará a su siguiente ráfaga de E/S. Los procesos que requieren más de ocho, pero menos de
24 milisegundos, también son atendidos con rapidez, aunque con menos prioridad que los procesos
más breves. Los procesos de larga duración descienden automáticamente a la cola 2 y son atendidos
en orden de llegada utilizando cualquier ciclo de la CPU que no ocupe las colas 0 y 1.
Por lo general, un planificador de colas de múltiples niveles con realimentación se define con los
siguientes parámetros:
✔
El número de colas.
✔
El algoritmo de planificación para cada cola.
✔
El método utilizado para determinar cuándo promover un proceso a una cola de mayor
prioridad.
✔
El método utilizado para determinar cuándo degradar un proceso a una cola de menor
prioridad.
✔
El método utilizado para determinar a cuál cola entrará un proceso cuando necesite servicio.
La definición de un planificador de colas de múltiples niveles con realimentación lo convierte en
el algoritmo de planificación de la CPU más general, aunque también el más complejo.
6 Planificación de múltiples procesadores
Hasta ahora nuestro análisis se ha centrado en los problemas de la planificación de la CPU en
un sistema con un solo procesador. Si hay múltiples CPU, el problema de planificación se vuelve más
complejo. Se han probado varias posibilidades y, como hemos visto en la planificación de la CPU con
un solo procesador, no hay una solución única que sea la mejor. A continuación analizaremos
brevemente algunos de los asuntos relacionados con la planificación de procesadores múltiples.
Uno de los factores principales es el tipo de procesadores que entran en juego, los cuales
pueden ser idénticos (un sistema homogéneo) o distintos (un sistema heterogéneo). Si los
procesadores son diferentes, las opciones son relativamente limitadas. Cada procesador tiene su
propia cola y su propio algoritmo de planificación. Los procesos están tipificados intrínsecamente por
su estructura, y deben ejecutarse en un procesador determinado. Así, los procesos se restringen a un
procesador y cada procesador se planifica a si mismo.
Si hay varios procesadores idénticos, pueden compartir cargas. Sería posible proporcionar una
cola distinta a cada procesador, pero en esta situación un procesador podría estar inactivo, con una
cola vacía, mientras los demás procesadores estuvieran muy activos. Para evitarlo utilizamos una cola
Página 21
Rafael Lozano
Gestión de procesos
común de procesos listos; todos los procesas entran a esta cola y se planifican en cualquier
procesador disponible.
Con este esquema puede emplearse una de entre dos estrategias de planificación. En una de
ellas, cada procesador se planifica a sí mismo. Cada procesador examina la cola común de procesos
listos y selecciona un proceso para ejecución. Si tenemos varios procesadores que tratan de acceder
a un proceso común hay que programar con cuidado cada procesador. Debemos asegurar que dos
procesadores no elijan el mismo proceso, y que no se pierdan procesos de la cola. La otra estrategia
evita este problema estableciendo a un procesador como planificador para los demás, creando así
una estructura amo-esclavo, es decir, el multiprocesamiento asimétrico.
7 Planificación de hilos
Cuando los procesos son multihilo tenemos dos niveles de paralelismo: procesos e hilo. La
planificación en tales sistemas dependerá de si los hilos se implementan a nivel de usuario o a nivel
de kernel.
En los sistemas de hilo a nivel de usuario como el kernel no es consciente de la existencia de los
hilos, opera de la misma forma de siempre: selecciona un proceso y le asigna la CPU. El planificador
de hilos dentro del proceso decide qué hilo se ejecuta y este hilo puede continuar todo el tiempo que
quiera. Si agota todo el tiempo de CPU asignado al proceso entonces el kernel seleccionará otro
proceso para su ejecución.
En los sistemas con hilo a nivel de kernel, este selecciona un hilo específico para su ejecución.
No tiene que tomar en cuenta a qué proceso pertenece el hilo, pero puede hacerlo si lo desea. El hilo
recibe la CPU por un tiempo y se suspende obligatoriamente cuando lo excede.
Figura 6.- Planificación multihilo
Página 22
Rafael Lozano
Gestión de Procesos
8 Bibliografía
WIKIPEDIA,
Hilo
de
ejecución
[acceso
septiembre
<http://es.wikipedia.org/wiki/Hilo_de_ejecuci%C3%B3n>
2014].
Disponible
en
TANENBAUM, A. T., Sistemas Operativos Modernos – 3ª Edición. 2009 Pearson Prentice Hall, ISBN 978607-442-046-3
Página 23