Lectura 2 - Procesos e Hilos PDF

Módulo 2
Unidad 2: Procesos e Hilos
Sistemas Operativos I
Prof. G. Adrian Rodríguez
2.1- Concepto de proceso.
Podemos considerar a un proceso como un programa en ejecución; dicho
proceso necesita ciertos recursos, como tiempo de CPU, memoria, archivos
y dispositivos de entrada y salida (E/S), para realizar su tarea. Estos
recursos se asignan a los procesos cuando se crea o bien durante su
ejecución.
En la mayoría de los sistemas, la unidad de trabajo son los procesos. Los

sistemas constan de una colección de procesos: los procesos del sistema
operativo ejecutan código del sistema y los procesos de usuario ejecutan
código de usuario. Todos estos procesos pueden ejecutarse de forma
concurrente.
Aunque tradicionalmente los procesos se ejecutaban utilizando un solo hilo

de control, ahora la mayoría de los sistemas operativos modernos permiten
ejecutar procesos compuestos por múltiples hilos.
El concepto de hilo será tratado más adelante en profundidad, y por el

momento se deberá ver al hilo como una sucesión de tareas ejecutadas
simultáneamente.
El sistema operativo es responsable de las actividades relacionadas con la

gestión de procesos e hilos: la creación y eliminación de procesos del
sistema y de usuario, la planificación de los procesos y la provisión de
mecanismos para la sincronización, la comunicación y el tratamiento de
interbloqueos en los procesos.
Los primeros sistemas informáticos sólo permitían que se ejecutara un

programa a la vez. Este programa tenía el control completo del sistema y
tenía acceso a todos los recursos del mismo. Por el contrario, los sistemas
informáticos actuales permiten que se carguen en memoria múltiples
programas y se ejecuten concurrentemente. Esta evolución requiere un
mayor control y aislamiento de los distintos programas y estas necesidades
dieron lugar al concepto de proceso, que es un programa en ejecución. Un
proceso es la unidad de trabajo en los sistemas modernos de tiempo
compartido.
Cuanto más complejo es el sistema operativo, más se espera que haga en

nombre de sus usuarios. Aunque su principal cometido es ejecutar
programas de usuario, también tiene que ocuparse de diversas tareas del
sistema que, por uno u otro motivo, no están incluidas dentro del kernel.
Por tanto, un sistema está forjado por una colección de procesos: procesos
del sistema operativo que ejecutan código del sistema y procesos de usuario
que ejecutan código de usuario.
Potencialmente, todos estos procesos pueden ejecutarse concurrentemente,

multiplexando la CPU (0 las distintas CPU) entre ellos. Cambiando la
asignación de la CPU entre los distintos procesos, el sistema operativo
puede incrementar la productividad de la computadora.
Lo dicho anteriormente dista de aclarar el concepto formal de proceso, por

lo tanto brindaremos una definición más acabada de procesos:
Sistemas Operativos 1 – G. Adrian Rodríguez | 2

Una pregunta que surge cuando se estudian los sistemas operativos es cómo
llamar a las diversas actividades de la CPU. Los sistemas de procesamiento
por lotes ejecutan trabajos, mientras que un sistema de tiempo compartido
tiene programas de usuario o tareas. Incluso en un sistema mono-usuario,
como Microsoft Windows, el usuario puede ejecutar varios programas al
mismo tiempo; un procesador de textos, un explorador web y un programa
de correo electrónico. A su vez, aunque el usuario pueda ejecutar sólo un
programa cada vez, el sistema operativo puede tener que dar soporte a sus
propias actividades internas programadas, como los mecanismos de gestión
de la memoria. En muchos aspectos, todas estas actividades son similares,
por lo que a todas ellas las denominamos procesos.
En este texto, los términos trabajo y proceso se usan indistintamente.

Aunque personalmente preferimos el término proceso, gran parte de la
teoría y terminología de los sistemas operativos se desarrolló durante una
época en que la principal actividad de los sistemas operativos era el
procesamiento de trabajos por lotes. Podría resultar confuso, por tanto,
evitar la utilización de aquellos términos comúnmente aceptados que
incluyen la palabra trabajos (como por ejemplo: planificación de trabajos)
simplemente porque el término proceso haya sustituido a trabajo.
El proceso
Informalmente, como hemos indicado antes, un proceso es un programa en
ejecución. Hay que resaltar que un proceso es algo más que el código de un
programa (al que en ocasiones se denomina sección de texto). Además del
código, un proceso incluye también la actividad actual, que queda
representada por el valor del contador de programa y por los contenidos de
los registros del procesador. Generalmente, un proceso incluye también la
pila del proceso, que contiene datos temporales (como los parámetros de las
funciones, las direcciones de retomo y las variables locales), y una sección
de datos, que contiene las variables globales. El proceso puede incluir,
asimismo, un cúmulo de memoria, la cual se asigna dinámicamente al
proceso en tiempo de ejecución. En la Figura 2.1 se muestra la estructura de
un proceso en memoria.
Máximo
Pila
Cúmulo de memoria
Datos
0 Texto
Figura 2.1. Proceso en memoria
Insistamos en que un programa, por si mismo, no es un proceso; un

programa es una entidad pasiva, un archivo que contiene una lista de
instrucciones almacenadas en disco (a menudo denominado archivo
ejecutable), mientras que un proceso es una entidad activa, con un contador
de programa que especifica la siguiente instrucción que hay que ejecutar y

un conjunto de recursos asociados. Un programa se convierte en un proceso
cuando se carga en memoria un archivo ejecutable. Dos técnicas habituales
para cargar archivos ejecutables son: hacer doble clic sobre un icono que
represente el archivo ejecutable e introducir el nombre del archivo
ejecutable en la línea de comandos (como por ejemplo, prog.exe).
Aunque puede haber dos procesos asociados con el mismo programa, esos
procesos se consideran dos secuencias de ejecución separadas. Por ejemplo,
varios usuarios pueden estar ejecutando copias diferentes del programa de
correo, o el mismo usuario puede invocar muchas copias del explorador
web. Cada una de estas copias es un proceso distinto y, aunque las secciones
de texto sean equivalentes, las secciones de datos, del cúmulo (heap) de
memoria y de la pila variarán de unos procesos a otros. También es habitual
que un proceso cree muchos otros procesos a medida que se ejecuta.
2.2. Modelo de estados.

En cualquier sistema operativo, es básico conocer el comportamiento que
exhibirán los distintos procesos y el conjunto de estados que pueden
atravesar.
Modelo de dos estados

Dentro de los modelos de estado, podemos encontrar el modelo de dos
estados, el cual consiste principalmente en que un proceso puede estar o no
ejecutándose en el procesador.
Básicamente el proceso puede estar en modo: Ejecución o No ejecución.

Estos estados pueden verse en la figura 2.2.
Entrada
No Ejecución Terminar
Ejecución
Figura 2.2. Esquema de un diagrama de dos estados
Siempre que se crea un nuevo proceso dentro del sistema operativo, se crea
en el estado de No ejecución. De esta manera el proceso está presente para
el sistema operativo, y a la espera de ser ejecutado.
En el momento indicado por el sistema operativo el proceso deja el estado

de No ejecución para pasar al estado de ejecución.

Con lapsos de tiempo determinados por el sistema operativo, los procesos
que se encuentran en ejecución son interrumpidos, por lo tanto pasa al
estado de No ejecución. El sistema operativo elije otro proceso que se
encuentra en estado de No ejecución para ponerlo en estado de Ejecución.
El ciclo vuelve a empezar otra vez.
El sistema operativo debe saber en cada momento del estado de cada unos
de los procesos que están corriendo y de su posición en la memoria, un
aspecto muy importante a la hora de diseñar un sistema operativo, inclusive
en modelos básicos de sistemas operativos.
Los procesos que están esperando pasar al estado de ejecución, deben

almacenarse en un tipo particular de estructura de datos, a la espera del que
el sistema operativo lo convoque. En la figura 2.3 propone una estructura
basada en una cola de procesos o cola FIFO (del inglés First In First Out).
Cola FIFO
Entrada Terminar
Procesador
Figura 2.3. Esquema de un sistema de Cola FIFO
Una cola de procesos consiste en una lista enlazada de bloques en la que

cada uno de estos bloques representa a un proceso en particular. Este
bloque es un recipiente de la estructura de datos donde el sistema operativo
guarda toda la información relativa al proceso en particular. El sistema
operativo se comporta de manera similar a un gestor de colas de cualquier
sucursal de un banco. De esta manera, una vez que el sistema operativo crea
un nuevo proceso se introducirá el correspondiente bloque al final de la
cola, esta acción también se llevará a cabo cuando un proceso sea
expropiado del procesador (pasa al estado de no ejecución) en favor de otro
o cuando se bloquee en espera de que se complete una operación de E/S.
Una vez que el proceso termina se descarta del sistema. Si cada uno de los
procesos presentes en el sistema estuviera a disposición siempre para ser
ejecutados, el sistema de cola de procesos seria ineficaz. El modelo de cola
sigue un comportamiento FIFO y el procesador opera siguiendo un turno
rotatorio con los procesos disponibles. De esta manera, se le otorga una
cierta cantidad de tiempo para ejecutar a cada proceso. Este proceso se
repetirá si no se presentan bloqueos y luego de un tiempo este volverá a la
cola a la espera de ser ejecutado y obtener control sobre el procesador. Este
tipo de implementación no suele ser del todo eficaz, ya que algunos
procesos en estado de no ejecución estarán listos para ejecutar mientras
que otros se encontraran a la espera de obtener algún recurso solicitado o a
la espera de que se complete una operación de E/S. El sistema operativo
posee la facultad de no entregar el procesador a un proceso que este

primero en la cola de espera, si éste está bloqueado, recorrerá la cola de
procesos revisando aquel que no es bloqueado y siguiendo el orden de
espera.
Una forma más natural de afrontar esta situación es dividir el estado de no

ejecución en dos; los estados listo y bloqueado. Además se añadirán dos
nuevos estados al sistema.
Estos estados son: nuevo y terminado, que resultan de utilidad para las
labores de gestión de procesos. Así se dará lugar al modelo de 5 estados.
Modelo de 5 estados
En este modelo un proceso puede encontrarse en cualquiera de los
siguientes 5 estados.
1. Estado Nuevo: este estado el procesos acaba de ser creado y

definido, sin que aún lo haya admitido el sistema operativo como
procesos ejecutables.
Antes de la ejecución del proceso, es necesario asignarles un

identificador y la crearles alguna estructura de control.
Una de las principales razones por la cual se realiza este tratamiento

a los procesos por parte del sistema operativo, es principalmente el
control por parte de este a la hora de manejar el rendimiento o por
las restricciones impuestas por la capacidad de la memoria.
2. Estado Listo o Preparado: Este estado es para los procesos que

dispongan de todos los recursos necesarios para dejar la inactividad
y comenzar su ejecución y es el estado que sigue al estado anterior
(estado nuevo).
3. Estado de Ejecución: Una vez que el proceso deja el estado de

listo, se procede a la ejecución del mismo y por lo tanto obtiene
control del procesador. Esto es aplicado a computadoras de un solo
procesador, ya que para el caso de poseer varios procesadores, el
estado dependerá del procesador que este libre, pero para el caso de
un solo procesador, el proceso deberá esperar a que el procesador se
libere.
4. Estado Bloqueado: Cuando un proceso presenta algún tipo de

complicación, es decir que carecen de algún recurso necesario para
su ejecución, es sistema operativo lo coloca en este estado y deberá
esperar un lugar nuevo en la cola de procesos para ser ejecutado.
5. Estado Terminado: Una vez que el proceso fue ejecutado con

éxito o fracaso, el sistema operativo lo excluye del grupo procesos
ejecutables. Existen tres condiciones para que un proceso alcance el
estado de terminado: cuando llega a su término, cuando se
interrumpe por un error irrecuperable u otro proceso con privilegios

hace que finalice. Luego de alcanzar esta situación, ya no será tenido
en cuenta para ser ejecutado por parte del sistema operativo,
aunque este último guarde información del proceso terminado para
su posible reutilización. El sistema operativo o alguna aplicación
determinada para tal fin, guardan información del proceso que
acaba de terminar, normalmente para fines estadísticos. Cuando la
información para fines estadísticos fue utilizada, es descartada por
parte del sistema operativo.
En la figura 2.4 presentamos el diagrama de transiciones entre estados
Pasar a ejecución
Preparado Ejecución
Fin de plazo
Esperar un
suceso
Nuevo
Ocurrencia Terminado
de suceso
Bloqueo
Figura 2.4. Diagrama de transiciones entre estados. La línea punteada indica situación
excepcional.
Existen sucesos que ocurren entre el paso de un estado a otro, esta serie de
sucesos se denominan transiciones:
Transición a Nuevo: Es el traspaso de la no existencia a la creación de un

nuevo proceso.
Transición Nuevo -Preparado: En esta transición, el sistema operativo

está preparado para aceptar o admitir un proceso más. Se deberán cumplir
condiciones básicas rendimiento de la memoria y de la cantidad de procesos
en ejecución.
Transición Preparado-Ejecución: Cuando el sistema operativo se

encuentra en condiciones de ejecutar otro proceso (porque no existen
procesos ejecutándose o porque algún proceso llegó a su fin) en función del
rendimiento del mismo.

Transición Ejecución-Preparado: Cada sistema operativo posee
parámetros de tiempo de ejecución de procesos, que serán monitoreados
para no superar el tiempo máximo permitido de ejecución ininterrumpida.
Otra forma de esta transición es cuando un proceso es forzado a terminar

en pos de la ejecución de otro proceso de mayor importancia.
Existen otras situaciones, menos comunes y que no están presentes en

todos los sistemas operativos, en donde por ejemplo, el proceso
voluntariamente cede el control del procesador.
Transición Ejecución-Bloqueo: Esta transición hace que el proceso esté

a la espera de un determinado recurso, la entrada de algún parámetro de
E/S o la ejecución de un determinado suceso.
Transición Bloqueado-Preparado: Esta transición ocurre cuando o

bien se le concede el recurso solicitado u ocurre el suceso por el que estaba
esperando el proceso.
Transición Preparado - Terminado: Esta transición ocurre cuando un

proceso que se encontraba a la espera de ser ejecutado, es finalizado por
algún otro proceso de mayor jerarquía o por la falta de recurso en ese
momento por parte del sistema operativo.
Transición Bloqueado - Terminado: Esta transición es similar a la

anterior, salvo que en esta el proceso quedo a la espera de algún recurso o
parámetro de E/SS u de otro proceso. Suele ocurrir de manera similar, que
cuando un proceso supero el tiempo de espera previamente determinado, el
sistema operativo decida terminarlo. Este tipo de modelo de cinco estados
puede llevarse a cabo estructuras de tipo cola FIFO, siguiendo un esquema
como el de la figura 2.5.
Cola FIFO
Entrada Terminar
Procesador
Fin de plazo
Ocurrencia
Cola de bloqueados
de suceso Esperar suceso
Figura 2.5. Diagrama de transiciones entre estados implementada con una cola FIFO.
Para este modelo, disponemos de dos colas FIFO, una para los procesos en
situación de preparado y otra para los bloqueados. Todo proceso que ha
sido creado en el sistema operativo se situará en la cola de preparados. Al
momento de la elección de un proceso a ejecutar, el sistema operativo
elegirá dicho proceso de dicha cola de procesos recién creados, respetando

siempre la prioridad de cada proceso en particular. Cuando no se disponga
de prioridades, la cola puede gestionarse mediante un algoritmo FIFO.
Todo proceso que es expropiado del procesador, es el resultado de haber

terminado su ejecución, excedido el tiempo máximo de posesión del
procesador (es devuelto a la cola de preparados) o ha quedado bloqueado a
la espera de un determinado suceso (se introducirá en la cola de
bloqueados). Un proceso que haya expirado por un determinado suceso,
hace que todos los procesos que esperaban por él son pasados desde la cola
de bloqueados a la de preparados.
Una vez que un proceso finalice, el sistema operativo, recorrerá la cola en

busca del proceso adecuado para su puesta en ejecución. En sistemas
operativos más grande se implementaran un conjunto de colas, debido a la
gran cantidad de procesos en la cola de bloqueados, esto resultará en una
mayor eficiencia por parte del sistema operativo. En la figura 2.6 reflejamos
esta situación, en donde podemos tener varias colas de bloqueados
simultáneas para cada proceso en particular.
Cola FIFO
Entrada Terminar
Procesador
Fin de plazo
Ocurrencia
Cola de bloqueados
de suceso 1 Esperar suceso
Ocurrencia
Cola de bloqueados
de suceso 2 Esperar suceso
Ocurrencia
Cola de bloqueados
de suceso n Esperar suceso
Figura 2.6. Diagrama de transiciones de varias colas de bloqueados.
Si la planificación de procesos se realiza mediante un esquema basado en

prioridades, entonces es conveniente tener un cierto número de colas de
procesos listos, una para cada prioridad.

Procesos suspendidos
Debido a que el procesador es mucho más rápido que los dispositivos de

E/S puede ocurrir que en un momento dado todos los procesos del sistema
se encuentren bloqueados a la espera de que se complete alguna operación
de E/S. Para solucionar este problema existen dos opciones:
1. Ampliar la memoria del sistema de forma que sea posible albergar

en ella más procesos e incrementar así la posibilidad de que alguno
de ellos haga uso efectivo del procesador.
2. La otra solución consiste en aplicar una técnica conocida como

intercambio o swaping. Esta técnica consiste en que cuando todos
los procesos que se encuentran en memoria principal están
bloqueados, el sistema operativo puede sacar a uno de ellos de su
correspondiente cola y transferirlo a memoria secundaria. El
proceso transferido se dice entonces que queda en estado
suspendido. Una vez realizada esta operación, el sistema operativo
está en condiciones de traer de nuevo a memoria a un proceso
previamente suspendido o bien dar entrada al sistema a un nuevo
proceso.
En general, se considera suspendido a un proceso que presenta las

características siguientes:
1. Un proceso suspendido no está disponible de inmediato para su

ejecución.
2. Un proceso puede estar esperando o no un suceso. Si lo está, la

condición de bloqueado es independiente de la condición de
suspendido y el acontecimiento del suceso bloqueante no lo habilita
para la ejecución.
3. El proceso fue situado en estado suspendido por un agente (el

sistema operativo o el proceso padre) con el fin de impedir su
ejecución.
4. El proceso no puede apartarse de estado hasta que llegue la orden

expresa para ello.
Si añadimos este nuevo estado a nuestro diagrama de 5 estados,

obtendremos la figura 2.7.

Pasar a ejecución
Fin de plazo
Esperar un
Ocurrencia suceso
Nuevo
de suceso
Terminado
Suspendido Bloqueo
Figura 2.7. Diagrama de 5 estados con suspensión.
Teniendo en cuenta que un proceso suspendido se encontraba bloqueado a

la espera de que ocurriera un cierto suceso y que dicho suceso puede ocurrir
mientras el proceso permanece en memoria secundaria, sería más eficiente
desdoblar el estado suspendido en dos, uno para las procesos suspendidos
que aún esperan el suceso que les bloqueo (estado bloqueado y suspendido)
y otro para los procesos suspendidos que por haber tenido lugar se
encuentran en situación de proseguir su ejecución (estado listo y
suspendido). Para visualizarlo esquematizamos la figura 2.8.
Pasar a ejecución
Fin de plazo
Esperar un
Ocurrencia suceso
Nuevo
de suceso
Terminado
Bloqueo
Preparado y
Suspendido
Bloqueado y
Suspendido
Figura 2.8. Diagrama de 5 estados con 2 estados de suspensión.

Las transiciones que involucran a los nuevos estados son las siguientes:
Transición Bloqueado y Suspendido - Preparado y Suspendido:

Esta transición tiene lugar si se ha producido un suceso por el que había
sido bloqueado el proceso suspendido. Es importante tener en cuenta que
esto requiere que este accesible para el sistema operativo la información
relativa a los procesos suspendidos.
Transición Preparado y Suspendido - Preparado: Cuando no hay

procesos preparados en memoria principal el sistema operativo tendrá que
traer de memoria secundaria un proceso que pueda continuar su ejecución.
Además, puede darse el caso de que el proceso en estado Preparado y
Suspendido tenga una nueva prioridad mayor que la de los procesos en
estado Preparado. En este caso se deberá decidir entre ejecutar el proceso
de mayor prioridad con el coste consiguiente de la operación de
intercambio si no hay espacio en memoria principal para todos los
procesos, o bien esperar a que haya espacio suficiente en memoria principal
para albergar al proceso suspendido.
Transición Preparado-Preparado y Suspendido: Como veíamos en

la transición anterior, se puede producir un intercambio entre un proceso
en estado Preparado y Suspendido y otro en estado de Preparado si no hay
memoria suficiente para ambos. Generalmente, el sistema operativo
prefiere suspender a un proceso bloqueado en vez de a uno en estado
Preparado. Sin embargo, puede ser necesario suspender a un proceso
Preparado si ésta es la única forma de liberar un bloque lo suficientemente
grande de memoria principal. Además, el sistema operativo puede escoger
suspender un proceso Preparado de más baja prioridad en lugar de uno
bloqueado de prioridad más alta si se estima que el proceso bloqueado
pronto pasará a estado de Preparado.
Transición Bloqueado y Suspendido-Bloqueado: Si un proceso

termina y libera memoria principal y existe además algún proceso en la cola
de procesos Bloqueados y Suspendidos con mayor prioridad de la de todos
los proceso que se encuentran en la cola de Preparados y Suspendidos, el
SO puede entonces traer el proceso a memoria si tiene razones para
suponer que va a ocurrir pronto el suceso que bloqueo al proceso.
Transición Ejecución-Preparado y Suspendido: Generalmente, un

proceso en ejecución pasa al estado Preparado cuando expira su fracción de
tiempo de procesador, sin embargo, si se está expulsando al proceso porque
hay otro de prioridad mayor en la lista de Bloqueados y Suspendidos que
acaba de desbloquearse, entonces el sistema operativo podría pasar
directamente el proceso en ejecución a la cola de Preparados y Suspendidos,
liberando así espacio en la memoria principal.

Ejemplo:
Un proceso de prioridad, uno en estado Bloqueado, tres procesos de

prioridad dos en Preparado, un proceso en Ejecución de prioridad uno y un
Preparado de prioridad tres.
Un bloqueado y suspendido de prioridad uno. Los bloqueados lo dejarán de

estar pronto.
¿Qué transición tendría lugar?
Entre las razones más habituales para la suspensión de procesos podemos

citar las siguientes:
1. Intercambio un proceso por otro(s): El sistema operativo necesita

liberar memoria principal para cargar un proceso que está listo para
ejecutarse.
2. Suspensión de un proceso por el sistema operativo por sospechar

que está causando algún tipo de problema.
3. Solicitud expresa del usuario.
4. Un proceso puede ejecutarse periódicamente y puede ser

suspendido mientras espera el intervalo de tiempo antes de una
nueva ejecución.
5. Por una petición del proceso padre.
2.3. Estructuras de control.

El sistema operativo es el controlador de los sucesos que se producen en un
sistema informático y es el responsable de planificar y expedir a los
procesos para su ejecución en el procesador.
El sistema operativo es quien asigna los recursos a los procesos y el que

responde a las solicitudes de servicios básicos realizadas por los programas
de usuario, esencialmente se puede considerar al sistema operativo como
una entidad que administra el uso que hacen los procesos de los recursos
del sistema.
A continuación se tratarán los elementos que necesita el sistema operativo

para llevar a cabo sus labores de control de procesos y de administración de
recursos.

Tablas de memoria, de E/S, de archivos
y de procesos
Todo sistema operativo posee información del estado actual de cada uno de
los procesos, independientemente del estado en que se encuentre, ya que de
esta manera, será más sencilla la administración de los recursos.
A través de un sistema sencillo de tablas de memorias de cada entidad,

facilita la administración por parte del sistema operativo. Ejemplo de ello
son las tablas de memoria se utilizan para mantener el control sobre la
memoria principal y la virtual.
Las tablas de memoria deberán incluir la siguiente información:
1. Asignación de memoria principal a los procesos.
2. Asignación de memoria secundaria a los procesos.
3. Atributos de protección de segmentos de memoria principal o

secundaria.
4. Información necesaria para la gestión de la memoria secundaria.
Otro ejemplo de utilización de las tablas, son la utilizadas por el sistema

operativo para la administración de los dispositivos y canales de E/S.
El sistema operativo debe conocer en todo momento el estado en el que se

encuentra un dispositivo o canal de E/S, ya sea porque está siendo utilizado
por algún proceso en particular o porque está a la espera de respuesta por
parte de otro proceso.
También, el sistema operativo utiliza las tablas para conocer el uso

(posición en la memoria principal o virtual) que está haciendo el dispositivo
de E/S, como así también el estado en que se encuentra dicha operación.
El sistema operativo también mantiene un conjunto de tablas de archivos,

las cuales ofrecen información sobre las propiedades de estos. Sobre su
posición y distribución en la memoria secundaria, su estado actual y otros
atributos. Gran parte de esta información, sino toda, puede ser mantenida y
utilizada por un sistema de gestión de archivos. Éste consistirá en un
módulo del sistema operativo bien diferenciado y su labor se ocupará de
todas las operaciones necesarias para la gestión y tratamiento de los
archivos.
Un ejemplo de estructura para la ubicación de archivos es la conocida como

FAT (File Allocation Table: Consiste en una tabla enlazada que hace
referencia a los sectores del disco duro asignados a un mismo archivo. FAT
presenta problemas al fragmentarse frecuentemente lo que provoca un
retardo al acceder a esos datos. Para solucionar este problema existen
herramientas de desfragmentación. En sistemas UNIX se trata desde el

principio más eficientemente esta asignación y los datos almacenados
apenas sufren fragmentación). Un ejemplo de este sistema de archivos sería
el utilizado por el sistema operativo Windows (en sus primeras versiones),
ya que más tarde y en la actualidad utiliza un sistema de archivos muy
diferente, tanto en su organización como en la seguridad de respaldo de
dichos archivos, este sistema fue implementado a partir de los sistemas
Windows NT y es conocido como NTFS (NT Filesystem).
Las tablas de procesos almacenan información relativa al conjunto de

procesos activos presentes en un instante determinado en el sistema. La
información típicamente almacenada para cada proceso y conocida como
imagen del proceso en memoria consiste en:
1. Datos de usuario: Almacena los datos con que trabaja el proceso

así como la pila utilizada por éste (espacio de direcciones del
proceso).
2. Programa de usuario: Contiene el código objeto (código que

puede ser ejecutado por una determinada arquitectura.) del
programa que se va a ejecutar (espacio de direcciones del proceso).
3. Pila de sistema: Se utiliza para almacenar parámetros y

direcciones de retorno (estructuras del sistema operativo).
4. Bloque de control de proceso: Contiene la información

necesaria para que un proceso pueda ser gestionado y controlado
por el sistema operativo (estructuras del sistema operativo).
Bloque de control de procesos (BCP)

El sistema operativo agrupa toda la información que necesita conocer
respecto a un proceso particular en una estructura de datos denominada
descriptor de proceso o bloque de control de proceso (BCP). Cada vez que se
crea un proceso, el sistema operativo crea uno de estos bloques para que
sirva como descripción en tiempo de ejecución durante toda la vida del
proceso, en la figura 2.9 puede verse esta situación más claramente. Cuando
el proceso termina, su BCP es liberado y devuelto al depósito de celdas
libres del cual se extraen nuevos BCPs.
Sistema Operativo
BCPs
Figura 2.9. Bloque de control reservado por el sistema operativo

Un proceso resultará conocido para el SO y, por tanto, susceptible de ser
elegido para competir por los recursos del sistema sólo cuando existe un
BCP activo asociado a él (en el modelo de 5 estados, había un estado
llamado Nuevo en donde el sistema operativo sabía que existía un nuevo
proceso pero sin BCP ya que aún no era candidato para asignarle recursos).
El BCP es una estructura de datos (el sistema operativo tiene bloques de

memoria libres preparados para almacenar BCPs) con campos para
registrar los diferentes aspectos de ejecución del proceso así como de la
utilización de los recursos. La información del BCP se agrupa generalmente
en las siguientes categorías:
1. Identificación del proceso: La información correspondiente a la

identificación del proceso consiste en un conjunto de identificadores
que incluyen:
a) El identificador del proceso (PID): Consiste en un número entero

asignado por el sistema.
b) El identificador del proceso padre.
c) La identificación del usuario: Es una cadena de caracteres.
2. Información del estado del procesador: La información

relativa al estado del microprocesador consta de:
a) Registros visibles para el usuario: Son los registros utilizados por el

proceso para almacenar datos de entrada y resultados.
b) Registros de control y estado, entre los cuales de incluyen el

contador de programa (PC), los registros de códigos de condición
(Bits que reflejan el resultado de una operación aritmética, entre los
que encontramos: bit de overﬂow, bit de acarreo, bit de cero, entre
otros.), los registros con indicadores de habilitación o inhabilitación
de interrupciones y el modo de ejecución.
c) Puntero a la pila del proceso: El proceso utiliza una estructura de

pila para almacenar parámetros y direcciones de retorno de
funciones y procedimientos.
3. Información de control y gestión del proceso: La información

de control y gestión del proceso incluye:
a) Información de planificación y estado: esta información es necesaria

para que el sistema operativo lleve a cabo sus funciones de
planificación. Los elementos típicos de esta información son los
siguientes:
1. Estado del proceso (ejecución, preparado, entre otros).
2. Prioridad de planificación (se utilizarán algoritmos de planificación

que usarán esta información).

3. Información para la planificación: ésta depende del algoritmo de
planificación utilizado.
4. Suceso por el que se encuentre esperando el suceso para reanudar su

ejecución
b) Estructuración de datos: Un proceso puede estar enlazado con otros

procesos formando una cola, un anillo o alguna otra estructura. Por
ejemplo, todos los procesos que se encuentran en estado preparado
con un determinado nivel de prioridad pueden estar enlazado en
una cola. El BCP podría contener entonces punteros a otros BCPs
para dar soporte a esas estructuras.
c) Comunicación entre procesos: en el BCP pueden ubicarse

indicadores, señales y mensajes asociados con la comunicación
entre los procesos independientes.
d) Privilegios de los procesos: A los procesos se les otorgan privilegios

en términos de la memoria a la que pueden acceder y los tipos de
instrucciones que pueden ejecutar. Además, también se pueden
aplicar privilegios al uso de servicios y utilidades del sistema.
e) Gestión de memoria: Esta sección incluye punteros a las tablas de

página y/o segmentos que describen la memoria asignada al
proceso.
f) Recursos en propiedad y utilización de los procesos: Se incluyen los

recursos controlados por el proceso tales como los archivos abiertos
por éste. También se suele incluir un histórico de la utilización del
procesador o de otro recurso.
Esta información puede ser necesaria para el planificador.
2.4. Modelo de Hilos.

El modelo de proceso presentado en el apartado 2.1 suponía que un proceso
era un programa en ejecución con un solo hilo de control. Ahora, la mayoría
de los Sistemas Operativos modernos proporcionan características que
permiten que un proceso tenga múltiples hilos de control.
En esta parte de la lectura se presentan diversos conceptos asociados con

los sistemas informáticos multi-hilos.
La programación multi-hilo afecta de sobremanera al diseño de los sistemas

operativos, independientemente sin son entornos Windows o GNU/Linux.

Hilos
Un hilo es una unidad básica de utilización de la CPU; comprende un ID de
hilo, un contador de programa, un conjunto de registros y una pila.
Comparte con otros hilos que pertenecen al mismo proceso de la sección de
código, la sección de datos y otros recursos del sistema operativo, como los
archivos abiertos y las señales. Un proceso tradicional (0 proceso pesado)
tiene un solo hilo de control. Si un proceso tiene, por el contrario, múltiples
hilos de control, puede realizar más de una tarea a la vez. En la figura 2.10
se ilustra la diferencia entre un proceso tradicional mono hilo y un proceso
multi hilo.
Código Datos Archivos Código Datos Archivos
Registro Pila Registro Registro Registro
Pila Pila Pila
Hilo
Hilos
Proceso de un solo hilo
Proceso multi hilo
Figura 2.10. Proceso de un solo hilo y multi hilo
Muchos paquetes de software que se ejecutan en los PC modernos de

escritorio son multi-hilo.
Normalmente, una aplicación se implementa como un proceso propio con

varios hilos de control. Por ejemplo, un explorador web puede tener un hilo
para mostrar imágenes o texto mientras que otro hilo recupera datos de la
red. Un procesador de textos puede tener un hilo para mostrar gráficos,
otro hilo para responder a las pulsaciones de teclado del usuario y un tercer
hilo para el corrector ortográfico y gramatical que se ejecuta en segundo
plano.
En determinadas situaciones, una misma aplicación puede tener que

realizar varias tareas similares. Por ejemplo, un servidor web acepta
solicitudes de los clientes que piden páginas web, imágenes, sonido, etc.
Un servidor web sometido a una gran carga puede tener varios (quizá,
miles) de clientes accediendo de forma concurrente a él. Si el servidor web
funcionara como un proceso tradicional de un solo hilo, sólo podría brindar
servicio a un cliente cada vez y la cantidad de tiempo que un cliente podría
tener que esperar para que su solicitud fuera servida podría ser enorme.

Una solución es que el servidor funcione como un solo proceso de
aceptación de solicitudes.
Cuando el servidor recibe una solicitud, crea otro proceso para dar servicio
a dicha solicitud. De hecho, este método de creación de procesos era
habitual antes de que los hilos se popularizaran.
Como hemos visto en la sección 2.1, la creación de procesos lleva tiempo y

hace un uso intensivo de los recursos. Si el nuevo proceso va a realizar las
mismas tareas que los procesos existentes, ¿Por qué realizar todo ese
trabajo adicional? Generalmente, es más eficiente usar un proceso que
contenga múltiples hilos. Según este método, lo que se hace es dividir en
múltiples hilos el proceso servidor web. El servidor crea un hilo específico
para escuchar las solicitudes de cliente y cuando llega una solicitud, en
lugar de crear otro proceso, el servidor crea otro hilo para dar servicio a la
solicitud.
Los hilos también juegan un papel importante en los sistemas de llamada a

procedimientos remotos (RPC). Los RPC permiten la comunicación entre
procesos proporcionando un mecanismo de comunicación similar a las
llamadas a funciones o procedimientos ordinarios. Normalmente, los
servidores RPC son multi-hilo. Cuando un servidor recibe un mensaje,
utiliza el mensaje usando un hilo específico. Esto permite al servidor dar
servicio a varias solicitudes concurrentes. Los sistemas RMI (Remote
Method Invocation) de java trabajan de forma similar.
Ahora todos kernels de sistemas operativos son multi-hilo; hay varios hilos
operando en el kernels y cada hilo realiza una tarea específica, tal como
gestionar dispositivos o tratar interrupciones. Por ejemplo, Solaris crea un
conjunto de hilos en el kemel específicamente para el tratamiento de
interrupciones; Linux utiliza un hilo del kernel para gestionar la cantidad
de memoria libre en el Sistema.
Inclusive el sistema Android, presente en la mayoría de los smartfones y

tablets, incluyen la capacidad de multi-hilo.
Dentro de las ventajas de la programación multi-hilo pueden dividirse en

cuatro categorías principales:
1. Capacidad de respuesta. El uso de múltiples hilos en una

aplicación interactiva permite que un programa continúe
ejecutándose incluso aunque parte de él este bloqueado o
realizando una operación muy larga, lo que incrementa la
capacidad de respuesta al usuario. Por ejemplo, un
explorador web multi-hilo permite la interacción del usuario
a través de un hilo mientras que en otro hilo se está cargando
una imagen.
2. Compartición de recursos. Por imprevisión, los hilos

comparten la memoria y los recursos del proceso al que
pertenecen. La ventaja de compartir el código y los datos es

que permite que una aplicación tenga varios hilos de
actividad diferentes dentro del mismo espacio de
direcciones.
3. Economía. La asignación de memoria y recursos para la

creación de procesos es costosa. Dado que los hilos
comparten recursos del proceso al que pertenecen, es más
económico crear y realizar cambios de contexto entre unos y
otros hilos. Puede ser difícil determinar empíricamente la
diferencia en la carga de adicional de trabajo administrativo
pero, en general, se consume mucho más tiempo en crear y
gestionar los procesos que los hilos. Por ejemplo, en Solaris,
crear un proceso es treinta veces más lento que crear un hilo,
y el cambio de contexto es aproximadamente cinco veces
más lento.
4. Utilización sobre arquitecturas multiprocesador.

Las ventajas de usar configuraciones multi-hilo pueden verse
incrementadas significativamente en una arquitectura
multiprocesador, donde los hilos pueden ejecutarse en
paralelo en los diferentes procesadores. Un proceso mono-
hilo sólo se puede ejecutar en una CPU, independientemente
de cuántos haya disponibles. Los mecanismos multi-hilo en
una máquina con varias CPU incrementan el grado de
concurrencia.
Modelos multi-hilo
Hasta ahora, nuestra exposición se ha ocupado de los hilos en sentido
genérico. Sin embargo, desde el punto de vista práctico, el soporte para
hilos puede proporcionarse en el nivel de usuario (para los hilos de usuario)
o por parte del kernel (para los hilos del kernel). El soporte para los hilos de
usuario se proporciona por encima del kernel y los hilos se gestionan sin
soporte del mismo, mientras que el sistema operativo soporta y gestiona
directamente los hilos del kernel. Casi todos los Sistemas operativos
actuales, incluyendo Windows 8, la gran familia de GNU/Linux, Mac OS X,
Solaris y Tru64 UNIX (antes Digital UNIX) soportan los hilos de kernel.
En último término, debe existir una relación entras las hilos de usuario y las
del kernel; en esta sección, vamos a ver tres formas de establecer esta
relación.
Modelo muchos a uno

El modelo muchos a uno (Figura 2.11) asigna múltiples hilos del nivel de
usuario a una hilo del kernel. La gestión de hilos se hace mediante la
biblioteca de hilos en el espacio de usuario, por lo que resulta eficiente, pero

el proceso completo se bloquea si un hilo realiza una llamada bloqueante al
sistema. A su vez, dado que sólo un hilo puede acceder al kernel cada vez,
no podrán ejecutarse varios hilos en paralelo sobre múltiples procesadores,
El sistema de hilos Green, una biblioteca de hilos disponible en Solaris, usa
este modelo, así como GNU Portable Threads.
Hilos de Usuario
Hilos de kernel
Kernel
Figura 2.11. Modelo muchos a uno
Modelo uno a uno

El modelo uno a uno (Figura 2.12) asigna a cada hilo de usuario un hilo del
kernel. Proporciona una mayor concurrencia que el modelo muchos a uno,
permitiendo que se ejecute otro hilo mientras un hilo hace una llamada
bloqueante al sistema; también permite que se ejecuten múltiples hilos en
paralelo sobre varios procesadores. El único inconveniente de este modelo
es que crear un hilo de usuario requiere crear el correspondiente hilo del
kernel. Dado que la carga de trabajo administrativa para la creación de hilos
del kernel puede repercutir en el rendimiento de una aplicación, la mayoría
de las implementaciones de este modelo restringen el número de hilos
soportados por el Sistema. En los sistemas GNU/Linux, junto con la familia
de sistemas operativos Windows (desde la versión 8 hacia abajo),
implementan el modelo uno-a-uno.
Hilos de Usuario
Hilos de kernel
Kernel Kernel Kernel
Figura 2.12. Modelo uno a uno

Modelo muchos a muchos
El modelo muchos a muchos (Figura 2.13) multiplexa muchos hilos de
usuario sobre un número menor o igual de hilos del kernel. El número de
hilos del kernel puede ser específico de una determinada aplicación 0 de
una determinada máquina (pueden asignarse más hilos del kernel a una
aplicación en un sistema multiprocesador que en uno de un solo
procesador). Mientras que el modelo muchos a uno permiten al
desarrollador crear tantos hilos de usuario como desee, no se consigue una
concurrencia real, ya que el kernel sólo puede planificar la ejecución de un
hilo cada vez.
Hilos de Usuario
Hilos de kernel
Kernel Kernel Kernel
Figura 2.13. Modelo muchos a muchos
El modelo uno a uno permite una mayor concurrencia, pero el desarrollado:

debe tener cuidado de no crear demasiados hilos dentro de una aplicación
(y, en algunos casos, el número de hilos que pueda crear estará limitado). El
modelo muchos a muchos no sufre ninguno de estos inconvenientes. Los
desarrolladores pueden crear tantos hilos de usuario como sean necesarias
y los correspondientes hilos del kernel pueden ejecutarse en paralelo en un
multiprocesador: Asimismo, cuando un hilo realiza una llamada bloqueante
al sistema, el kernel puede planificar otro hilo para su ejecución.
Una popular variación del modelo muchos a muchos multiplexa muchos

hilos del nivel de usuario sobre un número menor o igual de hilos del
kernel, pero también permite acopiar un hilo de usuario a un hilo del
kernel. Algunos sistemas operativos como IRIX, HP-UK y Tru64 UNIX
emplean esta variante, que algunas veces se denomina modelo de dos
niveles (Figura 2.14). El sistema operativo Solaris permitía el uso del
modelo de dos niveles en las versiones anteriores al Solaris 9. Sin embargo,
a partir de Solaris 9, este sistema emplea el modelo uno a uno.

Hilos de
Kernel Kernel Kernel Kernel
Hilos de kernel
Figura 2.14. Modelo de dos niveles
Bibliotecas de hilos
Una biblioteca de hilos proporciona al programador una API (Application
Programming Interface, interfaz de programación de aplicaciones) para
crear y gestionar hilos.
Existen dos formas principales de implementar una biblioteca de hilos. El

primer método consiste en proporcionar una biblioteca enteramente en el
espacio de usuario, sin ningún soporte del kernel. Todas las estructuras de
datos y el código de la biblioteca se encuentran en el espacio de usuario.
Esto significa que invocar a una función de la biblioteca es como realizar
una llamada a una función local en el espacio de usuario y no una llamada
al sistema.
El segundo método consiste en implementar una biblioteca en el nivel del

kernel, soportada directamente por el sistema operativo. En este caso, el
código y las estructuras de datos de la biblioteca se encuentran en el espacio
del kernel. Invocar una función en la API de la biblioteca normalmente da
lugar a que se produzca una llamada al sistema dirigida al kernel.
Las tres principales bibliotecas de hilos actualmente en uso Son: (1) POSIX
Pthreads, (2) Win32 y (3) Java. Pthreads, la extensión de hilos del estándar
POSIX, puede proporcionarse como biblioteca del nivel de usuario o del
nivel de kernel. La biblioteca de hilos de Win32 es una biblioteca del nivel
de kernel disponible en los sistemas Windows. La API de hilos de Java
permite crear y gestionar directamente hilos en los programas java. Sin
embargo, puesto que en la mayoría de los casos la JVM (Java Virtual
Machine) se ejecuta por encima del sistema operativo del host, la API de
hilos lava se implementa habitualmente usando una biblioteca de hilos
disponible en el sistema host. Esto significa que, normalmente, en los
sistemas Windows, los hilos Java se implementan usando la API de Win32,
mientras que en los sistemas GNU/LinuxLinux se suelen implementar
empleando Pthreads.

2.5. Control de procesos.
La planificación es una función fundamental del sistema operativo. Siendo
la CPU uno de los principales recursos, la planificación de su uso es
sumamente importante.
En un ambiente de multiprogramación, el sistema operativo debe decidir a

qué proceso le otorga la CPU entre los que están listos para ejecutarse.
¿Cuál es el criterio por el cual se prefiere la ejecución de uno sobre los
otros?
Existen diferentes algoritmos de selección, pero para escoger cuál es el que

corresponde a nuestro sistema debemos tener claro bajo qué criterios nos
interesa fijar las pautas. Por ejemplo:
• Maximizar el uso de la CPU: que se mantenga ocupada el mayor

tiempo posible.
• Maximizar la Productividad (throughput), considerando que

productividad (o rendimiento) es el número de procesos que se
ejecutan por unidad de tiempo.
• Minimizar el Tiempo de retorno (turnaround time), que es el tiempo

transcurrido desde que el proceso ingresa hasta que termina,
sumando espera para entrar en memoria, en cola de procesos listos,
ejecutándose en CPU y haciendo E/S.
• Minimizar el Tiempo de espera (waiting time), que es el tiempo que

el proceso está en la cola de listos.
• Minimizar el Tiempo de respuesta (response time), que es el tiempo

que transcurre desde que se presenta una solicitud hasta que se
tiene respuesta. Es el tiempo que tarda en comenzar a responder, no
incluyendo el tiempo de la respuesta en sí.
Lo ideal es maximizar el uso de la CPU y la productividad y minimizar los

tiempos de retorno, respuesta y espera.
Son otros criterios:
• La equidad: que todos los procesos tienen que ser tratados de igual
forma y a todos se les debe dar la oportunidad de ejecutarse, para
que ninguno sufra inanición.
• Recursos equilibrados: la política de planificación que se elija debe

mantener ocupados los recursos del sistema, favoreciendo a
aquellos procesos que no abusen de los recursos asignados,
sobrecargando el sistema y bajando la performance general.

Organización. Colas y schedulers
Colas
En un sistema operativo los recursos compartidos exigen la organización en

colas de las solicitudes pendientes. Tenemos colas para la planificación del
uso de la CPU como también colas para el uso de dispositivos, device
queues, que son utilizadas para ordenar los requerimientos que varios
procesos pueden tener sobre un dispositivo específico.
Al ser creados, los procesos se colocan en la cola de trabajos, formada por

los procesos que aún no residen en la memoria principal pero listos para su
ejecución.
La residencia en memoria es imprescindible para la ejecución de un

proceso. La cola de trabajos listos (ready queue) es aquella formada por los
procesos que están listos para la ejecución, en memoria principal. Son los
procesos que compiten directamente por CPU.
Un proceso que está en la cola de listos no puede estar en las colas de

dispositivo, pues en este último caso se encuentra esperando por E/S, por lo
tanto no puede estar compitiendo por CPU.
Los elementos de cualquiera de estas colas no son los procesos en sí, sino
sus PCB’s (Programa de control de bloqueo), que están en memoria.
La cola de procesos listos (ready queue) se almacena como una lista

enlazada donde la cabecera (header) de la ready queue tiene punteros al
primer y al último PCB de los procesos de la lista. Cada PCB apunta al
próximo en la lista.
Schedulers, dispatchers – Planificadores, activadores
Hay módulos del sistema operativo para elegir un proceso para su ejecución
de entre los que están compitiendo por CPU. Esa elección dependerá del
criterio adoptado. La elección estará asociada al carácter del sistema. Por
ejemplo, en un sistema batch (sistema por lotes) no hay tanta exigencia en
cuanto al tiempo de respuesta. En un sistema interactivo minimizar este
tiempo es imprescindible.
El algoritmo que se erigirá para la elección de procesos será diferente en

cada caso.
Recordemos que los sistemas operativos modernos permiten la convivencia

de las dos modalidades (batch e interactivo). ¿Cómo lo solucionamos?
Necesitamos que el sistema operativo, a través de sus módulos, elija un

proceso de acuerdo al criterio elegido, haga el cambio de contexto, lo cargue
en memoria y le dé la CPU. Cuando un proceso termina, normal o
anormalmente, debe elegirse otro proceso para cargar en memoria.

¿Qué pasa cuando un proceso de mayor prioridad debe ejecutarse y no hay
memoria suficiente? Un módulo debe encargarse de seleccionar uno de los
procesos que está en memoria y sacarlo temporariamente a memoria
secundaria para dar lugar (swapping), pero teniendo en cuenta que sigue
compitiendo por CPU y que se debe resguardar su contexto.
Estos módulos del sistema operativo son rutinas especiales y dependerá de

la implementación cómo las funciones que citamos se realizan en cada
sistema.
En un sistema hay procesos con mayor proporción de ráfagas E/S (I/O

bound process) y otros con mayor necesidad de CPU que de E/S (CPU
bound). Si cuando se seleccionan procesos para ejecutar se eligieran todos
I/O bound, tendríamos las colas de dispositivo llenas de solicitudes y,
probablemente, la CPU ociosa. Si se eligen muchos procesos limitados por
CPU la cola de listos estará llena y las colas de dispositivo, vacías. Por eso es
muy importante de qué manera se realiza la selección de trabajos para
mantener el sistema en equilibrio.
Esta selección la realizan los planificadores o schedulers.
Hay distintos planificadores que participan en diferentes momentos:
• El de largo plazo o long term, que elige entre la cola de listos, para
cargarlo en memoria.
• El de corto plazo o short term (también llamado CPU scheduler),

que elige entre los que están listos en memoria para darle la CPU.
• El de medio plazo o medium term, que selecciona un proceso de

entre los que están en memoria para llevarlo temporariamente a
memoria secundaria por necesidades de espacio en memoria.
Es importante aclarar que en las colas los registros son normalmente las
PCB’s de los procesos.
Otro módulo de importante participación en la planificación es el activador

o dispatcher (despachador). Es el que da el control de la CPU al proceso
elegido por el planificador de corto plazo.
Debe ser muy rápido pues una de sus funciones es encargarse del cambio de
contexto (context switch). Al tiempo entre detener un proceso y comenzar a
correr otro se le llama dispatch latency.
El dispatcher es también el que se encarga de pasar a modo usuario el

proceso que esta activando y “saltar” a la dirección de la instrucción que
comienza la ejecución del programa.

Análisis sobre la productividad
Hemos hablado que en un ambiente de multiprogramación cuando un

proceso se bloquea a la espera de algún evento, la CPU atiende al primer
proceso que se halle en la cola de procesos listos (ready) para su ejecución.
Si un proceso P0 (P cero) dura en total 11 segundos, intercalándose las

ráfagas de CPU y de E/s, si no existiera la posibilidad de atender otro
proceso P1 en los momentos que P0 hace E/S, P1 debería esperar hasta la
culminación de P0 para ejecutarse.
Si vamos en cambio intercalando el proceso de CPU de P0 con el de P1 (en

el momento que P0 hace E/S) aumentaremos la productividad pues en un
período menor de tiempo aumentamos la cantidad de trabajos realizados
incidencia del cambio de contexto (context switching).
El tiempo del cambio de contexto varía según el hardware. La velocidad de

memoria, número de registros y si hay o no instrucciones especiales,
inciden en ese tiempo.
En el análisis que haremos aquí no consideramos el tiempo para el context

switching pues este debería ser despreciable en comparación con el
quantum que se elija. Véase que un sistema donde este tiempo es
considerable, el sistema operativo tendrá mucho tiempo dedicado a esta
operación, en vez de dedicarlo a procesar.
Procesos orientados a la E/S y procesos orientados a la CPU
Hay procesos orientados a la E/S y procesos orientados a la CPU.
Los procesos orientados a la CPU tienen proporcionalmente ráfagas de CPU

mayores a las de E/S, siendo estas últimas además, pocas.
Normalmente los procesos de este tipo utilizan toda su porción de tiempo o

quantum al no tener que abandonar la CPU por E/S.
Los procesos orientados a la E/S tienen proporcionalmente ráfagas de E/S

mayores a las de CPU y muy seguidas. En un ambiente de
multiprogramación donde haya preponderancia de estos procesos, habrá
una intervención muy frecuente del planificador de corto plazo, y mucho
cambio de contexto.
La planificación de procesos en ambientes multiprocesador
En el caso en que los procesadores son idénticos, 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 común, y la atención se realiza de
acuerdo a la actividad de cada uno.
En ambientes de procesadores heterogéneos no olvidemos que un

procesador podría ejecutar solo aquellos procesos que fueron compilados
de acuerdo a su conjunto de instrucciones.
En otros sistemas se asume una estructura de procesadores master-slave

que asigna a un procesador la toma de decisiones en cuanto a scheduling y
otras actividades, dedicándose los otros procesadores a ejecutar código de
usuario. La ventaja es que sólo el procesador master accede a estructuras
del kernel, evitando inconsistencias.
Un ejemplo: Windows NT
El sistema operativo Windows NT es un ejemplo de diseño moderno que

utiliza modularidad para incrementar la funcionalidad y reducir el tiempo
necesario para implementar nuevas características. NT apoya múltiples
entornos operativos o subsistemas con los que los programas de aplicación
se comunican empleando un sistema de transferencia de mensajes.
Los programas de aplicación se pueden considerar como clientes del

servidor de subsistemas NT.
El recurso de transferencia de mensajes en Windows NT se llama Recurso

de Llamada a Procedimiento Remoto (LPC, Local Procedure Call), y sirve
para que se comuniquen entre sí dos procesos que están en la misma
máquina. El mecanismo es similar al de llamada a procedimientos remotos
estándar de uso general pero optimizado y específico para NT.
Windows NT, al igual que Mach, utiliza un objeto puerto para establecer y
mantener una conexión entre dos procesos. Cada cliente que invoca un
subsistema necesita un canal de comunicación, mismo que el objeto puerto
proporciona y que nunca se hereda. NT maneja dos tipos de puertos,
puertos de conexión y puertos de comunicación, que en realidad son iguales
pero reciben diferentes nombres según la forma en que se usa. Los puertos
de conexión son objetos con nombre, visibles para todos los procesos, y
ofrecen a las aplicaciones una forma de establecer un canal de
comunicación. La comunicación funciona como sigue:
• El cliente abre un mando para el objeto puerto de conexión del

subsistema.
• El cliente envía una solicitud de conexión.
• El servidor crea dos puertos de comunicación privados y devuelve el

mando de uno de ellos al cliente.
• El cliente y el servidor usan el mando de puerto correspondiente

para enviar mensajes o devoluciones de llamada y esperar
respuestas.

NT emplea tres tipos de técnicas de transferencia de mensajes por un
puerto que el cliente especifica cuando establece el canal. La más sencilla,
que se usa si el mensaje es pequeño, consiste en utilizar la cola de mensajes
del puerto como almacenamiento intermedio y copiar el mensaje de un
proceso al otro. Es posible enviar mensajes de hasta 256 bytes con este
método.
Si un cliente necesita enviar un mensaje más grande, lo transfiere a través

de un objeto sección (memoria compartida). El cliente tiene que decidir,
cuando establece el canal, si necesitará o no enviar un mensaje grande. Si el
cliente determina que desea enviar mensajes grandes, pide que se cree un
objeto sección. Asimismo, si el servidor decide que las respuestas serán
grandes, también creará un objeto sección. Para usar este objeto, se envía
un mensaje pequeño que contiene un puntero e información de tamaño
referente al objeto sección. Este método es un poco más complicado que el
primero, pero evita el copiado de datos. En ambos casos se puede utilizar
un mecanismo de devolución de llamada si el cliente o el servidor no
pueden responder de inmediato a una solicitud. El mecanismo de
devolución de llamada hace posible el manejo asincrónico de mensajes.
Una de las desventajas del uso de transferencia de mensajes para

desempeñar funciones rudimentarias, como la de gráficos, es que el
desempeño podría no ser tan bueno como el de un sistema de memoria
compartida. Con objeto de mejorar el desempeño, el entorno NT nativo
(Win32) utiliza un tercer método de transferencia de mensajes llamado LPC
rápida.
Un cliente envía una solicitud de conexión al puerto de conexión del

servidor e indica que usará LPC rápida. El servidor crea un hilo dedicado
para atender las solicitudes, un objeto sección de 64 KB, y un objeto par de
sucesos. A partir de ese momento, los mensajes se pasan a través del objeto
sección y el objeto par de sucesos se encarga de la sincronización. Esto
elimina el copiado de mensajes, el gasto extra de usar el objeto puerto, y el
gasto extra que implica determinar cuál hilo cliente llamó, ya que sólo hay
un hilo servidor para cada hilo clientes. Además, el núcleo concede al hilo
dedicado preferencia de planificación. Desde luego, la desventaja de este
método es que consume más recursos que los otros dos. Puesto que la
transferencia de mensajes implica cierto gasto extra, NT podría juntar
varios mensajes en uno solo para reducir ese gasto extra.

2.6. Concurrencia,
comunicación y
sincronización. Bloqueos.
Concurrencia
La concurrencia es el punto clave en los conceptos de multitarea,
multiprogramación y multiproceso y es fundamental para el diseño de los
sistemas operativos. La concurrencia comprende un gran número de
cuestiones de diseño incluyendo la comunicación entre procesos, la
compartición y competencia por los recursos, la sincronización de la
ejecución de varios procesos y la asignación del procesador a los procesos;
puede presentarse en tres contextos diferentes:
• Varias aplicaciones: en este caso el tiempo de procesador de una

máquina es compartido dinámicamente entre varios trabajos o
aplicaciones activas.
• Aplicaciones estructuradas: como consecuencia del diseño modular

de una aplicación y la división de la misma en tareas explicitas estas
pueden ser ejecutadas de forma concurrente.
• Estructura del sistema operativo: como resultado de la aplicación de

la estructuración en el diseño del propio sistema operativo, de forma
que este se implemente como un conjunto de procesos.
Como soporte a la actividad concurrente, el sistema operativo debe ser

capaz de realizar un estrecho seguimiento de los procesos activos,
asignando y desasignando recursos entre ellos, el sistema operativo debe
proteger los datos y recursos de cada proceso contra injerencias o
intrusiones intencionadas o no, de otros procesos.
El resultado de un proceso debe ser absolutamente independiente de la

velocidad relativa a la que se realice su ejecución con respecto al resto de
procesos, y por supuesto dicho resultado debe ser similar al obtenido si la
ejecución del proceso se realizara de forma individual.

Comunicación y sincronización de
procesos
Posibilidades de interacción de procesos
Las posibilidades de interacción de los procesos pueden clasificarse en

función del nivel de conocimiento que cada proceso tiene de la existencia de
los demás.
1. Un proceso no tiene en absoluto conocimiento de la existencia de los

demás. Se trata de procesos independientes que no están
preparados para trabajar conjuntamente y mantienen entre sí una
relación exclusivamente de competencia.
2. Que los procesos tengan un conocimiento indirecto de los otros

procesos. Esta situación tiene lugar cuando los procesos no tienen
un conocimiento explícito entre ellos, pero comparten el acceso a
algunos dispositivos o zonas de memoria del sistema. Entre estos
procesos se establece una relación de cooperación por compartir
objetos comunes.
3. Tiene lugar cuando los procesos tienen conocimiento directo unos

de otros por haber sido diseñados para trabajar conjuntamente la
alguna actividad. Esta situación muestra una relación claramente de
cooperación.
En cualquiera de estas tres situaciones hay que dar solución a tres

problemas de control:
5. Necesidad de exclusión mutua, es decir, los procesos deberán

acceder de forma exclusiva a ciertos recursos o zonas de
memoria considerados como críticos.
6. Interbloqueos: tienen lugar cuando ninguno de los procesos

en competencia puede continuar su ejecución normal por
carecer de alguno de los recursos que necesita.
7. Inanición: este problema tiene lugar cuando la ejecución de

un proceso queda siempre pospuesta a favor de algún otro de
los procesos en competencia.
Por supuesto, el control de la concurrencia involucra inevitablemente al

sistema operativo ya que es el encargado de asignar y arrebatar los recursos
del sistema a los procesos.
Necesidad de sincronización de los procesos: región crítica y

exclusión mutua
Independientemente del tipo de interacción existente entre los distintos

procesos activos, en un sistema con multiprogramación éstos comparten un

conjunto de elementos que deben ser accedidos de forma controlada para
evitar situaciones de inconsistencia.
Estos elementos compartidos ya sean dispositivos de E/S o zonas de

memoria comunes son considerados como críticos y la parte del programa
que los utiliza se conoce como región o sección crítica. Es muy importante
que sólo un programa pueda acceder a su sección crítica en un momento
determinado. Por esta razón, el sistema operativo debe ofrecer mecanismos
que hagan posible una correcta sincronización de los distintos procesos
activos en los accesos a los recursos que comparten.
El uso de variables compartidas es una forma sencilla y habitual de

comunicación entre procesos interactivos. Cuando un conjunto de procesos
tiene acceso a un espacio común de direcciones, se pueden utilizar variables
compartidas para una serie de cometidos como, por ejemplo, indicadores de
señalización o contadores. Sin embargo, la actualización de variables
compartidas puede conducir a inconsistencias; por esta razón, cuando se
utilicen hay que asegurarse de que los procesos acceden a ellas
debidamente ordenados.
Bloqueos
Principios del bloqueo
Una situación de bloqueo tiene lugar cuando ninguno de los procesos que
compiten por los recursos del sistema o interactúan entre sí puede avanzar
por carecer de algún recurso o esperar a que se produzca algún tipo de
evento.
Recursos reutilizables
Un recurso reutilizable es aquel que puede ser utilizado por un proceso y no

se agota por hacer uso del mismo, los procesos obtienen unidades de estos
recursos y tras utilizarlas las liberan para que puedan ser reutilizadas por
otros procesos. Como ejemplos de recursos reutilizables tenemos el
procesador, la memoria principal y los dispositivos E/S.
Recursos consumibles
Un recurso consumible es aquel que puede ser producido y consumido.

Normalmente no hay límite en el número de recursos consumibles de un
tipo particular. Así un proceso productor podría liberar cualquier número
de recursos consumibles. Las únicas restricciones en este sentido vendrán
impuestas por la capacidad de almacenamiento temporal del sistema.
Cuando un proceso consume un recurso de este tipo la parte consumida

queda excluida del sistema. Ejemplos típicos son: interrupciones, señales y
mensajes.
A continuación veremos una secuencia que muestra la posibilidad de

bloqueo entre procesos que utilizan recursos consumibles.
P1
recibir(P2,M)
enviar(P2,M)
P2
recibir(P1,M)
enviar(P1,M)
A continuación veremos otra secuencia que produce bloqueo entre procesos

que utilizan recursos reutilizables.
P1
solicitar(A)
solicitar(B)
P2
solicitar(B)
solicitar(A)
Condiciones de bloqueo
Deben darse tres condiciones para que se produzca un bloqueo:
1. Que exista acceso a algún recurso en exclusión mutua.
2. Que un proceso pueda retener los recursos que le han sido

asignados mientras espera que se le asignen los que
necesitan.
3. Que ningún proceso pueda ser obligado a abandonar los

recursos que retenga.
Estas tres condiciones de bloqueo son condiciones necesarias pero no

suficientes, es decir, pueden producirse tales situaciones y que el sistema no

evolucione a un bloqueo (de hecho, estas tres situaciones se dan con mucha
frecuencia de forma natural).
Para que se produzca bloqueo, debe darse una cuarta condición que
consiste en la existencia de una cadena cerrada de procesos donde cada uno
de los cuales retiene al menos un recurso de los que necesita el siguiente
proceso de la cadena para continuar su ejecución. A esta condición se le
denomina espera circular.
Prevención de bloqueos
La estrategia de prevención consiste, a grandes rasgos, en diseñar un

sistema de manera que este excluido a priori la posibilidad de bloqueo. Los
métodos para prevenir bloqueos son de dos tipos:
• Métodos indirectos; que consisten en prevenir o impedir la

aparición de alguna de las tres condiciones iniciales de interbloqueo.
• Métodos directos; que consisten en evitar la aparición del círculo

vicioso de espera, es decir, la cuarta condición.
A continuación se examinarán las técnicas empleadas para impedir cada

una de las cuatro condiciones.
1. Condición de exclusión mutua: No puede anularse, ya que si

el acceso a un recurso requiere exclusión mutua, el SO debe
soportarlo.
2. Retención y espera: Puede prevenirse exigiendo que todos

los procesos soliciten todos los recursos que necesitan a un
tiempo y bloqueando al proceso hasta que todos los recursos
puedan concedérsele simultáneamente. Esta solución resulta
ineficiente por dos factores:
a) En primer lugar, un proceso puede estar bloqueado

durante mucho tiempo esperando que se le concedan
todas sus solicitudes de recursos cuando, de hecho,
podría haber avanzado con sólo alguno de los recursos.
b) Los recursos asignados a un proceso pueden permanecer

sin usarse durante periodos considerables de tiempo
durante los cuales se priva a otros procesos de acceder a
estos recursos.
3. Condición de No Apropiación: Esta condición puede

prevenirse de varias formas:
a) Si a un proceso que retiene ciertos recursos, se le deniega

una nueva solicitud, dicho proceso deberá liberar los
recursos que poseía y solicitarlos de nuevo junto con el

recurso que le ha sido denegado (ésta parece la más
interesante de las dos).
b) Si un proceso solicita un recurso que está retenido por

otro proceso, el sistema operativo puede expulsar al
segundo proceso y exigirle que libere el recurso. Este
último esquema evita el bloqueo sólo si dos procesos no
pueden tener la misma prioridad con respecto a la
posesión de un recurso.
4. Circulo vicioso de espera: Esta condición puede prevenirse

definiendo una ordenación lineal en los tipos de recursos. Si
a un proceso se le han asignado recursos de tipo R sólo podrá
realizar peticiones posteriores sobre los recursos de los tipos
siguientes a R en la ordenación. Para implementar esta
estrategia se asocia un índice a cada tipo de recurso de forma
que si un proceso solicita el recurso Ri y a continuación el
recurso Rj debe cumplirse que i < j.
Detección de bloqueos
Las estrategias de detección de interbloqueos no limitan el acceso a los

recursos ni restringen las acciones de los procesos como ocurría con las
estrategias de prevención de bloqueos, mediante las estrategias de
detección de bloqueos se concederán los recursos que los procesos
necesitan siempre que sea posible. Periódicamente el sistema operativo
ejecuta un algoritmo que permite detectar la condición de círculo de espera.
Los algoritmos de detección más comúnmente utilizados son algoritmos
basados en grafos dirigidos. El control del interbloqueo puede llevarse a
cabo tan frecuentemente como las solicitudes de los recursos o con una
frecuencia menor, dependiendo de la probabilidad de que se produzca un
bloqueo.
La comprobación en cada solicitud de recurso tiene dos ventajas:
• Conduce a una pronta detección.
• El algoritmo es relativamente simple puesto que está basado en

cambios incrementales del estado del sistema.
Por otro lado, la frecuencia de comprobación consume un tiempo de CPU

considerable.
Una vez detectado el bloqueo, es posible implementar alguna estrategia de

recuperación, las siguientes técnicas son posibles enfoques enumerados por
orden de sofisticación.
1. Abandono de todos los procesos bloqueados: es la técnica más

utilizada por los sistemas operativos.

2. Retroceder cada proceso bloqueado hasta algún punto de control
definido previamente y volver a ejecutar todos los procesos. El
riesgo de esta solución es que puede volver a producirse el bloqueo
inicial, sin embargo el no determinismo del procesamiento
concurrente posibilita que esto no vuelva a ocurrir.
3. Abandonar sucesivamente los procesos bloqueados hasta que deje

de haber bloqueo. Para ello, se seguirá un criterio de mínimo coste.
Después de abandonar cada proceso se debe ejecutar de nuevo el
algoritmo de detección para ver si todavía existe el bloqueo.
4. Apropiación sucesiva de recursos hasta que deje de haber bloqueo

por parte de alguno de los procesos. Se debe emplear también una
solución basada en el coste y hay que ejecutar de nuevo el algoritmo
de detección después de cada apropiación.
Un proceso que pierda un recurso porque otro se lo apropie deberá

retroceder hasta un momento anterior a la adquisición de este recurso.
Para las dos últimas estrategias, el criterio de selección podría ser una de las
siguientes elecciones (siempre hablando de procesos a elegir):
1. La menor cantidad de tiempo de procesador consumido hasta el

momento. Se aplica el criterio de mínimo coste ya que el proceso
hay que repetirlo.
2. Menor número de líneas de salida producidas hasta el momento.
3. Mayor tiempo restante estimado.
4. Menor número de recursos asignados hasta el momento.
5. Prioridad más baja.
El algoritmo de detección de bloqueo no se ejecuta cada vez que un proceso

solicita un recurso, sino con una frecuencia menor.
Predicción de bloqueo. Algoritmo del banquero
En la predicción de bloqueo, se decide dinámicamente si la petición actual

de un recurso podría, de concederse, llevar potencialmente a un bloqueo. La
predicción de bloqueo necesita, por tanto, conocer las peticiones futuras de
recursos.
A continuación describiremos los dos enfoques para la predicción del

bloqueo.

Negativa de iniciación de procesos
Este enfoque consiste en no iniciar un proceso si sus demandas de recursos

pueden llevar a un interbloqueo. Consideremos un sistema con n procesos
activos y m tipos diferentes de recursos. Definiremos los vectores y matrices
siguientes:
R1
.
Donde Ri denota la cantidad
1. Vector de recursos: VR = del recurso i que hay en el
.
sistema.
.
Rm
AV1
.
2. Vector de recursos disponibles: AVR =
.
AVm
Donde AVi denota la cantidad de recurso i disponible en un

momento dado en el sistema.
C11 . . . Cn1
. .
3. Matriz demanda CR =
. . .
. .
C1m ... Cnm
Donde Cij la exigencia máxima que el proceso i tiene del recursos j (Se lee
por columnas: La columna uno indica las exigencias máximas del recurso
uno respecto de todos los recursos. Se lee por filas: La fila uno indica la
exigencia de todos los procesos sobre el recurso uno).
A11 . . . An1
. .
4. Matriz de asignación AR =
. . .
. .
A1m ... Anm

Donde Aij denota la cantidad de recurso j que tiene el proceso i en un
instante determinado, es decir, el total de recursos que tiene asignado un
proceso vendría dado por el vector:
Ai1
.
AiR = .
Aim
Donde i identifica al proceso.
Después de definir estas matrices y vectores, deben cumplirse las siguientes

condiciones.
n Akj + AVj = Rj. El número de unidades de un recurso es la
1. ∀j ∈ [1, m] ∑ k=1
suma de las unidades utilizadas y las unidades ociosas.
2. ∀i ∈ [1, n] , ∀k ∈ [1, m] Cik ≤ Rk. La demanda de ningún proceso sobre

ningún recurso puede superar la cantidad del recurso.
3. ∀i ∈ [1, n] , ∀k ∈ [1, m] Aik ≤ Cik. Ningún proceso puede tener asignada

más cantidad de un recurso que la que especifica su demanda máxima.
Teniendo en cuenta estas restricciones, un proceso n + 1 sólo puede

arrancarse si:
n+1
∀j ∈ [1, m] ∑ Ckj ≤ Rj
K=1
En palabras: la suma de las demandas máximas de todos los procesos

(incluido el candidato a nuevo) en relación a un recurso no debe superar
nunca la cantidad de ese recurso en el sistema. De esta forma, nos
aseguramos de que en el peor de los casos (todos piden demanda máxima)
todos podrán ser satisfechos.
Hay que tener en cuenta que siempre estamos ante la presencia de un

sistema operativo ideal, en el cual no acurren intervenciones ajenas al
sistema operativo, llámese otros programas u otras interrupciones.

Negativa de asignación de recursos
Esta estrategia también se denomina algoritmo de Banquero y fue

propuesta por primera vez por Dijkstra. Se comienza definiendo los
conceptos de estado y estado seguro.
El estado de un sistema en un momento dado es simplemente la asignación

actual de recursos a los procesos, así pues, el estado estará formado por los
vectores de recursos y de recursos disponibles, y por las matrices de
demanda y asignación definidas previamente. Teniendo esto en cuenta, un
estado seguro es un estado en el cual existe al menos un orden en que todos
los procesos pueden ejecutar hasta el final sin generar un bloqueo. Un
estado inseguro es, lógicamente, todo estado que no sea seguro.
La estrategia de predicción de bloqueo consiste en asegurar que el sistema

esté siempre en un estado seguro. Para conseguir esto, cuando un proceso
realiza una solicitud de un recurso o de un conjunto de recursos, se supone
que la solicitud se le concede, a continuación se actualiza el estado del
sistema para que refleje la nueva situación y se determina si en esa nueva
situación, el sistema se encuentra en un estado seguro. Si el estado es
seguro se concede la solicitud, mientras que si no lo es, el proceso
solicitante es bloqueado hasta que concederle los recursos lleve a un estado
seguro.
2.7. Planificación de
procesos. Algoritmos de
planificación.
Planificación de procesos
La planificación hace referencia a un conjunto de políticas y mecanismos
incorporados al sistema operativo que gobiernan el orden en que se
ejecutan los trabajos que deben ser completados por el sistema informático.
Un planificador es un módulo del sistema operativo que selecciona el
siguiente trabajo a admitir en el sistema y el siguiente proceso que tomará
el control sobre el procesador. El objetivo primario de la planificación es
optimizar el rendimiento del sistema de acuerdo con los criterios
considerados más importantes por los diseñadores del mismo.
Entre las medidas de rendimiento y los criterios de optimización más

habituales que los planificadores utilizan para llevar a cabo su labor se
encuentran los siguientes:

Utilización del procesador:
La utilización del procesador es la fracción de tiempo promedio durante la

cual el procesador está ocupado, es decir, la fracción de tiempo durante la
cual el procesador se encuentra activo ejecutando algún proceso, bien de
usuario, bien del propio sistema operativo. Con esta interpretación, la
utilización del procesador puede ser medida con relativa facilidad, por
ejemplo mediante un proceso nulo especial (1) que se ejecute cuando
ningún otro proceso pueda hacerlo.
(1)
En MINIX existe un proceso llamado idle:
idle(){
for(;;);
Una alternativa es considerar únicamente la operación en modo usuario y,

por tanto, excluir el tiempo empleado para el sistema operativo (podríamos
decir que el tiempo de uso real del procesador es el tiempo total de uso
menos el tiempo que se estuvo ejecutando la instrucción idle()).
En cualquier caso, el objetivo es mantener al procesador ocupado tanto

tiempo como sea posible. De esta forma, se conseguirá que los factores de
utilización de los restantes componentes también sean elevados
obteniéndose con ello buenas medidas de rendimiento.
Productividad
La productividad se refiere a la cantidad de trabajo completada por unidad

de tiempo.
Un modo de expresarla es definiéndola como el número de trabajos de

usuario ejecutados por una unidad de tiempo. Cuanto mayor sea este
número, más trabajo aparentemente está siendo ejecutado por el sistema.
Tiempo de retorno
El tiempo de retorno TR se define como el tiempo que transcurre desde el

momento en que un trabajo o programa es remitido al sistema hasta que es
totalmente completado por el mismo. Es decir, el tiempo de retorno TR es
el tiempo consumido por el proceso dentro del sistema y puede ser
expresado como la suma del tiempo de servicio o tiempo de ejecución + el
tiempo de espera. TR = TS + TE.
Tiempo de espera
El tiempo de espera TE es el tiempo que un proceso o trabajo consume a la

espera de la asignación de algún recurso o de que tenga lugar algún evento.
En este tiempo también se incluyen el periodo de espera por la obtención
del propio procesador (no confundir estos tiempos. El tiempo de espera por
el procesador está incluido en el tiempo de espera total TE) debido a la

competencia con otros procesos en un sistema con multiprogramación. Este
tiempo es la penalización impuesta por compartir recursos con otros
procesos y puede expresarse como el tiempo de retorno - el tiempo de
ejecución efectivo. El tiempo de espera TE elimina la variabilidad debida a
las diferencias en tiempos de ejecución del trabajo.
Tiempo de respuesta
El tiempo de respuesta en sistemas interactivos se define como el tiempo

que transcurre desde el momento en que se introduce el último carácter de
una orden que desencadena la ejecución de un programa o transacción
hasta que aparece el primer resultado en el terminal.
Generalmente también se le denomina tiempo de respuesta de terminal.
En sistemas en tiempo real, el tiempo de respuesta es esencialmente una

latencia y se define como el tiempo que transcurre desde el momento en
que un suceso interno o externo es señalado hasta que se ejecuta la primera
instrucción de su correspondiente rutina de servicio. A este tiempo suele
denominarse tiempo de respuesta al proceso.
Tipos de planificadores
En un sistema operativo complejo pueden coexistir tres tipos de
planificadores: A corto, a medio y a largo plazo.
Planificador a largo plazo (PLP)
Su misión consiste en controlar la admisión de procesos nuevos al sistema.

Cuando está presente este tipo de planificador, su objetivo principal es
proporcionar una mezcla equilibrada de trabajos. El PLP decide cuando se
da entrada al sistema a un nuevo proceso para que éste sea ejecutado. Este
proceso puede proceder de la respuesta al envío de un trabajo por lotes o
bien a la orden de ejecución realizada por el usuario. En cierto modo, el PLP
actúa como una válvula de admisión de primer nivel para mantener la
utilización de recursos al nivel deseado. Es importante conseguir una
administración equilibrada para saber cómo conjugar procesos interactivos
que tienen retardos especiales con procesos por lotes que son una simple de
cola de cálculo.
Por ejemplo, cuando la utilización del microprocesador puede admitir más

trabajos, el planificador puede dar entrada al sistema a nuevos procesos y
aumentar con ello la probabilidad de asignación de alguno de estos
procesos al procesador. Por el contrario, cuando el tiempo para la
utilización del procesador resulte alto y así se refleje en el deterioro en el
tiempo de espera, el PLP puede optar por reducir la frecuencia de admisión
de procesos a situación de preparado. El PLP es invocado generalmente
cada vez que un trabajo completado abandona el sistema.
La frecuencia de llamada al PLP es, por tanto, dependiente del sistema y de

la carga de trabajo pero generalmente es mucho más baja que para los otros
dos tipos de planificadores (en una unidad de tiempo se utilizará menos
veces y ello hará posible que su estructura sea más compleja).

Como resultado de esta no demasiada frecuente ejecución, el PLP puede
incorporar algoritmos relativamente complejos y computacionalmente
intensivos para admitir trabajos al sistema. En términos del diagrama de
transición de estados de procesos, el PLP quedará a cargo de las
transiciones del estado nuevo al estado preparado o listo.
En la figura 2.15 puede apreciarse esta situación, en la cual podemos ver un

sistema operativo con el apoyo de planificadores.
Figura 2.15. Esquema de un sistema operativo con planificadores
Planificador a corto plazo (PCP)
Este planificador decide qué procesos toman el control de la CPU. El PCP

asigna el procesador entre el conjunto de procesos preparados residentes en
memoria. Su principal objetivo es maximizar el rendimiento del sistema de
acuerdo a con el conjunto de criterios elegidos. Al estar a cargo de la
transición de estado preparado a ejecución, el PCP deberá ser invocado
cuando se realice una operación de conmutación de procesos para
seleccionar el siguiente proceso a ejecutar. En la práctica el PCP es llamado
cada vez que un suceso interno o externo hace que se modifique alguna de
las condiciones que definen el estado actual del sistema. Algunos de los
sucesos que provocan una re-planificación en virtud de su capacidad de
modificar el estado del sistema son:
1. Tics de reloj, es decir, interrupciones basadas en el

tiempo.
2. Interrupciones y terminaciones de operaciones de E/S.
3. Llamadas de operación al sistema operativo frente a

llamadas de consulta.
4. Envío y recepción de señales.
5. Activación de programas interactivos.
En general, cada vez que ocurre uno de estos sucesos, el SO llama al PCP
para determinar si debería planificarse otro proceso para su ejecución.

Planificador a medio plazo (PMP)
El PMP tiene por misión traer procesos suspendidos a la memoria

principal. Este planificador controla la transición de procesos en situación
de suspendidos a situación de preparados. El PMP permanecerá inactivo
mientras se mantenga la condición que dio lugar a la suspensión del
proceso, sin embargo, una vez desaparecida dicha condición el PMP intenta
asignar al proceso la cantidad de memoria principal que requiera y volver a
dejarlo en situación de preparado. Para funcionar adecuadamente, el PMP
debe disponer de información respecto a las necesidades de memoria de los
procesos suspendidos, lo cual no es complicado de llevar a la práctica ya
que el tamaño real del proceso puede ser calculado en el momento de
suspenderlo almacenándose en el BCP.
Este planificador será invocado cuando quede espacio libre en memoria por
la terminación de un proceso o cuando el suministro de procesos
preparados quede por debajo de un límite especificado.
Algoritmos de planificación
Antes de comenzar a estudiar los distintos tipos de algoritmos de
planificación es importante tener en cuenta que hay dos categorías
generales de éstos.
La planificación no apropiativa: Se basa en que una vez que el proceso

pasa a estado de ejecución no abandona el procesador hasta que termina o
hasta que se bloquea en espera de una operación de E/S o al solicitar algún
servicio del sistema.
La planificación apropiativa: Un proceso que está ejecutando puede

ser interrumpido por el sistema operativo para otorgar el procesador a un
proceso distinto en función de los criterios de planificación utilizados;
prioridad, número de usos del procesador, etc.
Algoritmo First Come First Serve (FCFS)
La disciplina de planificación más sencilla es el algoritmo FCFS. La carga de

trabajo se procesa simplemente en un orden de llegada. Por no tener en
consideración el estado del sistema ni las necesidades de recursos de los
procesos individuales, la planificación FCFS puede dar lugar a pobres
rendimientos. Este algoritmo exhibe un alto tiempo de respuesta a sucesos
debido a la falta de expropiación y caracterización con las propiedades de
los procesos. La planificación FCFS elimina la noción e importancia de las
prioridades de los procesos.
Algoritmo por reparto circular de tiempo (RR, Round-Robín)
En entornos interactivos tales como sistemas de tiempo compartido, el

requisito principal es proporcionar tiempos de espera razonablemente
buenos y, en general, compartir los recursos del sistema equitativamente

entre todos los usuarios. Solamente las disciplinas de planificación que
permiten la expropiación del procesador pueden ser consideradas en tales
entornos y una de las más utilizadas es la de Reparto circular de tiempos o
por turnos. Básicamente, el tiempo del procesador se divide en cuotas o
cuantos que son asignados a los procesos solicitantes. Ningún proceso
puede ejecutarse durante más tiempo que el establecido por ese cuanto si
hay más procesos esperando en la cola de preparados. Si un proceso
necesita más tiempo para completarse después de agotar su cuota de
tiempo, volverá de nuevo a la cola de procesos preparados. Si el proceso
termina antes de que expire esta cuota de tiempo, el planificador dará
inmediatamente el procesador a otro proceso en situación de preparado.
Con esta planificación y en un sistema con n procesos activos, cada proceso
recibe aproximadamente 1/n del tiempo del procesador.
Con este algoritmo de planificación, los procesos cortos pueden ser

ejecutados dentro de una única cuota de tiempo y presentarán por tanto
buenos tiempos de respuesta. En el caso de procesos más largos, éstos
pueden circular unas cuantas veces a través de la cola de preparados antes
de terminar. El tiempo de respuesta a estos procesos más largos será
siempre proporcional a sus necesidades de recursos.
La planificación por reparto de tiempo requiere el soporte de un

temporizador de intervalos que se programa generalmente para que
interrumpa al sistema operativo cada vez que expire una cuota o cuanto de
tiempo, forzando así la ejecución del planificador. El rendimiento de este
tipo de planificación es muy sensible a la elección de la cuota de tiempo,
que suele oscilar entre 1 y 100 milisegundos dependiendo del sistema. Una
cuota demasiado corta puede dar lugar a retrasos significativos debido a las
frecuentes interrupciones del temporizador y consiguientes conmutaciones
de procesos. En el otro extremo, una cuota demasiado larga transformaría a
un planificador RR en un planificador FCFS.
Existen unos valores normalizados que se definen como tiempo de retorno

normalizado (TRN) y se define como el tiempo de retorno/tiempo de
servicio en la ejecución de un proceso.

Bibliografía Lectura 2
Bibliografía Básica
* Tanenbaum, A. (2003) Sistemas Operativos Modernos.
Editorial Pearson Addison-Wesley. Edición Segunda. México
* W. Stallings (2005) Sistemas Operativos, 5ta. Edición,
Prentice Hall. España
Bibliografía Ampliatoria
* A.S. Tanenbaum, (2009) Sistemas Operativos Modernos,

3ra. Edición, Prentice Hall. España
* C. Crowley. Operating Systems, (1997) A Design-Oriented
Approach. Irwin-McGraw-Hill. USA
* Foundation for UNIX Development. (1986) Proceedings
Summer. USENIX Conference. USA
* H. M. Deitel y M. S. Kogan. (1994) The Design of OS/2.
Prentice-Hall. USA
* I Corbato, 19621 F. Corbato, M. Merwin-Dagget y R. Dealey.
A Experimental Time-Sharing System. USA
* María del Pilar Alegre Ramos, (2010) Sistemas Operativos
Monopuestos, 1ra edición, Editorial Paraninfo. España
* M. Accetta, R. Baron, D. Golub, R. Rashid, A. Tevanian y M.
Young. (1986) Mach: A New Kernel. España
* M. J. Bach. (1986) The Design of the Unix Operating
Systems. Prentice-Hall. USA
* M. Beck, N. Boheme, M. Dziadzka et al. Linux Kernel
Internals, (1988) 2. edición, Addison-Wesley. USA
* Pablo Martínez Cobo, Juan Carlos Díaz Martin. (1997)
Sistemas operativos: Teoría y práctica, Ed. Díaz de Santos. España
* Proced dings of the 1962 Spring Joint Computer Conference,
(1962). USA
* Silberschatz, A. Galvin, P. y Gagne, G. (1999) Operating
System Concepts. Editorial John Wiley & Sons. Edición Cuarta. New
York.
www.uesiglo21.edu.ar

Lectura 2 - Procesos e Hilos PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lectura 2 - Procesos e Hilos PDF

Загружено:

Авторское право:

Доступные форматы

Módulo 2

Unidad 2: Procesos e Hilos

En la mayoría de los sistemas, la unidad de trabajo son los procesos. Los

Aunque tradicionalmente los procesos se ejecutaban utilizando un solo hilo

El concepto de hilo será tratado más adelante en profundidad, y por el

El sistema operativo es responsable de las actividades relacionadas con la

Los primeros sistemas informáticos sólo permitían que se ejecutara un

Cuanto más complejo es el sistema operativo, más se espera que haga en

Potencialmente, todos estos procesos pueden ejecutarse concurrentemente,

Lo dicho anteriormente dista de aclarar el concepto formal de proceso, por

Sistemas Operativos 1 – G. Adrian Rodríguez | 2

En este texto, los términos trabajo y proceso se usan indistintamente.

Figura 2.1. Proceso en memoria

Insistamos en que un programa, por si mismo, no es un proceso; un

Sistemas Operativos 1 – G. Adrian Rodríguez | 3

2.2. Modelo de estados.

Modelo de dos estados

Básicamente el proceso puede estar en modo: Ejecución o No ejecución.

Figura 2.2. Esquema de un diagrama de dos estados

En el momento indicado por el sistema operativo el proceso deja el estado

Sistemas Operativos 1 – G. Adrian Rodríguez | 4

Los procesos que están esperando pasar al estado de ejecución, deben

Figura 2.3. Esquema de un sistema de Cola FIFO

Una cola de procesos consiste en una lista enlazada de bloques en la que

Sistemas Operativos 1 – G. Adrian Rodríguez | 5

Una forma más natural de afrontar esta situación es dividir el estado de no

1. Estado Nuevo: este estado el procesos acaba de ser creado y

Antes de la ejecución del proceso, es necesario asignarles un

Una de las principales razones por la cual se realiza este tratamiento

2. Estado Listo o Preparado: Este estado es para los procesos que

3. Estado de Ejecución: Una vez que el proceso deja el estado de

4. Estado Bloqueado: Cuando un proceso presenta algún tipo de

5. Estado Terminado: Una vez que el proceso fue ejecutado con

Sistemas Operativos 1 – G. Adrian Rodríguez | 6

En la figura 2.4 presentamos el diagrama de transiciones entre estados

Transición a Nuevo: Es el traspaso de la no existencia a la creación de un

Transición Nuevo -Preparado: En esta transición, el sistema operativo

Transición Preparado-Ejecución: Cuando el sistema operativo se

Sistemas Operativos 1 – G. Adrian Rodríguez | 7

Otra forma de esta transición es cuando un proceso es forzado a terminar

Existen otras situaciones, menos comunes y que no están presentes en

Transición Ejecución-Bloqueo: Esta transición hace que el proceso esté

Transición Bloqueado-Preparado: Esta transición ocurre cuando o

Transición Preparado - Terminado: Esta transición ocurre cuando un

Transición Bloqueado - Terminado: Esta transición es similar a la

Sistemas Operativos 1 – G. Adrian Rodríguez | 8

Todo proceso que es expropiado del procesador, es el resultado de haber

Una vez que un proceso finalice, el sistema operativo, recorrerá la cola en

Figura 2.6. Diagrama de transiciones de varias colas de bloqueados.

Si la planificación de procesos se realiza mediante un esquema basado en

Sistemas Operativos 1 – G. Adrian Rodríguez | 9

Debido a que el procesador es mucho más rápido que los dispositivos de

1. Ampliar la memoria del sistema de forma que sea posible albergar

2. La otra solución consiste en aplicar una técnica conocida como

En general, se considera suspendido a un proceso que presenta las

1. Un proceso suspendido no está disponible de inmediato para su

2. Un proceso puede estar esperando o no un suceso. Si lo está, la

3. El proceso fue situado en estado suspendido por un agente (el

4. El proceso no puede apartarse de estado hasta que llegue la orden

Si añadimos este nuevo estado a nuestro diagrama de 5 estados,

Sistemas Operativos 1 – G. Adrian Rodríguez | 10

Figura 2.7. Diagrama de 5 estados con suspensión.