2.1
CONCEPTO DE PROCESO
Un proceso no es más que un
programa en ejecución, e incluye los valores actuales del contador de programa,
los registros y las variables. Conceptual mente cada uno de estos procesos tiene
su propia CPU virtual. Desde luego, en la realidad la verdadera CPU conmuta de
un proceso a otro.
Un proceso es un concepto
manejado por el sistema operativo
Que consiste en el conjunto
formado por:
Las instrucciones de un
programa destinadas a ser ejecutadas por el microprocesador.
Su estado de ejecución en un
momento dado, esto es, los valores de los registros de la CPU para dicho
programa.
Su memoria de trabajo, es
decir, la memoria que ha reservado y sus contenidos.
Otra información que permite
al sistema operativo su planificación.
Esta definición varía
ligeramente en el caso de sistemas operativos
multihilo, donde un proceso
consta de uno o más hilos, la memoria de trabajo (compartida por todos los
hilos) y la información de planificación. Cada hilo consta de instrucciones y
estado de ejecución.
Los procesos son creados y
destruidos por el sistema operativo, así como también este se debe hacer cargo
de la
Comunicación entre procesos,
pero lo hace a petición de otros procesos. El mecanismo por el cual un proceso
crea otro proceso se denomina bifurcación (fork). Los nuevos procesos pueden
ser independientes y no compartir el espacio de memoria con el proceso que los
ha creado o ser creados en el mismo espacio de memoria.
En los sistemas operativos
multihilo es posible crear tanto hilos como procesos. La diferencia estriba en
que un proceso solamente puede crear hilos para sí mismo y en que dichos hilos
comparten toda la memoria reservada para el proceso.
En este modelo: todo software
ejecutable de la computadora, lo que a menudo incluye al sistema operativo, está
organizado en una serie del proceso secuenciales, o simplemente procesos.
La idea clava aquí es que un
proceso es una actividad de algún tipo: tiene programa, entrada, salida y un
estado. Se puede compartir un procesador entre varios procesos, usando algún
algoritmo de planificación para determinar cuándo debe de trabajar en un
proceso para atender a uno distinto.
Jerarquías
de procesos
Los sistemas operativos que
manejan el concepto de proceso deben contar con algún mecanismo para crear
todos los procesos necesarios. en los sistemas muy sencillos, o en los
diseñados para ejecutar solo una aplicación.
En otros sistemas operativos
existen llamadas al sistema para crear un proceso, cargar su memoria y ponerlo
en ejecutar. Sea cual sea la naturaleza exacta de la llamada al sistema. Los
procesos necesitan poder crear otros procesos.
En MINIX, los procesos se
crean con la llamada al sistema FORK (bifurcar), que crea una copia idéntica
del proceso invocador. El proceso hijo también puede ejecutar FORK, así que es
posible tener un árbol de proceso.
2.2.-
ESTADOS Y TRANSICIONES DE LOS PROCESOS.
El principal trabajo del
procesador es ejecutar las instrucciones de máquina que se encuentran en
memoria principal. Estas instrucciones se encuentran en forma de programas.
Para que un programa pueda ser ejecutado, el sistema operativo crea un nuevo
proceso, y el procesador ejecuta una tras otra las instrucciones del mismo. En
un entorno de multiprogramación, el procesador intercalará la ejecución de
instrucciones de varios programas que se encuentran en memoria. El sistema
operativo es el responsable de determinar las pautas de intercalado y
asignación de recursos a cada proceso.
Aunque cada proceso se una
entidad independiente, con su propio contador de programa y estado interno, los
procesos a menudo necesitan interactuar con otros procesos. Un proceso podría
generar ciertas salidas que otro proceso utilizan como entradas, en el comando
de Shell.
Cuando un proceso se bloquea,
lo que hace porque le es imposible continuar lógicamente, casi siempre porque
esta separando entradas que todavía no están disponibles, también puede ser que
un programa que conceptualmente esta listo y en condiciones de ejecutarse sea
detenido porque el sistema operativo ha decidido asignar la CPU a otro proceso
durante un tiempo. Estas dos condiciones son totalmente distintas, en el primer
caso, la suspensión es inherente al problema (no es posible procesar la línea
de comandos del usuarios antes de que este la teclee). En el segundo caso, se
trata de un tecnicismo del sistema (no hay suficiente: CPU para darle a cada
proceso su propio procesador privado).
1.- Ejecutándose (usando
realmente la CPU en este instante).
2.- Listo (se puede ejecutar,
pero se suspendió temporalmente para dejar que otro proceso se ejecute).
3.- Bloqueo (no puede
ejecutarse en tanto no ocurra algún evento externo).
Puede haber cuánto
transiciones entre estos tres estados, como se muestra:
La transacción 1 ocurre cuando
un proceso descubre que no puede continuar. En algunos sistemas el proceso debe
ejecutar una llamada al sistema, block, para pasar al estado bloqueado. En
otros sistemas, incluido MINIX, cuando un proceso lee de un conducto o de un
archivo especial, (p.ej., una terminal) y no hay entradas disponibles, se
bloquea automáticamente.
Las transiciones 2 y 3 son
causadas por el planificador de procesos, un parte del sistema operativo, sin
que el proceso se entere siquiera de ellas.
La transición 2 ocurre cuando
el planificador decide que el proceso en ejecución ya se ejecutó durante
suficiente tiempo y es ahora de dejar que otros procesos tengan algo de tiempo
de CPU.
La transacción 3 ocurre cuando
todos los demás procesos han disfrutado de una porción justa y es hora de que
el primer proceso reciba otra vez la CPU para ejecutarse.
La transacción 4 ocurre cuando
acontece el suceso externo que un proceso estaba esperando (como la llegada de
entrada). Sin ningún otro proceso se esta ejecutando en ese instante, se
dispara de inmediato la transacción 3 y el proceso comienza a ejecutarse.
En caso contrario, el proceso
tal vez tenga que esperar en el estado listo durante cierto tiempo hasta que la
CPU esté disponible. Usando el modelo de procesos, es mucho más fácil
visualizar lo que está sucediendo dentro del sistema.
2.3 PROCESOS LIGEROS (HILOS O
HEBRAS)
El concepto de proceso engloba
dos conceptos separados y potencialmente independientes: uno relativo a la
propiedad de recursos y otro que hace referencia a la ejecución.
Unidad que posee recursos: A
un proceso se le asigna un espacio de memoria y, de tanto en tanto, se le puede
asignar otros recursos como dispositivos de E/S o ficheros.
Unidad a la que se le asigna
el procesador: Un proceso es un flujo de ejecución (una
traza) a través de uno o más programas. Esta ejecución se entremezcla con la de
otros procesos. De tal forma, que un proceso tiene un estado (en ejecución,
listo, etc) y una prioridad de expedición u origen. La unidad planificada y
expedida por el sistema operativo es el proceso.
En la mayoría de los sistemas
operativos, estas dos características son, de hecho, la esencia de un proceso.
Sin embargo, son independientes, y pueden ser tratadas como tales por el
sistema operativo. Esta distinción ha conducido en los sistemas operativos
actuales a desarrollar la construcción conocida como thread, cuyas traducciones
más frecuentes son hilo, hebra y proceso ligero. Si se tiene esta división de
características, la unidad de asignación de la CPU se conoce como hilo,
mientras que a la unidad que posee recursos se le llama proceso.
.Dentro de un proceso puede
haber uno o más hilos de control cada uno con:
- Un estado de ejecución (en ejecución,
listo, bloqueado)
- Un contexto de procesador, que se salva
cuando no esté ejecutándose.
- Una pila de ejecución.
- Algún almacenamiento estático para
variables locales.
- Acceso a la memoria y a los recursos de
ese trabajo que comparte con los otros hilos.
Los beneficios clave de los
hilos se derivan de las implicaciones del rendimiento: se tarda menos tiempo en
crear un nuevo hilo de un proceso que ya existe, en terminarlo, y en hacer un
cambio de contexto entre hilos de un mismo proceso. Al someter a un mismo
proceso a varios flujos de ejecución se mantiene una única copia en memoria del
código, y no varias.
Un ejemplo de aplicación que podría hacer uso de los hilos es un servidor de
ficheros de una red de área local. Cada vez que llega una solicitud de una
operación sobre un fichero, se puede generar un nuevo hilo para su gestión. El
servidor gestiona multitud de solicitudes, por tanto, se pueden crear y
destruir muchos hilos en poco tiempo para dar servicio a estas peticiones. Si
el servidor es un multiprocesador, se pueden ejecutar varios hilos de un mismo
proceso simultáneamente y en diferentes procesadores.
Un proceso ligero (thread o hebra) es un programa en ejecución
que comparte la imagen de la memoria y otras informaciones con otros procesos
ligeros.
Es una
unidad básica de utilización de la CPU consistente en un juego de registros y
un espacio de pila. Comparte el código, los datos y los recursos con sus hebras
pares
- Una
tarea (o proceso pesado) está formada ahora por una o más hebras
- Una
hebra sólo puede pertenecer a una tarea
CARACTERISTICAS
- Se
comparten recursos. La compartición de la memoria permite a las hebras
pares comunicarse sin usar ningún mecanismo de comunicación inter-proceso
del SO.
- La
conmutación de contexto es más rápida gracias al extenso compartir de
recursos
- No
hay protección entre las hebras. Una hebra puede escribir en la pila de
otra hebra del mismo proceso.
ESTADOS
DE LOS PROCESOS LIGEROS
Un proceso ligero puede estar ejecutando, listo o bloqueado.
PARALELISMO
Los
procesos ligeros permiten paralelizar una aplicación.
2.4
CONCURRENCIA Y SECUENCIABILIDAD.
La concurrencia comprende un
gran número de cuestiones de diseño, incluyendo la comunicación entre procesos,
comparación y competencia por los recursos, sincronización de la ejecución de
varios procesos y asignación del tiempo de procesador a los procesos y es
fundamental para que existan diseños como Multiprogramación, Multiproceso y
Proceso distribuido
Los procesos son concurrentes
si existen simultáneamente. Cuando dos o más procesos llegan al mismo tiempo a
ejecutarse, se dice que se ha presentado una concurrencia de procesos. Es
importante mencionar que para que dos o más procesos sean concurrentes, es
necesario que tengan alguna relación entre ellos.
La concurrencia puede
presentarse en tres contextos diferentes:
• Varias aplicaciones: La multiprogramación se
creó para permitir que el tiempo de procesador de la máquina fuese compartido
dinámicamente entre varios trabajos o aplicaciones activas.
• Aplicaciones estructuradas:
Como ampliación de los principios del diseño modular y la programación
estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto
de procesos concurrentes.
• Estructura del sistema
operativo: Las mismas ventajas de estructuración son aplicables a los
programadores de sistemas y se ha comprobado que algunos sistemas operativos
están implementados como un conjunto de procesos.
Existen tres modelos de
computadora en los que se pueden ejecutar procesos concurrentes:
• Multiprogramación con un
único procesador. El sistema operativo se encarga de ir repartiendo el tiempo
del procesador entre los distintos procesos, intercalando la ejecución de los
mismos para dar así una apariencia de ejecución simultánea.
• Multiprocesador. Es una
maquina formada por un conjunto de procesadores que comparten memoria
principal. En este tipo de arquitecturas, los procesos concurrentes no sólo
pueden intercalar su ejecución sino también superponerla.• Multicomputadora. Es
una máquina de memoria distribuida, que está formada por una serie de computadoras.
En este tipo de arquitecturas también es posible la ejecución simultánea de los
procesos sobre los diferentes procesadores.
En general, la concurrencia
será aparente siempre que el número de procesos sea mayor que el de
procesadores disponibles, es decir, cuando haya más de un proceso por
procesador. La concurrencia será real cuando haya un proceso por procesador.
Aunque puede parecer que la intercalación y la superposición de la ejecución de
procesos presentan formas de ejecución distintas, se verá que ambas pueden
contemplase como ejemplos de procesos concurrentes.
Existen diversas razones que
motivan la ejecución de procesos concurrentes en un sistema:
• Acelera los cálculos. Si se
quiere que una tarea se ejecute con mayor rapidez, lo que se puede hacer es
dividirla en procesos, cada uno de los cuales se ejecuta en paralelo con los
demás.
• Posibilita el uso
interactivo a múltiples usuarios que trabajan de forma simultánea.
• Permite un mejor
aprovechamiento de los recursos, en especial de la CPU, ya que pueden
aprovechar las fases de entrada-salida de unos procesos para realizar las fases
de procesamiento de otros.
Así como existen las razones
que motivan la ejecución de procesos concurrentes, también existen sus contras:
• Inanición e interrupción de
procesos
• Ocurrencia de bloqueos
• Que dos o más procesos
requieran el mismo recurso (No apropiativo).
TIPOS DE PROCESOS
CONCURRENTES.
Los procesos que ejecutan de
forma concurrente en un sistema se pueden clasificar como:
Proceso independiente: Es
aquel que ejecuta sin requerir la ayuda o cooperación de otros procesos. Un
claro ejemplo de procesos independientes son los diferentes shells que se
ejecutan de forma simultánea en un sistema.
Procesos cooperantes: Son
aquellos que están diseñados para trabajar conjuntamente en alguna actividad,
para lo que deben ser capaces de comunicarse e interactuar entre ellos.
En ambos tipos de procesos
(independientes y cooperantes), puede producirse una serie de interacciones
entre ellos y pueden ser de dos tipos:
• Interacciones motivadas
porque los procesos comparten o compiten por el acceso a recursos físicos o
lógicos. Por ejemplo, dos procesos independientes compiten por el acceso a
disco o para modificar una base de datos.
• Interacción motivada porque
los procesos se comunican y sincronizan entre sí para alcanzar un objetivo
común, Por ejemplo, un compilador que tiene varios procesos que trabajan
conjuntamente para obtener un solo archivo de salida.
ELEMENTOS A GESTIONAR Y DISEÑAR
A CAUSA DE LA CONCURRENCIA
Se pueden enumerar los
siguientes:
1. El sistema operativo debe
ser capaz de seguir la pista de los distintos procesos activos. Esto lo hace
por medio de PBC’s (Bloque de Control de Procesos)
2. El sistema operativo debe asignar
y quitar los distintos recursos a cada proceso activo. Entre estos recursos se
incluyen:
• Tiempo de procesador: Es
función de la planificación.
• Memoria.
• Archivos.
• Dispositivos de E/S:
3. El sistema operativo debe
proteger los datos y los recursos físicos de cada proceso contra injerencias no
intencionadas de otros procesos. 4. Los resultados de un proceso deben ser
independientes de la velocidad relativa a la que se realiza la ejecución con
respecto a otros procesos concurrentes.
2.5 NIVELES, OBJETIVOS Y
CRITERIOS DE PLANIFICACIÓN
NIVELES DE PLANIFICACIÓN
La planificación es
el proceso por el cual el sistema operativo selecciona que proceso ejecutar. La selección del
proceso se basa en alguno de los algoritmos de planificación.
La planificación de la CPU, en
el sentido de conmutarla entre los distintos procesos, es una de las funciones
del sistema operativo. Este despacho es llevado a cabo por un pequeño programa
llamado planificador a corto plazo o dispatcher (despachador). La misión
del dispatcher consiste en asignar la CPU a uno de los procesos ejecutables del
sistema, para ello sigue un determinado algoritmo.
Los acontecimientos que pueden provocar la llamada al dispatcher dependen del
sistema (son un subconjunto de las interrupciones), pero son alguno de estos:
- El proceso en ejecución acaba su ejecución
o no puede seguir ejecutándose (por una E/S, operación WAIT,
etc).
- Un elemento del sistema operativo ordena
el bloqueo del proceso en ejecución
El proceso en ejecución agota su cuantum o cuanto de
estancia en la CPU.
- Un proceso pasa a estado listo.
Hay que destacar el hecho de
que cuanto menos se llame al dispatcher menos tiempo ocupa la CPU un programa
del sistema operativo, y, por tanto, se dedica más tiempo a los procesos del
usuario (un cambio de proceso lleva bastante tiempo).
.
Así, si sólo se activa el
dispatcher como consecuencia de los 2 primeros acontecimientos se estará
haciendo un buen uso del procesador. Este criterio es acertado en sistemas por
lotes en los que los programas no son interactivos. Sin embargo, en un sistema
de tiempo compartido no es adecuado, pues un proceso que se dedicara a realizar
cálculos, y no realizara E/S, monopolizaría el uso de la CPU. En estos sistemas
hay que tener en cuenta el conjunto de todos los procesos, activándose el
dispatcher con la circunstancia tercera y, posiblemente, la cuarta. Los sistema
operativos en que las dos siguientes circunstancias no provocan la activación
del dispatcher muestran preferencia por el proceso en ejecución, si no ocurre
esto se tiene más en cuenta el conjunto de todos los procesos.
Se puede definir el scheduling -algunas veces traducido como -planificación-
como el conjunto de políticas y mecanismos construidos dentro del sistema
operativo que gobiernan la forma de conseguir que los procesos a ejecutar
lleguen a ejecutarse.
El scheduling está asociado a
las cuestiones de:
- Cuándo introducir un nuevo proceso en el
Sistema.
- Determinar el orden de ejecución de los
procesos del sistema.
El scheduling está muy
relacionado con la gestión de los recursos. Existen tres niveles de scheduling,
estos niveles son:
- Planificador de la CPU o a corto plazo.
- Planificador a medio plazo.
- Planificador a largo plazo.
En la planificación de
procesos se suelen incluir varios niveles, en función del periodo temporal que
cubren:
- PLANIFICACIÓN A LARGO PLAZO
Este planificador está
presente en algunos sistemas que admiten además de procesos interactivos
trabajos por lotes. Usualmente, se les asigna una prioridad baja a los trabajos
por lotes, utilizándose estos para mantener ocupados a los recursos del sistema
durante períodos de baja actividad de los procesos interactivos. Normalmente,
los trabajos por lotes realizan tareas rutinarias como el cálculo de nóminas;
en este tipo de tareas el programador puede estimar su gasto en recursos,
indicándoselo al sistema. Esto facilita el funcionamiento del planificador a
largo plazo.
El objetivo primordial del
planificador a largo plazo es el de dar al planificador de la CPU una mezcla
equilibrada de trabajos, tales como los limitados por la CPU (utilizan mucho la
CPU) o la E/S. Así, por ejemplo, cuando la utilización de la CPU es baja, el
planificador puede admitir más trabajos para aumentar el número de procesos listos
y, con ello, la probabilidad de tener algún trabajo útil en espera de que se le
asigne la CPU. A la inversa, cuando la utilización de la CPU llega a ser alta,
y el tiempo de respuesta comienza a reflejarlo, el planificador a largo plazo
puede optar por reducir la frecuencia de admisión de trabajos.
Normalmente, se invoca al
planificador a largo plazo siempre que un proceso termina. La frecuencia de
invocación depende, pues, de la carga del sistema, pero generalmente es mucho
menor que la de los otros dos planificadores. Esta baja frecuencia de uso hace
que este planificador pueda permitirse utilizar algoritmos complejos, basados
en las estimaciones de los nuevos trabajos.
- PLANIFICACIÓN A MEDIANO
PLAZO
En los sistemas de
multiprogramación y tiempo compartido varios procesos residen en la memoria
principal. El tamaño limitado de ésta hace que el número de procesos que
residen en ella sea finito. Puede ocurrir que todos los procesos en memoria
estén bloqueados, desperdiciándose así la CPU. En algunos sistemas se
intercambian procesos enteros (swap) entre memoria principal y memoria
secundaria (normalmente discos), con esto se aumenta el número de procesos, y,
por tanto, la probabilidad de una mayor utilización de la CPU.
El planificador a medio plazo
es el encargado de regir las transiciones de procesos entre memoria principal y
secundaria, actúa intentando maximizar la utilización de los recursos. Por
ejemplo, transfiriendo siempre a memoria secundaria procesos bloqueados, o
transfiriendo a memoria principal procesos bloqueados únicamente por no tener
memoria.
- PLANIFICACIÓN A CORTO PLAZO
Qué proceso será el que se ejecutará en el procesador en el instante siguiente.
Expulsión denota
si un proceso acapara el procesador cuando está ejecutándose. Existen sistemas
con y sin expulsión:
a) Sin expulsión: un proceso conserva el uso del procesador
mientras lo desee; es decir, mientras no solicite del SO un servicio que lo
bloquee. Ventajas: minimiza tiempo de planificación. Inconvenientes: un proceso
podría monopolizar el uso del procesador.
b) Con expulsión: el SO puede desalojar a un proceso del uso
del procesador (sin que el proceso lo haya solicitado). Ventaja: control sobre
el tiempo de ejecución de cada proceso. Inconveniente: gasto de tiempo.
OBJETIVOS Y CRITERIOS DE
PLANIFICACIÓN
Los objetivos del planificador
se resumen en:
a) Reparto equitativo del tiempo de procesador
b) Eficiencia en el uso del procesador
c) Menor tiempo de respuesta en uso interactivo
d) Cumplir plazos de ejecución de los sistemas de tiempo real
El principal objetivo de la planificación a corto plazo es repartir el tiempo
del procesador de forma que se optimicen algunos puntos del comportamiento del
sistema. Generalmente se fija un conjunto de criterios con los que evaluar las
diversas estrategias de planificación. El criterio más empleado establece dos
clasificaciones. En primer lugar, se puede hacer una distinción entre los
criterios orientados a los usuarios y los orientados al sistema. Los criterios
orientados al usuario se refieren al comportamiento del sistema tal y como lo
perciben los usuarios o los procesos.
Uno de los parámetros es el
tiempo de respuesta. El tiempo de respuesta es el periodo de tiempo
transcurrido desde que se emite una solicitud hasta que la respuesta aparece en
la salida. Sería conveniente disponer de una política de planificación que
ofrezca un buen servicio a diversos usuarios.
Otros criterios están
orientados al sistema, esto es, se centran en el uso efectivo y eficiente del
procesador. Un ejemplo puede ser la productividad, es decir, el ritmo con el
que los procesos terminan. La productividad es una medida muy válida del
rendimiento de un sistema y que sería deseable maximizar.
Otra forma de clasificación es
considerar los criterios relativos al rendimiento del sistema y los que no lo
son. Los criterios relativos al rendimiento son cuantitativos y, en general,
pueden evaluarse o ser analizados fácilmente. Algunos ejemplos son el tiempo de
respuesta y la productividad.
Los criterios no relativos al
rendimiento son, en cambio cualitativos y no pueden ser evaluados fácilmente.
Un ejemplo de estos criterios es la previsibilidad. Sería conveniente que el
servicio ofrecido a los usuarios tenga las mismas características en todo
momento, independientemente de la existencia de otros trabajos ejecutados por el
sistema.
En particular, una disciplina
de planificación debe:
Ser equitativa: debe
intentar hacer una planificación justa, esto es, se debe tratar a todos los
procesos de la misma forma y no aplazar indefinidamente ningún proceso. La
mejor forma de evitarlo es emplear alguna técnica de envejecimiento; es decir,
mientras un proceso espera un recurso, su prioridad debe crecer.
Ser eficiente: debe
maximizar el uso de los recursos tales como intentar que la ocupación de la CPU
sea máxima. Al mismo tiempo se debe intentar reducir el gasto extra por
considerar que es trabajo no productivo. Normalmente el idear algoritmos
eficientes supone invertir recursos en gestión del propio sistema.
Lograr un tiempo bueno de
respuesta, es decir, que los usuarios interactivos reciban respuesta
en tiempos aceptables.
Lograr un tiempo de proceso
global predecible. Esto quiere decir que un proceso debe
ejecutarse aproximadamente en el mismo tiempo y casi al mismo costo con
independencia de la carga del sistema.
Elevar al máximo la productividad
o el rendimiento, esto es, maximizar el número de trabajos
procesados por unidad de tiempo. Eso supone, por un lado, dar preferencia a los
procesos que ocupan recursos decisivos y, por otro, favorecer a los procesos
que muestran un comportamiento deseable. En el primer caso conseguimos liberar
el recurso cuanto antes para que esté disponible para un proceso de mayor
prioridad. Con el segundo criterio escogemos a los procesos que no consumen
muchos recursos dejándole al sistema mayor capacidad de actuación.
Estos criterios son
dependientes entre sí y es imposible optimizar todos de forma simultánea. Por
ejemplo, obtener un buen tiempo de respuesta puede exigir un algoritmo de
planificación que alterne entre los procesos con frecuencia, lo que incrementa
la sobrecarga del sistema y reduce la productividad. Por tanto, en el diseño de
una política de planificación entran en juego compromisos entre requisitos
opuestos; el peso relativo que reciben los distintos requisitos dependerá de la
naturaleza y empleo del sistema.
2.6 TÉCNICAS DE ADMINISTRACIÓN
DEL PLANIFICADOR
Las disciplinas de
planificación pueden ser:
• Expropiativas
• No expropiativas
Se denomina planificador al software del sistema operativo encargado de asignar
los recursos de un sistema entre los procesos que los solicitan. Siempre que
haya tomar una decisión, el planificador debe decidir cuál de los procesos que
compiten por la posesión de un determinado recursos lo recibirá.
Los algoritmos (técnicas) tienen distintas propiedades según los criterios en
los que se basen para su construcción, lo cual se refleja en qué tipo de
procesos se puede ver favorecido frente a otro en la disputa del procesador.
Antes de realizar la elección de un algoritmo se debe considerar las
propiedades de estos frente al criterio de diseño elegido. Algunos de estos
son:
a) Eficacia: Se expresa como un porcentaje del tiempo medio de
utilización. Aunque puede parecer lógico intentar mantener este parámetro
próximo al 100%, con un valor tan elevado otros aspectos importantes de medida
del comportamiento del sistema pueden verse deteriorados, como por ejemplo el
tiempo medio de espera.
b) Rendimiento: Es una medida del número de procesos
completados por unidad de tiempo. Por ejemplo 10 procesos por segundo.
c) Tiempo de retorno o regreso: Es el intervalo de tiempo que
transcurre desde que un proceso se crea o presenta hasta que completa por el
sistema.
d) Tiempo de espera: Es el tiempo que el proceso espera hasta
que se le concede el procesador. Puede resultar una medida mas adecuada de la
eficiencia del sistema, ya que se elimina de la media el tiempo que tarda en
ejecutarse el mismo.
e) Tiempo de respuesta a un evento: Se denomina así el
intervalo de tiempo que transcurre desde que se señala un evento hasta que se
ejecuta la primera instrucción de la rutina de servicio de dicho evento. El
criterio de selección de un algoritmo se suele basar en la maximización o
minimización de una función de los parámetros anteriores.
