Sistemas Operativos

Tema II
GESTIÓN DE PROCESOS
2.1. PROCESO.
En todos los computadores actuales, se pueden hacer varias cosas a la vez, mientras está
ejecutando un programa de usuario, puede perfectamente también estar leyendo de un disco e
imprimiendo texto en una pantalla o una impresora. En un sistema multiprogramado la CPU
(Unidad Central de Proceso) también 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 sólo está ejecutando un programa, en el transcurso de un segundo ha
podido estar trabajando sobre varios programas, dando entonces a los usuarios la impresión de
un cierto paralelismo (pseudoparalelismo), en contraste con el auténtico paralelismo del hardware
de los sistemas multiprocesador (que tienen dos o más CPUs compartiendo la misma memoria
física). Seguir la pista de múltiples actividades paralelas resulta muy complicado, por ese motivo
los diseñadores de los sistemas operativos han desarrollado un modelo conceptual evolucionado
(el de los procesos secuenciales) que permite tratar el paralelismo de una forma más fácil.

En este modelo, todo el software ejecutable en el computador, incluyendo a veces al propio

sistema operativo, se organiza en un número de procesos secuenciales, o simplemente procesos.
Un proceso es justamente un programa en ejecución, 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 rápida conmutación
de un proceso a otro en algún orden se denomina multiprogramación.

Debe hacerse una distinción 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. El proceso se puede definir como un programa puesto en
ejecución por el sistema operativo y de una forma más precisa, como la unidad de procesamiento
gestionada por el sistema operativo. Dos o mas procesos podrían estar ejecutando el mismo
programa, empleando sus propios datos y recursos, por ejemplo, si dos o más usuarios están
usando simultáneamente el mismo editor de texto. El programa es el mismo, pero cada usuario
tiene un proceso distinto (y con distintos datos).

Por analogía 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. Creación 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 según
sea necesario durante la operación del sistema. Los cuatro principales sucesos que provocan la
creación de nuevos procesos son:
• La inicialización del sistema
• La ejecución por parte de un proceso (en ejecución) de una llamada al sistema de creación
de un nuevo proceso.
• La petición por parte del usuario de la creación de un nuevo proceso.
• El inicio de un trabajo en batch (lotes).

Cuando un sistema operativo arranca, se crean típicamente varios procesos. Algunos de esos
procesos son procesos foreground (en primer plano), esto es, procesos que interactúan con los
usuarios y realizan trabajo para ellos. Otros son procesos background (en segundo plano), que no
están asociados con usuarios particulares, sino que tienen alguna función específica. Los procesos
que se ejecutan como procesos background para llevar a cabo alguna actividad tal como el correo
electrónico, las páginas web, la impresión de archivos de salida, etc, se denominan demonios en
Unix o servicios en Windows. Los sistemas grandes tienen comúnmente docenas de ellos. En

Ing. Jorge Orellana A. 24

 Sistemas Operativos

UNIX, el programa ps puede utilizarse para listar los procesos que están en marcha. En Windows
se utiliza el administrador de tareas.
Adicionalmente a los procesos creados en el momento del arranque, también pueden crearse
nuevos procesos después. A menudo un proceso en ejecución puede hacer llamadas al sistema
para crear uno o más 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 ratón 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 más. En ambos sistemas, los usuarios pueden tener
múltiples ventanas abiertas a la vez, cada una de ellas ejecutando algún proceso. Utilizando el
ratón, el usuario puede seleccionar una ventana e interactuar con el proceso, por ejemplo,
proporcionando datos de entrada cuando sean necesarios.
La última situación que provoca la creación de procesos se aplica sólo a los sistemas en batch
(por lotes) 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 sólo 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. Después del fork, los dos procesos, el
padre y el hijo, tienen la misma imagen de memoria, las mismas variables de entorno y los mismos
archivos abiertos. Eso es todo lo que hay. Usualmente, a continuación 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 creación del proceso como la carga del programa correcto dentro del nuevo proceso. Tanto
en UNIX como en Windows, después de crear un proceso, tanto el padre como el hijo cuentan con
sus propios espacios de direcciones disjuntos.

2.1.2. Terminación de Procesos

Tras la creación de un proceso comienza su ejecución realizando el trabajo que se le ha
encomendado. Sin embargo tarde o temprano, 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 terminación.
• Otro proceso fuerza la terminación del proceso (por ejemplo en UNIX mediante la llamada al
sistema kill).
La mayoría 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 también la terminación
voluntaria. Los procesadores de texto, navegadores y programas similares cuentan siempre con
un icono o una opción de menú para que el usuario pueda elegir con el ratón indicándole al proceso
que borre cualquier archivo temporal que esté abierto y a continuación termine.
La segunda causa de terminación es que el proceso descubra un error fatal. Por ejemplo, si un
usuario teclea un comando incorrecto. La tercera causa de terminación es la aparición de un error
causado por el proceso, a menudo debido a un error de programación. Algunos ejemplos son: la
ejecución de una instrucción ilegal, una referencia a una posición de memoria inexistente, o una
división por cero. La cuarta razón por la cual un proceso puede terminar, es que un proceso ejecute
una llamada al sistema diciéndole al sistema operativo que mate a algún otro proceso. En UNIX
esta llamada al sistema es kill. La función Win32 correspondiente es TerminateProcess. En
ambos casos el proceso asesino debe contar con la debida autorización.

Ing. Jorge Orellana A. 25

 Sistemas Operativos

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).
• Ejecutándose (running). El proceso está siendo ejecutado en la CPU. Por lo tanto a lo
más 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 algún evento ocurra, como la finalización de una operación de E/S.
También 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 están 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 asignación 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 transición de estado iniciada por el propio proceso del usuario, puesto que
las otras transiciones son iniciadas por entidades ajenas al proceso.

El planificador (scheduler) forma parte del núcleo del sistema operativo. Entra en ejecución cada
vez que se activa el sistema operativo y su misión es seleccionar el proceso que se ha de ejecutar
a continuación. El activador (dispatcher) también forma parte del sistema operativo y su función
es poner en ejecución el proceso seleccionado por el planificador. Debe ser muy rápido 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 también el que se encarga de pasar a modo usuario el proceso que esta activando
y “saltar” a la dirección de la instrucción que comienza la ejecución del programa.

Ing. Jorge Orellana A. 26

 Sistemas Operativos

2.1.4. Implementación 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 información necesaria para reanudarlo
si es suspendido, y otros datos.
• Estado: Puede ser nuevo, listo, en ejecución, en espera, detenido, etcétera
• Contador de programa: El contador indica la dirección de la siguiente instrucción que se
ejecutará para este proceso.
• Registros de CPU: El número y el tipo de los registros varía dependiendo de la arquitectura
del computador. Los registros incluyen acumuladores, registros índice, punteros de pila y
registros de propósito general, así como cualquier información de códigos de condición que
haya. Junto con el contador de programa, esta información de estado se debe guardar cuando
ocurre una interrupción, para que el proceso pueda continuar correctamente después.
• Información para planificación: Esta información incluye una prioridad del proceso, punteros a
colas de planificación y cualquier otro parámetro de planificación que haya.
• Información para administración de memoria: Esta información puede incluir datos tales como
el valor de los registros de base y límite, las tablas de páginas o las tablas de segmentos,
dependiendo del sistema de memoria empleado por el sistema operativo.
• Información de estado de E/S: La información incluye la lista de dispositivos de E/S asignadas
a este proceso, una lista de archivos abiertos, etcétera.
• Estadísticas y otros: tiempo real y tiempo de CPU usado, identificador del proceso,
identificador del dueño, tiempo real consumido, límites de tiempo, números de cuenta,
números de trabajo o proceso, y demás.

Cuando el Sistema Operativo cambia la atención de la CPU entre los procesos, utiliza las áreas
de preservación del PCB para mantener la información 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. Además, si se usan las
técnicas de administración de memoria que veremos más adelante, hay más información
involucrada. Este cambio, que demora de unos pocos a mil microsegundos, dependiendo del

Ing. Jorge Orellana A. 27

 Sistemas Operativos

procesador, es puro overhead o sobrecosto, puesto que entretanto la CPU no hace trabajo útil
(ningún proceso avanza). Considerando que la CPU hace varios cambios de contexto en un
segundo, su costo es relativamente alto.
Algunos procesadores tienen instrucciones especiales para guardar todos los registros de una vez.
Otros tienen varios conjuntos de registros, de manera que un cambio de contexto se hace
simplemente cambiando el puntero al conjunto actual de registros. El problema es que si hay más
procesos que conjuntos de registros, igual hay que apoyarse en la memoria. Por ser un cuello de
botella tan importante para el desempeño del sistema operativo se emplean estructuras nuevas
(hilos) para evitarla hasta donde sea posible.

2.1.6. Jerarquia de procesos

La secuencia de creación de procesos genera un árbol de procesos. Para referirse a las relaciones
entre los procesos de la jerarquía se emplean los términos de padre, hermano o abuelo. Cuando
el proceso A solicita al sistema operativo que cree el proceso B, se dice que A es padre de B y
que B es hijo de A. Bajo esta óptica, la jerarquía de procesos puede considerarse como un árbol
genealógico. Algunos sistemas operativos, como Unix, mantienen de forma explícita esta
estructura jerárquica de procesos (un proceso sabe quién es su padre), mientras que otros
sistemas operativos como el Windows 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 cuántos terminales hay, y crea un proceso login para cada
terminal, que se encarga de solicitar nombre y contraseña. 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 más procesos según los comandos que ejecute el usuario, generándose así todo
un árbol de procesos: cada proceso tiene cero o más 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 múltiples hilos de control (threads) en el mismo espacio de direcciones
ejecutándose quasi-paralelamente, como si fueran procesos separados (excepto que comparten
el mismo espacio de direcciones).

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

Ing. Jorge Orellana A. 28

 Sistemas Operativos

En muchos aspectos los procesos livianos son similares a los procesos pesados, comparten el
tiempo de CPU, y a lo más 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
toda la memoria correspondiente al proceso pesado. En ese sentido, no hay protección entre
threads, nada impide que un thread pueda escribir, por ejemplo, sobre el stack de otro.

2.2.1. Comparando procesos livianos con procesos pesados

• El cambio de contexto entre hebras de un mismo proceso es mucho más 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
administración de memoria.
• La creación de threads también es mucho más barata, ya que la información que se requiere
para mantener un thread es mucho menos que un PCB. La mayor parte de la información del
PCB se comparte entre todos los threads del proceso.
• El espacio de direccionamiento compartido facilita la comunicación entre las hebras y el
compartimiento de recursos.

Ing. Jorge Orellana A. 29

 Sistemas Operativos

2.2.2. Implementación de procesos livianos (hebras)

Hay librerías que permiten implementar hebras dentro de procesos normales o pesados sin apoyo
del sistema operativo. La planificación y manejo de las hebras se hace dentro del proceso. El
sistema operativo no tiene idea de las hebras; sólo 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 también 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 rápidos, 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, aún cuando haya otras hebras listos para
ejecutar.

POSIX (Linux) especifica una serie de políticas de planificación, aplicables a procesos pesados y
procesos ligeros, que debe implementar cualquier sistema operativo que ofrezca esta interfaz. En
Windows la unidad básica de ejecución es el proceso ligero y, por tanto, la planificación se realiza
sobre este tipo de procesos.

2.3. PLANIFICACIÓN (SCHEDULING) DE PROCESOS

En un ambiente de multiprogramación es frecuente que en un momento dado haya múltiples
procesos compitiendo por el uso de la CPU al mismo tiempo. Esta situación se da siempre que
dos o más procesos están simultánemente en el estado preparado. Si sólo hay una CPU
disponible, es necesario hacer una elección para determinar cual de esos procesos será el
siguiente que se ejecute. La parte del sistema operativo que realiza esa elección se denomina el
planificador (scheduler), y el algoritmo que se utiliza para esa elección se denomina el algoritmo
de planificación.
Existen diferentes algoritmos de planificación 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 número 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, ejecutándose 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í.

Ing. Jorge Orellana A. 30

 Sistemas Operativos

• 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 política de planificación 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 organización en colas de las

solicitudes pendientes. Se tienen colas para la planificación del uso de la CPU como también colas
para el uso de dispositivos (device queues), que son utilizadas para ordenar los requerimientos
que varios procesos pueden tener sobre un dispositivo específico.
Al ser creados, los procesos se colocan en la cola de trabajos, formada por los procesos que aún
no residen en la memoria principal, pero listos para su ejecución. La residencia en memoria es
imprescindible para la ejecución de un proceso. La cola de trabajos listos (ready queue) es aquélla
formada por los procesos que están listos para la ejecución, 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 PCB’s, que están
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 próximo 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 proporción de ráfagas 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, tendríamos las colas de dispositivo llenas 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, vacías. Por eso es muy importante de qué manera se realiza
la selección de trabajos para mantener el sistema en equilibrio. Esta selección la realizan los
planificadores o schedulers.

2.3.2. Temporizador de Intervalos o Reloj de Interrupción

El proceso al cual está asignada la CPU se dice que está en ejecución 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 interrupción” o
“temporizador de intervalos” para generar una interrupción, en algún tiempo futuro específico o
después de un transcurso de tiempo en el futuro; la CPU es entonces despachada hacia el
siguiente proceso. En cada interrupción del reloj el Sistema Operativo decide si el proceso que se
está ejecutando continúa 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 interrupción atrae la atención de la CPU.

El reloj de interrupción 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”.

Ing. Jorge Orellana A. 31

 Sistemas Operativos

2.3.3. Niveles de Planificación del Procesador

Se consideran tres niveles importantes de planificación:

• Planificación 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 Planificación
de admisión.
• Planificación 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 efectúa “suspensiones” y “activaciones” (reanudaciones) de procesos. Debe
ayudar a alcanzar ciertas metas en el rendimiento total del sistema.
• Planificación 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 efectúa el Despachador del Sistema Operativo.

Los distintos Sistemas Operativos utilizan varias Políticas de Planificación, que se instrumentan
mediante Mecanismos de Planificación.

2.4. ALGORITMOS DE PLANIFICACIÓN

En entornos diferentes se necesitan algoritmos de planificación diferentes. Esto se debe a que
cada área de aplicación (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.

Ing. Jorge Orellana A. 32

 Sistemas Operativos

En los sistemas en batch, no existen usuarios que estén esperando impacientemente por una
rápida 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 número 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 demás. Incluso aunque
ningún proceso tenga intención de ejecutarse eternamente, es posible que debido a un error en el
programa un proceso mantenga parados a todos los demás indefinidamente. La expulsión es
necesaria para impedir ese comportamiento.
En los sistemas con restricciones de tiempo real, por extraño que parezca, la expulsión 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 rápidamente se bloquean. La diferencia con
los sistemas interactivos es que los sistemas en tiempo real sólo ejecutan programas pensados
como parte de una misma aplicación. Los sistemas interactivos por el contrario son sistemas de
propósito general y pueden ejecutar programas arbitrarios no cooperantes o incluso maliciosos.

2.4.1. Planificación en Sistemas en Batch

2.4.1.1. FCFS (first-come, first-served) Primero en llegar, primero en ser atendido.

Se le asigna la CPU al proceso que la requirió primero. Se maneja a través 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 expropiación, 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 código 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 están LISTOS para ejecutar su siguiente fase de
CPU, cuya duración 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 sólo 3 ms. En
consecuencia, FCFS no asegura para nada que los tiempos de espera sean los mínimos posibles;
peor aún, con un poco de mala suerte pueden llegar a ser los máximos posibles.

Suponiendo que se tiene un proceso intensivo en CPU (CPU bound) y varios procesos intensivos
en E/S (I/O bound). Entonces podría pasar lo siguiente: El proceso intensivo en CPU toma la CPU
por un período largo, suficiente como para que todas las operaciones de E/S pendientes se
completen. En esa situación, todos los procesos están LISTOS, y los dispositivos desocupados.
En algún 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
rápidamente y se va a invertir la situación: todos los procesos van a estar BLOQUEADOS, y la
CPU desocupada. Este fenómeno se conoce como efecto convoy, y se traduce en una baja
utilización 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 vacías).

2.4.1.2. SJF (Shortest-job-first Scheduling). Primero el trabajo más corto.

Este algoritmo elige entre los procesos de la cola de listos, aquel que tenga la próxima ráfaga de
CPU mas corta. Para ello este dato debe ser conocido. Es un algoritmo que permite que el tiempo

Ing. Jorge Orellana A. 33

 Sistemas Operativos

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 próxima ráfaga. Se podría aproximar
considerando el valor de la previa.

Suponiendo que se tiene tres procesos cuyas próximas fases de CPU son de a, b y c milisegundos
de duración. 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 conclusión, el tiempo medio se minimiza si se ejecuta siempre el proceso
con la menor próxima fase de CPU que esté LISTO. Además, 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 duración de la próxima fase de CPU de cada proceso.

2.4.2. Planificación en Sistemas Interactivos

2.4.2.1. Round-Robin Scheduling (RR). Planificación 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 dándole un máximo 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 interrupción.
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 elección 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 pequeño, 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 típico es 100 ms. Una regla que suele
usarse es que el 80% de las fases de CPU deben ser de menor duración que un quantum. Con
respecto a FCFS, se mejora el tiempo de respuesta y la utilización de la CPU, ya que se mantienen
más balanceadas las colas listos (READY) y bloqueadas (BLOCKED). Pero RR tampoco asegura
que los tiempos de espera sean los mínimos 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. Planificación 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, según cada sistema. También lo
determina cada sistema si el número mas bajo es la más alta o la más 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 dinámicamente de manera

Ing. Jorge Orellana A. 34

 Sistemas Operativos

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 y evitar
una situación indeseable llamada starvation (inanición). A la técnica 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 función del uso de los recursos (memoria, archivos
abiertos, tiempos). Si es externa, puede decidirse darle alta prioridad a un proceso de importancia,
a consideración del operador. POSIX (Linux) y Win32 (Windows) proporcionan planificación
basada en prioridades.

Hay muchos criterios para definir la prioridad, por ejemplo:

• Según categoría del usuario.
• Según tipo de proceso: sistema, interactivo, o por lotes; o bien, intensivo en CPU o
intensivo en E/S.
• Según cuanto hayan ocupado la CPU hasta el momento
• Para evitar que un proceso de baja prioridad sea postergado en demasía, aumentar
prioridad mientras más tiempo lleve esperando: envejecimiento (aging).
• Para evitar que un proceso de alta prioridad ejecute por demasiado tiempo, se le puede ir
bajando la prioridad.

Parámetro Linux Windows

Clases de planificación 3 2
1. Prioridades normales (dinámicas) 40; de -20 a 19 15; de 1 a 15
2. Prioridades de tiempo real FCFS (fijas) 100; de 0 a 99 16; de 16 a 31
3. Prioridades de tiempo real con rodaja (fijas) 100; de 0 a 99 --
Orden de importancia de la prioridad Baja®Alta Alta®Baja

2.4.2.3. Colas multinivel (Múltiples 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 más la cosa, se puede agrupar los procesos en distintas clases, y usar distintos
algoritmos de planificación intra-clase, más algún 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 según FCFS, teniendo los primeros prioridad absoluta sobre los segundos.

Existen algoritmos que contemplan esta situación dividiendo la cola de listos (ready) en distintas
colas según 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.

Ing. Jorge Orellana A. 35

 Sistemas Operativos

Cada cola usa su propio algoritmo de planificación, pero se necesita un algoritmo de planificación
entre las colas. Una posibilidad es prioridad absoluta con expropiación. 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 según FCFS,
y a las otras el resto.
Por otra parte, se podría 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 retroalimentación, un proceso puede “moverse” entre colas, es decir, según
convenga puede llegar a asignarse a otra cola. Los procesos se separan de acuerdo a la ráfaga
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 además un proceso estuvo demasiado tiempo en una cola de baja prioridad puede moverse a
una cola de mayor prioridad para prevenir inanición (starvation).

2.4.3. Planificación apropiativa, expropiativa o expulsiva (Preemptive Scheduling)

Hay que considerar en el esquema de planificación en que momento se realiza la selección. 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 decisión del sistema operativo. Esta decisión 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 algún 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 modificándolos al ser interrumpido. En Unix,
por ejemplo se espera que se termine de ejecutar el system call para permitir apropiación.

La apropiación se aplica en los diferentes algoritmos de la siguiente manera:

• 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.

Ing. Jorge Orellana A. 36

 Sistemas Operativos

• SJF puede ser apropiativo o no. Si mientras se esta ejecutando un proceso llega uno cuya
próxima ráfaga de CPU es mas corta que lo que queda de ejecutar del activo, puede existir
la decisión de interrumpir el que se esta ejecutando o no. Al SJF apropiativo, se le llama
shortest-remaining-time-first. (primero el de tiempo restante más 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 decisión 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 interrupción para
asignarla la CPU a otro proceso.

2.5. PLANIFICACIÓN EN WINDOWS (Win32) Y LINUX (POSIX)

El kernel de Windows está diseñado utilizando Programación Orientada a Objetos. Posee una
capa de abstracción de hardware (HAL), la cual es la única que se comunica directamente con el
procesador; el resto del kernel está diseñado para utilizar la interfaz de la HAL. La unidad mínima
de ejecución no es el proceso sino el hilo. Un hilo puede estar en alguno de estos seis estados:
listo, standby (siguiente a ejecutar), en ejecución, en espera, en transición (un nuevo hilo) y
terminado.

Windows utiliza una planificación basada en colas múltiples 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 Round Robin, aun así, si un hilo de mayor prioridad llega, el procesador le es
asignado a éste. La prioridades más altas son favorecidas. La prioridades de un thread no pueden
ser reducidas.

Los procesos en Linux pueden ser divididos en tres categorías, relacionadas con la prioridad:
interactivos, por lotes y de tiempo real. Los procesos en Tiempo Real son manejados bien por un
algoritmo FIFO o Round Robin. Los demás procesos son despachados utilizando planificación
Round Robin con un sistema de envejecimiento basado en créditos, donde el siguiente proceso a
ejecutar es aquel que más créditos posea. Los procesos en Tiempo Real son considerados
prioritarios sobre cualquier otro proceso en el sistema, por lo que serán ejecutados antes que los
demás. 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 planificación
(FIFO,RR) por medio del campo policy, la prioridad (priority), el contador del programa
(counter), entre otros.
• La función goodness otorga una “calificación” al proceso pasado como parámetro. Dicha
puntuación oscila entre -1000 (no elegible) y +1000 (TR). Los procesos que comparten una
zona de memoria ganan una puntuación equivalente a su prioridad.
• El quantum varía según el proceso y su prioridad. La duración base es de aprox. 200ms.
• La función switch_to es la encargada de salvar la información de un proceso y cargar el
siguiente.
• Las funciones sched_{get/set}scheduler se refieren al mecanismo de planificación 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 función execve.
• Las prioridades bajas son favorecidas. La mayoría de los procesos usan políticas de prioridad
dinámica. El valor “nice” establece la prioridad base de un proceso. Los valores de nice van
desde -20 a +20 (más grande = menor prioridad). Los usuarios no privilegiados sólo pueden
especificar valores de nice positivos. Los procesos normales se ejecutan sólo cuando no
quedan procesos de tiempo real (de prioridad fija) en la cola de listos.

Ing. Jorge Orellana A. 37