Gestión de Procesos

CAPÍTULO 2.
GESTIÓN DE PROCESOS
En un computador se ejecutan los programas, y cada programa es divido en procesos

que se cargan en memoria y se ejecutan uno tras otro. El sistema operativo es el
encargado de hacerlo todo, la carga de los procesos en memoria y la ejecución de dichos
procesos, pues para que se ejecute un programa es necesario que el microprocesador
ejecute los procesos de ese programa.
El microprocesador no hace las cosas por si solo, es el sistema operativo el que
determina que proceso se debe ejecutar y cuanto tiempo debe estar ejecutándose, a todo
esto se le denomina gestión de procesos.
Los procesos son un mecanismo esencial para definir y gestionar la ejecución
concurrente de los programas bajo control de un sistema operativo.
En esencia un proceso o tarea es una instancia de un programa en ejecución es la unidad
más pequeña de trabajo individualmente planificada por un sistema operativo. Un
sistema operativo controla a todos los procesos activos y les asigna recursos de sistema
de acuerdo a políticas de diseño. El método según el cual el sistema operativo decide
cuando intervenir y como asignar recursos es tratado en este capítulo.
En los ordenadores modernos se pueden hacer varias cosas al mismo tiempo, como por
ejemplo: ejecutar un programa, escuchar música, conectarse a Internet, leer un disco e
imprimir en un terminal o impresora. En un sistema multitarea, la UCP, alterna de
programa en programa ejecutando cada uno de ellos, unos cuantos milisegundos. En un
sentido estricto la UCP, ejecuta en un cierto instante un solo programa, pero durante
todo un segundo puede trabajar con varios de ellos, lo que nos da una apariencia de
paralelismo.
Los diseñadores del SO han usado el tiempo como parámetro del paralelismo. El
modelo proceso en sí es el programa ejecutándose en un momento dado con unos datos
y recursos concretos, conceptualmente cada proceso tendrá su propia UCP virtual,
PROCESOS 28
donde la verdadera y única UCP alterna los procesos, esta rápida alternancia es lo que
se llama multiprogramación.
2.1. Concepto del proceso:
No hay un acuerdo universal sobre el concepto de proceso, pero sí algunas definiciones
aceptadas:
 Un programa que se está en ejecución.
 Es un mecanismo fundamental dentro del sistema operativo para gestionar la
ejecución de programas concurrentes.
 Unidad de procesamiento gestionada por el sistema operativo.
 La unidad dinámica individualmente planificable.
 Proceso es una actividad de cierto tiempo.
Al hablar de procesos se debe tener presente dos conceptos: Las interrupciones y el
cambio de contexto.
Interrupción es la indicación al sistema de que hay otra actividad pendiente y cambio de
contexto consiste en que el procesador atendiendo una interrupción decide en función de
unos criterios preestablecidos cambiar de proceso.
Para reanudar el trabajo por donde se ha quedado hay que guardar la información de lo
que se estaba haciendo y liberar parte de la memoria para la nueva actividad, al hacer
este cambio de contexto el procesador deberá anotar todos los datos importantes que
había antes de la interrupción para poder reanudar más tarde la actividad.
Toda la información de los procesos se guarda en una estructura denominada Bloque de
Control de Procesos o BCP.
En sistemas multitarea, los procesos activos se encuentran típicamente en diferentes
etapas de ejecución en cada instante de tiempo. Un proceso particular suele evolucionar
cíclicamente recorriendo varias veces distintos estados, tales como los de ejecución y
suspendido, antes de terminar y salir del sistema. El sistema operativo sigue la pista
dinámicamente al estado de cada proceso y registra todos los cambios de estado cuando
se producen. Esta información es utilizada para planificación y para otras decisiones de
asignación de recursos en respuesta a demandas de los procesos activos. [1] Milan
Milenkovic
Capítulo 2. Sistemas Operativos

PROCESOS 29
2.1.1. División implícita y explícita en tareas

Dependiendo del sistema operativo y del entorno de ejecución de programas, la división
en procesos de un programa puede ser efectuada o bien por el sistema operativo o bien
por el programador de sistemas. En otras palabras un proceso separado en tiempo de
ejecución puede provenir de:
 División implícita definida por el Sistema Operativo
 División explicita definida por el Programador
División implícita.- Se usa para explotar los beneficios de concurrencia entre diferentes
aplicaciones. La división implícita en tareas significa que los procesos son definidos
por el sistema. Esta división implícita aparece comúnmente en sistemas de
multiprogramación de propósito general, tales como los de tiempo compartido. El
sistema operativo asigna valores iniciales a los atributos de procesos, tales como la
prioridad de planificación y los derechos de acceso, en el momento de crear el proceso
en base al perfil del usuario y a valores predeterminados del sistema. Los procesos
creados de esta manera son generalmente transitorios en el sentido de que son
destruidos y eliminados por el sistema después de cada ejecución.
División explicita.- Es usada por los programadores para definir explícitamente cada
proceso y algunos de sus atributos con el fin de mejorar su rendimiento. La división
explicita se utiliza en situaciones en donde se desea elevar el rendimiento o controlar
explícitamente las actividades del sistema. Las aplicaciones de tiempo real son ejemplos
típicos de procesos definidos por el programador. Después de dividir a mano el trabajo
de la aplicación en el número deseado de tareas independientes, el programador de
sistema define las fronteras de cada proceso individual. El programador puede asignar
valores iniciales de atributos de proceso y controlar diferentes aspectos de la ejecución
del proceso incorporando en llamadas al sistema.
Entre las razones comunes para aplicar la división explícita en tareas se incluyen:
 Ganancia de velocidad.
 Multiplexación de dispositivos de E/S.
 Multiprocesamiento.
 Computación distribuida con múltiples sesiones de red.
En general se puede usar división explícita por cualquier conveniencia del usuario.

PROCESOS 30
2.1.2. Relaciones entre procesos

Los procesos están ligados por dos relaciones que son la competición y la cooperación.
Tanto la competición como la cooperación de procesos requieren el adecuado soporte
por parte del SO.
Competición.- En un sistema multitarea todos los procesos concurrentes compiten unos
con otros por la asignación de los recursos del sistema necesarios para sus operaciones
respectivas. La competición requiere una protección de los recursos en términos de
aislamiento de los diferentes espacios de direcciones.
Cooperación.- Los procesos que provienen de una sola aplicación cooperan entre sí.
La cooperación es habitual entre los procesos creados como resultado de una división
explícita en tareas. Los procesos cooperativos intercambian entre si datos y señales de
sincronización necesarias para su progreso, controlados por ciertos mecanismos
exigentes y con frecuencia conflictivos que deben ser abordados durante el diseño de
los sistemas operativos de multiprogramación.
Los procesos cooperativos con frecuencia se agrupan en lo que se denomina una familia
de procesos, aunque dentro de una familia son posibles relaciones complejas, la más
frecuente es de jerarquía. En los cuales los procesos hijos heredan generalmente los
atributos de sus padres o hermanos en el momento de la creación.
La secuencia de creación de procesos genera un árbol de procesos como se muestra en
la Figura 2.1
Proc. Inic.
Inicio Inicio Inicio Inicio Dem. Impr. Dem. Com..
Shell Shell
Proceso A
Editor
Proceso B Proceso D Proceso C
Proceso E Proceso F
Figura 2.1. Jerarquía de procesos.

PROCESOS 31
Para referirse a las relaciones entre los procesos de la jerarquía se emplean los términos
de padre, hijo, hermano o abuelo. Cuando el proceso A solicita al sistema operativo que
cree el proceso B, se dice que A es padre de B y que B es hijo de A. Bajo esta óptica, la
jerarquía de procesos puede considerarse como un árbol genealógico.
Algunos sistemas operativos, como Linux, mantienen de forma explícita esta estructura
jerárquica de procesos, un proceso sabe quién es su padre, mientras que otros sistemas
operativos como el Windows NT relacionan los procesos con las llamadas hebras.
Una hebra es un proceso ligero con un estado reducido que comparten recursos del
proceso que provienen tales como memoria y archivos. Las hebras asumen el papel de
los procesos como unidad planificable. En tales sistemas el proceso o tarea sirve como
entorno para la ejecución de hebras.
El proceso se convierte por tanto en una unidad propietaria de recursos, tales como
memoria y archivos para una colección de hebras.
En sistemas con hebras, un proceso con una sola hebra es equivalente a un proceso
clásico. Cada hebra pertenece exactamente a un solo proceso, y ninguna hebra puede
existir fuera de un proceso. Los procesos son estáticos, y solo las hebras pueden ser
planificadas para ejecución. Típicamente, cada hebra representa un flujo separado de
control y está caracterizada por su propia pila y estado hardware.
Las hebras son un mecanismo conveniente para explotar la concurrencia dentro de una
aplicación. Las hebras pueden comunicarse eficientemente por medio de memoria
compartida comúnmente accesible dentro del proceso que las engloba. Los mecanismos
de comunicación y sincronización tales como las señales, también son eficaces debido
a que las hebras relacionadas comparten memoria, y su interacción no requiere el
recargo de cruzar fronteras de protección de memoria.
Las hebras proporcionan una base adecuada para la ejecución paralela de aplicaciones
sobre multiprocesadores de memoria compartida.
2.2. LOS PROCESOS DESDE LA PERSPECTIVA DEL PROGRAMADOR DE
SISTEMAS.
Los programadores de sistemas tienen que tratar con procesos de forma explícita. El
sistema operativo, o un lenguaje de programación proporcionan servicios para definir
los atributos para controlar o influenciar muchos aspectos importantes del
comportamiento y gestión del proceso en tiempo de ejecución. Al crear procesos, el

PROCESOS 32
programador informa al sistema operativo sobre que actividades pueden ser planificadas
para ejecución concurrente.
2.2.1. Ejemplo de multitarea
Ayudándonos de una aplicación típica como es la suma de dos números, podemos
indicar que existen cuatro actividades identificadas que se designan del modo siguiente:
 RECOGER (recoger los números a sumar puede ser a través del teclado o disco),
 GUARDAR (Almacenar los números a sumar y la respuesta en disco),
 CALCULAR (realizar la suma uso del procesador),
 IMPRIMIR (impresión del resultado puede ser en pantalla o impresora).
Como se entiende, la codificación, usando cualquier lenguaje, de estas actividades
serían:
Inicio del programa
inicio
Mientras se verdad {mientras sea verdad}
inicio
recoger_a y b; {A través del teclado o archivo previamente
almacenado}
guardar a, y b; {a disco}
calcular_c; {procesamiento sumar}
imprimir_c; {presentar resultados a pantalla o archivo}
fin {Mientras}
fin {una_tarea_}
La simplicidad engañosa de este ejemplo es intencionada. Demuestra cómo se puede
razonar lógicamente dando lugar a una implementación ineficiente de un solo proceso.
Si la aplicación fuera mayor no solamente la suma de dos números sino aplicaciones
grandes con tiempos críticos que se demoraría mucho tiempo en recoger los datos o
presentar la información el problema sería mayor.
Como podemos darnos cuenta el procesador tendrá tiempos muertos bastante largos en
espera que se cumplan las tareas de E/S.
Un enfoque multitarea puede producir un rendimiento mejor al disponer de un proceso
separado para manejar cada actividad. La ejecución concurrente de tales procesos puede
facilitar el progreso común mediante la reasignación del procesador a otros procesos
PROCESOS 33
ejecutables mientras los procesos suspendidos esperan la terminación de sus

operaciones de E/ S.
El primer paso importante en la preparación de ésta aplicación para su implementación
multitarea es identificar las operaciones que deben ser codificadas como procesos
separados y la determinación de su precedencia relativa, si existe. A partir de la
definición del problema en primer lugar se recolectan los datos, luego se guardan en
disco y luego se procesan. IMPRIMIR solo puede ejecutarse cuando acaba
CALCULAR, ya que imprime los datos proporcionados por CALCULAR.
Por ejemplo, comenzando con un sistema recién inicializado, se ejecuta primero
RECOGER (R1), que prepara los datos para la primera ejecución de GUARDAR (G1),
y CALCULAR (C1), los cuales pueden ejecutarse concurrentemente. Cuando acaban,
comienza otra ejecución de RECOGER (R2) concurrentemente con la primera
ejecución de IMPRIMIR (I1), que imprime las modificaciones obtenidas por
CALCULAR (C1). En el grafo de la figura 2.2 indican las relaciones causales y de
precedencia. Por ejemplo, R2 puede comenzar se ejecución sólo después de que G1 y
C1 hayan completado sus respectivas ejecuciones.
La ejecución concurrente de este ejemplo puede dar lugar a una mejora de rendimiento
del doble con respecto al caso secuencial.
En los siguientes gráficos se puede indicar esta implantación y su respectivo seudo
código:
Inicio del programa multitarea_ADQ;
...
proceso recoger;
inicio
Mientras sea verdad
inicio
esperar_señal_de(guardar, calcular);
recoger_a y b;
enviar_señal_a(guardar, calcular)
fin {mientras}
fin {recoger};

PROCESOS 34
R1 R1
G1 G1 C1
C1 R2 I1
I1 G2 C2
R2 R3 I2
G2 G3 C3
Figura 2.2. Ejecución secuencial y concurrente de procesos
2.2.2. Sincronización entre procesos.

Para forzar el cumplimiento de las relaciones de precedencia entre procesos
cooperativos se utilizan mecanismos de sincronización entre procesos como son las
señales, que se encuentran entre los servicios más importantes proporcionados por los
sistemas operativos multitarea

PROCESOS 35
Un proceso que espera una o más señales es suspendido por el sistema operativo, hasta
que le lleguen todas las señales requeridas enviadas por otro proceso. El envío de una
señal no ocasiona la suspensión del proceso emisor.
2.2.3. Comportamiento de los procesos del ejemplo
Para demostrar el comportamiento en tiempo de ejecución y la operación multiplexada
de los cuatro procesos, es necesario efectuar algunas suposiciones con respecto al
tiempo. La Figura 2.3a muestra gráficamente la temporización supuesta. [1] Milan
Milenkovic
 Los bloques de línea continua indican que se usa el procesador.
 Las líneas discontinuas representan las operaciones de E/ S.
 Las marcas de flecha hacia arriba los momentos en que se producen
interrupciones.
 Las flechas hacia abajo indican los instantes en que el proceso CALCULAR, que
no está controlado por interrupciones, se encuentra preparado para ejecución.
Unidades
de tiempo
Actividades por ciclo
Recoger (A/D) 3
Guardar (Disco) 4
Calcular (UCP) 2
Imprimir
(Impresora) 3
Sumad
o
12
1 2 3 4 5 6 7
(a) Suposiciones de tiempo
RECOGER GUARDAR CALCULAR IMPRIMIR RECOGER 2
Tiempo
0 1 2 3 4 5 6 7 8 9 10 11 12 13
(b) Ejecución Secuencial

PROCESOS 36
Figura 2.3. Procesos temporizados
Si suponemos que RECOGER, GUARDAR, CALCULAR e IMPRIMIR tardan

3,4,2,y3 unidades de tiempo, respectivamente, en realizar un ciclo de ejecución. Una
ejecución secuencial tarda 12 unidades de tiempo. Figura 2.3b.
Si suponemos también que el sistema operativo es uno de tiempo compartido, cada
proceso tendrá una prioridad, que en orden decreciente son las siguientes: GUARDAR,
RECOGER, IMPRIMIR, CALCULAR.
G1 G2 G3
GUARDAR
R1 R2 R3
RECOGER
I1 I2
IMPRIMIR 2 3 4
C1 C2 C3
CALCULAR
5.25
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Figura 2.4. Procesos temporizados con ejecución multitarea
En la Figura 2.4 se muestra la ejecución de los cuatro procesos, comenzando

inmediatamente después de la inicialización, desde el punto de vista del sistema.
Inicialmente, RECOGER es el primer proceso de ejecutarse, ya que es el único que no
necesita señales con el fin de continuar su ejecución. GUARDAR, CALCULAR e
IMPRIMIR están suspendidos por el sistema operativo al estar pendientes de la llegada
de las señales respectivas en las cuales están esperando. Cuando se completa la primera
pasada de RECOGER, RECOGER anuncia el suceso enviando señales a GUARDAR y
CALCULAR. Esto, a su vez, hace que ambos procesos GUARDAR y CALCULAR
sean elegibles para ejecución, pero GUARDAR tiene prioridad más elevada y por tanto
es el proceso planificado para ejecución. Cuando GUARDAR finaliza su primera ráfaga

PROCESOS 37
de utilización del procesador y espera a que se complete la operación de E/S de disco, el

SO asigna el procesador a CALCULAR.
CALCULAR, solo necesitar el procesador, continua ejecutándose hasta que se completa
la operación de E/S de disco, de modo que GUARDAR ya que esta preparado para
continuar (el SO es alertado de esta situación por la interrupción que indica terminación
de la E/S de disco). Debido a sus prioridades relativas, el SO elige expropiar a
CALCULAR y ejecutar GUARDAR. A esto se denomina disciplina de planificación
expropiativa basada en prioridades, la cual es frecuentemente utilizada en sistemas
operativos de tiempo real. [1] Milan Milenkovic
Suponiendo que la escritura de un disco utiliza búferes internos de entrada y salida se
experimenta un aumento de más del doble de su productividad. La utilización de
búferes mejora generalmente la productividad hasta que algún cuello de botella limite.
En este ejemplo, el cuello de botella es el tiempo de procesador, y se produce cuando se
utilizan dos búferes. En otras situaciones, podrían resultar útiles tres, cuatro o más
búferes. Generalmente el diseñador elige la utilización óptima de búferes analizando el
rendimiento y verificando el diseño mediante mediciones de tiempo. [1]Milan
Milenkovic
El ejemplo ilustra que los beneficios de la operación multitarea no se consiguen
gratuitamente. Para dividir en una serie de procesos lo que parecía un programa
sencillo, se ha introducido la complejidad adicional de las señales y la asignación de
prioridades, proceso que requiere una codificación cuidadosa y que se puede necesitar
varias iteraciones para perfeccionar su implementación en la vida real.
2.3. LOS PROCESOS DESDE LA PERSPECTIVA DEL SISTEMA
OPERATIVO:
Como se indicó anteriormente, el proceso es la unidad de procesamiento gestionada por
el sistema operativo. Para poder realizar este cometido, el proceso tiene asociado una
serie de elementos de información, que se resumen en la Figura 2.5, que se analizan
seguidamente.

PROCESOS 38
Registros
especiales Mapa de memoria
del Proceso A
Mapa de memoria
del Proceso B
Registros Tablas del sistema operativo
Mapa de memoria
generales del Proceso C Tabla de procesos
BCP Proceso A BCP Proceso B BCP Proceso C
- Estado (registros) - Estado (registros) - Estado (registros)
Tablas SO - Identificación - Identificación - Identificación
PC - Control - Control - Control
- Tabla de memoria
SP Mapa de - Tabla de E/S
Estado Memoria - Tabla de ficheros
Figura 2.5. Procesos temporizados
Estos elementos se organizan en tres grupos: Estado del procesador, Imagen de

memoria, Tablas del sistema operativo.
El estado del procesador de un proceso reside en los registros del procesador, cuando el
proceso está en ejecución, o en el bloque de control de proceso (BCP), cuando el
proceso no está en ejecución.
Cuando el proceso está ejecutando, el estado del procesador varía de acuerdo al flujo de
instrucciones. En este caso, la copia del estado del procesador que reside en el BCP no
está actualizada. Téngase en cuenta que los registros de la máquina se utilizan para no
tener que acceder a la información de memoria, dado que es mucho más lenta. Por
tanto, no tiene sentido plantear que, en cada modificación de un registro, se actualice su
valor en el BCP, puesto que está en memoria.
Sin embargo, cuando se detiene la ejecución de un proceso, como consecuencia de la
ejecución de una interrupción, es muy importante que el sistema operativo actualice la
copia del estado del procesador en su BCP. En términos concretos, la rutina del sistema
operativo que trata las interrupciones lo primero que ha de hacer es salvar el estado del
procesador en el BCP del proceso interrumpido. [2] J. Carretero
Imagen de memoria.- La imagen de memoria esta formado por el espacio que ocupa el
código y datos de proceso cargado en la memoria RAM. En general, este espacio será
virtual y estará compuesto por varias páginas.
Tablas del sistema operativo. El sistema operativo mantiene una serie de tablas que
describen a los procesos y a los recursos del sistema.
La información asociada a cada proceso se encuentra parcialmente en el BCP y
parcialmente fuera de él. La decisión de incluir o no una información en el BCP se toma

PROCESOS 39
según dos argumentos: eficiencia y necesidad de compartir información. En las

siguientes secciones se estudiará en detalle el BCP.
En general un proceso esta formado por:
 Código. Bajo este nombre se considera el programa máquina que ha de ejecutar el
proceso.
 Datos. Datos para procesar.
 Imagen de Memoria.
 Y al menos una hebra.
La formación de un proceso consiste en completar todas las informaciones que lo
constituyen, como se muestra en la Figura 2.6
De forma más específica, las operaciones que debe hacer el sistema operativo son las
siguientes:
 Asignar un espacio de memoria para albergar la imagen de memoria. En general,
este espacio será virtual y estará compuesto por varias páginas.
 Seleccionar un BCP libre de la tabla de procesos.
Mapa de
memoria Tabla de procesos
Cargador
Objeto
ejecutable Imagen BCP
del proceso
Bibliotec a
sistema
Figura 2.6. Creación de un proceso.

PROCESOS 40
 Rellenar el BCP con la información de identificación del proceso, con la

descripción de la memoria asignada, con los valores iniciales de los registros
indicados en el archivo objeto, etc.
 Cargar en el segmento de texto el código más las rutinas de sistema y en el
segmento de datos los datos iniciales contenidos en el archivo objeto.
 Crear en el segmento de pila, la pila inicial del proceso que incluye inicialmente el
entorno del proceso y los parámetros que se pasan en la invocación del programa
correspondiente.
 Una vez completada toda la información del proceso, se puede marcar como listo
para ejecutar, de forma que el planificador, cuando lo considere oportuno, lo
seleccione para su ejecución, mientras no pase esto al proceso se lo considera
como inactivo.
De acuerdo con la Figura 2.7, un proceso puede estar en varias situaciones
procesamiento, listo para ejecutar y espera, que se denominan estados. A lo largo de su
vida, el proceso va cambiando de estado según evolucionan sus necesidades.
Proceso A
Proceso B Procesamiento
Entrada/salida
Listo
Proceso C SO
Procesador
Tiempo
Figura 2.7. Comportamiento de procesos según estados.
Como se muestra en la Figura 2.7, existe un intervalo en el que el procesador no tiene

nada que hacer. Para evitar esta contradicción, los sistemas operativos incluyen el
denominado proceso nulo. Este proceso consiste en un bucle infinito que no realiza
ninguna operación útil. El objetivo de este proceso es «entretener» al procesador cuando
no hay ninguna otra tarea.

PROCESOS 41
En la Figura 2.7, no todos los procesos activos de un sistema multitarea están en la

misma situación. Se diferencian, por tanto, cuatro estados básicos en los que puede estar
un proceso, Figura 2.8, estados que detallamos seguidamente:
 Inactivo.- Algunos no lo consideran como estado, es la condición en la cual el
proceso todavía no se registra en el BCP, por lo tanto no es contabilizado.
 Preparado o Listo.- Un proceso está listo para ejecutar cuando puede entrar en fase
de procesamiento, posee todos los recurso excepto el procesador.
 Ejecución. En este estado está el proceso que está siendo ejecutado por el
procesador, es decir, posee todos los recursos. En esta fase el estado del proceso
reside en los registros del procesador.
 Bloqueado o Suspendido.- Un proceso bloqueado está esperando a que ocurra un
evento y no puede seguir ejecutando hasta que suceda el evento. Una situación
típica de proceso bloqueado se produce cuando el proceso solicita una operación
de E/S. Hasta que no termina esta operación, el proceso queda bloqueado. En esta
fase, el estado del proceso reside en el BCP.
EJECUCION
Termina Espera suceso
(E/S,
sincronización)
INACTIVO SUSPENDIDO
Planificado Expropiado
Creado
Ocurre suceso
PREPARADO
Figura 2.8. Transición de procesos según estados.

PROCESOS 42
Los estados colectivos de todos los procesos y recursos del sistema pueden ser
considerados como el estado global del sistema.
Las operaciones que pueden hacer sobre los procesos son:
 Crear.- Son cuando se ejecuta un proceso y este pasa a la cola de procesos
preparados para ser ejecutados, el único dato a tener en cuenta es la prioridad que
tiene dicho proceso sobre el resto de los procesos que se encuentran en ese
momento en la cola de preparados, por si el fuera de mayor privilegio que los
demás o al contrario.
 Bloquear.- Son cuando al estado se le pone en estado bloqueado por que el evento
o recurso al cual quiere acceder se encuentre en uso por otro proceso y por lo tanto
tiene que esperar, pero sin detener ni hacer perder tiempo al microprocesador.
 Reanudar.- Son cuando a los procesos bloqueados, se les reanuda la ejecución, por
que el evento o recurso que estaban esperando ya se encuentra disponible y puede
ser usado.
 Suspender.- Son cuando determinados procesos no van a ser usados y se devuelve
a la memoria RAM, pasando entonces a ser eliminados de los registros del
microprocesador para no ser ejecutados.
 Retirarlos.- Cuando un proceso se los suspende puede sacárselo de la memoria
RAM a memoria secundaria.
2.3.1. Bloque de control de procesos (BCP)
El BCP contiene la información básica del proceso, entre la que cabe destacar la
siguiente:
Información de identificación.- Esta información identifica al usuario y al proceso.
Como ejemplo, se incluyen los siguientes datos:
 Identificador del proceso.
 Identificador del proceso padre, en caso de existir relaciones padre-hijo
 Información sobre el usuario (identificador de usuario, identificador de grupo).
Estado del procesador.- Contiene los valores iniciales del estado del procesador o su
valor en el instante en que fue interrumpido el proceso.

PROCESOS 43
Información de control del proceso.- En esta sección se incluye diversa información

que permite gestionar al proceso. Destacaremos siguientes datos:
 Información de planificación y estado.
 Estado del proceso.
 Evento por el que espera el proceso cuando está bloqueado.
 Prioridad del proceso.
 Información de planificación.
 Descripción de los segmentos de memoria asignados al proceso.
 Recursos asignados, tales como:
o Archivos abiertos (tabla de descriptores o manejadores de archivo).
o Puertos de comunicación asignados.
 Punteros para estructurar los procesos en colas o anillos. Por ejemplo, los procesos
que están en estado de listo pueden estar organizados en una cola, de forma que se
facilite la labor del planificador.
 Comunicación entre procesos. El BCP puede contener espacio para almacenar las
señales y para algún mensaje enviado al proceso.
Para un proceso recién creado, el BCP se rellena con los atributos definidos por el
programador que se hallan en la plantilla del proceso o que son especificados como
parámetros de la llamada al sistema operativo CREA_PROCESO. En ese momento el
sistema operativo suele asignar valores por efecto a otros campos.
2.3.2. Estado del sistema y listas de procesos
Para seguir la pista a todos los procesos, para efectos de planificación el sistema
operativo mantiene listas de bloques de control de procesos clasificados por el estado.
En general existe una lista de procesos preparados, y una lista de procesos suspendidos,
en sistemas multiprocesadores también pueden haber una lista de procesos en ejecución
global.
El rendimiento del SO puede mejorar ordenando y actualizando estas listas de la
manera más conveniente para las rutinas del sistema operativo que se saben que operan
sobre ellas.
2.3.3. Transiciones de estado de un proceso
PROCESOS 44
Los sistemas operativos de multiprogramación están en gran medida guiados por

sucesos en el sentido de que efectúan las operaciones de gestión en respuesta a sucesos
del sistema que pueden provocar cambios de estado y conducir potencialmente a
reasignaciones de recursos, tal como la reasignación del procesador. Los sucesos que
producen la invocación al sistema operativo pueden ser externos, como la terminación
de una E/S, o internos, como el envió y recepción de señales. Desde el punto de vista
del sistema, los sucesos externos suelen ocurrir asincrónicamente y se manifiestan por
medio de interrupciones, los sucesos internos, por otra parte, son síncronos, ya que
generalmente ocurren como efecto secundario de la ejecución de llamadas al sistema
operativo invocadas por el proceso en ejecución.
2.3.4. Conmutación de procesos.

Cuando se produce una interrupción en la ejecución de un proceso, el sistema operativo
realiza ciertas operaciones, llamadas cambio de contexto.
 Guarda el estado del procesador en el correspondiente BCP.
 Pasa a ejecutar la rutina de tratamiento de interrupción del sistema operativo.
Como resultado del cambio de contexto se puede producir un cambio en el estado de
algunos procesos. Supóngase que el proceso A está bloqueado esperando a que se
complete una lectura de disco y que llega una interrupción del disco. Se produce un
cambio de contexto y entra a ejecutar el sistema operativo para tratar la interrupción. En
el caso de que la interrupción indique que ha terminado la lectura por la que esperaba, el
sistema operativo cambiará el estado de este proceso a listo o incluso a ejecución si así
lo decide el planificador. El resultado final es que ha habido un cambio de estado de
proceso. .
Supóngase ahora que está ejecutando el proceso A y que llega una interrupción de
teclado asociado al proceso B. Se produce el cambio de contexto, pero el proceso B
puede seguir en estado de bloqueado (no llegó el carácter de fin de línea) y el proceso A
puede seguir en estado de ejecución, por lo que no hay cambio de estado en los
procesos.
Las transiciones en el estado del proceso exigen un trabajo cuidadoso por parte del
sistema operativo, para que se hagan correctamente. El aspecto más delicado se refiere
al contenido de los registros de la computadora. Veamos detalladamente los pasos
involucrados:
PROCESOS 45
 Un proceso está en ejecución, su información reside en los registros del

procesador, que están siendo constantemente modificados por la ejecución de sus
instrucciones de máquina.
 Bien sea porque llega una interrupción o porque el proceso solicita un servicio del
sistema operativo, el proceso para su ejecución.
 Inmediatamente entra a ejecutar el sistema operativo, ya sea para atender la
interrupción o para atender el servicio demandado.
 La ejecución del sistema operativo, como la de todo programa, modifica los
contenidos de los registros de la máquina, destruyendo sus valores anteriores.
 Según la secuencia anterior, si se desea más adelante continuar con la ejecución
del proceso, se presenta un grave problema: los registros ya no contienen los
valores que deberían.
 Para evitar esta situación, lo primero que hace el sistema operativo al entrar a
ejecutar es salvar el contenido de todos los registros, teniendo cuidado de no haber
modificado el valor de ninguno de ellos Figura 2.9. Como muestra la Figura 2.11,
al interrumpirse la ejecución de un proceso el sistema operativo almacena los
contenidos de los registros en el BCP de ese proceso.
Registros
especiales
Tabla de procesos
BCP Proceso A BCP Proceso B BCP Proceso N

Estado
Registros Estado Estado Estado

generales (registros) (registros) (registros)
Información de Información de Información de
identificación identificación identificación
PC
Información de Información de Información de
SP Control Control Control
Estado
Figura 2.9. Información de los procesos
Los procedimientos que se llevan a cabo para realizar una conmutación de procesos se
resumen en la Figura 2.11.
PROCESOS 46
Espacio de Espacio del

usuario Sistema Operativo
Pa en ejecución
Cambio de Modo
Suceso
 Guarda el estado hardware de Pa

en BCP (a)
Conmutación  Actualiza el estado de Pa,
planificación, prioridad, etc...
de proceso  (Atiende al suceso)
Planifica el siguiente proceso a
(SO en 
ejecutar, Pb
ejecución)  Restaura el estado hardware de
Pb, y sus atributos desde BCP(b)
Cambio de Modo
Pb en ejecución
Figura 2.10. Conmutación de procesos.
El módulo del sistema operativo que pone a ejecutar un proceso se denomina activador
o dispatcher. La activación de un proceso consiste en copiar en los registros del
procesador el estado del procesador, que está almacenado en su BCP. De esta forma, el
proceso continuará su ejecución en las mismas condiciones en las que fue parado.
Evidentemente, la conmutación de proceso es una operación considerablemente más
compleja y costosa que la conmutación de contexto de interrupción, y puede ser
bastante complicada en sistemas operativos grandes que disponen de detallado
mantenimiento de recursos y sofisticados esquemas de planificación. Dada su
complejidad y relativa alta frecuencia de ocurrencia, la implementación de la
conmutación de proceso puede afectar significativamente al rendimiento de un
sistema operativo de multiprogramación. Es especialmente importante en sistemas
orientados al rendimiento, tales como las aplicaciones de tiempo real.
La eficiencia de la conmutación de proceso puede ser mejorada con la ayuda de
asistencias hardware y una técnica de estructuración de procesos especial denominada
hebras, que se discuten en la próxima sección.
Un esquema hardware habitualmente empleado para acelerar la conmutación de
proceso es disponer de múltiples conjuntos estructuralmente idénticos de registros del
procesador. Lo mínimo son dos: uno por el sistema operativo y otro para los procesos

PROCESOS 47
de usuario. Un bit dedicado en la (única copia) palabra de estado del procesador indica
el modo actual de operación, supervisor o usuario, y el conjunto correspondiente de
registros activos.
2.3.5. Hebras de ejecución (THREADS)
Un proceso ligero, o hebra (thread), es un programa en ejecución que comparte la
imagen de memoria y otras informaciones con otros procesos ligeros. Como muestra la
Figura 2.12, un proceso puede contener un solo flujo de ejecución, como ocurre en los
procesos clásicos o más de un flujo de ejecución (procesos ligeros).
Proceso
Procesos ligeros
Figura 2.11. División de un proceso en hebras
Es importante destacar que todos los procesos ligeros de un mismo proceso comparten
el mismo espacio de direcciones de memoria, que incluye el código, los datos y las pilas
de los diferentes procesos ligeros. Esto hace que no exista protección de memoria entre
los procesos ligeros de un mismo proceso, algo que sí ocurre con los procesos
convencionales.
El proceso ligero constituye la unidad ejecutable en Windows NT. La Figura 2.12
representa de forma esquemática la estructura de un proceso de Windows NT con sus
procesos ligeros.

PROCESOS 48
Proceso
Código
Datos
Recursos (ficheros, ...)
Entorno del proceso
Thread 1 Thread n
Registros ...... Registros
Pila Pila
Figura 2.12. Estructura de un proceso con sus hebras en Windows.
Comparando el uso de los procesos ligeros con otras soluciones se puede decir que:
 Los procesos ligeros permiten paralelismo y variables compartidas.
 División de trabajo que dan los procesos una mayor sencillez, lo que se traduce en
mejores prestaciones.
 Comparten memoria directamente, por lo que no hay que añadir ningún
mecanismo adicional para utilizarla.
 La destrucción de procesos ligeros requiere mucho menos trabajo que la de
procesos.
 Facilita la modularidad, al dividir trabajos complejos en tareas.
 Aumenta la velocidad de ejecución del trabajo, puesto que aprovecha los tiempos
de bloqueo de unos procesos ligeros para ejecutar otros.
 Permite la programación concurrente.
2.4. APLICACIONES Y MULTITAREA EN WINDOWS.

Como se sabe, Microsoft tuvo su éxito gracias a su política de mantener la
compatibilidad de los programas realizados para MS-DOS y Windows 3.x a Windows
95 y NT. Para lo cual tuvo que realizar muchos “parches” en su sistema operativo. Una
de las implementaciones es el concepto de máquina virtual, que es un contexto de

PROCESOS 49
ejecución para cada tipo de aplicación que se ejecute bajo Windows 95, NT y sus
descendientes. Así también cada tipo de aplicación tiene diferente comportamiento
respecto a la división en hebras. Aplicaciones desarrolladas para MSDOS de 8 bits y
las aplicaciones para Windows 3.x de 16 Bits no se dividen, o solo se divide, en una
hebra. No así las aplicaciones de 32 bits que se dividen en muchas hebras,
aprovechándose de muchas posibilidades que influyen en el rendimiento como mayor
tiempo de uso del procesador porque la planificación se realiza a nivel de hebra. Un
resumen del comportamiento de los diferentes tipos de aplicación con respecto al
número de hebras, máquinas virtuales y uso de memoria presentamos a continuación:
Tipo de # de máquinas Hebras1 Memoria.

Aplicación virtuales
8 bits (MSDOS) 1 por aplicaciones 1 Separada/cada

Aplicación
16 bits (Windows 1 por aplicación 1 Compartida

3.x)
32 bits (Windows 1 por todas las Más de Separada

9x y NT aplicaciones 1
En las Figuras 13a, 13b y 13c se presenta gráficamente las diferencias anotadas en la
tabla anterior:[14] Windows Training Microsoft.
También se debe indicar que Windows tiene que implementar dos tipos de multitarea
para poder ejecutar cada tipo de aplicación que son:
 Multitarea Cooperativa2.- Es el modelo de multitarea en la que se confía que cada
proceso que es planificado para su ejecución coopere dejando libre el procesador
cuando termine su trabajo.
1
Thread
2
Multitasking Cooperative

PROCESOS 50
 Multitarea con Derecho Preferente3.- Es un modelo en el que planificador4 del

sistema operativo es el que decide cuando un proceso tiene de dejar el procesador.
Figura 2.13 a Figura 2.13b Figura 2.13c
Figura 2.13. Características de las aplicaciones de 32,16 y 8 bits.
Como se podrá imaginar en el primer caso es arriesgado, ya que si un proceso falla en el

momento de su ejecución no podrá abandonar el procesador, quedándose
indefinidamente en un bucle; que causaría el colapso del sistema. En el segundo caso, el
sistema operativo a través de su planificador es quien toma el control, en presencia de
algún problema con el proceso que se está ejecutando, responde protegiéndose y
sacándolo al proceso del procesador y si no lo logra hacer por si solo, permite que el
usuario actué para finalizar el proceso. Continuando su trabajo como si nada hubiese
pasado.
En las Figuras 14 y 15 se representa los dos tipos de multitarea que tiene que implantar
Windows para efectos de compatibilidad:[14] Windows Training Microsoft.
3 Multitasking Preemptive
4
Scheduler

PROCESOS 51
Figura 2.14. Multitarea cooperativa.
Figura 2.15. Multitarea con derecho preferente
2.5. PLANIFICACIÓN:
La planificación de procesos tiene como objetivos obtener siempre la mayor
productividad, o la mayor cantidad de trabajos realizados en una unidad de tiempo.
El concepto de planificación podría llamarse al conjunto de políticas y mecanismos
incorporados al sistema operativo por el que se rige el orden en el que se completa el
trabajo que hay que realizar.

PROCESOS 52
La planificación se refiere a la manera o técnica que se usan para decidir cuánto tiempo
de ejecución y cuando se le asigna a cada proceso los recursos del sistema, es decir
decide ¿Qué, Cómo y Cúando? Obviamente, si el sistema es monousuario y monotarea
no hay mucho que decidir, pero en el resto de los sistemas esto es crucial para el buen
funcionamiento del sistema.
El planificador es el módulo del sistema operativo que realiza la función de seleccionar
el proceso en un estado y pasarlo a otro estado de ejecución.
Con la planificación se pretende:
 Justicia o Imparcialidad: Todos los procesos son tratados de la misma forma, y en
algún momento obtienen su turno de ejecución o intervalos de tiempo de
ejecución hasta su terminación exitosa.
 Maximizar la Producción: El sistema debe de finalizar el mayor número de
procesos por unidad de tiempo.
 Minimizar el Tiempo de Respuesta: Cada usuario o proceso debe observar que el
sistema les responde consistentemente a sus requerimientos.
 Evitar el Aplazamiento Indefinido: Los procesos deben terminar en un plazo finito
de tiempo.
 El sistema debe ser predecible: Ante cargas de trabajo ligeras el sistema debe
responder rápido y con cargas pesadas debe ir degradándose paulatinamente. Otro
punto de vista de esto es que si se ejecuta el mismo proceso en cargas similares de
todo el sistema, la respuesta en todos los casos debe ser similar.
La mayoría de estos objetivos son incompatibles entre sí, por lo que hay que centrar la
atención en aquel que sea de mayor interés. Por ejemplo, una planificación que realice
un reparto equitativo del procesador no conseguirá optimizar el uso del mismo.
En los sistemas de planificación generalmente se identifican tres niveles: el alto, medio
y el bajo. El nivel alto decide que trabajos (conjunto de procesos) son candidatos a
convertirse en procesos compitiendo por los recursos del sistema; el nivel intermedio
decide que procesos se suspenden o reanudan para lograr ciertas metas de rendimiento
mientras que el planificador de bajo nivel es el que decide que proceso, de los que ya
están listos (y que en algún momento paso por los otros dos planificadores) es al que le
toca ahora estar ejecutándose en la unidad central de procesamiento. En este trabajo se

PROCESOS 53
revisaran principalmente los planificadores de bajo nivel porque son los que finalmente
eligen al proceso en ejecución.
2.5.1.Tipos de planificadores:
Los sistemas pueden incluir varios tipos de planificadores de procesos. La figura 2.16
muestra el caso de tres tipos: corto, medio y largo plazo.
La planificación a largo plazo tiene por objetivo añadir nuevos procesos al sistema,
tomándolos de la lista de espera. Estos procesos son procesos de tipo batch, en los que
no importa el instante preciso en el que se ejecuten (siempre que se cumplan ciertos
límites de espera).
La planificación a medio plazo trata la suspensión de procesos. Es la que decide qué
procesos pasan a suspendido y cuáles dejan de estar suspendidos. Añade o elimina
procesos de memoria principal modificando, por tanto, el grado de multiprogramación.
La planificación a corto plazo se encarga de seleccionar el proceso en estado de listo
que pasa a estado de ejecución, es por tanto, la que asigna el procesador.
La planificación puede ser con expulsión o sin ella. En un sistema sin expulsión un
proceso conserva el procesador mientras lo desee, es decir, mientras no solicite del
sistema operativo un servicio que lo bloquee. Esta solución minimiza el tiempo que
gasta el sistema operativo en planificar y activar procesos, pero tiene como
inconveniente que un proceso puede monopolizar el procesador (imagínese lo que
ocurre si el proceso, por error, entra en un bucle infinito).
Planificación a
largo plazo
Memoria
Exit
Ejecución
Listo Fin E/S Bloqueado
Entra al Planificación a corto plazo

sistema
Zona de intercambio
Listo y Bloqueado y
Procesos Batch suspendido suspendido
en espera Planificación a medio plazo
Figura 2.16. Tipos de planificadores

PROCESOS 54
En los sistemas con expulsión, el sistema operativo puede quitar a un proceso del estado
de ejecución aunque éste no lo solicite. Esta solución permite controlar el tiempo que
está en ejecución un proceso, pero requiere que el sistema operativo entre de forma
sistemática a ejecutar para así poder comprobar si el proceso ha superado su límite de
tiempo de ejecución. Como sabemos, las interrupciones sistemáticas del reloj garantizan
que el sistema operativo entre a ejecutar cada pocos milisegundos, pudiendo determinar
en estos instantes si ha de producirse un cambio de proceso o no.
Para realizar las funciones de planificación, el sistema operativo organiza los procesos
listos en una serie de estructuras de información que faciliten la búsqueda del proceso a
planificar. Es muy frecuente organizar los procesos en colas de prioridad y de tipo.
Lo sucesos que provocan replanificación en virtud de su capacidad de modificar el
estado global del sistema son:
 Interrupciones basadas en el tiempo.
 Interrupciones y terminaciones de E / S.
 La mayoría de las llamada operacionales al SO.
 El envió y recepción de señales.
 La activación de programas interactivos.
2.5.2. Criterios de planificación y rendimiento
Con el fin de poder analizar el rendimiento de la planificación, se debe analizar algunos
parámetros, entre los más importantes tenemos:
 Utilización del Procesador.- Es el tiempo que el procesador se mantiene
trabajando.
 Productividad.- Es la cantidad de trabajo que el procesador completa en una
unidad de tiempo.
 Tiempo de Espera.- Es el tiempo que transcurre mientras el proceso espera en la
cola de procesos listos.
 Tiempo de Retorno.- Es la suma de los tiempos de espera, de ejecución y el
tiempo que el proceso efectúa las operaciones de E/S.
 El Tiempo de Respuesta.- Es el tiempo transcurrido desde la presentación de una
solicitud hasta que se produce la primera respuesta.

PROCESOS 55
Como es lógico un planificador ideal sería el que maximice la productividad con

utilización alta del procesador minimizando los tiempos retorno, de respuesta y espera
con imparcialidad, predecibilidad y repetibilidad.
La utilización del procesador es la fracción de tiempo promedio en el que el procesador
no está inactivo, ya sea ejecutando programas de usuario como el del sistema operativo.
El propósito es que, manteniendo el procesador ocupado tanto tiempo como sea posible,
los periféricos también permanecerán ocupados y se obtendrán buenas ganancias de
inversión.
Como es lógico el hecho de que el procesador esté siempre ocupado no garantiza cuánto
trabajo pueda procesar, ya que puede estar ocupado en los procesos llamados nulos. Lo
más importante es la productividad se refiere a la cantidad de trabajo útil completada en
una unidad de tiempo.
El tiempo de retorno R es el tiempo consumido dentro del sistema, y puede ser
expresado como la suma del tiempo de ejecución, el tiempo de espera y el tiempo en
E/S
El tiempo de espera E es el pago por la competencia entre procesos para usar el
procesador. Se puede expresar como el tiempo de retorno menos el tiempo de ejecución
efectivo x y el usado en los dispositivos E/S d
E(x) = R(x) – x- d
El tiempo de espera identifica a la ineficiencia. Por ejemplo, un trabajo largo ejecutado

sin expropiaciones y un trabajo corto ejecutado con varias expropiaciones pueden
experimentar idénticos tiempos de retorno. Pero los tiempos de espera serian diferentes,
como es lógico la aplicación corta tiene mayor tiempo de espera por lo tanto es mas
ineficiente.
El tiempo de respuesta o consola se define como el tiempo que transcurre desde el
momento en que se da la instrucción hasta que aparece el primer resultado en la
pantalla.
2.6. ALGORITMOS DE PLANIFICACIÓN:
Existen algunos algoritmos de planificación, la aplicación de ellos depende del tipo de
sistema operativo, se puede emplear uno solo o pueden operar conjuntamente para dar
mejores resultado. A continuación se explica cada uno de ellos.

PROCESOS 56
2.6.1. Planificación FCFS (FIRST-COME, FIRST-SERVED)

Es muy simple, los procesos se despachan de acuerdo con su tiempo de llegada a la cola
de listos o preparados. Una vez que el proceso obtiene el procesador, se ejecuta hasta
terminar, ya que es una disciplina no expropiativa
Puede ocasionar que procesos largos hagan esperar a procesos cortos y que procesos no
importantes hagan esperar a procesos importantes.
Suele utilizarse integrado a otros esquemas, por ejemplo, a procesos de igual prioridad
se puede despachar utilizando FCFS.
Es un algoritmo más predecible que otros esquemas y no puede garantizar buenos
tiempos de respuesta interactivos.
2.6.2. Planificación SRTN (SHORTEST REMAINING TIME NEXT)
El proceso en espera con el menor tiempo estimado de ejecución hasta su terminación
es el siguiente en ejecutarse. Requiere un conocimiento preciso del tiempo de ejecución
de un proceso, lo que generalmente se desconoce, pero se pueden estimar los tiempos en
base a estadísticas anteriores. La dependencia sobre el conocimiento futuro tiende a
limitar en la práctica la efectividad de las implementaciones SRTN, ya que en general el
comportamiento futuro del proceso es desconocido y difícil de estimar.
La planificación SRTN se puede implementar tanto con una disciplina expropiativa
como no expropiativa.
En general se puede indicar lo siguiente:
 Los tiempos promedio de espera son menores que con FCFS.
 Los tiempos de espera son menos predecibles que en FCFS.
 Favorece a los procesos cortos en detrimento de los largos.
 Tiende a reducir el número de procesos en espera.
2.6.3. Planificación por reparto del tiempo RR. (ROUND ROBIN)
Es un disciplina expropiativa ideal para entornos de tiempo compartido, también
conocida planificación por turnos. Básicamente, el tiempo del procesador se divide en
cuotas o cuantos que son asignados a los procesos que lo solicitan. Ningún proceso
puede ejecutarse durante mas de una cuota de tiempo cuando hay otros esperando en la

PROCESOS 57
cola de preparados. Sin un proceso necesita mas tiempo para completar después de
agotar su cuota de tiempo, se coloca la final de la lista de preparados para esperar a una
asignación siguiente. Se puede ayudar de la disciplina FCFS.
La determinación del tamaño del cuanto es decisiva para la operación efectiva de un
sistema computacional [7] Deitel.
Los interrogantes son: ¿Tamaño de cuanto pequeño o grande?, ¿Tamaño del cuanto fijo
o variable? y ¿Tamaño del cuanto igual para todos los procesos de usuarios o
determinado por separado para cada uno de ellos?
Si el cuanto se hace muy grande, cada proceso recibe todo el tiempo necesario para
llegar a su terminación, por lo cual la asignación en rueda (“RR”) degenera en “FIFO o
FCFS”.
Si el cuanto se hace muy pequeño, la sobrecarga del intercambio de contexto se
convierte en un factor dominante y el rendimiento del sistema se degrada, puesto que la
mayor parte del tiempo de cpu se invierte en el intercambio del procesador (cambio de
contexto) y los procesos de usuario disponen de muy poco tiempo de cpu.
El cuanto debe ser lo suficientemente grande como para permitir que la gran mayoría de
las peticiones interactivas requieran de menos tiempo que la duración del cuanto, es
decir que el tiempo transcurrido desde el otorgamiento de la UCP a un proceso hasta
que genera una petición de Entrada / Salida debe ser menor que el cuanto establecido,
de esta forma, ocurrida la petición la UCP pasa a otro proceso y como el cuanto es
mayor que el tiempo transcurrido hasta la petición de Entrada / Salida, los procesos
trabajan al máximo de velocidad, se minimiza la sobrecarga de apropiación y se
maximiza la utilización de la Entrada / Salida.
El cuanto óptimo varía de un sistema a otro y con la carga, siendo un valor de referencia
100 mseg (cien milisegundos). [7] Deitel.
2.6.4. Planificación con expropiación basada en prioridades ED ( EVENT
DRIVEN)
Considera factores externos al proceso. [10] Tanenbaum
Las ideas centrales son que cada proceso tiene asociada una prioridad y que el proceso
ejecutable con máxima prioridad es el que tiene el permiso de ejecución.
Los procesos de alta prioridad podrían ejecutarse indefinidamente.

PROCESOS 58
El planificador del sistema puede cambiar la prioridad del proceso en ejecución en cada
interrupción del reloj para lograr ciertas metas relacionadas con el procesador o la
Entrada / Salida.
Los procesos con requerimientos intensivos de Entrada / Salida ocupan mucho de su
tiempo en espera de operaciones de Entrada / Salida, por lo tanto:
 Deben tener prioridad para usar la UCP y efectuar la siguiente petición de Entrada
/Salida, ya que se ejecutará en paralelo con otro proceso que utilice la UCP.
 Si deben esperar mucho tiempo a la UCP estarán ocupando memoria por tiempo
innecesario.
Frecuentemente los procesos se agrupan en “Clases de Prioridad”, en cuyo caso se
utiliza la planificación con prioridades entre las clases y con round robin (RR) dentro de
cada clase. Si las prioridades no se reajustan en algún momento, los procesos de las
clases de prioridad mínima podrían demorarse indefinidamente.
2.6.5. Planificación MLQ
De las disciplina de planificación descritas hasta ahora ¿Cuál debería utilizarse en un
sistema mixto o de propósito general, en el que hay sucesos críticos en el tiempo, una
multitud de usuarios interactivos y algunos trabajos no interactivos muy largos?. La
solución podría estar en combinar varias disciplinas de planificación clasificadas de
acuerdo a la carga de trabajo manteniendo colas de procesos separadas servidas por
diferentes planificadores. A este método se le denomina planificación de colas
multinivel (MLQ).
Una posible división de la carga de trabajo seria: procesos de sistema, programas
interactivos y trabajos de lotes. Esto daría lugar a tres colas separadas, como se muestra
en la Figura 2.17.
Planificación
guiada por
eventos
Procesos de sistema
Cola de prioridad alta

Planificador entre colas
(Prioridad, Reparto de
Tiempo proporcional)
Planificación
reparto del
tiempo
Procesos
interactivos
Cola de prioridad media UCP
Planificación
FCFS
Procesos generados
por lotes
Cola de prioridad baja
Figura 2.17. Ejemplo de planificación de colas de multinivel.

PROCESOS 59
2.6.6. Planificación por múltiples colas con realimentación

La realimentación en el mecanismo MLQ tiende a clasificar los procesos
dinámicamente de acuerdo con la cantidad observada de servicio obtenido, dando
preferencia a aquellos que han recibido menos.
En lugar de tener clases fijas de procesos asignados a colas específicas, la idea es hacer
que un proceso pueda pasar de una cola a otra dependiendo de su compartimiento en
tiempo de ejecución.
En el caso de Windows utiliza los dos algoritmos de planificación, en primer lugar el de
prioridades y luego el de reparto de tiempo en dos fases. La figura 2.18 gráficamente
indica la secuencia:
Figura 2.18a. Actúa el primer planificador.
 En la primera fase se valora cada hebra por su prioridad. Figura 2.18 a

 Se le asigna un número que puede ir desde 0 a 32. Figura 2.18b
 Si hubiese dos o mas hebras con la misma prioridad pasa a actuar el segundo
planificador.

PROCESOS 60
Figura 2.18b. Actúa el primer planificador asignando prioridades.
Cuando existen dos o más procesos con la misma prioridad se utiliza el algoritmo de
reparto de tiempo entre estos procesos hasta finalizar, dejando los otros procesos en lo
que se denomina en segundo plano. Figura 2.18c y 2.18d
Figura 2.18c y d. Actúa el segundo planificador utilizando el reparto de tiempo.

Gestión de Procesos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestión de Procesos

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO 2.

En un computador se ejecutan los programas, y cada programa es divido en procesos

Capítulo 2. Sistemas Operativos

2.1.1. División implícita y explícita en tareas

Capítulo 2. Sistemas Operativos

2.1.2. Relaciones entre procesos

Inicio Inicio Inicio Inicio Dem. Impr. Dem. Com..

Proceso B Proceso D Proceso C

Figura 2.1. Jerarquía de procesos.

Capítulo 2. Sistemas Operativos

Capítulo 2. Sistemas Operativos

ejecutables mientras los procesos suspendidos esperan la terminación de sus

Capítulo 2. Sistemas Operativos

Figura 2.2. Ejecución secuencial y concurrente de procesos

2.2.2. Sincronización entre procesos.

Capítulo 2. Sistemas Operativos

(a) Suposiciones de tiempo

RECOGER GUARDAR CALCULAR IMPRIMIR RECOGER 2

(b) Ejecución Secuencial

Capítulo 2. Sistemas Operativos

Figura 2.3. Procesos temporizados

Si suponemos que RECOGER, GUARDAR, CALCULAR e IMPRIMIR tardan

Figura 2.4. Procesos temporizados con ejecución multitarea

En la Figura 2.4 se muestra la ejecución de los cuatro procesos, comenzando

Capítulo 2. Sistemas Operativos

de utilización del procesador y espera a que se complete la operación de E/S de disco, el

Capítulo 2. Sistemas Operativos

Figura 2.5. Procesos temporizados

Estos elementos se organizan en tres grupos: Estado del procesador, Imagen de

Capítulo 2. Sistemas Operativos

según dos argumentos: eficiencia y necesidad de compartir información. En las

Figura 2.6. Creación de un proceso.

Capítulo 2. Sistemas Operativos

 Rellenar el BCP con la información de identificación del proceso, con la

Figura 2.7. Comportamiento de procesos según estados.

Como se muestra en la Figura 2.7, existe un intervalo en el que el procesador no tiene

Capítulo 2. Sistemas Operativos

En la Figura 2.7, no todos los procesos activos de un sistema multitarea están en la

Termina Espera suceso

Figura 2.8. Transición de procesos según estados.

Capítulo 2. Sistemas Operativos

Capítulo 2. Sistemas Operativos

Información de control del proceso.- En esta sección se incluye diversa información

Los sistemas operativos de multiprogramación están en gran medida guiados por

2.3.4. Conmutación de procesos.

 Un proceso está en ejecución, su información reside en los registros del

BCP Proceso A BCP Proceso B BCP Proceso N

Registros Estado Estado Estado

Figura 2.9. Información de los procesos

Espacio de Espacio del

 Guarda el estado hardware de Pa

Figura 2.10. Conmutación de procesos.

Capítulo 2. Sistemas Operativos

Figura 2.11. División de un proceso en hebras

Capítulo 2. Sistemas Operativos

Recursos (ficheros, ...)

Entorno del proceso

Figura 2.12. Estructura de un proceso con sus hebras en Windows.

2.4. APLICACIONES Y MULTITAREA EN WINDOWS.

Capítulo 2. Sistemas Operativos

Tipo de # de máquinas Hebras1 Memoria.

8 bits (MSDOS) 1 por aplicaciones 1 Separada/cada

16 bits (Windows 1 por aplicación 1 Compartida

32 bits (Windows 1 por todas las Más de Separada