Sistemas Operativos

Ing. Jorge Orellana A.

13
Tema II
GESTIN DE PROCESOS

2.1. PROCESO.
Todos los computadores pueden hacer varias cosas a la vez, mientras est ejecutando un
programa de usuario puede perfectamente tambin estar leyendo de un disco e imprimiendo
texto en una pantalla o una impresora. En un sistema multiprogramado la CPU (Unidad Central
de Proceso) tambin conmuta de unos programas a otros, ejecutando cada uno de ellos durante
decenas o cientos de milisegundos. Aunque, estrictamente hablando, en cualquier instante de
tiempo la CPU slo est ejecutando un programa, en el transcurso de 1 segundo ha podido estar
trabajando sobre varios programas, dando entonces a los usuarios la impresin de un cierto
paralelismo (pseudoparalelismo), en contraste con el autntico paralelismo del hardware de los
sistemas multiprocesador (que tienen dos o ms CPUs compartiendo la misma memoria fsica).
Seguir la pista de mltiples actividades paralelas resulta muy complicado, por ese motivo los
diseadores de los sistemas operativos han desarrollado un modelo conceptual evolucionado (el
de los procesos secuenciales) que permite tratar el paralelismo de una forma ms fcil.
En este modelo, todo el software ejecutable en el ordenador, incluyendo a veces al propio
sistema operativo, se organiza en un nmero de procesos secuenciales, o simplemente
procesos. Un proceso es justamente un programa en ejecucin, incluyendo los valores actuales
del contador de programa, registros y variables. Conceptualmente cada proceso tiene su propia
CPU virtual. En realidad, la CPU real conmuta sucesivamente de un proceso a otro. Esta rpida
conmutacin de un proceso a otro en algn orden se denomina multiprogramacin.
Debe hacerse una distincin entre un programa y un proceso. Un programa es una entidad
estatica constituida por sentencias de programa que definen la conducta del proceso cuando se
ejecutan utilizando un conjunto de datos. Un proceso es una entidad dinmica que ejecuta un
programa sobre un conjunto de datos utilizando los recursos del sistema operativo. Dos o mas
procesos podran estar ejecutando el mismo programa, empleando sus propios datos y recursos,
por ejemplo, si dos o ms usuarios estn usando simultneamente el mismo editor de texto. El
programa es el mismo, pero cada usuario tiene un proceso distinto (y con distintos datos).

Por analoga al preparar una receta de una torta. El programa es la receta, el proceso es la
actividad que consiste en leer la receta, mezclar los ingredientes y hornear la torta.

2.1.1. Creacin de Procesos
Los sistemas operativos necesitan asegurar de alguna forma que puedan existir todos los
procesos requeridos, entonces es necesaria alguna manera de poder crear y destruir los
procesos segn sea necesario durante la operacin del sistema. Los cuatro principales sucesos
que provocan la creacin de nuevos procesos son:
La inicializacin del sistema
La ejecucin por parte de un proceso (en ejecucin) de una llamada al sistema de creacin
de un nuevo proceso.
La peticin por parte del usuario de la creacin de un nuevo proceso.
El inicio de un trabajo en batch (lotes).

Cuando un sistema operativo arranca, se crean tpicamente varios procesos. Algunos de esos
procesos son procesos foreground (en primer plano), esto es, procesos que interactan con los
usuarios y realizan trabajo para ellos. Otros son procesos background (en segundo plano), que
no estn asociados con usuarios particulares, sino que tienen alguna funcin especfica. Los
procesos que se ejecutan como procesos background para llevar a cabo alguna actividad tal
como el correo electrnico, las pginas web, las news o la impresin de ficheros de salida, etc,
se denominan demonios en Unix o servicios en Windows. Los sistemas grandes tienen
comnmente docenas de ellos. En UNIX, el programa ps puede utilizarse para listar los procesos
que estn en marcha. En Windows se utiliza el administrador de tareas.
Sistemas Operativos
Ing. Jorge Orellana A.
14
Adicionalmente a los procesos creados en el momento del arranque, tambin pueden crearse
nuevos procesos despus. A menudo un proceso en ejecucin puede hacer llamadas al sistema
para crear uno o ms procesos nuevos para que le ayuden en su trabajo.
En sistemas interactivos los usuarios pueden arrancar un programa tecleando un comando o
haciendo clic (dos veces) con el ratn sobre un icono. Realizando cualquiera de esas acciones
se consigue que comience un nuevo proceso y se ejecute el programa correspondiente. En
sistemas UNIX basados en comandos y ejecutando X-Windows, el nuevo proceso creado se
ejecuta sobre la ventana en la cual se le activ. En Windows, cuando un proceso comienza no
tiene ninguna ventana asignada, aunque puede crear una o ms. En ambos sistemas, los
usuarios pueden tener mltiples ventanas abiertas a la vez, cada una de ellas ejecutando algn
proceso. Utilizando el ratn, el usuario puede seleccionar una ventana e interactuar con el
proceso, por ejemplo, proporcionando datos de entrada cuando sean necesarios.
La ltima situacin que provoca la creacin de procesos se aplica slo a los sistemas en batch
que podemos encontrar en los grandes mainframes. En esos sistemas los usuarios pueden
lanzar (submit) al sistema trabajos en batch (posiblemente de forma remota). Cuando el sistema
operativo detecta que dispone de todos los recursos necesarios para poder ejecutar otro trabajo,
crea un nuevo proceso y ejecuta sobre l el siguiente trabajo que haya en la cola de entrada.

En UNIX slo existe una llamada al sistema para crear un nuevo proceso: fork. Esta llamada
crea un clon (una copia exacta) del proceso que hizo la llamada. Despus del fork, los dos
procesos, el padre y el hijo, tienen la misma imagen de memoria, las mismas variables de
entorno y los mismos ficheros abiertos. Eso es todo lo que hay. Usualmente, a continuacin el
proceso hijo ejecuta execve o una llamada al sistema similar para cambiar su imagen de
memoria y pasar a ejecutar un nuevo programa. En Windows, una nica llamada al sistema de
Win32, CreateProcess, realiza tanto la creacin del proceso como la carga del programa
correcto dentro del nuevo proceso. Tanto en UNIX como en Windows, despus de crear un
proceso, tanto el padre como el hijo cuentan con sus propios espacios de direcciones disjuntos.

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



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

Nuevo (new).
Ejecutndose (running). El proceso est siendo ejecutado en la CPU. Por lo tanto a lo
ms un proceso puede estar en este estado en un computador uniprocesador.
Listo para ejecutar (ready). El proceso est en condiciones de ejecutarse, pero debe
esperar su turno de CPU.
Bloqueado o En espera (waiting) El proceso no est en condiciones de ejecutarse.
Est esperando que algn evento ocurra, como la finalizacin de una operacin de E/S.
Tambin se dice que est suspendido o en espera.
Terminado (terminated)

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



2.1.4. Implementacin de procesos
El sistema operativo mantiene para cada proceso un bloque de control de proceso o process
control block (PCB), donde se guarda para cada proceso la informacin necesaria para
reanudarlo si es suspendido, y otros datos.
Estado: Puede ser nuevo, listo, en ejecucin, en espera, detenido, etctera
Contador de programa: El contador indica la direccin de la siguiente instruccin que se
ejecutar para este proceso.
Registros de CPU: El nmero y el tipo de los registros vara dependiendo de la arquitectura
del computador. Los registros incluyen acumuladores, registros ndice, punteros de pila y
registros de propsito general, as como cualquier informacin de cdigos de condicin que
haya. Junto con el contador de programa, esta informacin de estado se debe guardar
cuando ocurre una interrupcin, para que el proceso pueda continuar correctamente
despus.
Informacin para planificacin: Esta informacin incluye una prioridad del proceso, punteros
a colas de planificacin y cualquier otro parmetro de planificacin que haya.
Informacin para administracin de memoria: Esta informacin puede incluir datos tales
como el valor de los registros de base y lmite, las tablas de pginas o las tablas de
segmentos, dependiendo del sistema de memoria empleado por el sistema operativo.
Sistemas Operativos
Ing. Jorge Orellana A.
16
Informacin de estado de E/S: La informacin incluye la lista de dispositivos de E/S
asignadas a este proceso, una lista de archivos abiertos, etctera.
Estadsticas y otros: tiempo real y tiempo de CPU usado, identificador del proceso,
identificador del dueo, tiempo real consumido, lmites de tiempo, nmeros de cuenta,
nmeros de trabajo o proceso, y dems.
















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


2.1.5. Cambios de contexto (context switch)
Cuando el sistema operativo entrega la CPU a un nuevo proceso, debe guardar el estado del
proceso que estaba ejecutando, y cargar el estado del nuevo proceso. El estado de un proceso
comprende el PC (Contador del programa), y los registros de la CPU. Adems, si se usan las
tcnicas de administracin de memoria que veremos ms adelante, hay ms informacin
involucrada. Este cambio, que demora de unos pocos a mil microsegundos, dependiendo del
procesador, es puro overhead o sobrecosto, puesto que entretanto la CPU no hace trabajo til
(ningn proceso avanza). Considerando que la CPU hace varios cambios de contexto en un
segundo, su costo es relativamente alto.
Algunos procesadores tienen instrucciones especiales para guardar todos los registros de una
vez. Otros tienen varios conjuntos de registros, de manera que un cambio de contexto se hace
simplemente cambiando el puntero al conjunto actual de registros. El problema es que si hay
ms procesos que conjuntos de registros, igual hay que apoyarse en la memoria. Por ser un
cuello de botella tan importante para el desempeo del sistema operativo se emplean estructuras
nuevas (hilos) para evitarla hasta donde sea posible.

2.1.6. Jerarquia de procesos
La secuencia de creacin de procesos genera un rbol de procesos. Para referirse a las
relaciones entre los procesos de la jerarqua se emplean los trminos de padre, hermano o
abuelo. Cuando el proceso A solicita al sistema operativo que cree el proceso B, se dice que A
Sistemas Operativos
Ing. Jorge Orellana A.
17
es padre de B y que B es hijo de A. Bajo esta ptica, la jerarqua de procesos puede
considerarse como un rbol genealgico. Algunos sistemas operativos, como Unix, mantienen de
forma explcita esta estructura jerrquica de procesos (un proceso sabe quin es su padre),
mientras que otros sistemas operativos como el Windows NT no la mantienen.

Por ejemplo, en Unix, cuando se carga el sistema operativo, se inicializa un proceso init. Este
proceso lee un archivo que dice cuntos terminales hay, y crea un proceso login para cada
terminal, que se encarga de solicitar nombre y contrasea. Cuando un usuario entra, login
determina qu shell le corresponde al usuario, y crea otro proceso para ejecutar esa shell. A su
vez, la shell crea ms procesos segn los comandos que ejecute el usuario, generndose as
todo un rbol de procesos: cada proceso tiene cero o ms hijos, y exactamente un padre (salvo
init, que no tiene padre). Haciendo una analogia en Windows, aun cuando este sistema operativo
no mantiene esta jerarquia y todos son iguales, unos de los primeros procesos seria System,
luego Winlogon para crear una sesion y sobre ella crea su shell que es el Explorer, en el cual
se ejecutaran todos los demas programas como hijos de este proceso.

2.2. PROCESOS LIVIANOS, HILOS, HEBRAS O THREADS
En los sistemas operativos tradicionales, cada proceso tiene su propio espacio de direcciones y
un nico flujo (hilo) de control. Sin embargo, frecuentemente hay situaciones en las que es
deseable contar con mltiples hilos de control (threads) en el mismo espacio de direcciones
ejecutndose quasi-paralelamente, como si fueran procesos separados (excepto que comparten
el mismo espacio de direcciones).
Una hebra (thread, hilo o proceso liviano) es un hilo de control dentro de un proceso. Un proceso
tradicional tiene slo una hebra de control. Si usamos threads, entonces podemos tener varias
hebras dentro de un proceso. Cada hebra representa una actividad o unidad de computacin
dentro del proceso, es decir, tiene su propio PC, conjunto de registros y stack, pero comparte
con las dems hebras el espacio de direccionamiento y los recursos asignados, como archivos
abiertos y otros.










En muchos aspectos los procesos livianos son similares a los procesos pesados, comparten el
tiempo de CPU, y a lo ms un thread est activo (ejecutando) a la vez, en un monoprocesador.
Los otros pueden estar listos o bloqueados. Pero los procesos pesados son independientes, y el
sistema operativo debe proteger a unos de otros, lo que acarrea algunos costos. Los procesos
livianos dentro de un mismo proceso pesado no son independientes, cualquiera puede acceder a
Sistemas Operativos
Ing. Jorge Orellana A.
18
toda la memoria correspondiente al proceso pesado. En ese sentido, no hay proteccin entre
threads, nada impide que un thread pueda escribir, por ejemplo, sobre el stack de otro.









2.2.1. Comparando hebras con procesos
El cambio de contexto entre hebras de un mismo proceso es mucho ms barato que el
cambio de contexto entre procesos; gracias a que comparten el espacio de
direccionamiento, un cambio de contexto entre threads no incluye los registros y tablas
asociados a la administracin de memoria.
La creacin de threads tambin es mucho ms barata, ya que la informacin que se requiere
para mantener un thread es mucho menos que un PCB. La mayor parte de la informacin del
PCB se comparte entre todos los threads del proceso.
El espacio de direccionamiento compartido facilita la comunicacin entre las hebras y el
compartimiento de recursos.


2.2.2. Implementacin de hebras
Hay libreras de hebras que permiten implementar hebras dentro de procesos normales o
pesados sin apoyo del sistema operativo. La planificacin y manejo de las hebras se hace dentro
del proceso. El sistema operativo no tiene idea de las hebras; slo ve y maneja un proceso como
cualquier otro.
La alternativa es que el propio sistema operativo provea servicios de hebras; as como se
pueden crear procesos, se pueden tambin crear nuevas hebras dentro de un proceso, y stos
son administrados por el sistema operativo.
La ventaja del primer esquema respecto del segundo, es que los cambios de contexto entre
hebras de un mismo proceso son extremadamente rpidos, porque ni siquiera hay una llamada
al sistema de por medio. La desventaja es que si una de las hebras hace una llamada
bloqueante (Ej., solicita E/S), el sistema operativo bloquea todo el proceso, an cuando haya
otras hebras listos para ejecutar.

En el caso de sistemas operativos de servidores, cada hebra puede manejar una solicitud. El
diseo es ms sencillo y este esquema mejora la productividad, porque mientras unos hilos
esperan, otros pueden hacer trabajo til. Por ejemplo servidor de archivos, que recibe solicitudes
para leer y escribir archivos en un disco. Para mejorar el rendimiento, el servidor mantiene un
Sistemas Operativos
Ing. Jorge Orellana A.
19
cach con los datos ms recientemente usados, en la eventualidad que reciba algn
requerimiento para leer esos datos, no es necesario acceder el disco.
Cuando se recibe una solicitud, se le asigna a un thread para que la atienda. Si ese thread se
bloquea porque tuvo que acceder el disco, otros threads pueden seguir atendiendo otras
solicitudes. La clave es que el buffer debe ser compartido por todos los threads, lo que no podra
hacerse si se usa un proceso pesado para cada solicitud. POSIX (Linux) especifica una serie de
polticas de planificacin, aplicables a procesos y procesos ligeros, que debe implementar
cualquier sistema operativo que ofrezca esta interfaz. En Windows la unidad bsica de ejecucin
es el proceso ligero y, por tanto, la planificacin se realiza sobre este tipo de procesos.

2.3. PLANIFICACIN (SCHEDULING) DE PROCESOS
En un ambiente de multiprogramacin es frecuente que en un momento dado haya mltiples
procesos compitiendo por el uso de la CPU al mismo tiempo. Esta situacin se da siempre que
dos o ms procesos estn simultnemente en el estado preparado. Si slo hay una CPU
disponible, es necesario hacer una eleccin para determinar cual de esos procesos ser el
siguiente que se ejecute. La parte del sistema operativo que realiza esa eleccin se denomina el
planificador (scheduler), y el algoritmo que se utiliza para esa eleccin se denomina el algoritmo
de planificacin.
Existen diferentes algoritmos de planificacin que deben cumplir con criterios basicos, como:

Maximizar el uso de la CPU (que se mantenga ocupada el mayor tiempo posible).
Maximizar la Productividad (throughput), considerando que productividad (o rendimiento) es
el nmero de procesos que se ejecutan por unidad de tiempo.
Minimizar el Tiempo de retorno (turn around time), que es el tiempo transcurrido desde que
el proceso ingresa hasta que termina, sumando espera para entrar en memoria, en cola de
procesos listos, ejecutndose en CPU y haciendo E/S.
Minimizar el Tiempo de espera (waiting time), que es el tiempo que el proceso est en la cola
de listos.
Minimizar el Tiempo de respuesta (response time), que es el tiempo que transcurre desde
que se presenta una solicitud hasta que se tiene respuesta. Es el tiempo que tarda en
comenzar a responder, no incluyendo el tiempo de la respuesta en s.
La equidad (Justicia), que todos los procesos tienen que ser tratados de igual forma y a
todos se les debe dar la oportunidad de ejecutarse.
Recursos equilibrados, que la poltica de planificacin que se elija debe mantener ocupados
los recursos del sistema, favoreciendo a aquellos procesos que no abusen de los recursos
asignados, sobrecargando el sistema y bajando la performance general.

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

2.3.1. Procesos orientados a la E/S y procesos orientados a la CPU
En un sistema hay procesos con mayor proporcin de rfagas E/S (I/O bound process) y otros
con mayor necesidad de CPU que de E/S (CPU bound process). Si cuando se seleccionan
procesos para ejecutar se eligieran todos I/O bound, tendramos las colas de dispositivo llenas
Sistemas Operativos
Ing. Jorge Orellana A.
20
de solicitudes y, probablemente, la CPU ociosa. Si se eligen muchos procesos limitados por CPU
la cola de listos estar llena y las colas de dispositivo, vacas. Por eso es muy importante de qu
manera se realiza la seleccin de trabajos para mantener el sistema en equilibrio. Esta seleccin
la realizan los planificadores o schedulers.



El planificador (scheduler) forma parte del ncleo del sistema operativo. Entra en ejecucin cada
vez que se activa el sistema operativo y su misin es seleccionar el proceso que se ha de
ejecutar a continuacin.

El activador (dispatcher) tambin forma parte del sistema operativo y su funcin es poner en
ejecucin el proceso seleccionado por el planificador. Debe ser muy rpido pues una de sus
funciones es encargarse del cambio de contexto (context switch). Al tiempo entre detener un
proceso y comenzar a correr otro se le llama dispatch latency.
El dispatcher es tambin el que se encarga de pasar a modo usuario el proceso que esta
activando y saltar a la direccin de la instruccin que comienza la ejecucin del programa.

2.3.2. Temporizador de Intervalos o Reloj de Interrupcin
El proceso al cual est asignada la CPU se dice que est en ejecucin y puede ser un proceso
de Sistema Operativo o de usuario.
El Sistema Operativo dispone de mecanismos para quitarle la CPU a un proceso de usuario para
evitar que monopolice el sistema. El Sistema Operativo posee un reloj de interrupcin o
temporizador de intervalos para generar una interrupcin, en algn tiempo futuro especfico o
despus de un transcurso de tiempo en el futuro; la CPU es entonces despachada hacia el
siguiente proceso. En cada interrupcin del reloj el Sistema Operativo decide si el proceso que
se est ejecutando contina o si el proceso agot su tiempo de CPU y debe suspenderse y ceder
la CPU a otro proceso.

Un proceso retiene el control de la CPU hasta que ocurra alguna de las siguientes situaciones:
La libera voluntariamente.
El reloj la interrumpe.
Alguna otra interrupcin atrae la atencin de la CPU.

El reloj de interrupcin ayuda a garantizar tiempos de respuesta razonables a usuarios
interactivos, ya que evita que el sistema se cuelgue a un solo usuario en un ciclo infinito y
permite que los procesos respondan a eventos dependientes del tiempo.

2.3.3. Niveles de Planificacin del Procesador
Se consideran tres niveles importantes de planificacin:

Planificacin de alto nivel (largo plazo o long term). Determina a qu trabajos se les va a
permitir competir activamente por los recursos del sistema, lo cual se denomina Planificacin
de admisin.
Sistemas Operativos
Ing. Jorge Orellana A.
21
Planificacin de nivel intermedio (mediano plazo o medium term). Determina a qu procesos
se les puede permitir competir por la CPU. Responde a fluctuaciones a corto plazo en la
carga del sistema y efecta suspensiones y activaciones (reanudaciones) de procesos.
Debe ayudar a alcanzar ciertas metas en el rendimiento total del sistema.
Planificacin de bajo nivel (corto plazo o short term). Determina a qu proceso listo se le
asigna la CPU cuando esta queda disponible y asigna la CPU al mismo, es decir que
despacha la CPU al proceso. La efecta el Despachador del Sistema Operativo.

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



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

Batch (lotes)
Interactivo
Tiempo Real.

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

2.4.1. Planificacin en Sistemas en Batch

2.4.1.1. FCFS (first-come, first-served) Primero en llegar, primero en ser atendido.
Sistemas Operativos
Ing. Jorge Orellana A.
22
Se le asigna la CPU al proceso que la requiri primero. Se maneja a travs de una cola FIFO
(First In First Out), y cuando un proceso requiere CPU, su PCB se coloca la final de la cola.
Cuando se debe elegir un proceso para asignarle CPU se elige el proceso cuya PCB esta
primera en la cola.

Es un algoritmo que no usa expropiacin, y atiende a los procesos por estricto orden de llegada
a la cola de listos (READY). Cada proceso se ejecuta hasta que termina, o hasta que hace una
llamada bloqueante (de E/S), o sea, ejecuta su fase de CPU completa. El cdigo para
implementar este algoritmo es simple y comprensible. Pero el tiempo promedio de espera puede
ser largo.


Considerando que los procesos P1, P2 y P3 estn LISTOS para ejecutar su siguiente fase de
CPU, cuya duracin ser de 24, 3 y 3 milisegundos, respectivamente. Si ejecutan en el orden P1,
P2, P3, entonces los tiempos de espera son: 0 para P1, 24 para P2 y 27 para P3, o sea, en
promedio, 17 ms. Pero si se ejecutan en orden P2, P3, P1, entonces el promedio es slo 3 ms.
En consecuencia, FCFS no asegura para nada que los tiempos de espera sean los mnimos
posibles; peor an, con un poco de mala suerte pueden llegar a ser los mximos posibles.

Suponiendo que se tiene un proceso intensivo en CPU (CPU bound) y varios procesos intensivos
en E/S (I/O bound). Entonces podra pasar lo siguiente: El proceso intensivo en CPU toma la
CPU por un perodo largo, suficiente como para que todas las operaciones de E/S pendientes se
completen. En esa situacin, todos los procesos estn LISTOS, y los dispositivos desocupados.
En algn momento, el proceso intensivo en CPU va a solicitar E/S y va a liberar la CPU.
Entonces van a ejecutar los otros procesos, pero como son intensivos en E/S, van a liberar la
CPU muy rpidamente y se va a invertir la situacin: todos los procesos van a estar
BLOQUEADOS, y la CPU desocupada. Este fenmeno se conoce como efecto convoy, y se
traduce en una baja utilizacin tanto de la CPU como de los dispositivos de E/S. Obviamente, el
rendimiento mejora si se mantienen ocupados la CPU y los dispositivos (o sea, conviene que no
haya colas vacas).

2.4.1.2. SJF (Shortest-job-first Scheduling). Primero el trabajo ms corto.
Este algoritmo elige entre los procesos de la cola de listos, aquel que tenga la prxima rfaga de
CPU mas corta. Para ello este dato debe ser conocido. Es un algoritmo que permite que el
tiempo de espera promedio sea bajo. Se puede utilizar en planificadores de largo plazo, pero no
en los de corto plazo pues no hay manera de conocer la medida de la prxima rfaga. Se podra
aproximar considerando el valor de la previa.

Suponiendo que se tiene tres procesos cuyas prximas fases de CPU son de a, b y c
milisegundos de duracin. Si ejecutan en ese orden, el tiempo medio de espera es:

(0 + a + (a + b))/3 = (2a+b)/3

El primer proceso que se ejecute es el que tiene mayor incidencia en el tiempo medio, y el
ltimo, tiene incidencia nula. En conclusin, el tiempo medio se minimiza si se ejecuta siempre el
proceso con la menor prxima fase de CPU que est LISTO. Adems, es una buena manera de
prevenir el efecto convoy. Lo malo es que para que esto funcione, hay que adivinar el futuro,
pues se requiere conocer la duracin de la prxima fase de CPU de cada proceso.
Lo que se hace es predecir la prxima fase de CPU en base al comportamiento pasado del
proceso, usando un promedio exponencial. Suponiendo que la prediccin para la n-sima fase
es T
n
, entonces, se actualiza el estimador para predecir T
n+1

Sistemas Operativos
Ing. Jorge Orellana A.
23

T
n+1
= (1-alpha) T
n
+ alpha T
n


El parmetro alpha, entre 0 y 1, controla el peso relativo de la ltima fase en relacin a la historia
pasada.

T
n+1
= (1-alpha) T
n
+ alpha(1-alpha) T
n-1
+ ... + alpha
j
(1-alpha) T
n-j
+ ... + alpha
n+1
T
0


Mientras ms antigua la fase menos incidencia tiene en el estimador. Un valor atractivo para
alpha es 1/2, ya que en ese caso slo hay que sumar los valores y dividir por dos.

2.4.2. Planificacin en Sistemas Interactivos

2.4.2.1. Round-Robin Scheduling (RR). Planificacin por turno circular o Carrousel.
Se la asigna a cada proceso de la cola de listos un intervalo de tiempo de CPU. Ese intervalo es
llamado time slice o quantum. Para implementar este algoritmo la cola de listos se mantiene
como una cola FIFO, y la CPU se va asignando dndole un mximo de un quantum a cada
proceso.
Si el proceso no va a usar todo ese tiempo, usa lo necesario y libera la CPU. Se elige entonces
otro proceso de la cola. Si excede el quantum, se produce una interrupcin.
En ambos casos al dejar la CPU hay un cambio de contexto. El tiempo promedio de espera
puede ser largo. Su performance depende fuertemente de la eleccin del quantum. Y el tiempo
gastado en el cambio de contexto es una variable que se debe tener muy en cuenta. Se debe
determinar un quantum que sea mucho mayor que el tiempo de cambio de contexto. Se utiliza en
los sistemas de tiempo compartido (time-sharing). El punto interesante es encontrar el quantum
adecuado. Si es muy grande, se degenera en FCFS, pero tampoco puede ser demasiado
pequeo, porque entonces el costo en cambios de contexto es preponderante.

Por ejemplo, si un cambio de contexto toma 5 ms, y se fija el quantum en 20 ms, entonces 20%
del tiempo de la CPU se perder en sobrecosto. Un valor tpico es 100 ms. Una regla que suele
usarse es que el 80% de las fases de CPU deben ser de menor duracin que un quantum. Con
respecto a FCFS, se mejora el tiempo de respuesta y la utilizacin de la CPU, ya que se
mantienen ms balanceadas las colas listos (READY) y bloqueadas (BLOCKED). Pero RR
tampoco asegura que los tiempos de espera sean los mnimos posibles. Usando el mismo
ejemplo anterior, y considerando un quantum de 4ms, pero sin considerar costos de cambio de
contexto, si el orden es P1, P2, P3 entonces el tiempo medio de espera es 5.66ms (P1 espera
6ms, P2 espera 4ms. y P3 espera 7ms.)




2.4.2.2. Planificacin por prioridad
Se le asocia un valor a cada proceso que representa la prioridad, y se le asigna la CPU al
proceso de la cola de listos (ready) que tenga la mayor prioridad.
Los valores asociados a la prioridad son un rango fijo de 0 a N, segn cada sistema. Tambin lo
determina cada sistema si el nmero mas bajo es la ms alta o la ms baja prioridad.
La prioridad puede ser fija o variable, externa o interna. Si es fija, ese valor no varia en el ciclo de
vida del proceso. Si es variable, significa que ese valor puede cambiar dinmicamente de
manera tal que haya factores, por ejemplo, el tiempo que lleva esperando en colas, que puedan
ayudar a que haya un mejor nivel de competencia elevando la prioridad de procesos postergados
Sistemas Operativos
Ing. Jorge Orellana A.
24
y evitar una situacin indeseable llamada starvation (inanicin). A la tcnica de elevar la prioridad
a un proceso de acuerdo al tiempo que hace que esta en el sistema se le llama envejecimiento
(aging).
Si la prioridad es interna, es determinada en funcin del uso de los recursos (memoria, archivos
abiertos, tiempos). Si es externa, puede decidirse darle alta prioridad a un proceso de
importancia, a consideracin del operador. POSIX (Linux) y Win32 (Windows) proporcionan
planificacin basada en prioridades.

Hay muchos criterios para definir la prioridad, por ejemplo:
Segn categora del usuario.
Segn tipo de proceso: sistema, interactivo, o por lotes; o bien, intensivo en CPU o
intensivo en E/S.
Segn cuanto hayan ocupado la CPU hasta el momento
Para evitar que un proceso de baja prioridad sea postergado en demasa, aumentar
prioridad mientras ms tiempo lleve esperando: envejecimiento (aging).
Para evitar que un proceso de alta prioridad ejecute por demasiado tiempo, se le puede
ir bajando la prioridad.

2.4.2.3. Colas multinivel (Mltiples colas)
En un sistema conviven procesos mixtos. Puede haber requerimientos de tiempo de respuesta
distintos si conviven procesos interactivos con procesos batch (o para aquellos que provienen del
Unix, procesos en foreground y procesos en background).
Para complicar ms la cosa, se puede agrupar los procesos en distintas clases, y usar distintos
algoritmos de planificacin intra-clase, ms algn algoritmo inter-clases. Por ejemplo, los
procesos interactivos y los procesos por lotes tienen distintos requerimientos en cuanto a
tiempos de respuesta. Entonces, se puede planificar los procesos interactivos usando RR, y los
procesos por lotes segn FCFS, teniendo los primeros prioridad absoluta sobre los segundos.

Existen algoritmos que contemplan esta situacin dividiendo la cola de listos (ready) en distintas
colas segn el tipo de proceso, estableciendo una competencia entre las colas y entre los
procesos del mismo tipo entre si. Por ejemplo, se puede tener una cola para
Procesos de sistema.
Procesos interactivos.
Procesos de los alumnos.
Procesos por lotes.

Cada cola usa su propio algoritmo de planificacin, pero se necesita un algoritmo de planificacin
entre las colas. Una posibilidad es prioridad absoluta con expropiacin. Otra posibilidad: asignar
tajadas de CPU a las colas. Por ejemplo, a la cola del sistema se le puede dar el 60% de la CPU
para que haga RR, a la de procesos por lotes el 5% para que asigne a sus procesos segn
FCFS, y a las otras el resto.
Sistemas Operativos
Ing. Jorge Orellana A.
25
Por otra parte, se podra hacer que los procesos migren de una cola a otra. Por ejemplo: varias
colas planificadas con RR, de prioridad decreciente y quantum creciente. La ltima se planifica
con FCFS. Un proceso en la cola i que no termina su fase de CPU dentro del quantum asignado,
se pasa al final de la siguiente cola de menor prioridad, pero con mayor quantum. Un proceso en
la cola i que s termina su fase de CPU dentro del quantum asignado, se pasa al final de la
siguiente cola de mayor prioridad, pero con menor quantum. Ejemplo:

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

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




2.4.3. Planificacin en Sistemas de Tiempo Real
Un sistema de tiempo real es uno en el cual el tiempo juega un papel esencial. Tpicamente, se
tiene uno o ms dispositivos fsicos externos al ordenador que generan estmulos a los cuales
debe reaccionar el ordenador de la manera apropiada y dentro de un plazo de tiempo prefijado.
Por ejemplo, el computador interno de un reproductor de discos compactos recibe los bits tal y
como salen de la unidad y debe convertirlos en msica en un intervalo de tiempo muy ajustado.
Si el clculo tarda demasiado, la msica sonar rara. Otros sistemas en tiempo real monitorizan
pacientes en la unidad de cuidados intensivos de un hospital, controlan el piloto automtico de
Sistemas Operativos
Ing. Jorge Orellana A.
26
un avin y controlan los robots en una fbrica automatizada. En todos estos casos, producir la
respuesta correcta demasiado tarde es a menudo tan malo como no producir ninguna respuesta.
Los sistemas en tiempo real se clasifican generalmente en sistemas de tiempo real estricto (hard
real time) y sistemas de tiempo real moderado (soft real time). En los sistemas de tiempo real
estricto hay plazos absolutos que deben cumplirse, pase lo que pase. En los sistemas de tiempo
real moderado el incumplimiento ocasional de un plazo aunque es indeseable, es sin embargo
tolerable. En ambos casos, el comportamiento en tiempo real se logra dividiendo el programa en
varios procesos cuyo comportamiento es predecible y conocido por adelantado. Generalmente,
tales procesos son cortos y pueden terminar su trabajo en mucho menos de un segundo.
Cuando se detecta un suceso externo, el planificador debe planificar los procesos de tal modo
que se cumplan todos los plazos.
Los algoritmos de planificacin para tiempo real pueden ser estticos o dinmicos. Los primeros
toman sus decisiones de planificacin antes de que el sistema comience a ejecutarse. Los
segundos toman las decisiones en tiempo de ejecucin. La planificacin esttica slo funciona si
se est perfectamente informado por anticipado sobre el trabajo que debe realizarse y los plazos
que deben cumplirse. Los algoritmos de planificacin dinmica no tienen estas restricciones.

2.4.4. Planificacin apropiativa, expropiativa o expulsiva (Preemptive Scheduling)
Hay que considerar en el esquema de planificacin en que momento se realiza la seleccin. Un
algoritmo no apropiativo es aquel que una vez que le da la CPU a un proceso se ejecuta hasta
que termina o hasta que se bloquea hasta la ocurrencia de determinado evento. En cambio, un
algoritmo apropiativo es aquel en que un proceso que se esta ejecutando puede ser interrumpido
y pasado a cola de listos (ready queue) por decisin del sistema operativo. Esta decisin puede
ser porque llego un proceso de mayor prioridad, por ejemplo. Si bien los algoritmos apropiativos
tienen un mayor costo que los no apropiativos, el sistema se ve beneficiado con un mejor
servicio pues se evita que algn proceso pueda apropiarse de la CPU.
No obstante si se utilizaran algoritmos apropiativos debe considerarse si el sistema operativo
esta preparado para desplazar en cualquier momento un proceso. Por ejemplo, si ese proceso
en ese momento, a causa de una llamada al sistema (system call) esta modificando estructuras
de kernel y se lo interrumpe, esas estructuras pueden quedar en un estado inconsistente. O
puede ocurrir con procesos que comparten datos y uno de ellos esta modificndolos al ser
interrumpido.

En Unix, por ejemplo se espera que se termine de ejecutar el system call para permitir
apropiacin.


Relacionemos la idea de apropiacin con los diferentes algoritmos vistos.
FCFS es no apropiativo. Cuando se le da la CPU a un proceso, este la mantiene hasta
que decide liberarla, porque termino, o porque requiere I/O.
SJF puede ser apropiativo o no. Si mientras se esta ejecutando un proceso llega uno
cuya prxima rfaga de CPU es mas corta que lo que queda de ejecutar del activo,
puede existir la decisin de interrumpir el que se esta ejecutando o no. Al SJF
apropiativo, se le llama shortest-remaining-time-first. (primero el de tiempo restante ms
corto).
Prioridades puede ser apropiativo o no. Si mientras se esta ejecutando un proceso llega
a la cola de ready un proceso de mayor prioridad que el que se esta ejecutando puede
existir la decisin de interrumpir el que se esta ejecutando o no. Si es no apropiativo, en
lugar de darle la CPU al nuevo proceso, lo pondr primero en la cola de ready.
RR es apropiativo pues si el proceso excede el tiempo asignado, hay una interrupcin
para asignarla la CPU a otro proceso.

Sistemas Operativos
Ing. Jorge Orellana A.
27
2.5. LA PLANIFICACIN DE PROCESOS EN AMBIENTES MULTIPROCESADOR

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

Cada procesador es responsable de su planificacin, y saca procesos de la cola listos
(READY) para ejecutar. El problema es que hay ineficiencia por la necesaria sincronizacin
entre los procesadores para acceder la cola.
En el caso en que los procesadores son idnticos, cualquier procesador disponible puede
usarse para atender cualquier proceso en la cola. No obstante, debemos tener en cuenta
que puede haber dispositivos asignados de manera privada o nica a un procesador, y si un
proceso quiere hacer uso de ese dispositivo deber ejecutarse en ese procesador. Otra
ventaja es implementar load sharing (carga compartida), permitiendo que si un procesador
esta ocioso puedan pasarse procesos de la cola de otro procesador a este, o hacer una cola
comn, y la atencin se realiza de acuerdo a la actividad de cada uno.
Dejar que slo uno de los procesadores planifique y decida qu procesos deben correr los
dems: multiprocesamiento asimtrico. Se asume una estructura de procesadores
master-slave que asigna a un procesador la toma de decisiones en cuanto a scheduling y
otras actividades, dedicndose los otros procesadores a ejecutar cdigo de usuario. La
ventaja es que solo el procesador master accede a estructuras del kernel, evitando
inconsistencias.

2.6. PLANIFICACIN EN WINDOWS (Win32) Y LINUX (POSIX)
El kernel de Windows est diseado utilizando POO. Posee una capa de abstraccin de
hardware (HAL), la cual es la nica que se comunica directamente con el procesador; el resto del
kernel est diseado para utilizar la interfaz de la HAL. La unidad mnima de ejecucin no es el
proceso sino el hilo. Un hilo puede estar en alguno de estos seis estados: listo, standby
(siguiente a ejecutar), en ejecucin, en espera, en transicin (un nuevo hilo) y terminado.

Windows utiliza una planificacin basada en colas mltiples de prioridades. Posee 32 niveles de
colas, clasificadas en clase de Tiempo Real fija (16-31) y prioridad dinamica (0-15). Las colas se
recorren de mayor a menor ejecutando los hilos asociados. Cada cola es manejada por medio de
un algoritmo de RR, aun as, si un hilo de mayor prioridad llega, el procesador le es asignado a
ste. La prioridades ms altas son favorecidas. La prioridades de un thread no pueden ser
reducidas.

Los procesos en Linux pueden ser divididos en tres categoras, relacionadas con la prioridad:
interactivos, por lotes y de tiempo real. Los procesos TR son manejados bien por un algoritmo
FIFO o RR. Los dems procesos son despachados utilizando planificacin RR con un sistema de
envejecimiento basado en crditos, donde el siguiente proceso a ejecutar es aquel que ms
crditos posea. Los procesos TR son considerados prioritarios sobre cualquier otro proceso en el
sistema, por lo que sern ejecutados antes que los dems. Algunos aspectos de la estructura
interna del kernel que caben destacarse son:
La PCB est representada por la estructura task_struct. sta indica el tipo de planificacin
(FIFO,RR) por medio del campo policy, la prioridad (priority), el contador del programa
(counter), entre otros.
La funcin goodness otorga una calificacin al proceso pasado como parmetro. Dicha
puntuacin oscila entre -1000 (no elegible) y +1000 (TR). Los procesos que comparten una
zona de memoria ganan una puntuacin equivalente a su prioridad.
El quantum vara segn el proceso y su prioridad. La duracin base es de aprox. 200ms.
La funcin switch_to es la encargada de salvar la informacin de un proceso y cargar el
siguiente.
Sistemas Operativos
Ing. Jorge Orellana A.
28
Las funciones sched_{get/set}scheduler se refieren al mecanismo de planificacin asociado
a ese proceso.
Una nueva copia del proceso actual es creada mediante la llamada al sistema fork. Para
ejecutar un nuevo programa se utiliza la funcin execve.
Las prioridades bajas son favorecidas. La mayora de los procesos usan polticas de
prioridad dinmica. El valor nice establece la prioridad base de un proceso. Los valores de
nice van desde -20 a +20 (ms grande = menor prioridad). Los usuarios no privilegiados slo
pueden especificar valores de nice positivos. Los procesos normales se ejecutan slo
cuando no quedan procesos de tiempo real (de prioridad fija) en la cola de listos.