Download - Sistemas Operativos Mod6
© FUOC • P05/75097/00809 • Módulo 6 La gestión de procesos
Índice
Introducción............................................................................................. 5
Objetivos .................................................................................................... 5
1. El proceso: una mirada desde el interior del sistema ............... 7
1.1. Los elementos de un proceso y su representación .......................... 7
1.2. La ejecución concurrente ................................................................ 9
1.3. Los estados de un proceso ............................................................... 10
2. El ciclo de vida de un proceso ......................................................... 13
2.1. La creación y la destrucción de procesos ........................................ 13
2.2. La herencia entre procesos .............................................................. 16
2.3. La sincronización y el estado de finalización
en la destrucción de procesos.......................................................... 19
2.3.1. La sincronización ................................................................. 19
2.3.2. El estado de finalización de los procesos ............................. 21
2.4. Los cambios en el entorno de ejecución ......................................... 22
3. Las excepciones y las señales de software..................................... 25
4. La gestión de procesos en UNIX ...................................................... 27
4.1. La creación y la destrucción de procesos ........................................ 28
4.2. Los cambios del entorno que configura un proceso ....................... 30
4.3. La jerarquía de procesos en UNIX ................................................... 36
4.4. Las señales en UNIX ........................................................................ 37
Resumen..................................................................................................... 39
Actividades................................................................................................ 41
Ejercicios de autoevaluación ................................................................ 41
Solucionario.............................................................................................. 45
Glosario ...................................................................................................... 46
Bibliografía............................................................................................... 47
© FUOC • P05/75097/00809 • Módulo 6 5 La gestión de procesos
La gestión de procesos
Introducción
Este módulo didáctico se centra en el estudio de la vida de los procesos desde
el punto de vista de las llamadas al sistema que permiten manipularlos. Así
pues, en lugar de ver –como ya se hizo en esta asignatura– la creación de fiche-
ros ejecutables y los mecanismos del sistema para comunicarse con los progra-
mas (las llamadas), ahora nos centraremos en el estudio de las operaciones
que permiten gestionar los procesos, en concreto en las que permiten crear-
los, destruirlos y modificarlos. Antes de nada, sería necesario que profundizá-
semos brevemente en el concepto de proceso, que ya se ha presentado en esta
asignatura, y en la gestión interna de los procesos que lleva a cabo el sistema
operativo (SO).
Objetivos
Los materiales didácticos de este módulo contienen las herramientas necesa-
rias para alcanzar los siguientes objetivos:
1. Entender el concepto de proceso como objeto gestionado por el SO.
2. Conocer las diferentes partes que componen un proceso y ver cómo se re-
presenta este proceso en el interior del sistema.
3. Entender los estados en que puede encontrarse un proceso y los motivos
por los cuales un proceso puede cambiar de estado.
4. Saber qué es el ciclo de vida de los procesos y conocer las relaciones entre
procesos.
5. Comprender el concepto de herencia y ver qué repercusiones tiene la he-
rencia en la creación de procesos.
6. Conocer las diferentes posibilidades que nos ofrece el hecho de poder cam-
biar algunos de los elementos que componen los procesos, sobre todo en
relación con los redireccionamientos.
7. Entender el concepto de señal de software y estudiar su relación con la des-
trucción de procesos.
© FUOC • P05/75097/00809 • Módulo 6 7 La gestión de procesos
1. El proceso: una mirada desde el interior del sistema
Para gestionar los procesos y darles servicios, el sistema operativo tiene que
proporcionar herramientas o tiene que llevar a cabo acciones que permitan
conseguir los siguientes objetivos:
• Crear y eliminar procesos.
• Garantizar que los procesos dispongan de los recursos necesarios para
avanzar en su ejecución.
• Actuar en casos excepcionales durante la ejecución del proceso*.
• Proporcionar los mecanismos necesarios para que los procesos se comuni-
quen, ya sea para intercambiar información, ya sea para sincronizarse du-
rante la ejecución.
• Mantener estadísticas sobre el funcionamiento de los procesos.
• Temporizar la ejecución de un proceso: hacer que un proceso se ejecute
cada cierto tiempo.
• Otros servicios misceláneos.
En este apartado realizamos una introducción a la gestión que el SO lleva a
cabo sobre los procesos. Veremos las estructuras de datos que representan in-
ternamente un proceso y la forma como pueden ejecutarse concurrentemente
varios procesos en un único procesador.
1.1. Los elementos de un proceso y su representación
Tal y como hemos visto, el SO construye los procesos de acuerdo con un con-
junto de elementos que son necesarios para la ejecución de un programa. Para
gestionar este conjunto de recursos como un todo, el sistema reúne informa-
ción de éstos en una estructura de datos denominada bloque de control de
procesos* o PCB. A cada proceso le corresponde su propio PCB. Los campos
más importantes que configuran los PCB son los siguientes:
1) El identificador del proceso. Es el código único que identifica de manera
biunívoca cada uno de los diferentes procesos que se encuentran en ejecución
Un proceso es básicamente un entorno formado por todos los recursos ne-
cesarios para ejecutar programas. Desde el punto de vista del SO, un proce-
so es un objeto más que hay que gestionar y al cual hay que dar servicio.
Podéis ver el concepto de proceso en el subapartado 2.1. del módulo didáctico “El sistema operativo:una máquina virtual”.
* Consideramos casos excepcionales sucesos como
las interrupciones, los errores, etc.
La expresión Process Control Block o PCB es el equivalente inglés del concepto bloque de control
de procesos.
© FUOC • P05/75097/00809 • Módulo 6 8 La gestión de procesos
en el sistema y que, por tanto, tiene que ser distinguido individualmente. Por
lo general, este identificador es numérico.
2) El estado del proceso. Este campo indica el estado del proceso en el momen-
to actual, dentro de unas posibilidades determinadas (run, ready, wait, etc.). El
estado de un proceso y su significado aparecen descritos más adelante.
3) El contador del programa. Este campo es fundamental porque “señala” la
instrucción que estaba a punto de ejecutarse justo en el momento en que se
produce una interrupción. Cuando el proceso puede continuar, lo hace exac-
tamente en este punto.
4) Los registros internos de la CPU. Son registros utilizados por todos los
procesos. Por lo tanto, después de una interrupción no es suficiente con con-
tinuar la ejecución del proceso en el punto donde se dejó, sino que también
hay que encontrar un entorno idéntico al que tenía antes de producirse la in-
terrupción. Para contar con esta posibilidad también es necesario que guarde-
mos el valor de los registros.
5) El estado de la memoria. Es difícil generalizar acerca de lo que necesita
cada sistema operativo para tener toda la información relativa a la memoria
de cada proceso, pero podemos dar algunas ideas, como la cantidad de memo-
ria asignada, el lugar donde se encuentra, el tipo de gestión que se lleva a cabo,
las protecciones de cada parte, las comparticiones, etc.
6) Contabilidad y estadísticas. El sistema operativo obtiene para cada proce-
so una serie de información relativa al comportamiento de cada usuario. Esta
información tiene un gran valor para los administradores de sistema, pero no
demasiado para los usuarios o los programadores.
7) El estado de los dispositivos de entrada/salida. Los dispositivos de entra-
da/salida asignados, las solicitudes pendientes, los ficheros abiertos, etc. tam-
bién forman parte del entorno de ejecución.
8) El dominio de protección. Este campo contiene información de los domi-
nios a los cuales pertenece el proceso y de los derechos que tienen asociados.
9) La planificación de la CPU. En este campo se agrupa información relativa
a la forma como el proceso accede al procesador en concurrencia con los otros
procesos.
10) Otras informaciones. Cada sistema operativo mantiene otras informa-
ciones particulares en función de diferentes aspectos, como por ejemplo el fa-
bricante del sistema operativo, el tipo de orientación* y el tipo de explotación**.
Podéis ver los estados de un proceso y su significado en el subapartado 1.3. de este módulo didáctico.
Podéis ver los dominios de protección en el subapartado 4.1. del módulo didáctico “El sistema de ficheros”.
* El trabajo en tiempo real,las comunicaciones, etc.
** Uso privado, uso público, etc.
© FUOC • P05/75097/00809 • Módulo 6 9 La gestión de procesos
De acuerdo con los PCB, el sistema gestiona la ejecución de los programas con-
tenidos en la memoria de los procesos. En los siguientes subapartados analiza-
remos los principales componentes de esta gestión teniendo en cuenta las
necesidades de un sistema multiprogramado.
1.2. La ejecución concurrente
En la figura 1 podemos ver la ejecución concurrente de un conjunto de proce-
sos (P1, P2 y P3) sobre un sistema monoprocesador multiprogramado. En fun-
ción de la escala de tiempo con la que examinemos la evolución de los
procesos en el sistema, podemos tener diferentes versiones.
1) La primera escala de tiempo, que se ve en la figura 1a, corresponde al punto
de vista del usuario. Aquí parece que la ejecución de los tres procesos se efectúa
en paralelo, y en apariencia cada proceso utiliza siempre el procesador. Ésta es
la impresión que se quiere dar en los sistemas multiusuario: que cada usuario
tiene una buena interactividad con el sistema y que el usuario está solo traba-
jando ante la máquina. En realidad, en un sistema que trabaja en modalidad
de tiempo compartido, esto no es cierto.
Figura 1
© FUOC • P05/75097/00809 • Módulo 6 10 La gestión de procesos
2) Si nos fijamos en el comportamiento de los procesos a una escala de tiempo
menor, veremos que se da una multiplexación del procesador en el tiempo (ob-
servad la figura 1b). Ampliando la figura 1a (haciendo un zoom), podemos obser-
var que no hay una ejecución real en paralelo de los procesos; sólo uno de ellos
está en ejecución real. Para conseguir el efecto de ejecución concurrente se lleva
a cabo una conmutación entre los procesos que se reparten el tiempo del proce-
sador. Estas conmutaciones se denominan cambio de contexto.
3) finalmente, ampliando más la imagen, es decir, a una escala de tiempo toda-
vía menor, podemos ver el detalle de las transiciones entre procesos o cambio
de contexto (observad la figura 1c). Podemos observar que tiene que aparecer
un fragmento de código nuevo para gestionar la interrupción que provoca el
cambio, y para ello es necesario llevar a cabo las siguientes operaciones:
• Guardar el estado del procesador tal y como lo tenía el proceso P1 en el ins-
tante en que se ha producido la interrupción sobre su PCB.
• Localizar el PCB del proceso P2.
• Restaurar el estado del procesador guardado en el segundo PCB.
El estado del procesador en un instante concreto está formado por los valores
contenidos en cada uno de los registros en lenguaje máquina, por el puntero a
la pila, por el contador de programa y, en general, por toda la información que
configura un proceso. Los valores concretos de este conjunto de registros en un
instante de la vida de un proceso se conocen como contexto del proceso.
1.3. Los estados de un proceso
En un sistema multiprogramado como el que hemos descrito en el subaparta-
do anterior, con muchos procesos y un procesador, en un momento determi-
nado sólo puede haber un proceso en ejecución, y el resto de los procesos
puede estar esperando su turno para acceder al procesador o la finalización de
una operación de entrada/salida. Esta variedad de situaciones se puede repre-
sentar con un diagrama de estados como el de la figura 2, donde los nodos re-
presentan los estados en que pueden encontrarse los procesos, y los arcos son
las acciones que hacen que un proceso cambie de estado.
Cuando el sistema acaba de crear un proceso, este proceso se encuentra en el
estado inicial (1), el estado ready. El sistema puede salir de este estado por es-
tas dos causas:
1) Un acontecimiento externo al propio proceso, que se puede deber a la ac-
ción de otro proceso mediante una señal de software, provoca la finalización
del proceso (2).
Ready significa: “Lo tengo todoa punto y estoy preparado para
recibir la CPU y trabajar”.
© FUOC • P05/75097/00809 • Módulo 6 11 La gestión de procesos
2) El gestor le asigna la CPU (3) y el proceso empieza a ejecutar sus instruccio-
nes y pasa al estado run.
Del estado run se puede salir por los tres motivos que presentamos a con-
tinuación:
1) El proceso ejecuta la última línea de código y acaba (4).
2) El proceso tiene que esperar un acontecimiento externo. El ejemplo más
normal es cuando se solicita una operación de entrada/salida (5) y el proceso
espera que sea servida*. En este caso, el proceso pasa al estado wait y espera
hasta que la petición se haya servido.
3) Cuando el sistema operativo trabaja en la modalidad de tiempo comparti-
do, si el proceso supera la cuota máxima de tiempo de uso de CPU que tiene
asignada (6), deja el procesador y vuelve al estado ready.
Cuando un proceso sale del estado run para pasar a ready o wait, se produce un
cambio de contexto, como se ha indicado en el subapartado anterior.
Finalmente, los procesos tienen dos destinos posibles tras salir del estado wait:
1) Uno hacia el estado ready, cuando finaliza la operación por la cual esperaban
(7) o, dicho de otro modo, cuando el proceso tiene suficiente información y pue-
de continuar. Por ejemplo, si el proceso estaba pendiente de una operación de en-
trada/salida y ya ha llegado la información esperada porque el usuario ha pulsado
una tecla.
* Por ejemplo, una entrada de información por teclado.
Podéis ver la ejecución de procesos en la modalidad de tiempo compartido en el subapartado 2.3. del módulo didáctico “Introducción a los sistemas operativos”.
Figura 2
© FUOC • P05/75097/00809 • Módulo 6 12 La gestión de procesos
2) Otro, hacia la finalización del proceso (8), debida a un acontecimiento ex-
terno al propio proceso, como sucedía en el estado ready.
Para saber qué hace cada uno de los procesos y así poder controlar sus recursos,
el sistema operativo mantiene unas colas de procesos en función de su estado.
Así, el sistema tiene una cola de procesos preparados (ready) y una de procesos
en estado de espera (wait). No podemos hablar de una cola de procesos en eje-
cución, ya que en entornos monoprocesador sólo hay un proceso en ejecu-
ción. De este modo, el procedimiento del núcleo del SO que se encarga de la
planificación del procesador puede examinar la lista de procesos preparados
para asignar el procesador al proceso que resulte más conveniente.
Figura 3
ID: identificador de procesos
© FUOC • P05/75097/00809 • Módulo 6 13 La gestión de procesos
2. El ciclo de vida de un proceso
Como hemos ido viendo en esta asignatura, los procesos constituyen uno más
de los objetos que gestiona el SO. A diferencia de muchos otros objetos, los
procesos son dinámicos y suelen tener un tiempo de vida limitado*. En este
apartado analizaremos el ciclo de vida de los procesos y las operaciones que se
relacionan con éstos.
Las diferentes etapas de la vida de un proceso son las siguientes:
1) Creación, nacimiento o inicio. En esta etapa se asignan e inicializan los
recursos necesarios para crear un proceso nuevo.
2) Desarrollo. Una vez se han creado, los procesos evolucionan a partir de la
ejecución del programa que contienen. Este desarrollo puede llevarlos a mo-
dificar los recursos con los que se han constituido inicialmente.
3) Destrucción, muerte o finalización. Tras finalizar el trabajo que especifi-
ca la aplicación que se ejecuta en el marco del proceso, el SO destruye el pro-
ceso y libera los recursos que se le habían asignado.
En este apartado nos disponemos a analizar el ciclo de vida del proceso, y para
hacerlo estudiaremos en primer lugar los procesos de creación y destrucción
de un proceso; a continuación, las relaciones que se dan entre estas dos accio-
nes y, finalmente, veremos algunas de las modificaciones que se pueden efec-
tuar sobre el entorno que constituye un proceso durante su existencia.
2.1. La creación y la destrucción de procesos
Los procesos son elementos dinámicos que se crean, operan durante un inter-
valo de tiempo y se destruyen. El sistema es el encargado de proporcionar el
conjunto de llamadas necesarias para llevar a cabo todas estas acciones. En
este subapartado analizaremos las operaciones de creación y destrucción de
procesos.
1) Creación de procesos
La creación de un proceso nuevo es el resultado de la ejecución de una
llamada al sistema del tipo crear_proceso, que es invocada, como todas
las llamadas, por un proceso ya existente.
* Los procesos se crean, interactúan con el sistema y mueren.
© FUOC • P05/75097/00809 • Módulo 6 14 La gestión de procesos
La ejecución de la llamada crear_proceso comporta la creación de un en-
torno de ejecución que contiene los siguientes elementos:
• La memoria donde residirán el programa, el código y los datos con que
operará el proceso.
• El punto de entrada desde donde se ejecutará el programa que contenga la
memoria.
• El entorno de entrada/salida con el cual el proceso se comunicará con el exterior.
• Los atributos relacionados con los dominios de protección con los que el sis-
tema operativo verificará la legalidad de las operaciones que quiera efectuar.
Cada uno de estos elementos del entorno se tendrá que especificar en el siste-
ma para que éste pueda crear un proceso nuevo. La especificación de estos ele-
mentos se puede realizar de las dos formas siguientes:
a) De manera explícita, con los parámetros de la llamada al sistema que crea
el proceso.
b) De manera implícita, haciendo que el sistema tome unos valores por defecto.
Normalmente, los sistemas combinan las dos alternativas: obligan a especifi-
car algunos de estos elementos mediante los parámetros de la llamada, y dejan
otros con valores por defecto.
Otro aspecto que hay que tener en cuenta es la relación que se establece entre
el entorno desde donde se ejecuta la llamada al sistema que dará lugar al nue-
vo proceso y el nuevo entorno que se creará. Para ver esta relación con una
mayor claridad partimos del hecho ya mencionado de que los procesos son
creados por el sistema operativo a petición de otros procesos. Esta situación
hace que los procesos se puedan ver desde el punto de vista de la descenden-
Figura 4
© FUOC • P05/75097/00809 • Módulo 6 15 La gestión de procesos
cia, en la que los procesos mantienen relaciones de parentesco como la de pa-
dre e hijo. En este ámbito podemos hablar de los conceptos de herencia entre
procesos y sincronización entre procesos padre e hijo.
Tras haber creado el proceso, el sistema le otorga un nombre (generalmente
un nombre dentro de un espacio lineal) mediante el cual se podrá referenciar
en acciones de control y manipulación, tanto desde otros procesos como di-
rectamente desde el SO. Este nombre tiene que ser único para cada proceso,
no sólo durante la vida del proceso al que hace referencia, sino durante toda
la vida del sistema.
La finalidad del sistema de tener un nombre único para cada proceso durante
toda la vida del sistema es evitar confusiones y malos funcionamientos del SO
a causa de la reutilización de nombres. Por ejemplo, imaginemos dos procesos
(proceso A y proceso B) que colaboran y se sincronizan mediante señales gra-
cias al hecho de que conocen sus identificadores. Si uno (el proceso B) acaba
de manera imprevista y su indentificador es reutilizado para crear otro proce-
so, entonces el proceso A se está sincronizando con un proceso que tiene un
identificador B, que no es el proceso con el que se había previsto una comuni-
cación. El resultado es que quizá ninguno de los dos procesos funcione correc-
tamente o, lo que todavía es más problemático, que se haya abierto un agujero
en la protección del sistema.
Con esta solución, si el punto de ejecución del proceso hijo fuese una copia del
del padre, como ya habíamos comentado, el valor de retorno de crear_proceso
tendría que ser diferente en función de si el proceso es el padre o el hijo.
2) Destrucción de procesos
La destrucción de un proceso por parte del sistema puede ser consecuencia de
alguna de las siguientes situaciones:
a) La ejecución de la llamada al sistema destruir_proceso específica para este
motivo. En la mayor parte de los sistemas, esta llamada provoca la destrucción
del proceso que la invoca, y no se puede dirigir a otros procesos.
Así pues, una posible estructura de la llamada crear_proceso podría ser:
Id_proceso = crear_proceso (entorno_mem, nombre_prog, punto_ejecución,
entorno_E/S, entorno_dominio).
La destrucción de un proceso comporta la destrucción del entorno que
lo constituye y la liberación de los recursos que tenía asignados.
Podéis ver la herencia entre procesos en el subapartado 2.2. y la sincronización entre procesosen el subapartado 2.3. de este módulo didáctico.
Podéis ver los espacios linealesen el subapartado 3.2. del módulo didáctico “El sistema de ficheros”.
Podéis ver los identificadores de los procesos en el subapartado 1.1. del módulo didáctico “La concurrenciay la comunicación”.
Podéis ver en el caso de UNIX los diferentes valores retornados para la operación crear_proceso según el tipo de proceso en el apartado 4 de este módulo didáctico.
Podéis ver las situaciones que comporta la destrucción de un proceso en la figura 7 del subapartado 4.4. del módulo didáctico “El sistema operativo: una máquina virtual”.
© FUOC • P05/75097/00809 • Módulo 6 16 La gestión de procesos
b) El mal funcionamiento del proceso destruido. Si el sistema detecta que un
proceso no funciona correctamente y efectúa operaciones no permitidas, lo
destruye. Estas operaciones suelen asociarse a las excepciones provocadas por
acciones como pueden ser acceder a posiciones de memoria que no se tienen
asignadas, ejecutar instrucciones privilegiadas o efectuar operaciones aritmé-
ticas incorrectas como, por ejemplo, una división por cero, etc.
c) El efecto lateral de la ejecución, por parte de otro proceso, de una llamada
al sistema diferente de la llamada destruir_proceso, que provoca una excepción
sobre el proceso que se destruye.
Ahora nos centraremos en exclusiva en el primer punto: la destrucción de un
proceso como resultado de la ejecución de la llamada al sistema destruir_proceso.
Las dos últimas situaciones las veremos más adelante.
Todo proceso, cuando finaliza sin incidentes la ejecución del programa que alma-
cena, tiene que ser destruido. Esta destrucción puede ser el resultado de la ejecu-
ción de la llamada destruir_proceso. Para que se lleve a cabo la destrucción, el
compilador inserta automáticamente, de manera transparente para el software, la
llamada al sistema destruir_proceso como última instrucción del programa. De
manera adicional, el programador puede incluir invocaciones a la llamada
destruir_proceso para provocar la finalización del proceso en situaciones contro-
ladas por el programa.
2.2. La herencia entre procesos
En concreto, tenemos los tres tipos de herencia que exponemos a continua-
ción:
1) Compartición: el proceso padre y el proceso hijo comparten un mismo
elemento y, en consecuencia, las manipulaciones de este elemento que se lle-
ven a cabo afectarán a ambos procesos de la misma manera.
2) Copia: el SO crea los elementos que configuran el entorno del proceso hijo
como una copia de los elementos del proceso padre en el momento de invocar
Así pues, la llamada para destruir un proceso podría ser ésta:
Estado = destruir_proceso (id_proceso).
La herencia entre procesos es la relación que se establece entre los dife-
rentes elementos que configuran el entorno del proceso padre y los que
configuran el entorno del proceso hijo.
Podéis ver la destrucción de procesos como efecto derivado dela ejecución de otros procesos o de las llamadas al sistema solicitadas por otros procesos en el apartado 3 de este módulo didáctico.
© FUOC • P05/75097/00809 • Módulo 6 17 La gestión de procesos
la operación de creación. A partir del momento en que el proceso hijo ha sido
creado, los dos entornos evolucionan de forma diferente.
3) Valores nuevos: en este caso, el SO crea de nuevo los elementos del proce-
so hijo y lo hace sin tener en cuenta los del proceso padre.
Cada elemento que configura el entorno puede tener una herencia diferente
que puede venir predeterminada por el sistema o bien puede establecerse me-
diante los parámetros de la llamada al sistema de creación. A continuación
analizaremos lo que representan estas posibilidades con respecto a cada uno
de los elementos del entorno:
1) La memoria y su contenido. La memoria, como hemos visto anterior-
mente, se puede organizar por segmentos. Para simplificar la exposición, nos
centraremos en tres segmentos: el código, los datos y la pila. Los atributos de
herencia pueden ser diferentes para cada segmento; el código y los datos pue-
den tener cualquiera de los tres atributos de herencia, mientras que la pila sólo
puede tener herencia de copia o de valores nuevos, pero no compartida, ya
que refleja el estado de llamadas a procedimientos y a variables locales de cada
proceso. Esto último se debe al hecho de que la pila es necesaria para garanti-
zar que los dos procesos (padre e hijo) evolucionan de manera independiente.
Así pues, las herencias posibles para la memoria son las siguientes:
a) Compartición: los procesos hijo y padre comparten el mismo segmento de
memoria física. Ésta es la situación más conveniente para segmentos de código
y, en general, para segmentos que contengan información que sólo tiene que
ser leída. En caso de compartición de un segmento de datos, cualquier modi-
ficación que realice uno de los dos procesos alterará el estado de la memoria.
Esta situación permite la colaboración de los procesos mediante la comparti-
ción de información.
b) Copia: los segmentos del proceso hijo son una copia exacta de los del padre
en el instante de la creación. Cuando se crea un proceso por duplicación del
proceso padre, hay que copiar, como mínimo, todos los segmentos que se pue-
den modificar durante la ejecución independiente del proceso padre y del hi-
jo, que son los segmentos de datos y de pila. Otro caso es cuando se crea un
proceso por compartición, y padre e hijo comparten código y datos. En esta
situación, el segmento de pila no se puede compartir, por lo que hay que co-
piarlo. El motivo, como ya se ha expuesto, es que la pila refleja el estado de las
llamadas a procedimientos y a variables locales de cada proceso que son fruto
de la ejecución independiente de los procesos.
c) Valores nuevos: en este caso se carga un fichero ejecutable que definirá de
nuevo el contenido de la memoria.
2) El punto de inicio de ejecución dentro de la memoria. El punto de inicio
de ejecución del programa depende del contenido de la memoria, en concreto
Podéis ver la segmentación de la memoria en el subapartado 3.1. del módulo didáctico “La gestión de la memoria”.
Podéis ver la problemática asociada a la compartición de la información en el apartado 1 del módulo didáctico “La concurrencia y la comunicación”.
© FUOC • P05/75097/00809 • Módulo 6 18 La gestión de procesos
del contenido del segmento de código. En caso de copiar o compartir el código
con el proceso padre, el punto de ejecución puede ser o bien el mismo que el
del proceso padre, o bien una dirección que se introduce como parámetro de
la operación de creación. En caso de cargar en la memoria un programa nuevo,
el punto de ejecución ya está especificado en el fichero ejecutable.
Así pues, las posibles herencias serán éstas:
a) Copia: el punto de ejecución del proceso padre se copia en el hijo. Este caso
sólo es posible si se comparten o se copian los segmentos de código y de datos.
Para distinguir el proceso padre del proceso hijo, lo más habitual es que los dos
procesos reciban valores de retorno diferentes de la llamada de creación al sis-
tema.
b) Valores nuevos: el punto de ejecución se define o bien por los parámetros
de la llamada al SO, o bien por el fichero ejecutable que definirá el contenido
de la memoria.
El entorno de compartición no es posible, ya que los procesos padre e hijo
cuentan con ejecuciones independientes.
3) El entorno de entrada/salida. La herencia del entorno de entrada/salida es
independiente de la de memoria. El concepto de entorno de entrada/salida hace
referencia a las sesiones de acceso a dispositivos que el proceso encontrará abiertas
de manera implícita.
El entorno de entrada/salida puede tener las tres modalidades de herencia que
presentamos a continuación:
a) Compartición: el proceso padre comparte con el proceso hijo las sesiones
de trabajo con los dispositivos que tenga abiertos en el momento de la crea-
ción. Las modificaciones que uno de los dos procesos realice sobre estas sesio-
nes de trabajo también afectarán al otro. Así, por ejemplo, en el caso de una
sesión de acceso secuencial, los dos procesos compartirán un único puntero de
acceso. Las sesiones de acceso a los dispositivos que abran a partir del momen-
to de la creación serán independientes en cada proceso.
b) Copia: el proceso hijo encuentra abiertas las mismas sesiones de acceso a
los dispositivos que tenía abiertas el padre, pero con la diferencia de que las
acciones que se efectúen en estas sesiones no afectarán a las del otro.
c) Valores nuevos: en este tercer caso, el proceso hijo encuentra abierto un
conjunto de sesiones de acceso a los dispositivos que se especifican como pa-
rámetros de la llamada al sistema.
4) El dominio de protección. El dominio de protección que hereda un pro-
ceso está formado por los atributos de los dominios a los que pertenecerá y por
Podéis ver la coincidencia de los puntos de ejecución de los procesos padre e hijo en el apartado 4 de este módulo didáctico.
© FUOC • P05/75097/00809 • Módulo 6 19 La gestión de procesos
sus derechos asociados. En el caso de un sistema con protecciones basadas en
capabilities, la herencia también incluye la lista de capabilities inicial del nuevo
proceso. Las capabilities tienen un comportamiento análogo al de los disposi-
tivos virtuales.
Por tanto, en la siguiente descripción sólo haremos referencia a los atributos
de dominio; consideraremos que éstos no se pueden copiar, de manera que el
dominio de protección puede tener las dos modalidades de herencia que aho-
ra presentamos:
a) Compartición: el proceso hijo pertenece al mismo dominio que el proceso
padre o, lo que suele ser lo mismo, pertenecen al mismo usuario. Ésta es la si-
tuación más habitual, e implica que las acciones del proceso hijo sean impu-
tables al mismo usuario que las del proceso padre.
b) Valores nuevos: sin embargo, en algunas ocasiones el proceso hijo necesita
unos privilegios diferentes de los que tiene asociados el usuario al cual perte-
nece el proceso padre. En este caso, y en condiciones controladas de protec-
ción, se puede especificar un nuevo dominio para el proceso hijo. El cambio
de dominio suele ir acompañado de un cambio de programa y, para mantener
el sistema protegido, el usuario que configura el nuevo dominio tiene que ha-
ber escrito el nuevo programa.
2.3. La sincronización y el estado de finalización en la destrucción
de procesos
Hasta ahora hemos analizado el mecanismo de creación y destrucción de pro-
cesos básicamente desde la óptica del proceso creado, y no nos hemos fijado
en las acciones que puede efectuar el proceso padre como consecuencia de la
creación de un hijo. Los procesos padre pueden tener que sincronizar su eje-
cución con la finalización de los procesos que han creado y, al mismo tiempo,
necesitan conocer el estado en que se ha producido esta finalización.
2.3.1. La sincronización
Ya vimos un ejemplo de la necesidad de sincronización entre procesos padre
e hijo cuando hablábamos de las modalidades de ejecución de las órdenes: de
primer plano, de fondo y diferidas. Si nos fijamos en las dos primeras
modalidades, se puede identificar un proceso padre, que es el que ejecuta el
intérprete de órdenes, y unos procesos hijos, que son los que ejecutan las ór-
denes. Así pues, podemos ejecutar las órdenes de estas tres formas:
1) En la modalidad de primer plano, el intérprete de órdenes espera que fi-
nalice la orden antes de solicitar una nueva orden para ejecutar. En esta situa-
ción, el proceso padre tiene que esperar a que el proceso hijo finalice y, para
Podéis ver las capabilities en el subapartado 4.4. del módulo didáctico “La gestión de ficheros”.
Podéis ver con detenimiento y desde un punto de vista más general el concepto de sincronización en el módulo didáctico “La concurrencia y la comunicación”.
Podéis ver las modalidades de ejecución de órdenes en el subapartado 1.3. del módulodidáctico “El sistema operativo: una máquina virtual”.
© FUOC • P05/75097/00809 • Módulo 6 20 La gestión de procesos
conseguirlo, el SO debe proporcionar las herramientas para congelar la ejecu-
ción del proceso padre hasta que el proceso hijo sea destruido.
2) En la modalidad de ejecución de fondo, el intérprete de órdenes no espe-
ra a que finalice la orden, sino que inmediatamente después de haber creado
el proceso que ejecutará la orden, continúa adelante y solicita una orden nue-
va. En esta otra situación, el proceso padre sólo necesita que el sistema lo re-
tenga mientras crea el nuevo proceso, con el fin de retornarle el identificador
del proceso si la creación se ha ejecutado de manera correcta o, en caso con-
trario, retornarle un error.
3) Una tercera posibilidad es la modalidad mixta, que consiste en una com-
binación de las dos modalidades anteriores. Entonces un proceso padre crea
un proceso hijo en modalidad de fondo y, a partir de un determinado instante
de su ejecución, decide esperar a que finalice uno de sus procesos hijos. El SO
tiene que proporcionar llamadas específicas de sincronización.
La figura que podemos ver a continuación muestra los tres modelos de ejecución:
Como consecuencia de la sincronización entre los procesos padre e hijo, el sis-
tema puede ofrecer los siguientes modelos de llamadas al sistema:
a) Introducir un parámetro, modo_ejecución, que indique si el proceso padre
tiene que esperar la destrucción del hijo o no.
Figura 5
© FUOC • P05/75097/00809 • Módulo 6 21 La gestión de procesos
b) Conseguir que para crear no sea necesario esperar nunca la finalización de
un proceso y se pueda proporcionar una llamada específica que permita llevar
a cabo esta función.
2.3.2. El estado de finalización de los procesos
Como ya hemos adelantado, para el proceso padre puede resultar interesante
conocer el punto donde la aplicación ha finalizado o el motivo de esta finali-
zación. Con este objetivo, la llamada destruir_proceso suele tener un parámetro
que el programador puede utilizar para notificar al proceso padre el motivo de
la finalización o, lo que es lo mismo, el punto del algoritmo donde se ha deci-
dido finalizar el proceso.
Además, tal y como hemos visto anteriormente, la ejecución de un proceso
puede finalizar como consecuencia de acciones no previstas por el programa-
dor: por errores de ejecución o por efectos laterales de la ejecución de otras lla-
madas al sistema. En estos casos, el sistema operativo se encarga de codificar
los motivos de la finalización para notificárselos al proceso padre.
El sistema operativo debe proporcionar una llamada que permita a los proce-
sos padres recuperar los parámetros de finalización de sus procesos hijos; esta
llamada suele ser la misma que les permite sincronizarse con la finalización
del proceso hijo: esperar_finalización.
• Id_proceso = crear_proceso(modo_ejecución, entorno_mem, nombre_prog,
punto_ejecución, entorno_E/S, entorno_dominio).
• Estado = destruir_proceso(id_proceso).
• Id_proceso = crear_proceso(entorno_mem, nombre_prog, punto_ejecución,
entorno_E/S, entorno_dominio).
• Estado = destruir_proceso(id_proceso).
• Estado = esperar_finalización(id_proceso).
La llamada destruir_proceso quedaría de esta manera:
Estado = destruir_proceso(id_proceso, estado_finalización).
© FUOC • P05/75097/00809 • Módulo 6 22 La gestión de procesos
2.4. Los cambios en el entorno de ejecución
Tras haber creado un proceso, el SO inicia la ejecución del código que contiene
este proceso. Como resultado de esta ejecución, el entorno puede evolucionar
y cambiar, y los cambios pueden afectar a cualquiera de los elementos que
configuran el proceso: la memoria, el contenido de la memoria, el entorno de
entrada/salida o el dominio de protección. Para todos ellos, el SO tiene que
proporcionar llamadas que permitan modificarlos.
A lo largo de esta asignatura hemos estudiado las llamadas que hacen referen-
cia a los dispositivos, a los ficheros y a la protección. En este subapartado nos
centraremos especialmente en aquellas que modifican el contenido y la es-
tructura del espacio de la memoria en el marco del cambio de imagen, y pro-
fundizaremos en aquellas otras que cambian el entorno de entradas/salidas en
el marco de los redireccionamientos o, en otras palabras, en el marco de la
asignación implícita de dispositivos virtuales a reales.
1) Cambio de imagen
Los sistemas operativos tienen que permitir que los procesos carguen nuevos
programas en la memoria para ser ejecutados. Esta acción se puede realizar de
las dos maneras siguientes:
a) Al mismo tiempo que se crea un nuevo proceso.
b) A posteriori, una vez se ha creado el proceso, mediante la invocación de
una llamada específica (cargar).
En función del SO se ofrecerán combinaciones diferentes de estas dos posibi-
lidades; aquí vamos a enfocar la explicación partiendo de un SO que sólo ofre-
ce la segunda posibilidad. Consideraremos, entonces, que los procesos nuevos
en un principio siempre ejecutan el mismo código que el proceso padre, ya sea
porque lo comparten, ya sea porque se ha copiado. A posteriori, una vez se ha
iniciado la ejecución del nuevo proceso, éste decidirá si tiene que cargar un
nuevo código o no.
Éste es el caso del funcionamiento del intérprete de órdenes que, como vere-
mos más adelante, en primer lugar obtendría la orden que tendría que llevar
a cabo por la entrada estándar, analizaría la existencia de algún ejecutable con
posibilidades de hacerlo y, en tal caso, crearía un nuevo proceso igual que él.
Este nuevo proceso, al ejecutarse, cargaría la aplicación que da servicio a la or-
den recibida.
La carga de un nuevo ejecutable provoca la reconfiguración total del espacio
lógico del proceso sobre el cual se efectúa, de manera que todos los valores
de variables y constantes, los procedimientos y las funciones que se encon-
traban dentro del espacio lógico del proceso antes de la carga desaparecen.
Podéis encontrar las llamadas al sistema relacionadas con los dispositivos, los ficheros y la protección en los módulos didácticos “Los dispositivos de entrada/salida”y “El sistema de ficheros”.
Podéis ver el funcionamientodel intérprete de órdenes en el subapartado 4.2. de este módulo didáctico.
© FUOC • P05/75097/00809 • Módulo 6 23 La gestión de procesos
Para que el código cargado pueda utilizar información elaborada por el códi-
go anterior a la carga, tiene que utilizar mecanismos o dispositivos de alma-
cenamiento que sirvan de puente entre ambos. Una manera sencilla de
hacerlo es utilizar el sistema de ficheros o, en general, un dispositivo de al-
macenamiento. A pesar de esto, los SO ofrecen la posibilidad de pasar la in-
formación a través de ellos mismos en forma de parámetros de la llamada
cargar, los cuales son recibidos por el nuevo programa como parámetros de
entrada de la función principal.
El paso del código a C
Si se utiliza el lenguaje C, el nuevo programa recibiría la información del código anteriora su carga como parámetros de la función main:
Tenemos que apreciar que la llamada cargar sólo afecta a la estructura y al con-
tenido de la memoria, así como al contador de programa, que nos indica la
próxima instrucción que hay que ejecutar. El resto de los elementos que con-
figuran el entorno del proceso no tiene por qué verse afectado, de manera que
el nuevo ejecutable debe encontrar el mismo entorno de entrada/salida y el
mismo entorno de protección. A pesar de todo, esta afirmación puede variar
en función de si el SO asigna otras funciones a la llamada cargar.
Esta llamada sólo retorna un valor en caso de error, ya que si tiene éxito, todo
el código y los datos del programa que la contienen habrán desaparecido de la
memoria.
Overlay
En todos los sistemas, el tamaño de los programas está limitado por el tamaño del espaciológico. Además, en los sistemas que carecen de memoria virtual, el tamaño del espacio lógicose encuentra limitado por la cantidad de memoria física que puede asignar el sistema a cadaproceso. Esta limitación hace que ciertas aplicaciones no quepan en el espacio lógico y, enconsecuencia, impide que se puedan ejecutar.
Para solucionar este problema se utiliza la técnica de los overlays, que consiste en dividir el eje-cutable de la aplicación en varias partes u overlays, de manera que en cualquier instante de laejecución de la aplicación sólo sea necesario tener cargado en la memoria un subconjunto deltotal de overlays. Durante la ejecución, las aplicaciones tienen que controlar en cada momentoqué overlays necesitan y cuáles no, y deben indicarle al SO que sustituya unos por otros. El SO,por su parte, tiene que proporcionar llamadas al sistema para sustituirlos.
Esta técnica se aplica en sistemas sin gestión de memoria virtual, como el MS-DOS.
main (argc, argv, env)
int argc;
char **argv, **env;
La llamada cargar podría tener la siguiente forma:
Estado = cargar(nombre_ejecutable, parámetros).
Podéis ver las funciones de la llamada cargar en el caso de UNIX en el subapartado 5.2. del módulo didáctico “La gestión de ficheros”,y en el subapartado 4.4. de este módulo didáctico.
© FUOC • P05/75097/00809 • Módulo 6 24 La gestión de procesos
2) Redireccionamientos de entrada/salida
La forma en que se introducen las modificaciones en general en el entorno de
entrada/salida de un proceso consiste en abrir y cerrar sesiones de acceso a los
dispositivos. En este subapartado nos fijaremos concretamente en cómo se pue-
den realizar los redireccionamientos de las entradas/salidas. Como se ha visto,
los redireccionamientos de las entradas/salidas se basan en la asignación de dis-
positivos virtuales estándar a dispositivos reales. Para conseguir la independen-
cia y la portabilidad de las aplicaciones, esta asignación se tiene que hacer con
anterioridad a la ejecución de los programas que configuran las aplicaciones y,
por consiguiente, de manera transparente para ellos. Este hecho es el que hemos
denominado asignación implícita de los dispositivos virtuales.
El sistema puede llevar a cabo esta asignación básicamente de las tres formas
que presentamos a continuación:
a) El proceso hijo puede heredar del proceso padre los dispositivos virtuales
que éste tenga abiertos.
b) El proceso padre especifica en los parámetros de llamada crear_proceso qué
dispositivos reales hay que asignar a los dispositivos virtuales del hijo.
c) El proceso hijo modifica su entorno de entrada/salida una vez se ha creado
y antes de cargar un nuevo programa.
La última de estas opciones es la que nos interesa en este subapartado.
Figura 6
Podéis consultar las sesiones de acceso al entorno de entrada/salida en el subapartado 4.2. del módulo didáctico “Los dispositivosde entrada/salida”.
© FUOC • P05/75097/00809 • Módulo 6 25 La gestión de procesos
3. Las excepciones y las señales de software
Como hemos ido viendo, un SO define una nueva máquina con una semán-
tica más elaborada que la de la máquina física sobre la cual se ejecuta. A pesar
de este aumento del nivel semántico, el SO conserva muchas de las funciones
y los mecanismos de que dispone el hardware, y uno de estos mecanismos que
reproduce es el de las interrupciones. Los procesos pueden necesitar ser infor-
mados de acontecimientos que suceden de manera imprevista en cualquier
instante de la ejecución de un programa.
Así, por ejemplo, un proceso puede necesitar saber si se ha producido un
error en el acceso a la memoria para solicitar que se aumente el área asignada
a una determinada variable; o también puede necesitar saber si un cierto ter-
minal sobre el que trabaja se ha apagado, para acabar la aplicación correcta-
mente, etc.
La procedencia de las señales de software nos permite clasificarlas de esta
manera:
1) Los dispositivos de entrada/salida, que necesitan informar al proceso de
situaciones que pueden dar lugar a un error si el proceso no las conoce. Son
situaciones como, por ejemplo: la desconexión de un terminal, la pulsación
de una tecla de control por parte del usuario, etc.
2) Las excepciones, que vienen provocadas por el proceso de manera invo-
luntaria durante la ejecución de una instrucción o a causa de la saturación de
un elemento de hardware (overflow), de la violación de un segmento o de una
instrucción errónea*.
3) Las llamadas explícitas al sistema, que se pueden realizar para enviar se-
ñales a un proceso determinado. Para poder hacerlo, el proceso que envía la
señal necesita tener permiso. En general, sólo se permite enviar señales entre
procesos del mismo dominio de protección; se trata de señales como la orden
de eliminar un proceso que utiliza el administrador del sistema, o señales para
sincronizar la ejecución de procesos que lo necesiten. Por ejemplo, un proceso
Las señales de software son la herramienta que proporciona el sistema
operativo para trasladar el mecanismo de las interrupciones al ámbito
del proceso. Igual que el mecanismo de hardware de las interrupciones,
las señales proporcionan apoyo a un amplio conjunto de situaciones
variadas que los procesos tienen que reconocer y atender con cierta ur-
gencia.
* Son instrucciones erróneasla división por cero, la raíz cuadrada
de un número negativo, etc.
© FUOC • P05/75097/00809 • Módulo 6 26 La gestión de procesos
que tiene como función inicializar una estructura de datos determinada po-
dría utilizar una señal para informar a los procesos usuarios de esta estructura
que ya ha sido inicializada.
4) El reloj del sistema, que utilizan los procesos cuando necesitan llevar a
cabo una serie de acciones a intervalos concretos de tiempo. Por ejemplo, un
proceso que esté esperando una cierta entrada desde un módem puede solici-
tar que el reloj del sistema (timeout) lo avise dentro de un cierto lapso de tiem-
po para detectar si la línea se ha cortado o no.
5) Y por último, un proceso puede recibir una señal como el efecto lateral de
una llamada al sistema. Por ejemplo, un proceso padre puede recibir una se-
ñal que le indique que uno de sus procesos hijos ha sido destruido.
El tratamiento que da un proceso a una señal que le llega puede ser uno de los
tres tipos que presentamos a continuación:
1) Un tratamiento definido por el mismo usuario. El proceso indica me-
diante una llamada al SO qué procedimiento hay que ejecutar cuando llegue
una señal determinada.
2) No dar ningún tratamiento (ignorar el acontecimiento). El proceso pue-
de decidir no preocuparse de la señal y, por lo tanto, cuando llegue la señal
continuará su ejecución normalmente, como si no hubiese pasado nada.
3) Un tratamiento dado por el SO. Algunas circunstancias que provocan se-
ñales se deben a un mal funcionamiento del proceso o pueden llevar a éste si
no se utilizan las medidas necesarias. En estos casos, si el proceso no ha defi-
nido un tratamiento, el sistema tiene que proporcionar uno. Por norma gene-
ral, este tratamiento tiene asociada por defecto la destrucción del proceso al
cual iba destinada la señal. Por ejemplo, si un proceso efectúa un acceso inco-
rrecto a la memoria y el proceso no lo soluciona, el SO se ve en la obligación
de destruir el proceso e informar de ello a su proceso padre.
Para finalizar, tenemos que apreciar que la programación de las señales es una
información de cada proceso que configura el entorno de ejecución y, como
tal, tiene que formar parte del PCB, y es necesario tenerlo en cuenta en el mo-
mento de la creación de un nuevo proceso.
Así pues, el SO destruirá un proceso cuando reciba una señal que no es-
pera a causa de un error en su ejecución, de un acontecimiento impre-
visto en uno de los dispositivos a los que accede o por la actuación
deliberada de otro proceso. En este caso, el SO se encarga de enviar el
estado de finalización al proceso padre para indicarle el motivo de la
destrucción.
© FUOC • P05/75097/00809 • Módulo 6 27 La gestión de procesos
4. La gestión de procesos en UNIX
Los principales elementos que constituyen un proceso en UNIX son:
1) El espacio de memoria, formado por tres segmentos lógicos: uno de códi-
go*, uno de datos y uno de pila. El segmento de código puede ser compartido
por otros procesos; entre el segmento de datos y el de pila existe una porción
de espacio lógico no asignada al proceso. Cuando conviene, el proceso puede
aumentar el segmento de datos con la llamada malloc.
2) El entorno de entrada/salida, que está formado por una tabla de file descriptors
(dispositivos virtuales), y es local a cada proceso. Cada entrada de esta tabla apunta
a otra tabla, que en este caso es de carácter global para el sistema, y contiene los
punteros de lectura secuencial, el modo de acceso y un puntero a la estructura
del SO que gestiona el dispositivo real asociado a un file descriptor. Finalmente,
el entorno de entrada/salida se complementa con la información de cuál es el
directorio de trabajo actual.
3) El UID y el GID, que corresponden al número de identificador del usuario
y al número de identificador del grupo del usuario, hacen referencia al usua-
rio y al grupo al que pertenecen los procesos dentro del dominio de protección.
4) El estado de los registros del procesador, que refleja en qué estado se en-
cuentra la ejecución del programa que contiene el proceso.
5) La información estadística, que presenta informaciones tales como el
tiempo consumido de CPU, el volumen consumido de memoria o el número
de procesos hijos generados.
En UNIX, un proceso es un entorno de ejecución identificado por un
número denominado PID*, que es el identificador del proceso y es
único durante toda la vida del SO.
* PID es el acrónimo del término inglés Process IDentifier.
* El segmento de código tambiénse denomina segmento de texto.
Podéis ver los file descriptors en el apartado 5 del módulo didáctico “Los dispositivos de entrada/salida”.
El UID y el GID...
... son los acrónimosde los términos inglesesUser Dentifier y Group IDentifier, respectivamente.
Figura 7
© FUOC • P05/75097/00809 • Módulo 6 28 La gestión de procesos
4.1. La creación y la destrucción de procesos
Las correspondencias entre las llamadas de UNIX y las que hemos visto en este
módulo son:
UNIX ha optado por tratar el tema de la creación y la destrucción de procesos
de la manera más sencilla posible. Las llamadas que ofrece tienen el mínimo
número posible de parámetros, y crean y destruyen los procesos a partir de
una definición implícita en el sistema. A posteriori, y definiéndolo por progra-
ma, el usuario puede cambiar el entorno de ejecución y hacer el proceso a su
medida. A continuación veremos cómo actúa cada una de las llamadas que he-
mos visto en el presente módulo en el sistema operativo UNIX:
Operación Llamadas de UNIX
Crear_proceso fork
Destruir_proceso exit
Esperar_finalización wait
La creacióny destrucción...
... de procesos en UNIX se ajus-ta a la filosofía general de UNIX de ofrecer herramientas de uso sencillas, que permitan desar-rollar cualquier política que se necesite.
Figura 8
© FUOC • P05/75097/00809 • Módulo 6 29 La gestión de procesos
1) La llamada fork no tiene ningún parámetro y crea un nuevo proceso hijo
que es un duplicado del proceso padre. En general, el PCB del hijo es una copia
del PCB del padre; el espacio de memoria del proceso hijo es una copia del es-
pacio del padre y las entradas de la tabla de file descriptors apuntan a las mis-
mas entradas de la tabla de punteros de lectura/escritura. El proceso hijo
pertenece al mismo usuario y grupo de usuarios que el padre. Ambos procesos
continúan la ejecución de manera independiente en el punto inmediatamen-
te posterior a la llamada fork al sistema.
Normalmente, después de la llamada fork, el proceso hijo tiene que ejecutar
un código diferente del código del padre. Para poder distinguirse, la llamada
fork retorna valores diferentes en función de si es el proceso padre o el hijo:
el hijo recibe un valor 0 y el padre recibe el identificador (PID) del hijo.
Durante la creación de un nuevo proceso, UNIX controla los aspectos impor-
tantes que afectan al conjunto del sistema, como puede ser la disponibilidad
de recursos*. Un ejemplo concreto de este control es el hecho de que no per-
mite que un usuario normal (y no procesos de sistema) ocupe la última en-
trada de la tabla de procesos, la última área de memoria libre, etc. Si esto
ocurriese, quizá el sistema no se podría recuperar de situaciones en las que
sería necesario poner en marcha algún proceso del sistema de manera urgen-
te. Por ejemplo, si fuese necesario realizar una rápida detención del sistema,
podría ser catastrófico no poder poner en marcha el proceso de detención del
sistema (shutdown).
2) La llamada exit destruye un proceso. La destrucción de un proceso me-
diante esta llamada es idéntica a la que hemos explicado en el caso de la crea-
ción y la destrucción de procesos: el sistema se encarga de destruir el proceso
que la ejecuta. Con el objetivo de notificar el estado de finalización, se pasa
un parámetro al sistema operativo que el proceso padre podrá recoger median-
te la llamada wait.
3) La llamada wait bloquea el proceso que lo ha llamado hasta que alguno
de sus procesos hijo haya sido destruido. Cuando esto sucede, el sistema le re-
torna el PID de proceso destruido y, como parámetro de salida, el estado en
que ha finalizado.
Combinando las tres llamadas que se han presentado en este subapartado, el
intérprete de órdenes puede ejecutar órdenes en las modalidades de primer
plano y de fondo (observad la figura 9).
UNIX guarda el estado de finalización de los procesos destruidos en su PCB y
espera que su proceso padre lo recoja mediante la llamada wait. Por este mo-
tivo, UNIX no libera el PCB de un proceso en el momento de su destrucción.
Los procesos esperan en un estado especial denominado zombie hasta que se
ejecuta la llamada wait, que permitirá eliminarlos definitivamente. Para evi-
tar la acumulación de procesos en estado zombie se han previsto los dos meca-
nismos que ahora exponemos:
* Los recursos del sistema sonla memoria, las entradas en la tabla
de PCB, etc.
Podéis ver la destrucción de procesos en el subapartado 2.1.de este módulo didáctico.
© FUOC • P05/75097/00809 • Módulo 6 30 La gestión de procesos
1) Cada usuario sólo puede tener en un instante determinado un cierto nú-
mero de procesos activos, incluidos los zombies.
2) Los procesos que se destruyen más tarde que sus procesos padre pasan a ser
considerados hijos del primer proceso del sistema*, que es el encargado de re-
coger su estado de finalización.
4.2. Los cambios del entorno que configura un proceso
En UNIX hemos visto que cualquier cambio que se quiera llevar a cabo en un
proceso se tiene que realizar tras haberlo creado. El cambio de ejecutable y los
cambios en las entradas/salidas que se han hecho a posteriori de la llamada
fork permiten controlar por programa y, de manera flexible, tener acceso a
un abanico muy amplio de posibilidades que con dificultad se podrían haber
previsto a priori desde el SO. Para ilustrar este hecho nos fijaremos en el intér-
prete de órdenes de UNIX (shell) y en los redireccionamientos que permite.
Antes, sin embargo, analizaremos los puntales de esta flexibilidad, que son los
siguientes elementos:
• La llamada fork, que ya hemos visto.
• La llamada exec de cambio de ejecutable.
• La llamada dup de entrada/salida, que permite manipular los file descriptors.
• Las pipes, como dispositivo especial que se basa en la herencia entre proce-
sos para que se puedan utilizar correctamente.
A continuación veremos cómo los tres últimos elementos nos permiten modi-
ficar el entorno que configura un proceso.
* El primer proceso del sistema se denomina init y tiene un PID
igual a cero.
Figura 9
© FUOC • P05/75097/00809 • Módulo 6 31 La gestión de procesos
1) El cambio de ejecutable
El cambio que tiene lugar mediante la llamada exec no afecta a los elementos que
configuran el proceso, como puede ser el entorno de entrada/salida. En general,
sólo afecta a la programación de las señales y al dominio de protección si el fiche-
ro ejecutable que hay que cargar tiene activo el bit setuid o el setgid. Los bits setuid
y setgid hacen que durante la ejecución del programa, el proceso que lo ha cargado
cambie respectivamente al dominio del usuario propietario, o al grupo del usuario
propietario del fichero ejecutable. Estos derechos permiten construir aplicaciones
que accedan de manera controlada a bases de datos o a ficheros en general sobre
los cuales no se quiere dar un derecho de escritura generalizado.
2) La manipulación de los file descriptors
Con esta operación se pueden modificar con facilidad los valores en los file
descriptors estándares.
Veamos un ejemplo de uso de la llamada dup en combinación con la llamada
exec:
La llamada exec al sistema de UNIX permite cambiar la imagen o el eje-
cutable que contiene un proceso.
La llamada dup permite duplicar el valor de una entrada concreta de la ta-
bla de file descriptors en la primera posición libre que se encuentre
dentro de la tabla.
int estado, descFichero, pid;
…
pid = fork ( ) ;
switch (pid) {
case 0:
descFichero = open ( “fichero”, O_RDONLY) ;
if (descFichero == –1) {
/*tratamiento del error*/
}
…
close (0) ;
dup (descFichero) ;
close (descFichero) ;
…
exec1 (“\bin\orden”, “orden”, 0) ;
Podéis ver la programación de las señales en el subapartado 4.4. de este módulo didáctico.
Podéis ver el cambio de dominio de usuario por parte del proceso en el subapartado 5.2. del módulo didáctico “El sistema de ficheros”.
© FUOC • P05/75097/00809 • Módulo 6 32 La gestión de procesos
El código anterior podría ser el que ejecuta el intérprete de órdenes cuando se
ha dado la siguiente orden: $ orden < fichero.
En este caso sólo se muestra la parte del código que, tras haber leído la orden desde
el terminal, ejecuta la orden. Esta ejecución se lleva a cabo en la modalidad de pri-
mer plano. Y ahora vamos a ver los diferentes pasos de esta ejecución.
En primer lugar, el intérprete crea el proceso hijo que tendrá que ejecutar
la orden. Una vez se ha creado, hay que realizar el redireccionamiento de
entrada estándar para que cuando se haya cargado el programa orden se en-
cuentre el redireccionamiento efectuado. Para hacerlo, se crea un file des-
criptor vinculado a fichero con la llamada open (descFichero), con la
cual se ocupa la primera entrada libre de la tabla de file descriptors.
Las figuras que encontramos a continuación ilustran la evolución de las ta-
blas internas del sistema durante este proceso:
a) Situación después de haber abierto fichero:
…
/* tratamiento del error*/
…
case –1:
…
/* tratamiento del error*/
…
default:
while(pid != wait (&estado) ) ;
}
…
Figura 10
© FUOC • P05/75097/00809 • Módulo 6 33 La gestión de procesos
Para redireccionar la entrada estándar desde fichero, hay que hacer que el
file descriptor 0 se encuentre asociado al fichero. Para hacerlo, desasignamos
el dispositivo real asociado al file descriptor 0 y, mediante la llamada dup, lo
volvemos a asignar copiando sobre su entrada en la tabla de file descriptors la
entrada asociada a descFichero. Así, los dos file descriptors hacen referencia
a la misma sesión de trabajo abierta sobre fichero.
b) Situación después de haber ejecutado la llamada dup:
Figura 11
Falta eliminar, mediante la llamada close, el file descriptor descFichero para
conseguir el entorno de entrada/salida que debe encontrar la orden que hay
que ejecutar. Después, el proceso hijo puede cargar el nuevo ejecutable me-
diante la llamada exec*.
c) Situación después de haber cargado el ejecutable de la orden:
Figura 12
* En el ejemplo se utiliza execl, que es una de la diferentes formas
de esta llamada.
© FUOC • P05/75097/00809 • Módulo 6 34 La gestión de procesos
3) La utilización de las pipes
Una pipe es un dispositivo que se crea en el momento en que se abre mediante
la llamada pipe, y se destruye cuando el último proceso que lo tiene abierto
lo cierra. La llamada pipe crea el dispositivo y le asocia dos file descriptors, uno
de entrada y otro de salida. Es un dispositivo que no se puede abrir de manera
explícita mediante la operación open. Una vez se ha creado, los diferentes pro-
cesos que se quieren utilizar tienen que heredar los file descriptors de su proceso
padre.
Su funcionamiento básico se rige por el mecanismo de sincronización del para-
digma productor/consumidor: cuando un proceso intenta leer sobre una pipe va-
cía, se queda bloqueado hasta que algún otro proceso le escribe los caracteres
suficientes como para que el proceso bloqueado pueda efectuar la lectura. Cuan-
do un proceso intenta escribir sobre una pipe completa, se queda bloqueado hasta
que algún otro proceso lee los caracteres suficientes de la pipe como para que el
proceso bloqueado pueda efectuar la escritura.
La detección del cierre de todos los file descriptors de escritura provoca que, cuando
la pipe se queda vacía, los procesos lectores reciban una marca de fin de fichero en
lugar de bloquearse. El tratamiento de todos los file descriptors de lectura hace que
los procesos con file descriptors de escritura reciban una señal de software asociada
a esta situación.
Veamos un ejemplo de utilización de las pipes:
Por último, las pipes son un dispositivo lógico destinado a comunicar pro-
cesos con una relación de parentesco. Funcionan como una cola de ca-
racteres con una longitud fija, donde los procesos pueden escribir y leer.
int estado, descFichero [2], longitud = 512;
char buf [512] ;
…
estado = pipe(descFichero);
if (estado == –1) {
/*tratamiento del error*/
}
…
switch (fork()) {
case 0:
close (descFichero[0]);
…
Podéis ver las pipes en el subapartado 5.1. del módulo didáctico “Los dispositivos de entrada/salida”.
© FUOC • P05/75097/00809 • Módulo 6 35 La gestión de procesos
Como muestra el código anterior, el proceso crea inicialmente una pipe con los
file descriptors de lectura y escritura en el mismo proceso, como podéis ver en
la figura 13.
a) Situación después de haber creado la pipe:
Figura 13
La pipe es útil cuando se lleva a cabo la llamada fork al sistema, y el proceso
hijo hereda del padre los file descriptors entre los cuales encontramos los
que se han creado con la llamada pipe: descFichero[0] es el de lectura,
y descFichero[1], el de escritura.
Después de la creación del hijo, y para establecer la comunicación, ambos
cierran el canal del sentido de la comunicación que no van a utilizar, para
así permitir la detección del proceso de comunicación. En este punto queda
establecido un canal de comunicaciones unidireccional.
write(descFichero[1]);
…
default:
close(descFichero[1]);
…
read(descFichero [∅], buf, longitud);
…
}
© FUOC • P05/75097/00809 • Módulo 6 36 La gestión de procesos
b) Situación final después de haber ejecutado todo el código anterior:
Figura 14
4.3. La jerarquía de procesos en UNIX
El proceso init con PID igual a cero es el primer proceso que se crea en un siste-
ma UNIX, y es el antecesor de todos los procesos que se crearán a continuación.
Init es el único proceso que no se ha creado con la llamada al sistema fork, ya
que lo crea directamente el núcleo durante la inicialización del sistema.
Figura 15
© FUOC • P05/75097/00809 • Módulo 6 37 La gestión de procesos
Las principales funciones del proceso init son las de inicializar todos los pro-
cesos de sistema, como por ejemplo los procesos servidores de red*, poner en
funcionamiento un proceso getty para cada terminal y, finalmente, liberar los
procesos zombie que ya no tienen el proceso padre.
El proceso getty se encarga de esperar que se pongan en marcha los termina-
les. Cuando un terminal se pone en marcha, el proceso que ejecuta el progra-
ma getty carga el programa login para identificar al nuevo usuario. Tras haber
verificado la identidad del usuario, el programa login carga el intérprete de
órdenes (shell) e inicia una sesión de trabajo con el usuario. Cuando el usuario
la finaliza, el proceso shell se destruye, e init crea un nuevo proceso getty que
lo sustituye.
4.4. Las señales en UNIX
Las señales (signals) en UNIX se comportan como hemos explicado hasta
ahora. En UNIX se ha previsto un conjunto fijo de señales con un significado
concreto.
En la tabla siguiente mostramos estas señales para el estándar POSIX de UNIX.
Otros estándares de UNIX presentan variaciones con respecto al tratamiento
y al número de posibles señales.
Señal Significado de la señal
SIGABRTAborta la ejecución del proceso. Se realizará un vaciado de la memoria del proceso.
SIGALRM Se ha producido una interrupción de reloj.
SIGFPE Se ha producido un error de coma flotante.
SIGHUPSe ha producido un corte de línea de comunicación, generalmente con un terminal o un módem.
SIGILL Instrucción de máquina no válida.
SIGINT Se ha tecleado la secuencia de teclas de control asociada a esta señal.
SIGQUITSe ha tecleado la secuencia de teclas de control asociada a esta señal. Se realizará un vaciado de la memoria del proceso.
SIGKILL Destruir el proceso. El proceso no la puede ignorar ni programar.
SIGPIPE Se ha escrito en una pipe sin ningún lector.
SIGSEGV Se ha producido un acceso indebido a memoria.
SIGTERM Se solicita que el proceso finalice.
SIGUSR1 Disponible para usos propios de las aplicaciones.
SIGUSR2 Disponible para usos propios de las aplicaciones.
* Procesos servidores de la red como rout o telnet.
Podéis ver las señales del software en el apartado 3 de este módulo didáctico.
© FUOC • P05/75097/00809 • Módulo 6 38 La gestión de procesos
Como se puede ver por el tipo de señales previstas, los elementos que pueden
provocar una señal son los siguientes:
• Los dispositivos de entrada/salida.
• Las excepciones.
• Las llamadas explícitas al sistema, mediante la llamada kill.
• El reloj del sistema. Se puede programar para que genere una señal SIGALARM
cuando haya pasado un cierto intervalo de tiempo. Para hacerlo, el sistema
proporciona la llamada alarm.
La programación de las señales en UNIX se indica mediante la llamada al siste-
ma signal. Los tratamientos posibles de UNIX a una señal pueden ser los
que presentamos a continuación:
1) El que da el sistema operativo por defecto en función del tipo de señal. Para
las señales estándares consiste en destruir el proceso y, en algunos casos, en
crear un fichero denominado core con el contenido de la memoria del proceso
destruido.
2) Ignorar el acontecimiento. Los procesos pueden ignorar la llegada de seña-
les concretas.
3) El definido por el mismo usuario. Mediante la llamada signal se especifica
qué procedimiento se tendrá que ejecutar en caso de que se produzca una señal
determinada. La programación de una señal sólo es válida una vez, puesto que
tras haberse producido la señal y haberse ejecutado el procedimiento asociado
a su tratamiento, el tratamiento pasa a ser el que hay por defecto. Si se quiere
mantener la programación, hay que volver a ejecutar la llamada signal.
Un caso especial es la señal SIGKILL, que no puede ser ignorada ni programa-
da, ya que se utiliza como último recurso para destruir un proceso.
En la creación de un nuevo proceso, la programación de las señales (signals) se he-
reda del proceso padre. Cuando se ejecuta exec, las señales con un tratamiento
definido por un procedimiento del usuario pasan a ser por defecto. El motivo de
esto es evidente: estos procedimientos serán sustituidos por el nuevo ejecutable.
© FUOC • P05/75097/00809 • Módulo 6 39 La gestión de procesos
Resumen
En el presente módulo didáctico hemos analizado la gestión de procesos que lle-
va a cabo el SO partiendo de la definición de proceso que ya habíamos visto en
esta asignatura, y lo hemos hecho siguiendo los pasos que ahora exponemos:
a) En primer lugar, para entender mejor el concepto de proceso, hemos anali-
zado de manera superficial la representación interna del proceso en el SO y la
gestión de los procesos en un sistema multiprogramado de tiempo compar-
tido. Los principales conceptos que hemos presentado son los siguientes:
• El bloque de control de procesos, como estructura básica que configura
un proceso.
• La ejecución concurrente, mediante la multiplexación del procesador en
tiempo.
• El estado de los procesos (run, ready y wait).
• El cambio de contexto como mecanismo para pasar un proceso del estado
run a ready o wait, o viceversa.
b) En segundo lugar, hemos analizado desde el punto de vista del usuario las
llamadas que permiten manipular los procesos, es decir, que permiten crear-
los, modificarlos y destruirlos. Como principales conceptos relacionados con es-
tas llamadas, podemos destacar los siguientes:
• La herencia entre los procesos padre e hijo en el momento de la creación
de un nuevo proceso.
• La sincronización, para ver cómo el proceso padre sincroniza la creación
y destrucción de un proceso hijo.
• Los cambios de ejecutable y los redireccionamientos, como principales
cambios del entorno que configura un proceso.
c) Y, ya para finalizar, hemos presentado las señales en tanto que mecanismo
de sincronización de los procesos con acontecimientos que se producen de
manera no prevista. El origen de estos acontecimientos se encuentra en situa-
ciones producidas por un mal funcionamiento del proceso o por situaciones
externas, como pueden ser acciones de otros procesos o estados de los dispo-
sitivos. Su aparición puede alterar el entorno del proceso y a menudo compor-
tan la acción de destrucción de los procesos a los que afectan. A pesar de todo,
Podéis ver la definición de proceso en el subapartado 2.1. del módulo didáctico “El sistema operativo: una máquina virtual”.
© FUOC • P05/75097/00809 • Módulo 6 40 La gestión de procesos
el sistema proporciona mecanismos para solucionar la situación mediante un
tratamiento específico explicitado con un procedimiento.
Después de ver los SO en general, hemos hecho una confrontación de los con-
ceptos anteriores con el sistema UNIX. Las llamadas al sistema de gestión de
procesos siguen una filosofía de diseño basada en la sencillez y la flexibilidad
que permite crear y modificar los procesos con toda libertad desde el progra-
ma. Una consecuencia de este hecho es la gran cantidad de posibilidades que
puede ofrecer el intérprete de órdenes (shell) por lo que respecta a modos de
ejecución y de redireccionamiento de las entradas y salidas.
La siguiente figura muestra un mapa conceptual con los principales conceptos
explicados en este módulo didáctico y sus relaciones:
© FUOC • P05/75097/00809 • Módulo 6 41 La gestión de procesos
Actividades
1. Estudiad la orden ps de UNIX. Observad qué campos presenta y qué significado tienen.Analizad también qué procesos tenéis en marcha en el sistema y en qué estado se encuentran.
2. LINUX permite ver los recursos asignados a los procesos como ficheros que cuelgan deldirectorio /proc. Buscad en el manual de UNIX la entrada asociada a este directorio y anali-zad qué se puede encontrar en ésta.
3. Analizad las diferentes posibilidades de ejecución de órdenes y de redireccionamientosque nos ofrece el intérprete de órdenes (shell) de UNIX y pensad en cómo se podrían realizardesde las llamadas al sistema.
4. Buscad en el manual de UNIX las señales que hay, y con la orden stty analizad qué ca-racteres provocan señales.
Ejercicios de autoevaluación
1. Dentro del diagrama de estados de los procesos que se muestra en el subapartado de esta-dos de un proceso, ¿dónde colocaríais el estado zombie de UNIX? Justificad la respuesta.
2. ¿Cómo se podrían redireccionar las entradas/salidas de los procesos hijos en un sistema enel que la llamada crear_proceso fuerza el cambio de imagen? Justificad vuestra respuesta.
3. Después de ejecutar “primero”, ¿qué salidas obtendremos y por qué dispositivo se realiza-rán? Justificad la respuesta.
Primero
Segundo
main ( )
{
char a;
a = ‘A’ ;
if (write (1, &a, 1) == –1) {
/*error*/
write (2,“error”,5) ;
}
close (1) ;
execl (“segundo”, “segundo”, 0) ;
if (write (2, &a, 1) == –1) {
/*error*/
exit (1) ;
}
}
main ( )
{
char a;
if (write (1, &a, 1) == –1) {
/*error*/
write (2, “error”, 5) ;
© FUOC • P05/75097/00809 • Módulo 6 42 La gestión de procesos
4. Comentad cómo se ve afectada la programación de las señales de software por el hecho decambiar de imagen. Justificad la respuesta.
5. ¿Cómo sería el código para conectar mediante una pipe dos procesos que leen y escribenpor sus canales estándares?
6. La señal SIGKILL de UNIX no puede ser inhibida ni programada por el usuario. ¿Creéisque es necesaria su existencia? Explicad por qué.
De selección
1. Cuando se lleva a cabo un cambio de contexto entre dos procesos, el sistema tiene que guardarlos valores que configuran el estado del proceso que deja el procesador para poder reemprendersu ejecución más adelante. Estableced cuáles de los elementos que ahora presentamos y que con-figuran un proceso tienen que ser guardados explícitamente en el momento del cambio:a) El contador de programa.b) Los segmentos de memoria.c) Los dispositivos virtuales.d) El identificador del proceso.e) Los registros del procesador.Justificad la respuesta.
2. De entre los resultados que se presentan a continuación, ¿cuál creéis que producirá la eje-cución del siguiente programa?
}
if (write(2, &a, 1) == –1) {
/*error*/
exit(1) ;
a = ‘B’ ;
if (write(2, &a, 1) == –1) {
/*error*/
exit(1) ;
}
}
main ( )
{
int fd, pid;
char buff[2];
fd = open(fichero, O_RDONLY)
if (read(fd, buff, 2) == –1) {
/*error*/
exit(1) ;
}
write(1, buff, 2);
pid = fork( );
switch(pid) {
case 0:
if (read(fd, buff, 2) == –1) {
/*error o fin de fichero*/
exit(1) ;
}
default:
write(1, buff, 2);default:
if (read(fd, buff, 2) == –1) {
© FUOC • P05/75097/00809 • Módulo 6 43 La gestión de procesos
a) ABCD.b) AABBCCDD.c) ABCCDD.d) ABDC.e) Las opciones a o d indistintamente.Justificad la respuesta.
3. Determinad cuál de los siguientes resultados creéis que producirá la ejecución del progra-ma que presentamos a continuación:
a) “hijo: num = 4”, “padre: num = 6”.b) “hijo: num = 4”, “padre: num = 5”.c) “hijo: num = 1”, “padre: num = 2”.d) “hijo: num = 4”, “padre: num = 5”.e) El valor de num no se encuentra definido en el hijo y el padre efectúa la salida: “padre:num = 5”. Justificad la respuesta.
4. ¿Cuál de los diagramas de tiempo es el que representa la ejecución del siguiente código?Justificad la respuesta.
/*error o fin de fichero*/
exit(1) ;
}
write(1, buff, 2) ;}
}
}
main ( )
{
int num, pid;
num = 3;
pid = fork( );
switch (pid) {
case 0:
num = num + 1;
printf(“hijo: num = %d/n”, num);
default:
num = num + 2;
printf(“padre: num = %d/n”, num);
}
}
main ( )
{
int pid1, pid2, estado;
A
pid1 = fork ( ) ;
switch (pid) {
case 0:
B
default:
pid1 = fork ( ) ;
switch (pid) {
case 0:
© FUOC • P05/75097/00809 • Módulo 6 44 La gestión de procesos
a)
b)
c)
d)
C
default:
while(pid1!= wait(&estado)) ;
while(pid2!= wait(&estado)) ;
D
}
}
}
© FUOC • P05/75097/00809 • Módulo 6 45 La gestión de procesos
Solucionario
Ejercicios de autoevaluación
1. El estado zombie es previo a la destrucción total del proceso mientras éste espera a que elproceso padre, o en su defecto el proceso init, recoja el parámetro de finalización. Una vez seha recogido, se acaban de liberar los recursos del proceso.
2. Puesto que la llamada crear_proceso obliga a cargar un nuevo ejecutable, es imposible queel hijo herede el código del proceso padre, motivo por el cual no se puede especificar median-te el programa cómo se debe modificar el entorno de entrada/salida del proceso hijo. En estascondiciones, con los parámetros de la llamada crear_proceso, tenemos que poder especificarlos dispositivos reales que se quieren asociar a los dispositivos virtuales estándares del proce-so hijo. Por ejemplo:
crear_proceso(nombre_ejecutable,fichero1,fichero2,fichero3,otros parámetros...)
donde fichero1 corresponde a la entrada estándar, fichero2, a la salida estándar y fichero3, a la sa-lida de error. Si se quisiese hacer más flexible, de modo que se permitiese redireccionar cualquierdispositivo con cualquier modo de acceso, sería necesario incluir en él más parámetros.
3. La salida se efectuará como presentamos ahora:a) El ejecutable “primero” escribe “A” para la salida estándar.b) Se cierra la salida estándar.c) Se cambia de ejecutable. Se carga “segundo” y todo el código que el ejecutable “primero”tiene por debajo de la llamada exec desaparece, y no se ejecutará nunca.d) El ejecutable “segundo” escribe “error” para la salida de error estándar, puesto que se en-cuentra cerrada, tal y como hemos comentado en el punto b.e) El ejecutable “segundo” escribe un carácter indeterminado para la salida de error estándar,ya que la variable a del ejecutable “segundo” se ha creado en el momento de su carga, y noha sido inicializada.f) El ejecutable “segundo” escribe “B” para la salida de error estándar.
4. El hecho de cambiar la imagen hace que todo el código y las variables de la imagen antiguasean sustituidos por los de la nueva. Por lo tanto, toda programación de señales que se baseen la premisa de que el proceso proporciona un procedimiento de tratamiento de la señaldebe quedar anulada. El resto de los tratamientos (por defecto e ignorar la señal) no tienenpor qué verse afectados.
5.
main ( )
{
int estado, descFichero[2] ;
Figura 20
© FUOC • P05/75097/00809 • Módulo 6 46 La gestión de procesos
6. La existencia de esta señal permite que los procesos de gestión del sistema puedan destruir
cualquier proceso, aunque éste lo intente evitar programando o no haciendo caso de ningu-na de las señales. Así pues, con esta señal protegemos el sistema de procesos que, a pesar de
que no producen ninguna excepción, funcionan de manera incorrecta. Por ejemplo, un pro-
ceso que se haya quedado ejecutando una iteración de manera indefinida consume CPU, me-
moria, etc. El administrador del sistema tiene que poder destruirlo y, así, liberar los recursosque ocupa.
De selección
1. Hay que guardar el contador de programa (a), que indica la próxima instrucción que hay
que ejecutar, y el valor de los registros del procesador (b), que básicamente contienen valoresparciales de los cálculos que se están llevando a cabo y el puntero a la última posición de la
pila. Es necesario guardar todos aquellos elementos dinámicos que configuran el punto de
ejecución donde se encuentra el programa que contiene el proceso. El resto de los elementos,
a pesar de que configura el entorno de ejecución, ya están guardados en el PCB, de maneraque no es necesario volver a guardarlos.
2. La respuesta correcta es la e. Los procesos padre e hijo comparten los punteros de lectura/es-
critura de los ficheros que el padre tiene abiertos en el momento de la creación del hijo. Así, las
operaciones de lectura que realice cualquiera de los dos modifican el mismo puntero. Por otraparte, ambos procesos se ejecutan concurrentemente y, por lo tanto, no podemos saber cuál de
los dos efectuará primero la operación de lectura. Por este motivo se pueden dar ambas salidas.
3. La solución correcta es la b. La herencia de la llamada fork es de copia, así que el proceso
hijo tendrá, una vez creado, el mismo código y los mismos datos que el padre. A partir del mo-mento de la creación, cada uno evolucionará de manera independiente y con sus variables.
4. La respuesta correcta es la a. El proceso padre ejecuta el código A y después crea un proceso
hijo que ejecuta el código B. Al mismo tiempo crea un segundo proceso hijo que ejecuta con-
currentemente el código C. Una vez se han creado todos los hijos, el proceso padre espera aque sus dos procesos hijos hayan finalizado, y entonces ejecuta D.
Glosario
bloque de control de procesos Estructura de datos que contiene la información del entorno de cada proceso necesaria paraque el sistema pueda gestionar la ejecución concurrente de un conjunto de procesos.sigla: PCB
cambio de contextoTécnica que, mediante la multiplexación del tiempo de procesador, consigue la ejecución
concurrente de todos los procesos preparados para utilizarlo.
estado = pipe (descFichero) ;
if (estado == –1) {
/*tratamiento del error*/
}
switch(fork( )) {
case 0:
close(descFichero[0] ) ;
close(1) ;
dup(descFichero[1] ) ;
exec1(fichero2, fichero2, 0) ;
default:
close(descFichero[1] ) ;
close(0) ;
dup(descFichero[0] ) ;
close(descFichero[0] ) ;
exec1(fichero2, fichero2, 0) ;
}
}
© FUOC • P05/75097/00809 • Módulo 6 47 La gestión de procesos
cuotaTiempo máximo de CPU que puede utilizar un proceso de manera continua. Los sistemasoperativos que trabajan en la modalidad de tiempo compartido utilizan la cuota para realizarcambio de contexto y dar el control del procesador a un nuevo proceso.sin.: quantum
estado de un procesoEstado que se asigna a cada proceso para controlar sus cambios de modo de ejecución a lolargo de su existencia en el sistema. Sólo hay un conjunto limitado de estados posibles, y lasacciones que pueden dar lugar a transiciones entre los estados también están definidas.
overlayTécnica que consiste en dividir el ejecutable de la aplicación en varias partes u overlays, demanera que en cualquier instante de la ejecución de una aplicación sólo sea necesario tenercargado en la memoria un subconjunto del total de overlays.
quantumVed cuota.
señal de software Herramienta que proporciona el sistema operativo con el objetivo de trasladar el mecanismode las interrupciones al ámbito del proceso. Igual que en el mecanismo de hardware de lasinterrupciones, las señales ofrecen apoyo a un amplio conjunto de situaciones diferentes quetienen que ser conocidas y atendidas con una cierta urgencia por parte de los procesos.
Bibliografía
Bibliografía básica
Milenkovic, M. (1994). Sistemas operativos, conceptos y diseño (2.ª ed.; trad. de A. Bautista). Ma-drid: McGraw-Hill.
Silberschatz, A.; Peterson, J.; Galvin, P. (1994). Sistemas operativos, conceptos fundamentales(3.ª ed.; trad. de E. Morales). Wilmington: Addison-Wesley Iberoamericana.
Tanenbaum, A. (1993). Sistemas operativos modernos (trad. de O. Palmas). México: PrenticeHall Hispanoamericana.
Bibliografía complementaria
Kernighan, B.: Pike, R. (1997). El entorno de programación UNIX. México: Prentice HallHispanoamericana.
Robbins, K.; Robbins, S. (1997). UNIX: programación práctica. México: Prentice Hall His-panoamericana.