Procesos

Sistemas Operativos I
Apuntes. Capítulo II
SISTEMAS OPERATIVOS
Procesos
Concepto de proceso [DEIT93] [LIST86] [TANE93]
Hasta ahora hemos utilizado siempre el término programa. A partir de ahora

distinguiremos entre programa y proceso. Un programa es una secuencia de
instrucciones escrita en un lenguaje dado. Un proceso es una instancia de
ejecución de un programa, caracterizado por su contador de programa, su palabra
de estado, sus registros del procesador, su segmento de texto, pila y datos, etc.
Un programa es un concepto estático, mientras que un proceso es un concepto
dinámico. Es posible que un programa sea ejecutado por varios usuarios en un
sistema multiusuario, por cada una de estas ejecuciones existirá un proceso, con
su contador de programa, registros, etc. El sistema operativo necesita el concepto
de proceso para poder gestionar el procesador mediante la técnica de
multiprogramación o de tiempo compartido, de hecho, el proceso es la unidad
planificable, o de asignación de la CPU.
Estados de un proceso y Transiciones de estado de los procesos [DEIT93]

[TANE93] [SILB94][STAL95]
Durante su vida, un proceso puede pasar por una serie de estados discretos,
algunos de ellos son:
1 En ejecución: El proceso ocupa la CPU actualmente, es decir, se está

ejecutando.
Grupo 91R221
UTP/F.I.S.C. –Panamá Oeste
2008
2 Listo o preparado: El proceso dispone de todos los recursos para su

ejecución, sólo le falta la CPU.
3 Bloqueado: Al proceso le falta algún recurso para poder seguir

ejecutándose, además de la CPU. Por recurso se pueden entender un
dispositivo, un dato, etc. El proceso necesita que ocurra algún evento que le
permita poder proseguir su ejecución.
Hay otros estados de los procesos, pero en la presente exposición se tratarán

estos tres. Por sencillez, se considera un sistema con una sola CPU, aunque no
es difícil la extensión a múltiples procesadores. Solamente puede haber un
proceso en ejecución a la vez, pero pueden existir varios listos y varios pueden
estar bloqueados. Así pues, se forman una lista de procesos listos y otra de
procesos bloqueados. La lista de procesos listos se ordena por prioridad, de
manera que el siguiente proceso que reciba la CPU será el primero de la lista. La
lista de procesos bloqueados normalmente no está ordenada; los procesos no se
desbloquean (es decir, no pasan a ser procesos listos) en orden de prioridad, sino
que lo hacen en el orden de ocurrencia de los eventos que están esperando.
Como se verá más adelante, hay situaciones en las cuales varios procesos
pueden bloquearse esperando la ocurrencia del mismo evento; en tales casos es
común asignar prioridades a los procesos que esperan.
Transiciones de estado de los procesos
A continuación se dan ejemplos de eventos que pueden provocar transiciones de

estado en un proceso en este modelo de tres estados (ver Figura 1.2). La mayoría
de estos eventos se discutirán con profundidad a lo largo del curso:
Grupo 91R221
2008
1 De ejecución á Bloqueado: al iniciar una operación de E/S, al realizar una

operación WAIT sobre un semáforo a cero (en el tema de procesos
concurrentes se estudiarán los semáforos).
2 De ejecución á Listo: por ejemplo, en un sistema de tiempo compartido,

cuando el proceso que ocupa la CPU lleva demasiado tiempo ejecutándose
continuamente (agota su cuanto) el sistema operativo decide que otro
proceso ocupe la CPU, pasando el proceso que ocupaba la CPU a estado
listo.
3 De Listo á en ejecución: cuando lo requiere el planificador de la CPU

(veremos el planificador de la CPU en el tema de planificación de
procesos).
4 De Bloqueado á Listo: se dispone del recurso por el que se había

bloqueado el proceso. Por ejemplo, termina la operación de E/S, o se
produce una operación SIGNAL sobre el semáforo en que se bloqueó el
proceso, no habiendo otros procesos bloqueados en el semáforo.
Obsérvese que de las cuatro transiciones de estado posibles, la única

iniciada por el proceso de usuario es el bloqueo, las otras tres son iniciadas
por entidades externas al proceso.
Grupo 91R221
2008
Figura 1.2Transiciones de estado de los procesos.
Interpretación de la figura. Como podemos observar en esta figura tenemos

una serie de transiciones posibles entre estados de proceso, representados
a partir mediante una gama de colores. Estos colores hay que interpretarlos
de forma que, el color del borde de los estados representa a dichos
estados, los colores dentro de los círculos nos dicen las posibles
alternativas de acceso hacia otro estado, y los colores de las flechas nos
representan hacia que estado nos dirigimos si seguimos la misma.
Cambio de Proceso
A primera vista, la función de cambio de proceso parece sencilla. En cierto

momento, un proceso que se está ejecutando se interrumpe, el sistema operativo
pone a otro proceso en el estado de ejecución y pasa el control a dicho proceso.
Sin embargo, surgen diversas cuestiones de diseño. En primer lugar, ¿qué
sucesos provocan un cambio de proceso? Otra cuestión es que se debe hacer una
Grupo 91R221
2008
distinción entre cambio de contexto y cambio de proceso. Por último, ¿qué debe
hacer el sistema operativo con las diferentes estructuras de datos bajo su control
para llevar a cabo un cambio de proceso?
¿Qué eventos provocan el cambio de proceso?
Un cambio de proceso puede suceder en cualquier instante en el que el sistema

operativo gana el control de la CPU.
En primer lugar, se van a tener en cuenta las interrupciones del sistema. Se

pueden distinguir dos clases de interrupciones del sistema. La primera es
originada por algún tipo de suceso que es externo e independiente del proceso
que se está ejecutando, como la culminación de una E/S. La segunda tiene que
ver con una condición de error o excepción generada dentro del proceso que se
está ejecutando, como un intento ilegal de acceso a un fichero, una división entre
cero, una instrucción máquina con código de operación no contemplado. En una
interrupción ordinaria, el control se transfiere primero al gestor de interrupciones,
quien lleva a cabo algunas tareas básicas y, después, se salta a la rutina del
sistema operativo que se ocupa del tipo de interrupción que se ha producido.
Algunos ejemplos de estas interrupciones son:
1 Interrupción de reloj: Un reloj es un dispositivo que genera interrupciones

periódicamente. Ante una interrupción de este tipo, un sistema operativo de
tiempo compartido, entre otras cosas, determina si el proceso en ejecución
ha alcanzado el máximo tiempo de ejecución que se le concedió. Si es así,
el proceso pasará a estado listo, y se asignará la CPU a otro proceso.
2 Interrupción de E/S: El sistema operativo determina exactamente qué

acción de E/S ha ocurrido. Si se trata de un evento o suceso por el que
esperaban uno o más procesos, entonces el sistema operativo traslada
todos los procesos bloqueados en dicho evento al estado listo, y determina
(dependiendo de la política de planificación, que se verá en el próximo
Grupo 91R221
2008
tema) si reanuda la ejecución del proceso interrumpido o pasa a otro de

mayor prioridad.
3 Falta de memoria: Un proceso hace una referencia a una dirección que no

se encuentra en memoria y que debe traerse de memoria secundaria (esta
posibilidad se estudiará en el módulo de gestión de la memoria). Después
de hacer la solicitud de E/S para traer esa o esas direcciones de memoria,
el sistema operativo lleva a cabo un cambio de contexto (próximo apartado)
para reanudar la ejecución de otro proceso; el proceso que cometió la falta
de memoria se pasa al estado bloqueado. Después de que las direcciones
aludidas se carguen en memoria, dicho proceso se pondrá en estado listo.
En una interrupción del segundo tipo, el sistema operativo determina si el error es

fatal. Si lo es, el proceso que se estaba ejecutando es eliminado, y se produce un
cambio de proceso. Si no es fatal, la acción del sistema operativo dependerá de la
naturaleza del error y del diseño del sistema operativo. Se puede hacer un cambio
de proceso o, simplemente, reanudar el mismo proceso que se estaba ejecutando.
Finalmente, el sistema operativo puede activarse mediante una llamada al sistema

desde el programa que se está ejecutando. Por ejemplo, está ejecutándose un
proceso de usuario y se llega a una instrucción que solicita una operación de E/S,
tal como abrir un fichero. Esta llamada provoca la transferencia a una rutina que
forma parte del código del sistema operativo. Por lo general (aunque no siempre)
el uso de una llamada al sistema hace que el proceso de usuario pase al estado
bloqueado.
Grupo 91R221
2008
Monoprogramación y Multiprogramación
La mayoría de los sistemas operativos utilizan una técnica de gestión del
procesador denominada multiprogramación, o una variante de ésta llamada tiempo
compartido. Los primeros sistemas operativos gestionaban el procesador
mediante otra técnica llamada monoprogramación (utilizada en los monitores de
batch de flujo único). En este apartado comentaremos el por qué se evolucionó de
la monoprogramación a la multiprogramación. Antes de entrar en esta discusión
vamos a ver cómo se realizan las operaciones de entrada/salida (E/S), es decir,
las operaciones que permiten la comunicación con los dispositivos de E/S.
Realización de las operaciones de E/S
Para facilitar el uso de los dispositivos, éstos se dividen en dos componentes. La

primera es la componente eléctrica, a la cual se le llama controlador del
dispositivo. La segunda es la componente mecánica, y es a lo que se llama
propiamente dispositivo. Esta división permite un diseño más modular del
dispositivo, además de simplificar su uso, ya que la CPU casi siempre trabaja con
el controlador (más fácil de usar), que hace de interfaz entre la CPU y el
dispositivo.
El controlador contiene una serie de registros llamados puertos de entrada/salida.

Estos registros son accesibles (pueden ser leídos y modificados) mediante la
ejecución de instrucciones máquina. Las operaciones de E/S se realizan a través
de la carga y lectura de estos registros. Casi todo controlador dispone de los
siguientes registros:
1 Registro de estado. Indica la situación actual del dispositivo. Un bit del

registro, al que llamaremos bit de ocupación, indica si el dispositivo está
ocupado (el bit tendrá el valor uno) realizando una operación de E/S o si
está desocupado (el bit tendrá el valor cero), y, por tanto, preparado para
recibir una orden.
Grupo 91R221
2008
2 Registro de órdenes. En este registro se escribe la operación de E/S que

se desea que realice el dispositivo. Por ejemplo, en una cinta un código de
00 puede indicar rebobinar la cinta, 01 leer de la cinta, 10 escribir en la
cinta, etc. El controlador se encarga de traducir estas órdenes en órdenes
comprensibles para el dispositivo.
3 Buffer. Un buffer es un almacén de información. El buffer del controlador

se utiliza para guardar temporalmente los datos implicados en una
operación de E/S. Por ejemplo, si se quiere escribir en una impresora, se
carga la información a escribir desde memoria principal al buffer.
Posteriormente, el controlador mandará dicha información desde el buffer a
la impresora.
Monoprogramación
Pasemos ahora a introducir el concepto de monoprogramación. En un sistema de

monoprogramación todos los recursos del ordenador -CPU, memoria, discos,
impresoras, etc- se dedican a la ejecución de un único programa. Este modo de
trabajar lleva a una baja utilización de los recursos del ordenador como se justifica
a continuación. Cuando el programa en ejecución realiza una operación de E/S se
introduce la orden precisa en el registro de órdenes. El controlador responde a
esto traduciendo esas órdenes al dispositivo, y poniendo a uno el bit de ocupación
para indicar que el dispositivo está ocupado realizando una operación de E/S.
Cuando termine la operación, el controlador pone a cero este bit para indicar que
la operación concluyó, y el dispositivo está desocupado. Para saber cuándo
termina la E/S, el programa, después de mandar la orden, tiene que ejecutar un
ciclo del siguiente estilo:
Leer el registro de estado
Mientras (el bit de ocupación esté a uno)
Leer el registro de estado
Grupo 91R221
2008
Fin Mientras
Figura 1.3 Utilización de los recursos con monoprogramación
Obsérvese que esta forma de realizar las operaciones de E/S nos lleva a una
situación en la que en un momento dado se tiene que, o bien la CPU está
ejecutando instrucciones de un programa que no son de E/S, y los dispositivos de
E/S están ociosos, o bien un único dispositivo de E/S está trabajando, mientras la
CPU está en un ciclo comprobando si ha finalizado la operación. Esto se ilustra en
la figura 6.1, donde los rectángulos rellenos a trazas representan el ciclo de
comprobación. Para dar una medida de la infrautilización de los recursos que
conlleva esta forma de realizar las E/S, piénsese que en el tiempo en que una
impresora imprime una línea, la CPU, en lugar de ejecutar el ciclo de
comprobación que aparece líneas más arriba, podría ejecutar millones de
instrucciones de otro programa. A esta forma de realizar la E/S de los sistemas de
monoprogramación se le llama E/S controlada por programa.
Grupo 91R221
2008
Multiprogramación
Para paliar la baja utilización de los recursos se desarrolló la multiprogramación.

La multiprogramación se apoya en varios elementos del hardware: la interrupción,
el DMA y el canal. En un sistema multiprogramado la memoria principal alberga a
más de un programa de usuario. La CPU ejecuta instrucciones de un programa,
cuando el programa en ejecución (es decir, el que ocupa la CPU) realiza una
operación de E/S, emite ciertas órdenes al controlador (al igual que en los
sistemas monoprogramados); pero en lugar de esperar a que termine la operación
de E/S comprobando el bit de ocupación, se pasa a ejecutar otro programa. Si
este nuevo programa realiza, a su vez, otra operación de E/S, se mandan las
órdenes oportunas al controlador, y pasa a ejecutarse otro programa. Esto permite
que varios dispositivos trabajen simultáneamente, además, en la CPU no se tienen
que ejecutar ciclos de comprobación del estado de los dispositivos.
Esto se ilustra en la figura 1.3, en ella P1, P2 y P3 representan programas que

residen en la memoria principal. Los rectángulos representan si el recurso está
siendo utilizado, salvo para P1, P2 y P3 que representan si el programa ocupa la
CPU. Al principio se está ejecutando P1, cuando inicia una operación de E/S con
la impresora se cede la CPU a P2. P2 se ejecuta hasta que comienza una
operación con el scanner, entonces se cede la CPU a P3, éste se ejecuta hasta
que utiliza la impresora, momento en el cual se reanuda P1. Obsérvese que en
este ejemplo la CPU siempre está activa. No obstante, podría suceder que todos
los programas que residen en la memoria inicien una operación de E/S y en un
momento dado todos estén esperando la finalización de su operación, esto
conllevaría la no utilización de la CPU hasta que acabe la operación de E/S de
cualquiera de los programas.
Grupo 91R221
2008
Figura 1.4 Utilización de los recursos con multiprogramación
Cuando un dispositivo acaba una operación de E/S debe de poder comunicárselo

al programa que espera su finalización, para que así, el programa pueda proseguir
su ejecución. Para indicar el fin de la operación el controlador manda una
interrupción a la CPU. Una interrupción no es más que una señal eléctrica que
provoca que el contador del programa y la PSW del programa en ejecución se
salven en un lugar seguro de memoria, para, a continuación, cargar el contador de
programa con una dirección fija de memoria donde reside un programa del
sistema operativo que gestiona la interrupción. Este programa ejecutará cierto
código para indicar al programa que esperaba la finalización de la operación de
E/S que ésta ya terminó. Una vez que este programa del sistema operativo acaba
su trabajo ejecuta una instrucción de retorno de interrupción, la cual restaura el
contador de programa y la PSW del programa interrumpido, prosiguiéndose así su
ejecución sin que éste sea consciente de que ha sido interrumpido. A esta forma
de realizar la E/S se le llama E/S controlada por interrupción.
Analicemos ahora el DMA y el canal. Cuando un dispositivo realiza una operación

de E/S, por ejemplo, una lectura de una cinta, la información leída pasa del
controlador. Después, el programa que inició la lectura ejecuta al buffer ciertas
Grupo 91R221
2008
instrucciones para copiar esta información desde el buffer hacia la memoria

principal. La copia se realiza mediante un ciclo, copiando en cada iteración del
ciclo un byte o una palabra desde el buffer del controlador a la memoria principal.
En un controlador que disponga de DMA (acrónimo de Direct Memory Access,
acceso directo a memoria) la copia del buffer a memoria la realiza el propio
controlador; para ello, el programa ha de indicarle al controlador la dirección de
memoria de inicio de la copia y el número de bytes a copiar, esto lo hace en el
momento de darle la orden de E/S, metiendo esta información en algunos registros
del controlador. Pasemos ahora a ver lo que es un canal, un canal es un pequeño
procesador de E/S (es decir, un ordenador que sólo entiende instrucciones de
E/S), su utilidad es proporcionar DMA a varios dispositivos, resultando más
económico que tener un controlador DMA por dispositivo.
Después de la aparición de la multiprogramación surgieron los ordenadores de

acceso múltiple o multiusuario. En ellos cada usuario dispone de un terminal, es
decir, un teclado y una pantalla conectados al ordenador. Los usuarios ejecutan
programas interactivos. Un programa interactivo es aquel que se comunica con el
usuario por medio de un terminal, el usuario le suministra información al programa
mediante el teclado, y recibe información del programa a través de la pantalla. Los
programas de los usuarios comparten los recursos (CPU, memoria, discos,
impresoras, etc) del ordenador. Estos sistemas hacen uso de una variante de la
multiprogramación llamada tiempo compartido.
En el tiempo compartido los programas de los distintos usuarios residen en

memoria; al realizar una operación de E/S los programas ceden la CPU a otro
programa, al igual que en la multiprogramación. Pero, a diferencia de ésta, cuando
un programa lleva cierto tiempo ejecutándose sin realizar operaciones de E/S el
sistema operativo lo detiene para que se ejecute otro programa. Con esto se
consigue repartir la CPU con equidad entre los programas de los distintos
usuarios. Al tener la CPU una capacidad de cálculo tan grande, los programas de
Grupo 91R221
2008
los usuarios no se sienten demasiado ralentizados por el hecho de que la CPU (y

los demás recursos) sean compartidos.
Definamos ahora el término concurrencia. Por concurrencia se entiende la

existencia de varias actividades simultáneas o paralelas. Ejemplo de ello lo
constituyen la superposición de las operaciones de E/S con el proceso de
computación. Otro ejemplo lo constituye la concurrencia de varios programas que
se conmutan en un procesador. Aunque esta concurrencia no es real en un
instante dado (si sólo existe un procesador), sí es real en un intervalo más amplio
de tiempo.
En general, a lo largo del curso estudiaremos sistemas operativos que se ejecutan

sobre un único procesador. Los sistemas distribuidos prácticamente no se tendrán
en cuenta. Cuando se hable de algo aplicable a un sistema multiprocesador
(memoria compartida) se observará explícitamente.
Grupo 91R221
2008
Planificación de procesos [DEIT93] [MILE94] [STAL95]
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. En
secciones posteriores estudiaremos algunos algoritmos posibles. Para que el
dispatcher conmute el procesador entre dos procesos es necesario realizar un
cambio de proceso.
Los acontecimientos que pueden provocar la llamada al dispatcher dependen del

sistema (son un subconjunto de las interrupciones), pero son alguno de estos:
1 El proceso en ejecución acaba su ejecución o no puede seguir

ejecutándose (por una E/S, operación WAIT, etc).
2 Un elemento del sistema operativo ordena el bloqueo del proceso en

ejecución (estados de un proceso).
3 El proceso en ejecución agota su cuantum o cuanto de estancia en la

CPU.
4 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
Grupo 91R221
2008
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.
Grupo 91R221
2008
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:
1 Cuándo introducir un nuevo proceso en el Sistema.
Grupo 91R221
2008
2 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, como se ilustra en la figura 1 de planificación, estos niveles
son:
1 Planificador de la CPU o a corto plazo.
2 Planificador a medio plazo.
3 Planificador a largo plazo.
Ya hemos hablado del planificador de la CPU, y en los subapartados posteriores

se comentan los dos restantes:
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
Grupo 91R221
2008
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 Medio 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.
Grupo 91R221
2008
Algoritmos de planificación [DEIT93] [SILB94] [TANE93] [BIC88]
Vamos a estudiar ciertos algoritmos utilizados para planificar la CPU, la elección

de uno (o de una mezcla de varios) depende de decisiones de diseño. Antes de
exponer los algoritmos vamos a explicar ciertas medidas que se utilizan para
evaluarlos.
1 Porcentaje de utilización de la CPU por procesos de usuario. La CPU es

un recurso caro que necesita ser explotado, los valores reales suelen estar
entre un 40% y un 90%.
2 Rendimiento (throughput) = nº de ráfagas por unidad de tiempo. Se define

una ráfaga como el período de tiempo en que un proceso necesita la CPU;
un proceso, durante su vida, alterna ráfagas con bloqueos. Por extensión,
también se define como el nº de trabajos por unidad de tiempo.
3 Tiempo de espera (E) = tiempo que una ráfaga ha permanecido en estado

listo.
4 Tiempo de finalización (F) = tiempo transcurrido desde que una ráfaga

comienza a existir hasta que finaliza. F = E + t (t = tiempo de CPU de la
ráfaga).
5 Penalización (P) = E + t / t = F / t, es una medida adimensional que se

puede aplicar homogéneamente a las ráfagas independientemente de su
longitud.
En general, hay que maximizar los dos primeros parámetros y minimizar los tres
últimos. Sin embargo, estos objetivos son contradictorios, el dedicar más tiempo
de CPU a los usuarios se hace a costa de llamar menos al algoritmo de
planificación (menos cambios de proceso), y de simplificarlo. Esto provoca que la
Grupo 91R221
2008
CPU se reparta menos equitativamente entre los procesos, en detrimento de los

últimos tres parámetros.
Así pues, dependiendo de los objetivos se elegirá cierto algoritmo. En los sistemas
por lotes suele primar el rendimiento del sistema, mientras que en los sistemas
interactivos es preferible minimizar, por ejemplo, el tiempo de espera.
Grupo 91R221
2008
Planificación Primero en Entrar-Primero en Salir (FIFO, First In First Out)
Cuando se tiene que elegir a qué proceso asignar la CPU se escoge al que llevara
más tiempo listo. El proceso se mantiene en la CPU hasta que se bloquea
voluntariamente.
La ventaja de este algoritmo es su fácil implementación, sin embargo, no es válido

para entornos interactivos ya que un proceso de mucho cálculo de CPU hace
aumentar el tiempo de espera de los demás procesos . Para implementar el
algoritmo (ver figura 2) sólo se necesita mantener una cola con los procesos listos
ordenada por tiempo de llegada. Cuando un proceso pasa de bloqueado a listo se
sitúa el último de la cola.
En a) el proceso P7 ocupa la CPU, los procesos P2, P4 y P8 se mantienen en la

lista de preparados. En b) P7 se bloquea (ya sea al realizar una E/S, una
operación WAIT sobre un semáforo a cero u otra causa) y P2 pasa a ocupar la
CPU. En c) ocurre un evento (finalización de la operación de E/S, operación
SIGNAL, ...) que desbloquea a P7, esto lo vuelve listo, pasando al final de la cola
de procesos listos.
Grupo 91R221
2008
Algunas de las características de este algoritmo es que es no apropiativo y justo

en el sentido formal, aunque injusto en el sentido de que: los trabajos largos hacen
esperar a los cortos y los trabajos sin importancia hacen esperar a los importantes.
Por otro lado es predecible pero no garantiza buenos tiempos de respuesta y por
ello se emplea como esquema secundario.
Planficación por Turno Rotatorio (Round Robin).
Este es uno de los algoritmos más antiguos, sencillos y equitativos en el reparto

de la CPU entre los procesos, muy válido para entornos de tiempo compartido.
Cada proceso tiene asignado un intervalo de tiempo de ejecución, llamado
cuantum o cuanto. Si el proceso agota su cuantum de tiempo, se elige a otro
proceso para ocupar la CPU. Si el proceso se bloquea o termina antes de agotar
su cuantum también se alterna el uso de la CPU. El round robin es muy fácil de
implementar. Todo lo que necesita el planificador es mantener una lista de los
procesos listos, como se muestra en la figura 6.2.
En esta figura en a) el proceso P7 ocupa la CPU. En b) P7 se bloquea pasando P2

a ocupar la CPU. En c) P2 agota su cuantum con lo que pasa al final de la lista y
P4 ocupa la CPU. La figura 4 representa un ejemplo más largo de la ocupación de
la CPU utilizando el algoritmo round robin.
Grupo 91R221
2008
Este algoritmo presupone la existencia de un reloj en el sistema. Un reloj es un

dispositivo que genera periódicamente interrupciones. Esto es muy importante,
pues garantiza que el sistema operativo (en concreto la rutina de servicio de
interrupción del reloj) coge el mando de la CPU periódicamente. El cuantum de un
proceso equivale a un número fijo de pulsos o ciclos de reloj. Al ocurrir una
interrupción de reloj que coincide con la agotación del cuantum se llama al
dispatcher.
Grupo 91R221
2008
Tamaño del Cuanto
La determinación del tamaño del cuanto es vital para la operación efectiva de un

sistema de cómputo. ¿Debe el cuanto ser pequeño o grande?, ¿fijo o variable?,
¿el mismo para todos los usuarios o debe determinarse por separado para cada
uno?
Si el cuanto de tiempo es muy grande, cada proceso tendrá el tiempo necesario

para terminar, de manera que el esquema de planificación por turno rotatorio
degenera en uno de primero-en-entrar-primero-en-salir. Si el cuanto es muy
pequeño, el gasto extra por cambio de proceso se convierte en el factor dominante
y el rendimiento del sistema se degradará hasta el punto en que la mayor parte del
tiempo se invierte en la conmutación del procesador, con muy poco o ningún
tiempo para ejecutar los programas de los usuarios.
¿Exactamente dónde, entre cero e infinito, debe fijarse el tamaño del cuanto? La
respuesta es, lo bastante grande como para que la mayoría de las peticiones
interactivas requieran menos tiempo que la duración del cuanto.
Pongamos un ejemplo, supongamos que el cambio de proceso tarda 5 mseg., y la

duración del cuantum es de 20 mseg.. Con estos parámetros, se utiliza un mínimo
del 20% del tiempo de la CPU en la ejecución del sistema operativo. Para
incrementar la utilización de la CPU por parte de los procesos de usuario
podríamos establecer un cuantum de 500 mseg., el tiempo desperdiciado con este
parámetro sería del 1%. Pero consideremos lo que ocurriría si diez usuarios
interactivos oprimieran la tecla enter casi al mismo tiempo. Diez procesos se
colocarían en la lista de procesos listos. Si la CPU está inactiva, el primero de los
procesos comenzaría de inmediato, el segundo comenzaría medio segundo
después, etc. Partiendo de la hipótesis de que todos los procesos agoten su
cuantum, el último proceso deberá de esperar 4'5 seg. para poder ejecutarse.
Esperar 4'5 seg. para la ejecución de una orden sencilla como pwd parece
excesivo.
Grupo 91R221
2008
En conclusión, un cuantum pequeño disminuye el rendimiento de la CPU, mientras

que un cuantum muy largo empobrece los tiempos de respuesta y degenera en el
algoritmo FIFO. La solución es adoptar un término medio como 100 mseg.
Planificación por Prioridad al más corto (SJF, Short Job First).
Al igual que en el algoritmo FIFO las ráfagas se ejecutan sin interrupción, por
tanto, sólo es útil para entornos batch. Su característica es que cuando se activa el
planificador, éste elige la ráfaga de menor duración. Es decir, introduce una noción
de prioridad entre ráfagas. Hay que recordar que en los entornos batch se pueden
hacer estimaciones del tiempo de ejecución de los procesos.
La ventaja que presenta este algoritmo sobre el algoritmo FIFO es que minimiza el
tiempo de finalización promedio, como puede verse en el siguiente ejemplo:
Ej: Supongamos que en un momento dado existen tres ráfagas listos R1,
R2 y R3, sus tiempos de ejecución respectivos son 24, 3 y 3 ms. El proceso
al que pertenece la ráfaga R1 es la que lleva más tiempo ejecutable,
seguido del proceso al que pertenece R2 y del de R3. Veamos el tiempo
medio de finalización (F) de las ráfagas aplicando FIFO y SJF:
1 FIFO F = (24 + 27 + 30) / 3 = 27 ms.
2 SJF F = (3 + 6 + 30) / 3 = 13 ms.
Se puede demostrar que este algoritmo es el óptimo. Para ello, consideremos el

caso de cuatro ráfagas, con tiempos de ejecución de a, b, c y d. La primera ráfaga
Grupo 91R221
2008
termina en el tiempo a, la segunda termina en el tiempo a+b, etc. El tiempo

promedio de finalización es (4a+3b+2c+d)/4. Es evidente que a contribuye más al
promedio que los demás tiempos, por lo que debe ser la ráfaga más corta, b la
siguiente, y así sucesivamente. El mismo razonamiento se aplica a un número
arbitrario de ráfagas.
No obstante, este algoritmo sólo es óptimo cuando se tienen simultáneamente

todas las ráfagas. Como contraejemplo, considérense cinco ráfagas desde A hasta
E, con tiempo se ejecución de 2, 4, 1, 1 y 1 respectivamente. Sus tiempos de
llegada son 0, 0, 3, 3 y 3. Primero se dispone de A y B, puesto que las demás
ráfagas no han llegado aún. Con el algoritmo SJF las ejecutaríamos en orden A, B,
C, D, y E con un tiempo de finalización promedio de 4.6. Sin embargo, al
ejecutarlas en orden B, C, D, E y A se tiene un promedio de finalización de 4.4.
Planificación por Prioridad al Tiempo Restante más Corto (SRTF, Short

Remaining Time First). (Agregado)
Grupo 91R221
2008
Es similar al anterior, con la diferencia de que si un nuevo proceso pasa a listo se

activa el dispatcher para ver si es más corto que lo que queda por ejecutar del
proceso en ejecución. Si es así el proceso en ejecución pasa a listo y su tiempo de
estimación se decrementa con el tiempo que ha estado ejecutándose.
En la figura 6.5 tenemos un ejemplo de funcionamiento del algoritmo en el que se

observa cómo se penalizan las ráfagas largas (como en SJF). Un punto débil de
este algoritmo se evidencia cuando una ráfaga muy corta suspende a otra un poco
más larga, siendo más largo la ejecución en este orden al ser preciso un cambio
adicional de proceso y la ejecución del código del planificador.
Planificación a la Tasa de Respuesta más Alta. (Agregado)
Brinch Hansen desarrolló la estrategia de prioridad a la tasa de respuesta más alta

(HRN, highest-response-ratio-next) que corrige algunas deficiencias de SJF,
Grupo 91R221
2008
particularmente el retraso excesivo de trabajos largos y el favoritismo excesivo

para los trabajos cortos. HRN es un disciplina de planificación no apropiativa en la
cual la prioridad de cada proceso no sólo se calcula en función del tiempo de
servicio, sino también del tiempo que ha esperado para ser atendido. Cuando un
trabajo obtiene el procesador, se ejecuta hasta terminar. Las prioridades
dinámicas en HRN se calculan de acuerdo con la siguiente expresión:
1 prioridad = (tiempo de espera + tiempo de servicio) / tiempo

de servicio
Como el tiempo de servicio aparece en el denominador, los procesos cortos

tendrán preferencia. Pero como el tiempo de espera aparece en el numerador, los
procesos largos que han esperado también tendrán un trato favorable. Obsérvese
que la suma tiempo de espera + tiempo de servicio es el tiempo de respuesta del
sistema para el proceso si éste se inicia de inmediato.
Grupo 91R221
2008
Comunicación y Sincronización de Procesos [BENA82] [LIST86] [STAL95]

[TANE93] [FINK90]
A continuación, dos temas importantes en cuanto a la sincronización de los

pr
ocesosensi
;“LaCooper
aci
ónyLaCompet
enci
a”. Puede verse la concurrencia
de procesos como la ejecución simultánea de varios procesos. Si tenemos un
multiprocesador o un sistema distribuido(tema 1) la concurrencia parece clara, en
un momento dado cada procesador ejecuta un proceso. Se puede ampliar el
concepto de concurrencia si entendemos por procesado concurrente (o procesado
paralelo) la circunstancia en la que de tomar una instantánea del sistema en
conjunto, varios procesos se vean en un estado intermedio entre su estado inicial
y final. Esta última definición incluye los sistemas multiprogramados de un único
procesador que estudiamos en los temas anteriores.
Los distintos procesos dentro de un ordenador no actúan de forma aislada. Por un

lado, algunos procesos cooperan para lograr un objetivo común. Por otro lado, los
procesos compiten por el uso de unos recursos limitados, como el procesador, la
memoria o los ficheros. Estas dos actividades de cooperación y competición llevan
asociada la necesidad de algún tipo de comunicación entre los procesos. Parte de
este tema lo dedicaremos a estudiar mecanismos de comunicación entre los
procesos.
Para aclarar un poco todo esto, supongamos que en un entorno UNIX se ejecuta
la orden
cat tema1 tema2 tema3 | wc -l
Esta orden va a provocar que el intérprete de órdenes cree dos procesos

concurrentes, el primero ejecutará el programa cat, que concatenará el contenido
de los ficheros de texto tema1, tema2 y tema3. El segundo ejecutará el programa
wc, que contará el número de líneas de la salida producida por cat. Estos dos
Grupo 91R221
2008
procesos cooperan, y será preciso algún tipo de sincronización entre ellos,

concretamente hasta que cat no produzca alguna salida wc debería bloquearse.
Cooperación entre Procesos
La velocidad de un proceso con respecto a otro es impredecible ya que depende

de la frecuencia de la interrupción asociada a cada uno de ellos y cuán a menudo
y de por cuánto tiempo tiene asignado cada proceso un procesador. Diremos,
pues, que un proceso se ejecuta asíncronamente con respecto a otro, es decir,
sus ejecuciones son independientes. Sin embargo, hay ciertos instantes en lo que
los procesos deben sincronizar sus actividades. Son estos puntos a partir de los
cuales un proceso no puede progresar hasta que otro haya completado algún tipo
de actividad.
Los procesos también necesitan comunicarse entre sí. Por ejemplo, para leer de
un fichero, los procesos de usuario deben decir al proceso que gestiona los
ficheros lo que desean. Este, a su vez, debe pedirle al proceso de disco que lea
los bloques necesarios. Cuando el shell conecta dos procesos con un tubo, los
datos de salida del primer proceso se transfieren al segundo. Se necesita que los
procesos se comuniquen entre sí, con un mecanismo bien estructurado y no por
medio de interrupciones.
Competencia entre los procesos
Los recursos de un sistema pueden clasificarse como compartibles, lo que

significa que pueden ser utilizados por varios procesos de forma concurrente, o no
compartibles, lo que equivale a que su uso se restrinja a un sólo proceso a la vez.
El hecho de que un recurso no sea compartible deriva de una de las dos razones
siguientes:
1 La naturaleza física del recurso hace que sea imposible

compartirlo. Un ejemplo lo constituye una impresora, si una
Grupo 91R221
2008
impresora fuera utilizada por varios procesos simultáneamente sus

salidas se entremezclarían en el papel.
2 El recurso es tal que si es usado por varios procesos de forma

concurrente la acción de uno de ellos puede interferir con la de otro.
Un ejemplo común lo constituye un fichero que contiene unos datos
accesibles desde más de un proceso, y modificables al menos por
uno de ellos. Por ejemplo, supongamos un fichero que contiene
registros con la siguiente información sobre una cuenta bancaria:
CLAVE SALDO
Supongamos también dos procesos que se ejecutan concurrentemente y que

actualizan una misma cuenta, el proceso P1 añade al saldo el valor de la nómina y
el proceso P2 descuenta del saldo una factura domiciliada. El código de los
procesos es el siguiente:
El resultado final de la ejecución de los dos procesos debería actualizar el saldo

añadiéndole la nómina, y descontándole la factura. Sin embargo, la secuencia de
ejecución en el procesador de las instrucciones a1b1b2b3a2a3, que puede darse
debido a un cambio de proceso, hace que no se descuente la factura.
Grupo 91R221
2008
Dentro de la categoría de recursos no compartibles se incluirán la mayoría de los

periféricos (los discos no), los ficheros de escritura y las zonas de memoria sujetas
a modificación. Los recursos compartibles incluirán la CPU (en los temas previos
vimos cómo compartir la CPU entre los procesos introduciendo el concepto de
PCB), los ficheros de lectura, y las zonas de memoria que contengan rutinas puras
o bien datos que no están sujetos a modificación.
Requisitos para la Exclusión Mutua
Los recursos no compartibles, ya sean periféricos, ficheros, o datos en memoria,

pueden protegerse del acceso simultáneo por parte de varios procesos evitando
que éstos ejecuten de forma concurrente sus fragmentos de código a través de los
cuales llevan a cabo este acceso. Estos trozos de código reciben el nombre de
secciones o regiones críticas, pudiéndose asimilar el concepto de exclusión mutua
en el uso de estos recursos a la idea de exclusión mutua en la ejecución de las
secciones críticas. Así, por ejemplo, puede implementarse la exclusión mutua de
varios procesos en el acceso a una tabla de datos mediante el recurso de que
todas las rutinas que lean o actualicen la tabla se escriban como secciones
críticas, de forma que sólo pueda ejecutarse una de ellas a la vez. En el ejemplo
previo de la cuenta bancaria los fragmentos de código a1a2a3 y b1b2b3
constituyen dos secciones críticas mutuamente excluyentes, esto significa que una
vez que se ha comenzado la ejecución de una sección crítica, no se puede entrar
en otra sección crítica mutuamente excluyente.
Idear soluciones que garanticen la exclusión mutua es uno de los problemas

fundamentales de la programación concurrente. Muchas son las alternativas y
tipos de mecanismos que se pueden adoptar. A lo largo de este tema veremos
diferentes soluciones software y alguna hardware ; unas serán sencillas y otras
complejas, algunas requieren la cooperación voluntaria de los procesos y otras
que exigen un estricto ajuste a rígidos protocolos. La selección de las operaciones
primitivas adecuadas para garantizar la exclusión mutua de las secciones críticas
Grupo 91R221
2008
es una decisión primordial en el diseño de un sistema operativo. Al menos, una

solución apropiada debería cumplir las cuatro condiciones siguientes:
1. Que no haya en ningún momento dos procesos dentro de sus

respectivas secciones críticas.
2. Que no hagan suposiciones a priori sobre las velocidades relativas de

los procesos o el número de procesadores disponibles.
3. Que ningún proceso que esté fuera de su sección crítica pueda bloquear
a otros.
4. Que ningún proceso tenga que esperar un intervalo de tiempo

arbitrariamente grande para entrar en su sección crítica.
Grupo 91R221
2008
Problemas Clásicos de Comunicación entre Procesos [TANE93] [MILE94]
El problema de la cena de los filósofos
En 1965 Dijkstra planteó y resolvió un problema de sincronización llamado el

problema de la cena de los filósofos, que se puede enunciar como sigue. Cinco
filósofos se sientan a la mesa, cada uno con un plato de espaghetti. El espaghetti
es tan escurridizo que un filósofo necesita dos tenedores para comerlo. Entre cada
dos platos hay un tenedor. En la figura se muestra la mesa.
Los filósofos se disponen a comer
La vida de un filósofo consta de periodos alternos de comer y pensar. Cuando un

filósofo tiene hambre, intenta obtener un tenedor para su mano derecha, y otro
para su mano izquierda, cogiendo uno a la vez y en cualquier orden. Si logra
obtener los dos tenedores, come un rato y después deja los tenedores y continúa
pensando. La pregunta clave es: ¿ puede el lector escribir un programa para cada
filósofo que permita comer equitativamente a los filósofos y no se interbloquee ?
Grupo 91R221
2008
Algoritmo 1. Una no-solución al problema de la cena de los filósofos
El algoritmo muestra una solución obvia. El procedimiento coger_tenedor espera

hasta que el tenedor especificado esté disponible y lo coge. Por desgracia la
solución obvia es incorrecta. Supongamos que los cinco filósofos cogen sus
tenedores izquierdos de forma simultánea. Ninguno podría coger su tenedor
derecho, lo que produciría un interbloqueo.
Grupo 91R221
2008
Se podría modificar el programa de forma que después de coger el tenedor

izquierdo, el programa verificara si el tenedor derecho está disponible. Si no lo
está, el filósofo deja el izquierdo, espera cierto tiempo y vuelve a repetir el
proceso. Esta propuesta también falla, aunque por razones distintas. Con un poco
de mala suerte todos los filósofos podrían empezar el algoritmo de forma
simultánea, por lo que cogerían sus tenedores izquierdos, verían que los derechos
no están disponibles, esperarían, volverían a coger sus tenedores izquierdos
simultáneamente, etc. eternamente. Esto implica un aplazamiento indefinido.
Grupo 91R221
2008
Algoritmo 2. Una solución al problema de la cena de los filósofos
El lector podría pensar: "si los filósofos esperaran un tiempo arbitrario, en vez del
mismo tiempo, después de que no pudieran coger el tenedor derecho, la
probabilidad de que todo quedara bloqueado, incluso una hora, sería muy
pequeña". Esta observación es correcta, pero en ciertas aplicaciones se desea
una solución que funcione siempre, y no que pueda funcionar bien con gran
probabilidad. (Piense en el control de seguridad de una planta nuclear).
Una mejora a el siguiente algoritmo, que no tiene interbloqueos ni aplazamiento

indefinido, es la protección de los cinco enunciados siguientes a la llamada al
Grupo 91R221
2008
procedimiento pensar mediante un semáforo binario exmut. Antes de empezar a

coger los tenedores, un filósofo haría un wait sobre exmut. Desde el punto de vista
teórico esta solución es adecuada. Desde el punto de vista práctico presenta un
error de eficiencia: en todo instante existirá a lo sumo un filósofo comiendo. Si se
dispone de cinco tenedores, se debería permitir que dos filósofos comieran al
mismo tiempo.
La solución que aparece en el algoritmo 3, es correcta, y permite el máximo

paralelismo para un número arbitrario de filósofos. Utiliza un vector, estado, para
llevar un registro de la actividad de un filósofo: si está comiendo, pensando o
hambriento (estado que indica que quiere coger los tenedores). Un filósofo puede
comer únicamente si los vecinos no están comiendo. Los vecinos del i-ésimo
filósofo se definen en las macros IZQ y DER. En otras palabras, si i= 2, entonces
IZQ = 1, y DER = 3.
El programa utiliza un vector de semáforos, uno por filósofo, de forma que los
filósofos hambrientos puedan bloquearse si los tenedores necesarios están
ocupados. Observe que cada proceso ejecuta el procedimiento filósofo como
programa principal, pero los demás procedimientos, coger_tenedores,
dejar_tenedores y prueba, son procedimientos ordinarios y no procesos
separados.
El problema de los lectores y los escritores
El problema de la cena de los filósofos es útil para modelar procesos que compiten
por el acceso exclusivo a un número limitado de recursos, como una unidad de
Grupo 91R221
2008
cinta u otro dispositivo de E/S. Otro problema famoso es el de los lectores y

escritores (Courtois et al., 1971), que modela el acceso a una base de datos.
Supóngase una base de datos, con muchos procesos que compiten por leer y
escribir en ella. Se puede permitir que varios procesos lean de la base de datos al
mismo tiempo, pero si uno de los procesos está escribiendo (es decir,
modificando) la base de datos, ninguno de los demás debería tener acceso a ésta,
ni siquiera los lectores. La pregunta es ¿ cómo programaría los lectores y
escritores ? La solución se muestra en la a continuación.
En esta solución, el primer lector que obtiene el acceso a la base de datos realiza
un wait sobre el semáforo bd. Los lectores siguientes sólo incrementan un
contador, nl. Al salir los lectores, éstos decrementan el contador, y el último en
salir realiza un signal sobre el semáforo, lo que permite entrar a un escritor
bloqueado, si existe.
Una hipótesis implícita en esta solución es que los lectores tienen prioridad sobre
los escritores. Si surge un escritor mientras varios lectores se encuentran en la
base de datos el escritor debe esperar. Pero si aparecen nuevos lectores, y queda
al menos un lector accediendo a la base de datos, el escritor deberá esperar hasta
que no haya más lectores interesados en la base de datos.
Grupo 91R221
2008
Grupo 91R221
2008

Procesos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Procesos

Uploaded by

Copyright:

Available Formats

Sistemas Operativos I

Hasta ahora hemos utilizado siempre el término programa. A partir de ahora

Estados de un proceso y Transiciones de estado de los procesos [DEIT93]

1 En ejecución: El proceso ocupa la CPU actualmente, es decir, se está

2 Listo o preparado: El proceso dispone de todos los recursos para su

3 Bloqueado: Al proceso le falta algún recurso para poder seguir

Hay otros estados de los procesos, pero en la presente exposición se tratarán

Transiciones de estado de los procesos

A continuación se dan ejemplos de eventos que pueden provocar transiciones de

1 De ejecución á Bloqueado: al iniciar una operación de E/S, al realizar una

2 De ejecución á Listo: por ejemplo, en un sistema de tiempo compartido,

3 De Listo á en ejecución: cuando lo requiere el planificador de la CPU

4 De Bloqueado á Listo: se dispone del recurso por el que se había

Obsérvese que de las cuatro transiciones de estado posibles, la única

Figura 1.2Transiciones de estado de los procesos.

Interpretación de la figura. Como podemos observar en esta figura tenemos

A primera vista, la función de cambio de proceso parece sencilla. En cierto

¿Qué eventos provocan el cambio de proceso?

Un cambio de proceso puede suceder en cualquier instante en el que el sistema

En primer lugar, se van a tener en cuenta las interrupciones del sistema. Se

1 Interrupción de reloj: Un reloj es un dispositivo que genera interrupciones

2 Interrupción de E/S: El sistema operativo determina exactamente qué

tema) si reanuda la ejecución del proceso interrumpido o pasa a otro de

3 Falta de memoria: Un proceso hace una referencia a una dirección que no

En una interrupción del segundo tipo, el sistema operativo determina si el error es

Finalmente, el sistema operativo puede activarse mediante una llamada al sistema

Realización de las operaciones de E/S

Para facilitar el uso de los dispositivos, éstos se dividen en dos componentes. La

El controlador contiene una serie de registros llamados puertos de entrada/salida.

1 Registro de estado. Indica la situación actual del dispositivo. Un bit del

2 Registro de órdenes. En este registro se escribe la operación de E/S que

3 Buffer. Un buffer es un almacén de información. El buffer del controlador

Pasemos ahora a introducir el concepto de monoprogramación. En un sistema de

Leer el registro de estado

Mientras (el bit de ocupación esté a uno)

Leer el registro de estado

Figura 1.3 Utilización de los recursos con monoprogramación

Para paliar la baja utilización de los recursos se desarrolló la multiprogramación.

Esto se ilustra en la figura 1.3, en ella P1, P2 y P3 representan programas que

Figura 1.4 Utilización de los recursos con multiprogramación

Cuando un dispositivo acaba una operación de E/S debe de poder comunicárselo

Analicemos ahora el DMA y el canal. Cuando un dispositivo realiza una operación

instrucciones para copiar esta información desde el buffer hacia la memoria

Después de la aparición de la multiprogramación surgieron los ordenadores de

En el tiempo compartido los programas de los distintos usuarios residen en

los usuarios no se sienten demasiado ralentizados por el hecho de que la CPU (y

Definamos ahora el término concurrencia. Por concurrencia se entiende la

En general, a lo largo del curso estudiaremos sistemas operativos que se ejecutan

Planificación de procesos [DEIT93] [MILE94] [STAL95]

La planificación de la CPU, en el sentido de conmutarla entre los distintos

Los acontecimientos que pueden provocar la llamada al dispatcher dependen del

1 El proceso en ejecución acaba su ejecución o no puede seguir

2 Un elemento del sistema operativo ordena el bloqueo del proceso en

3 El proceso en ejecución agota su cuantum o cuanto de estancia en la

4 Un proceso pasa a estado listo.

Así, si sólo se activa el dispatcher como consecuencia de los 2 primeros

Se puede definir el scheduling -algunas veces traducido como -planificación- como

El scheduling está asociado a las cuestiones de:

1 Cuándo introducir un nuevo proceso en el Sistema.

2 Determinar el orden de ejecución de los procesos del sistema.

1 Planificador de la CPU o a corto plazo.

2 Planificador a medio plazo.

3 Planificador a largo plazo.

Ya hemos hablado del planificador de la CPU, y en los subapartados posteriores