Sistemas Operativos Mod6

La gestiónde procesosTeodor Jové LagunasJosep Lluís Marzo i Làzaro

P05/75097/00809Módulo 6

© FUOC • P05/75097/00809 • Módulo 6 2 La gestión de procesos

© 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


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.


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.


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.


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


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”.


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


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


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.


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


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”.


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.


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”.


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.


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”.


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


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).


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.


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.


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”.


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.


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.


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


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


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.


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


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”.


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


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.


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) {


}

…

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”.


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);

…

}


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


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.


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.


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”.


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:


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) ;


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:


/*error o fin de fichero*/

exit(1) ;

}

default:

write(1, buff, 2);default:



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:


a)

b)

c)

d)

C

default:

while(pid1!= wait(&estado)) ;

while(pid2!= wait(&estado)) ;

D

}

}

}


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


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) {


}

switch(fork( )) {

case 0:

close(descFichero[0] ) ;

close(1) ;

dup(descFichero[1] ) ;

exec1(fichero2, fichero2, 0) ;

default:


close(0) ;

dup(descFichero[0] ) ;


exec1(fichero2, fichero2, 0) ;

}

}


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.

Documents

Sistemas Operativos Mod6