UNIVERSIDAD NACIONAL JOSÉ MARÍA

ARGUEDAS

PROCESOS EN UN SISTEMA
OPERATIVO

CURSO: Computadores y Sistemas Operativos

INTEGRANTES:
 Franklin Daniel Carbajal Osis
 Lino Eduardo Llalli Borda
 Noe Lujan Gutiérrez
 Irineo rojas Carrasco

PROFESOR: FARFÁN INCA ROCA JESÚS

2019
 PRESENTACIÓN

El presente trabajo constituye un resumen monográfico con el motivo de dar a conocer el

funcionamiento de los procesos en un sistema operativo, desde el concepto básico de un

proceso, abarcando diferentes conceptos de definicones, funciones y las aplicaciones de este

tema. Nuestro trabajo consta de doce temas en el cual se explican de forma clara con

ejemplos e imágenes para el mejor entendimiento del lector y los últimos temas se detallan

las apicaciones de los conceptos de proceso en ejmplos con algoritmos en el lenguaje c para

ponerlo en práctica, investigar y analizar dichos algoritmos. Los temas que abarcamos en

esta monografía se encuentran debidamente citadas en la referencia bibliografica para su

verificación, analisis y seguimiento del lector para profundizar más en los temas.

I
 INDICE

Contenido
1. CONCEPTO DE PROCESO............................................................................................................ 1
2. MULTITAREA ........................................................................................................................ 3
2.1. BASE DE LA MULTITAREA .................................................................................................. 4
2.2. VENTAJAS DE LA MULTITAREA .......................................................................................... 6
2.3. INFORMACIÓN DEL PROCESO ........................................................................................... 7
3. ESTADO DEL PROCESADOR ............................................................................................. 7
3.1. IMAGEN DE MEMORIA DEL PROCESO .............................................................................. 8
3.2. TABLAS DEL SISTEMA OPERATIVO .................................................................................. 10
4. FORMACIÓN DE UN PROCESO....................................................................................... 10
5. ESTADOS DEL PROCESO ................................................................................................ 11
6. PROCESOS LIGEROS ........................................................................................................ 19
7. Planificación ......................................................................................................................... 25
7.1 . Algoritmos de planificación .................................................................................. 27
7.2. Planificación en POSIX .................................................................................................. 30
7.3. Planificación en Windows NT/2000............................................................................. 31
8. SEÑALES Y EXCEPCIONES ............................................................................................. 32
8.1 . Señales ........................................................................................................................ 32
8.2. Excepciones...................................................................................................................... 33
9. TEMPORIZADORES ............................................................................................................ 34
10. SERVIDORES Y DEMONIOS ......................................................................................... 34
11. SERVICIOS POSIX ........................................................................................................... 36
12. SERVICIOS DE W1N32 ................................................................................................... 43
Referencias bibliográficas: ....................................................................................................... 50

0
 1. CONCEPTO DE PROCESO

Todos los programas, cuya ejecución solicitan los usuarios, se ejecutan en forma de
procesos, de ahí la importancia para el informático de conocerlos en detalle. El proceso se
puede definir como un programa en ejecución y, de una forma un poco más precisa, como
la unidad de procesamiento gestionada por el sistema operativo.

Asimismo, para que un programa pueda ser ejecutado ha de residir con sus datos en memoria
principal. Observe que durante su ejecución el proceso va modificando los registros del
modelo de programación de la computadora, de acuerdo a las instrucciones de máquina
involucradas.

El sistema operativo mantiene por cada proceso una serie de estructuras de información que
permiten identificar las características de éste, así como los recursos que tiene asignados.
En esta última categoría entran los descriptores de los segmentos de memoria asignados, los
descriptores de los archivos abiertos, los descriptores de los puertos de comunicaciones, etc.

Una parte muy importante de estas informaciones se encuentra en el llamado bloque de

control del proceso (BCP). El sistema operativo mantiene una tabla de procesos con todos
los BCP de los procesos. Por razones de eficiencia, la tabla de procesos se construye
normalmente como una estructura estática, que tiene un determinado número de BCP, todos
ellos del mismo tamaño. El contenido del BCP se analizará con más detalle en secciones
posteriores; sin embargo, de manera introductoria se puede decir que la información que
compone un proceso es la siguiente:

• Contenido de los segmentos de memoria en los que residen el código y los datos del
proceso. A esta información se le denomina imagen de memoria o core image.

• Contenido de los registros del modelo de programación.

•Contenido del BCP.

Es de destacar que el proceso no incluye información de E/S, puesto que ésta suele estar
reservada al sistema operativo.

1
JERARQUIA DE PROCESOS

La secuencia de creación de procesos genera un árbol de procesos, como el incluido en la

Figura 3.1.

Para referirse a las relaciones entre los procesos de la jerarquía se emplean los términos de
padre, hijo. hermano o abuelo. Cuando el proceso A solicita al sistema operativo que cree el
proceso B. se dice que A es padre de B y que B es hijo de A. Bajo esta óptica, la jerarquía
de procesos puede considerarse como un árbol genealógico.

Algunos sistemas operativos, como UNIX, mantienen de forma explícita esta estructura
jerárquica de procesos —un proceso sabe quién es su padre—, mientras que otros sistemas
operativos como el Windows NT no la mantienen.

Figura 3.1 Jerarquía de proceso

2
 2. MULTITAREA
Como ya se vio en el capítulo anterior, dependiendo del número de procesos y de usuarios
que puedan ejecutar simultáneamente, un sistema operativo puede ser:

• Monotarea o monoproceso.

• Multitarea o multiproceso.

• Monousuario.

• Multiusuario (tiempo compartido).

Un sistema operativo monotarea, también llamado monoproceso, solamente permite que

exista un proceso en cada instante. Si se quieren ejecutar varios procesos, o tareas, hay que
lanzar la ejecución de la primera y esperar a que termine antes de poder lanzar la siguiente.
El ejemplo típico de sistema operativo monoproceso es el MS-DOS. La ventaja de estos
sistemas operativos es que son muy sencillos.

Por el contrario, un sistema operativo multitarea o multiproceso permite que coexistan varios
procesos activos a la vez. El sistema operativo se encarga de ir repartiendo el tiempo del
procesador entre estos procesos, para que todos ellos vayan avanzando en su ejecución.

Un sistema monousuario está previsto para dar soporte a un solo usuario. Estos sistemas
pueden ser monoproceso o multiproceso. En este último caso el usuario puede solicitar
varias tareas al mismo tiempo, por ejemplo, puede estar editando un archivo y,
simultáneamente, puede estar accediendo a una página Web de la red.

El sistema operativo multiusuario da soporte a varios usuarios que trabajan simultáneamente

desde varios terminales. A su vez, cada usuario puede tener activos más de un proceso, por
lo que el sistema, obligatoriamente, ha de ser multitarea. Los sistemas multiusuario reciben
también el nombre de tiempo compartido, puesto que el sistema operativo ha de repartir el
tiempo de la computadora entre los usuarios, para que las tareas de todos ellos avancen de
forma razonable.

3
Figura 3.2. Tipos de sistemas operativos en función del número de procesos y usuarios

2.1. BASE DE LA MULTITAREA

La multitarea se basa en las tres características siguientes:

• Paralelismo real entre E/S y procesador.

• Alternancia en los procesos de fases de E/S y de procesamiento.

• Memoria principal capaz de almacenar varios procesos.

Figura 3.3. Un proceso Alterna entre fases de procesamiento y de E/S.

Como se vio en el Capítulo 1, existe concurrencia real entre el procesador y las funciones
de F/S realizadas por los controladores de los periféricos. Esto significa que, mientras se
están realizando una operación de FIS de un proceso, se puede estar ejecutando otro proceso.

Como se muestra en la Figura 3.3, la ejecución de un proceso alterna, típicamente, fases de

procesamiento con fases de FIS, puesto que, cada cierto tiempo, necesita leer o escribir datos

4
en un periférico. En un sistema monotarea el procesador no tiene nada que hacer durante las
fases de entrada/salida, por lo que desperdicia su potencia de procesamiento. En un sistema
multitarea se aprovechan las fases de entrada/salida de unos procesos para realizar las fases
de procesamiento de otros.

La Figura 3.4 presenta un ejemplo de ejecución multitarea con tres procesos activos.
Observe que, al finalizar la primera fase de procesamiento del proceso A, hay un intervalo
de tiempo en el que no hay trabajo para el procesador.

Como muestra la figura, el sistema operativo entra a ejecutar al final de las fases de
procesamiento y al final de las fases de entrada/salida. Esto es así puesto que las operaciones
de F/S no las gobiernan directamente los procesos, sino que se limitan a pedirle al sistema
operativo que las realice. Del mismo modo, el sistema operativo trata las interrupciones que
generan los controladores para avisar que han completado una operación.

Finalmente es importante destacar que la multitarea exige tener más de un proceso activo y
cargado en memoria principal. Por tanto, hay que disponer de suficiente memoria principal
para albergar a estos procesos.

Figura 3.4 Ejemplo de ejecución en un sistema multitarea

PROCESO NULO

Como se indicó en el Capítulo 1, el procesador no para de ejecutar nunca. Esto parece que
contradice a la Figura 3.4, puesto que muestra un intervalo en el que el procesador no tiene
nada que hacer. Para evitar esta contradicción, los sistemas operativos incluyen el
denominado proceso nulo.

Este proceso consiste en un bucle infinito que no realiza ninguna operación útil. El objetivo
de este proceso es «entretener» al procesador cuando no hay ninguna otra tarea.

5
ESTADOS DE LOS PROCESOS

De acuerdo con la Figura 3.4, un proceso puede estar en varias situaciones (procesamiento,
listo para ejecutar y espera), que denominaremos estados. A lo largo de su vida, el proceso
va cambiando de estado según evolucionan sus necesidades. En la Sección 3.5 se describirán
con mayor detalle los estados de un proceso.

PLANIFICADOR Y ACTIVADOR

El planificador (scheduler) forma parte del núcleo del sistema operativo. Entra en ejecución
cada vez que se activa el sistema operativo y su misión es seleccionar el proceso que se ha
de ejecutar a continuación.

El activador (dispatcher) también forma parte del sistema operativo y su función es poner
en ejecución el proceso seleccionado por el planificador.

2.2. VENTAJAS DE LA MULTITAREA

La multiprogramación presenta varias ventajas, entre las que se pueden resaltar las
siguientes:

• Facilita la programación. Permite dividir las aplicaciones en varios procesos, lo que

beneficia a su modularidad.

• Permite prestar un buen servicio, puesto que se puede atender a varios usuarios de forma
eficiente, interactiva y simultánea.

• Aprovecha los tiempos muertos que los procesos pasan esperando a que se completen sus
operaciones de E/S.

6
• Aumenta el uso de la UCP, al aprovechar los espacios de tiempo que los procesos están
bloqueados.

Todas estas ventajas hacen que, salvo para situaciones muy especiales, no se conciba
actualmente un sistema operativo que no soporte multitarea.

2.3. INFORMACIÓN DEL PROCESO

Como se indicó anteriormente, el proceso es la unidad de procesamiento gestionada por el

sistema operativo. Para poder realizar este cometido, el proceso tiene asociado una serie de
elementos de información, que se analizan seguidamente. Estos elementos se organizan en
tres grupos: estado del procesador, imagen de memoria y tablas del sistema operativo.

3. ESTADO DEL PROCESADOR

El estado del procesador está formado por el contenido de todos sus registros, que se
enumeran seguidamente:

•Registros generales. De existir registros específicos de coma flotante también se incluyen

aquí.

• Contador de programa.

• Puntero de pila.

• Registro o registros de estado.

• Registros especiales. Como puede ser el RIED (registro identificador de espacio de

direccionamiento).

El estado del procesador de un proceso reside en los registros del procesador, cuando el
proceso está en ejecución, o en el bloque de control de proceso (BCP), cuando el proceso
no está en ejecución.

7
Cuando el proceso está ejecutando, el estado del procesador varía de acuerdo al flujo de
instrucciones maquina ejecutado. En este caso, la copia del estado del procesador que
reside en el BCP no está actualizada. Téngase en cuenta que los registros de la máquina se
utilizan para no tener que acceder a la información de memoria, dado que es mucho más
lenta. Por tanto, no tiene sentido plantear que, en cada modificación de un registro, se
actualice su valor en el BCP, puesto que está en memoria.

Sin embargo, cuando se detiene la ejecución de un proceso, como consecuencia de la

ejecución de una interrupción, es muy importante que el sistema operativo actualice la copia
del estado del procesador en su BCP. En términos concretos, la rutina del sistema operativo
que trata las interrupciones lo primero que ha de hacer es salvar el estado del procesador en
el BCP del proceso interrumpido.

3.1. IMAGEN DE MEMORIA DEL PROCESO

La imagen de memoria del proceso está formada por los espacios de memoria que está
autorizado a utilizar. Las principales características de la imagen de memoria son las
siguientes:

• El proceso solamente puede tener información en su imagen de memoria y no fuera de

ella. Si genera una dirección que esté fuera de ese espacio, el hardware de protección deberá
detectarlo y levantar una excepción. Esta excepción activará la ejecución del sistema
operativo que se encargará de tomar las acciones oportunas, que por lo general consistirán
en abortar ¡a ejecución del proceso.

• Dependiendo de la computadora, la imagen de memoria estará referida a memoria virtual

o a memoria física. Observe que esto es transparente (irrelevante) para el proceso, puesto
que él genera direcciones que serán virtuales o físicas según el caso.

• Los procesos suelen necesitar asignación dinámica de memoria. Por tanto, la imagen de
memoria de los mismos se deberá adaptar a estas necesidades, creciendo o decreciendo
adecuadamente.

8
• No hay que confundir la asignación de memoria con la asignación de marcos de memoria.
El primer término contempla la modificación de la imagen de memoria y se refiere a
espacio virtual en los sistemas con este tipo de espacio. El segundo sólo es de aplicación
en los ¡sistemas con memoria virtual y se refiere a la modificación del conjunto residente
del proceso.

El sistema operativo asigna la memoria al proceso, para lo cual puede emplear distintos
modelos de imagen de memoria, que se analizan seguidamente.

Este es el modelo más sencillo de imagen de memoria y su uso se suele restringir a los
sistemas sin memoria virtual. El proceso recibe un único espacio de memoria que, además,
no puede variar de tamaño.

Se puede decir que esta solución no se emplea. En sistemas sin memoria virtual los
segmentos no pueden crecer a menos que se deje espacio de memoria principal de reserva;
se chocaría con otro proceso. Ahora bien, la memoria principal es muy cara como para
dejarla de reserva. En sistemas Con memoria virtual sí se podría emplear, pero es más
conveniente usar un modelo de varios segmentos, pues es mucho más flexible y se adapta
mejor a las necesidades reales de los procesos.

Un proceso contiene varios tipos de información, cuyas características se analizan

seguidamente:

• Texto o código. Bajo este nombre se considera el programa máquina que ha de ejecutar el
proceso. Aunque el programa podría automodificarse. no es esta una práctica recomendada,
por lo cual se considerará que esta información es fija y que solamente se harán operaciones
de lectura sobre ella (Aclaración 3.2).

• Datos. Este bloque de información depende mucho de cada proceso. Los lenguajes de
programación actuales permiten asignación dinámica de memoria, lo que hace que varíe el
tamaño del bloque de datos al avanzar la ejecución del proceso. Cada programa estructura
sus datos de acuerdo a sus necesidades, pudiendo existir los siguientes tipos:

-Datos con valor inicial. Estos datos son estáticos y su valor se fija al cargar el proceso desde
el archivo ejecutable. Estos valores se asignan en tiempo de compilación.

9
-Datos sin valor inicial. Estos datos son estáticos, pero no tienen valor asignado. por lo que
no están presentes en el archivo ejecutable. Será el sistema operativo el que, al cargar el
proceso, rellene o no rellene esta zona de datos con valores predefinidos.

-Datos dinámicos. Estos datos se crean y se destruyen de acuerdo a las directrices del
programa.

Los datos podrán ser de lectura-escritura o solamente de lectura.

Pila. A través del puntero de pila, los programas utilizan una estructura de pila residente en
memoria. En ella se almacenan, por ejemplo, los bloques de activación de los
procedimientos llamados. La pila es una estructura dinámica, puesto que crece y decrece
según avanza la ejecución del proceso.

3.2. TABLAS DEL SISTEMA OPERATIVO

El sistema operativo mantiene una serie de tablas que describen a los procesos y a los
recursos del sistema. Algunos de los aspectos de estas tablas ya se han ido comentando, pero
aquí se profundizará y detallará el contenido de las mismas.

La información asociada a cada proceso se encuentra parcialmente en el BCP y parcialmente

fuera de él. La decisión de incluir o no una información en el BCP se toma según dos
argumentos: eficiencia y necesidad de compartir información.

4. FORMACIÓN DE UN PROCESO

La formación de un proceso consiste en completar todas las informaciones que lo

constituyen, como se muestra en la Figura 3.13. De forma más específica, las
operaciones que debe hacer el sistema operativo son las siguientes:

• Asignar un espacio de memoria para albergar la imagen de memoria. En

general, este espacio será virtual y estará compuesto por varios
segmentos.

10
 • Seleccionar un BCP libre de la tabla de procesos.
• Rellenar el BCP con la información de identificación del proceso, con la
descripción de la memoria asignada, con los valores iniciales de los
registros indicados en el archivo objeto, etc.
• Cargar en el segmento de texto el código más las rutinas de sistema y en
el segmento de datos los datos iniciales contenidos en el archivo objeto.
• Crear en el segmento de pila la pila inicial del proceso. La pila incluye
inicialmente el entorno del proceso y los parámetros que se pasan en la
invocación del programa correspondiente.

Una vez completada toda la información del proceso, se puede marcar como listo
para ejecutar, dc forma que el planificador, cuando lo considere oportuno, lo
seleccione para su ejecución.

5. ESTADOS DEL PROCESO

Como se puede observar en la Figura 3.4, no todos los procesos activos de un

sistema multitarea están en la misma situación. Se diferencian, por tanto, tres
estados básicos en los que puede estar un proceso, estados que detallamos
seguidamente:

11
Ejecución. En este estado está el proceso que está siendo ejecutado por el
procesador, es decir, que está en fase de procesamiento. En esta fase el estado
del proceso reside en los registros del procesador.

Figura 3.13 Formación de un proceso.

Bloqueado. Un proceso bloqueado está esperando a que ocurra un evento y no

puede seguir ejecutando hasta que suceda el evento. Una situación típica de
proceso bloqueado se produce cuando el proceso solicita una operación de E/S.
Hasta que no termina esta operación, el proceso queda bloqueado. En esta fase,
el estado del proceso reside en el BCP.

Listo. Un proceso está listo para ejecutar cuando puede entrar en fase de
procesamiento. Dado que puede haber varios procesos en este estado, una de las
tareas del sistema operativo será seleccionar aquel que debe pasar a ejecución.
El módulo del sistema operativo que toma esta decisión se denomina
planificador. En esta fase, el estado del proceso reside en el BCP.

La Figura 3. 14 presenta estos tres estados, indicando algunas de las posibles

transiciones entre ellos. Puede observarse que sólo hay un proceso en estado de
ejecución, puesto que el procesador solamente ejecuta un programa en cada
instante (Prestaciones 3. 1). Del estado de ejecución se pasa al estado de
bloqueado al solicitar, por ejemplo, una operación de EIS. También se puede
pasar del estado de ejecución al de listo cuando el sistema operativo decide que
ese proceso lleva mucho tiempo en ejecución. Del estado de bloqueado se pasa
al estado de listo cuando se produce el evento por el que estaba esperando el
proceso (p. ej.: cuando se completa la operación de E/S solicitada). Todas las
transiciones anteriores están gobernadas por el sistema operativo, lo que implica
la ejecución del mismo en dichas transiciones.

Estados suspendidos

Además de los tres estados básicos de ejecución, listo y bloqueado, los procesos
pueden estar en los estados de espera y de suspendido. El diagrama de estados
completo de un proceso se representa en la Figura 3.15.
Los procesos entran en el sistema porque lo solicita un proceso de usuario o
porque está prevista su ejecución hatch. Es frecuente tener una lista de procesos
batch en espera para ser ejecutados cuando se pueda. El sistema operativo ha
de ir analizando dicha lista para lanzar la ejecución de los procesos a medida que
disponga de los recursos necesarios.
Los procesos salen del sistema cuando mueren, es decir, al ejecutar el servicio
correspondiente o al producir algún error irrecuperable.

Figura 3.14. Estados básicos de un proceso.

 Figura 3.15. Diagrama completo con los estados de un proceso.

Para disminuir el grado de multiprogramación efectivo, el sistema operativo puede

suspender algunos procesos, lo que implica que les retira todos sus marcos de
páginas, dejándolos enteramente en la zona de intercambio. En la Figura 3. ¡5 se
muestra cómo los procesos listos o bloqueados pueden suspenderse. El objetivo
de la suspensión estriba en dejar suficiente memoria a los procesos no
suspendidos para que su conjunto residente tenga un tamaño adecuado que evite
la hiperpaginacion.
No todos los sistemas operativos tienen la opción de suspensión. Por ejemplo, un
sistema operativo monousuario puede no incluir la suspensión, dejando al usuario
la labor de cerrar procesos si observa que no ejecutan adecuadamente.
Los procesos hatch que entran en el sistema lo pueden hacer pasando al estado
de listo o al de listo suspendido.
Cambio de contexto

La activación del sistema operativo se realiza mediante el mecanismo de las

interrupciones. Cuando se produce una interrupción se realizan las dos
operaciones siguientes:

• Se salva el estado del procesador en el correspondiente BCP.

• Se pasa a ejecutar la rutina de tratamiento de interrupción del sistema
operativo.

Llamaremos cambio de contexto al conjunto de estas operaciones. Como

resultado del cambio de contexto se puede producir un cambio en el estado de
algunos procesos, pero no necesariamente. Supóngase que el proceso A está
bloqueado esperando a que se complete una lectura de disco y que llega una
interrupción del disco. Se produce un cambio de contexto y entra a ejecutar el
sistema operativo para tratar la interrupción. En el caso de que la interrupción
indique que ha terminado la lectura por la que esperaba A, el sistema operativo
cambiará el estado de este proceso a listo o incluso a ejecución si así lo decide el
planificador. El resultado final es que ha habido un cambio de estado de proceso.

Supóngase ahora que está ejecutando el proceso A y que llega una interrupción
de teclado asociado al proceso B. Se produce el cambio de contexto, pero el
proceso B puede seguir en estado de bloqueado (no llegó el carácter de fin de
línea) y el proceso A puede seguir en estado de ejecución, por lo que no hay
cambio de estado en los procesos.

Salvaguarda del estado

Las transiciones en el estado del proceso exigen un trabajo cuidadoso por parte
del sistema operativo, para que se hagan correctamente. El aspecto más delicado
se refiere al contenido de los registros de la computadora. Veamos detalladamente
los pasos involucrados:

• Un proceso está en ejecución, por tanto, parte de su información reside

en los registros de la máquina, que están siendo constantemente
 modificados por la ejecución de sus instrucciones de máquina.
• Bien sea porque llega una interrupción o porque el proceso solicita un
servicio del sistema operativo, el proceso para su ejecución.
• Inmediatamente entra a ejecutar el sistema operativo, ya sea para atender
la interrupción o para atender el servicio demandado.
• La ejecución del sistema operativo, como la de todo programa, modifica
los contenidos de los registros de la máquina, destruyendo sus valores
anteriores.

Según la secuencia anterior, si se desea más adelante continuar con la ejecución

del proceso, se presenta un grave problema: los registros ya no contienen los
valores que deberían. Supongamos que el proceso está ejecutando la secuencia
siguiente:

Supongamos que el valor de CANT es HexA4E78, pero que el sistema operativo

al ejecutar modifica cl registro. 5 dándole el valor HexEB7A4. Al intentar, más
tarde, que siga la ejecución del mencionado proceso, la instrucción “LD. 1, [ .5]
“cargará en el registro. 1 el contenido de la dirección HexEB7A4 en vez del
contenido de la dirección HexA4E78.
Para evitar esta situación, lo primero que hace el sistema operativo al entrar a
ejecutar es salvar el contenido de todos los registros, teniendo cuidado de no
haber modificado el valor de ninguno de ellos. Como muestra la Figura 3.16, al
interrumpirse la ejecución de un proceso el sistema operativo almacena los
contenidos de los registros en el BCP de ese proceso (Recordatorio 3.3).

.
 Figura 3.16. Al interrumpirse la ejecución de un proceso se salva su
estado en el BCP.

Cuando el sistema operativo decide volver a pasar un proceso a estado de

ejecución, ha dc reintegrar los registros al estado previamente salvado en el BCP.
De esta forma, se consigue que el proceso pueda seguir ejecutando sin notar
ninguna diferencia.
Activación de un proceso

El módulo del sistema operativo que pone a ejecutar un proceso se denomina

activador dispatcher. La activación de un proceso consiste en copiar en los
registros del procesador el estado del procesador, que está almacenado en su
BCP. De esta forma, el proceso continuará su ejecución en las mismas
condiciones en las que fue parado. El activador termina con una instrucción RETI
(Recordatorio 3.4) de retorno de interrupción. El efecto de esta instrucción es
restituir el registro de estado y el contador de programa, lo cual tiene los
importantes efectos siguientes:

• Al restituir el registro de estado, se restituye el bit que especifica el nivel

de ejecución. Dado que cuando fue salvado este registro el bit indicaba
nivel de usuario, puesto que estaba ejecutando un proceso, su restitución
garantiza que el proceso seguirá ejecutando en nivel de usuario.
• Al restituir el contador de programa, se consigue que la siguiente
instrucción máquina que ejecute el procesador sea justo la instrucción en
la que fue interrumpido el proceso. En este momento es cuando se ha
dejado de ejecutar el sistema operativo y se pasa a ejecutar el proceso.
 6. PROCESOS LIGEROS

Un proceso ligero, o thread, es un programa en ejecución (flujo de ejecución) que

comparte la imagen de memoria y otras informaciones con otros procesos ligeros.
Como muestra la Figura 3.17, un proceso puede contener un solo flujo de
ejecución, como ocurre en los procesos clásicos, o más de un flujo de ejecución
(procesos ligeros).
Desde el punto de vista de la programación, un proceso ligero se define corno una
función cuya ejecución se puede lanzar en paralelo con otras. El hilo de ejecución
primario, o proceso ligero primario, corresponde a la función main.
Cada proceso ligero tiene informaciones que le son propias y que no comparte
con otros procesos ligeros. Las informaciones propias se refieren
fundamentalmente al contexto de ejecución, pudiéndose destacar las siguientes:

• Contador de programa.
• Pila.
• Registros.
• Estado del proceso ligero (ejecutando, listo o bloqueado).

Todos los procesos ligeros de un mismo proceso comparten la información del

mismo. En concreto, comparten:
• Espacio de memoria.
• Variables globales.
• Archivos abiertos.
• Procesos hijos.
• Temporizadores.
• Señales y semáforos.
• Contabilidad.
Es importante destacar que todos los procesos ligeros de un mismo proceso
comparten el mismo espacio de direcciones de memoria, que incluye el código,
los datos y las pilas de los diferentes procesos ligeros. Esto hace que no exista
protección de memoria entre los procesos ligeros de un mismo proceso, algo que
sí ocurre con los procesos convencionales.

El proceso ligero constituye la unidad ejecutable en Windows NT. La Figura 3. IX

representa de forma esquemática la estructura de un proceso de Windows NT con
sus procesos ligeros.

Figura 3.17. Proceso ligero.

Figura 3.18. Estructura de un proceso en Windows NT

Estados del proceso ligero

El proceso ligero puede estar en uno de los tres estados siguientes: ejecutando,
listo para ejecutar y bloqueado. Como muestra la Figura 3.19, cada proceso ligero
de un proceso tiene su propio estado, pudiendo estar unos bloqueados, otros listos
y otros en ejecución (Aclaración 3.4).

El estado del proceso será ¡a combinación de los estados de sus procesos ligeros.
Por ejemplo, si tiene un proceso ligero en ejecución, el proceso está en ejecución.
Si no tiene proceso ligero en ejecución, pero tiene alguno listo para ejecutar, el
proceso está en estado de listo. Finalmente, si todos sus procesos ligeros están
bloqueados, el proceso está bloqueado. No tiene sentido el estado dc suspendido,
puesto que, si el proceso está suspendido, todos sus procesos ligeros lo estarán.

Figura 3.19. Estado dc un proceso ligero.

Paralelismo

Los procesos ligeros permiten paralelizar una aplicación, tal y como muestra la
Figura
En efecto, cuando un programa puede dividirse en procedimientos que pueden
ejecutar de forma independiente, el mecanismo de los procesos ligeros permite
lanzar simultáneamente la ejecución de todos ellos. De esta forma se consigue
que el proceso avance más rápidamente (Prestaciones 3.2).
La base de este paralelismo estriba en que, mientras un proceso ligero está
bloqueado, otro puede ejecutar.
Comparando el uso de los procesos ligeros con otras soluciones se puede decir
que:

• Los procesos ligeros:

— Permiten paralelismo y variables compartidas.
— Utilizan llamadas al sistema bloqueantes por proceso ligero. Esta es
la solución más sencilla de conseguir paralelismo desde el punto de
vista de la programación.

• Un proceso convencional con un solo proceso ligero:

— No hay paralelismo.
— Utiliza llamadas al sistema bloqueantes.

• Un proceso con un solo proceso ligero, que usa llamadas no bloqueantes

y estructurado en máquina de estados finitos:

— Permite paralelismo.
— Utiliza llamadas al sistema no bloqueantes, lo que lleva a un diseño
muy complejo y difícil de mantener.
 Figura 3.20. Los procesos ligeros permiten paralelizar la ejecución
de una aplicación.

• Varios procesos convencionales cooperando:

— Permite paralelismo.
— No comparte variables, por lo que la comunicación puede consumir
mucho tiempo.

Diseño con procesos ligeros

La utilización de procesos ligeros ofrece las ventajas de división de trabajo que

dan los procesos, pero con una mayor sencillez, lo que se traduce en mejores
prestaciones. En este sentido, es de destacar que los procesos ligeros comparten
memoria directamente, por lo que no hay que añadir ningún mecanismo adicional
para utilizarla, y que la creación y destrucción de procesos ligeros requiere mucho
menos trabajo que la de procesos.
Las ventajas de diseño que se pueden atribuir a los procesos ligeros son las
siguientes:
• Permite separación de tareas. Cada tarea se puede encapsular en un
proceso ligero independiente.
• Facilita el modularidad, al dividir trabajos complejos en tareas.
• Aumenta la velocidad de ejecución del trabajo, puesto que aprovecha los
tiempos de bloqueo de unos procesos ligeros para ejecutar otros.
El paralelismo que permiten los procesos ligeros, unido a que comparten memoria
(utilizan variables globales que ven todos ellos), permite la programación
concurrente. Este tipo de programación tiene un alto nivel de dificultad, puesto que
hay que garantizar que el acceso a los datos compartidos se haga de forma
correcta. Los principios básicos que hay que aplicar son los siguientes:

• Hay variables globales que se comparten entre varios procesos ligeros.

Dado que cada proceso ligero ejecuta de forma independiente a los
demás, es fácil que ocurran accesos incorrectos a estas variables.
• Para ordenar la forma en que los procesos ligeros acceden a los datos se
emplean mecanismos de sincronización, como el mutex, que se
describirán en el Capítulo 5. El objetivo de estos mecanismos es impedir
que un proceso ligero acceda a unos datos mientras los esté utilizando
otro.
• Para escribir código correcto hay que imaginar que los códigos de los otros
procesos ligeros que pueden existir están ejecutando cualquier sentencia
al mismo tiempo que la sentencia que se está escribiendo.
Diseño de servidores mediante procesos ligeros

Una de las aplicaciones típicas de los procesos ligeros es el diseño de procesos

servidores paralelos.
La Figura 3.21 muestra tres posibles soluciones. En la primera se plantea un
proceso ligero distribuidor cuya función es la recepción de las órdenes y su
traspaso a un proceso ligero trabajador. El esquema puede funcionar creando un
nuevo proceso ligero trabajador por cada solicitud dc servicio, proceso ligero que
muere al finalizar su trabajo, o teniendo un conjunto de ellos creados a los que se
va asignando trabajo y que quedan libres al terminar la tarea encomendada. Esta
segunda alternativa es más eficiente, puesto que se evita el trabajo de crear y
destruir a los procesos ligeros.
Figura 3.21. Ejemplos de diseño de servidores paralelos mediante procesos
ligeros.

La segunda solución consiste en disponer de un conjunto de procesos ligeros

iguales, todos los cuales pueden aceptar una orden (leer de un puerto en el caso
de la figura). Cuando llega una solicitud, la recibe uno de los procesos ligeros que
están leyendo del puerto. Este proceso ligero tratará la petición y, una vez
finalizado el trabajo solicitado, volverá a la fase de leer una nueva petición del
puerto.
La tercera solución aplica la técnica denominada de segmentación (pipe-line).
Cada trabajo se divide en una serie de fases, encargándose de cada una de ellas
un proceso ligero especializado. El esquema permite tratar al mismo tiempo tantas
solicitudes como fases tenga la segmentación, puesto que se puede tener una en
cada proceso ligero.

7. Planificación
El objetivo de la planificación de procesos es el reparto del tiempo de procesador
entre los proseos que pueden ejecutar. El planificador es el módulo del sistema
operativo que realiza la función de selección el proceso de listo que pasa a estado
de ejecución, mientras que el activador es el módulo que pone en ejecución el
proceso planificado.

La planificación a largo plazo tiene por objetivo añadir nuevos procesos al sistema,
tomándolos de la lista de espera. Estos procesos son procesos de tipo batch, en
los que no importa el instante preciso en el que se ejecuten (siempre que se
cumplan ciertos límites de espera).

La planificación a medio plazo trata la suspensión de procesos. Es la que decide

qué procesos pasan a suspendido y cuáles dejan de estar suspendidos. Añade o
elimina procesos de memoria principal modificando, por tanto, el grado de
multiprogramación.

La planificación a corto plazo se encarga de seleccionar el proceso en estado de

listo que pasa a estado de ejecución. Es, por tanto, la que asigna el procesador.

Figura 3.22. tipos de planificación

Expulsión

La planificación puede ser con expulsión o sin ella. En un sistema sin expulsión un
proceso conserva el procesador mientras lo desee, es decir, mientras no solicite
del sistema operativo un servicio que lo bloquee. Esta solución minimiza el tiempo
que gasta el sistema operativo en planificar y activar procesos, pero tiene como
inconveniente que un proceso puede monopolizar el procesador (imagínese lo que
ocurre si el proceso, por error, entra en un bucle infinito).

En los sistemas con expulsión, el sistema operativo puede quitar a un proceso del
estado de ejecución, aunque éste no lo solicite. Esta solución permite controlar el
tiempo que está en ejecución un proceso, pero requiere que el sistema operativo
entre de forma sistemática a ejecutar para así poder comprobar si el proceso ha
superado su límite de tiempo de ejecución.

Objetivos de la planificación

El objetivo de la planificación es optimizar el comportamiento del sistema. Ahora

bien, el comportamiento de un sistema informático es muy complejo, por tanto, el
objetivo de la planificación se deberá centrar en la faceta del comportamiento en el
que se esté interesado. Entre los objetivos que se suelen perseguir están los
siguientes:

 Reparto equitativo del procesador.

 Eficiencia (optimizar el uso del procesador).
 Menor tiempo de respuesta en uso interactivo.
 Menor tiempo de espera en lotes (batch).
 Mayor número de trabajos por unidad de tiempo (batch).
 Cumplir los plazos de ejecución de un sistema de tiempo real.

La mayoría de estos objetivos son incompatibles entre sí, por lo que hay que
centrar la atención en aquel que sea de mayor interés. Por ejemplo, una
planificación que realice un reparto equitativo del procesador no conseguirá
optimizar el uso del mismo.

Hay que observar que algunos objetivos están dirigidos a procesos interactivos,
mientras que otros lo están a procesos batch.

7.1 . Algoritmos de planificación

En esta sección se presentan los algoritmos de planificación más usuales.

Cíclica o Round-robin

El algoritmo cíclico está diseñado para hacer un reparto equitativo del tiempo del
procesador, por lo que está especialmente destinado a los sistemas de tiempo
compartido. El algoritmo se basa en el concepto de rodaja (slot) de tiempo.
Los procesos están organizados en forma de cola circular, eligiéndose para su
ejecución el proceso cabecero de la cola. Un proceso permanecerá en ejecución
hasta que ocurra una de las dos condiciones siguientes:

 El proceso pasa a estado de bloqueado, porque solicita un servicio del

sistema operativo.
 El proceso consume su rodaja de tiempo, es decir, lleva ejecutando el tiempo
estipulado de rodaja.

Un proceso que ha consumido su rodaja de tiempo es expulsado y pasa a ocupar

el último lugar en la cola. De esta forma, se consigue que todos los procesos pasen
a ejecutar, repartiendo el tiempo del procesador de forma homogénea entre ellos.
La Figura 3.25 muestra cómo el proceso 5, al consumir su rodaja de tiempo, pasa
al final de la cola.

Figura 3.25. planificación clínica

Fifo

En este caso, la cola de procesos en estado de listo está ordenada de acuerdo al

instante en que los procesos pasan al estado de listo. Los que llevan más tiempo
esperando están más cerca de la cabecera.

El algoritmo es sencillo, puesto que consiste en tomar para ejecutar al proceso de

la cabecera de la cola. No se plantea expulsión, por lo que el proceso ejecuta hasta
que realiza una llamada bloqueante al sistema operativo. Es aplicable a los
sistemas batch, pero no a los interactivos.

Prioridades

En el algoritmo de prioridades se selecciona para ejecutar el proceso en estado de

listo que tenga la máxima prioridad.
Cuando las prioridades son fijas puede surgir el problema de la inanición, que
implica que un proceso puede estar esperando indefinidamente sin llegar a
ejecutar. Esto ocurrirá si van apareciendo siempre procesos de mayor prioridad que
estén en estado de listo.

Para evitar este problema, se puede añadir un mecanismo de envejecimiento, que

se encargue de aumentar la prioridad a los procesos que lleven un determinado
tiempo esperando a ser ejecutados. Por ejemplo, suponiendo que la mayor
prioridad es la 0, un proceso de prioridad 22 que lleve más de X ms esperando en
estado de listo pasaría a prioridad 21, si pasados otros X ms siguiese sin ejecutar
pasaría a prioridad 20 y así sucesivamente. Una vez que haya ejecutado volverá a
tomar su prioridad normal de 22. Dado que puede haber varios procesos listos con
el mismo nivel de prioridad, es necesario utilizar otro algoritmo para decidir entre
ellos. Se podría utilizar, por ejemplo, un cíclico, si el sistema es interactivo o un
FIFO si es hatch. Los algoritmos basados en prioridades suelen ser con expulsión.

Aleatorio o lotería

Este algoritmo consiste en elegir al azar el proceso a ejecutar. Se puede basar en

un generador de números pseudoaleatorios.

Planificación de sistemas de tiempo real

Los sistemas de tiempo real se caracterizan porque los procesos tienen que
ejecutar en instantes predeterminados. Se pueden diferenciar dos tipos de
procesos de tiempo real: a plazo fijo y periódico. La diferencia estriba en que los de
plazo fijo tienen que ejecutar una vez, en un instante determinado, mientras que
los periódicos deben ejecutar de forma repetitiva cada cierto tiempo.

Figura 3.26. planificación de sistemas en tiempo real.

7.2. Planificación en POSIX
POSIX especifica una serie de políticas de planificación, aplicables a procesos y
procesos ligeros, que debe implementar cualquier sistema operativo que ofrezca
esta interfaz. En POSIX cada unidad ejecutable (proceso o proceso ligero) lleva
asociada una política de planificación y una prioridad. Estos parámetros, como se
verá en la Sección 3.11, pueden ser modificados mediante los servicios
correspondientes.

Cada política de planificación lleva asociada un rango de prioridades. POSIX

especifica que cada implementación debería ofrecer un rango de, al menos, 32
niveles de prioridad. El planificador elegirá siempre para ejecutar el proceso o
proceso ligero con la prioridad más alta. Las políticas de planificación disponibles
en POSIX son las siguientes:

 FIFO: Los procesos que se planifican según esta política se introducen al

final de la cola de su prioridad asociada. Un proceso con esta política de
planificación sólo se expulsará de la UCP cuando ejecute una llamada al
sistema bloqueante o cuando aparezca en el sistema un proceso con mayor
prioridad. El comportamiento del planificador para este tipo de planificación
viene dado por las siguientes reglas:
— Si un proceso es expulsado de la UCP por otro de mayor prioridad, el
proceso expulsado pasa a ser el primero de la cola asociada a su prioridad.
— Cuando un proceso bloqueado pasa a listo para ejecutar, el proceso se
introduce al final de la cola asociada a su prioridad.
— Cuando un proceso cambia su prioridad o su política de planificación,
utilizando para ello los servicios adecuados, se realiza una replanificación.
Si como resultado de ésta el proceso resulta expulsado, éste se introduce
al final de la cola de procesos de su prioridad.

 Cíclica: En este caso, los procesos de cada nivel de prioridad se planifican

según una política de planificación cíclica con una determinada rodaja de
tiempo. El comportamiento del planificador para los procesos con este tipo
de planificación es el siguiente:
— Cuando un proceso acaba su rodaja de tiempo, se introduce
al final de la cola de procesos de su prioridad.
 — Cuando un proceso es expulsado por otro de mayor prioridad,
se introduce al principio de su cola sin restaurar su rodaja de
tiempo.
— De esta forma, cuando el proceso continúe la ejecución, lo
hará hasta que consuma el resto de la rodaja de tiempo.

7.3. Planificación en Windows NT/2000

En Windows NT la unidad básica de ejecución es el proceso ligero y, por tanto, la
planificación se realiza sobre este tipo de procesos. La Figura 3.27 (tomada de
(Solomon, 1998)) describe los distintos estados por los que puede pasar un
proceso ligero durante su ejecución. Estos estados son:

 Listo. Los procesos ligeros en este estado están listos para ejecutar.
 Reserva. Un proceso ligero en este estado será el siguiente proceso ligero
a ejecutar en un procesador determinado. Sólo puede haber un proceso
ligero en este estado por procesador.
 Ejecución. El proceso ligero permanece ejecutando hasta que se cumpla
alguna de estas condiciones: el sistema operativo lo expulsa para ejecutar
un proceso ligero de mayor prioridad, la rodaja de tiempo del proceso
termina o bien el proceso ligero finaliza su ejecución.
 Bloqueado. Cuando el proceso ligero deja de estar bloqueado puede,
dependiendo de su prioridad, comenzar su ejecución inmediatamente o
pasar al estado de listo para ejecutar.
 Transición. Un proceso ligero entra en este estado cuando está listo para
ejecutar, pero la pila que utiliza el sistema operativo para ese proceso no
reside en memoria principal. Cuando la página vuelva a memoria, el proceso
ligero pasará al estado de listo para ejecutar.
 Finalizado. Cuando un proceso ligero finaliza su ejecución, pasa a este
estado. Una vez terminado, el proceso ligero puede o no ser eliminado del
sistema. En caso de no ser eliminado, podría ser reutilizado de nuevo.
Figura 7.27. Estados de los procesos ligeros en Windows NT

 Dieciséis niveles con prioridades de tiempo real (niveles 16 al 31).

 Quince niveles con prioridades variables (niveles 1 al 15).
 Un nivel de sistema (0).

8. SEÑALES Y EXCEPCIONES
Cuando un sistema operativo desea notificar a un proceso la ocurrencia de un
determinado evento, o error, recurre a dos tipos de mecanismos: señales y
excepciones. Las primeras se utilizan en POS IX y las segundas en Windows NT.
En las siguientes secciones se tratan estos dos mecanismos.

8.1 . Señales
Las señales tienen frente al proceso el mismo comportamiento que las
interrupciones tienen frente al procesador, por lo que se puede decir que una señal
es una interrupción al proceso.

El proceso que recibe una señal se comporta, como muestra la Figura 3.28, de la
siguiente forma:
Figura 7.28. recepción de una señal por parte de un proceso.

 El proceso detiene su ejecución en la instrucción de máquina que está

ejecutando.
 Bifurca a ejecutar una rutina de tratamiento de la señal, cuyo código ha de
formar parte del propio proceso.
 Una vez ejecutada la rutina de tratamiento, sigue la ejecución del proceso
en la instrucción en el que fue interrumpido.
El origen de una señal puede ser un proceso o el sistema operativo.

Tipos de señales

Dado que las señales se utilizan para indicarle al proceso muchas cosas diferentes,
existen una gran variedad de ellas. A título de ejemplo, se incluyen aquí tres
categorías de señales:

 Excepciones hardware.
 Comunicación.
 FIS asíncronas.

8.2. Excepciones
Una excepción es un evento que ocurre durante la ejecución de un programa y que
requiere la ejecución de un fragmento de código situado fuera del flujo normal de
ejecución.

Las excepciones son generadas por el hardware o el software. Ejemplos de

excepciones hardware incluyen la división por cero o la ejecución de instrucciones
ilegales. Las excepciones software incluyen aquellas detectadas y notificadas por
el sistema operativo o el propio proceso. Cuando ocurre una excepción, tanto
hardware como software, el control es transferido al Sistema operativo, que ejecuta
la rutina de tratamiento de excepción correspondiente. Esta rutina crea un registro
de excepción que contiene información sobre la excepción generada. Si existe un
manejador para la excepción generada, el sistema operativo transfiere el control a
dicho manejador, en caso contrario aborta la ejecución del proceso. (lopez)

9. TEMPORIZADORES
El sistema operativo mantiene en cada BCP un temporizador que suele estar
expresado en segundos. Cada vez que la rutina del sistema operativo que trata
las interrupciones de reloj comprueba que ha transcurrido un segundo,
decrementa todos los temporizadores que no estén a «0» y comprueba si han
llegado a «0». Para aquellos procesos cuyo temporizador acaba de llegar a «0»,
el sistema operativo notifica al proceso que el temporizador ha vencido. En
POSIX se genera una señal SIGALRN. En Win32 se ejecuta una función
definida por el usuario y que se asocia al temporizador.

El proceso activa el temporizador mediante un servicio en el que especifica el

número de segundos o milisegundos que quiere temporizar. Cuando vence la
temporización, recibirá la correspondiente señal o se ejecutará la función
asociada al mismo.

10. SERVIDORES Y DEMONIOS

Los servidores y los demonios son dos tipos de procesos muy frecuentes y que
tienen unas características propias que se analizan seguidamente.

Un servidor es un proceso que está pendiente de recibir órdenes de trabajo que

provienen de otros procesos, que se denominan clientes. Una vez recibida la orden,
la ejecuta y responde al peticionario con el resultado.

El proceso servidor tiene la siguiente estructura de bucle infinito:

 Lectura de orden. El proceso está bloqueado esperando a que llegue una

orden.
 Recibida la orden, el servidor la ejecuta.
 Finalizada la ejecución, el servidor responde con el resultado al proceso
cliente y vuelve al punto de lectura de orden.

Un servidor será secuencial cuando siga estrictamente el esquema anterior. Esto

implica que hasta que no ha terminado el trabajo de una solicitud no admite otra.
En muchos casos interesa que el servidor sea paralelo, es decir, que admita varias
peticiones y las atienda simultáneamente. Para conseguir este paralelismo se
puede proceder de la siguiente manera:

 Lectura de la orden. El proceso está bloqueado esperando a que llegue una

orden.
 Asignación de un nuevo puerto para el nuevo cliente.
 Generación de un proceso hijo que realiza el trabajo solicitado por el cliente.
 Vuelta al punto de lectura de orden.

De esta forma, el proceso servidor dedica muy poco tiempo a cada cliente, puesto
que el trabajo lo realiza un nuevo proceso, y puede atender rápidamente nuevas
peticiones. La Figura 3.30 muestra esta secuencia.

Figura 3.30. Funcionamiento de un proceso servidor.

Un proceso demonio: es un proceso que suele tener las siguientes

características:

 Se arranca al iniciar el sistema, puesto que debe estar siempre activo.

 No muere. En caso de que un demonio muera por algún imprevisto es muy
recomendable que exista un mecanismo que detecte la muerte y lo
rearranque.
 En muchos casos está a la espera de un evento. En el caso frecuente de
que el demonio sea un servidor, el evento por el que espera es que llegue
una petición al correspondiente puerto.
 En otros casos, el demonio tiene encomendada una labor que hay que hacer
de forma periódica. ya sea cada cierto tiempo o cada vez que una variable
alcanza un determinado valor.
  Es muy frecuente que no haga directamente el trabajo: lanza
otros procesos para que lo realicen.
 Los procesos servidores suelen tener el carácter de demonios.
 Los demonios ejecutan en haekground y no están asociados a un
terminal o procesos login.
 Como ejemplos de procesos servidores se pueden citar los
siguientes: el servidor de FTP el servidor de TELNET, el servidor
de WEB y el spooler de impresora.

11. SERVICIOS POSIX

Esta sección describe los principales servicios que ofrece POSIX para la gestión
de procesos.

Servicios POSIX para la gestión de procesos

En esta sección se describen los principales servicios que ofrece POSIX para la
gestión de procesos. Estos servicios se han agrupado según las siguientes
categorías:

 Identificación de procesos.
 El entorno de un proceso.
 Creación de procesos.
 Terminación de procesos.

En las siguientes secciones se presentan los servicios incluidos en cada una de

estas categorías.

Identificación de procesos

POSIX identifica cada proceso por medio de un entero único denominado

identificador de proceso de tipo pid_ti. Los servicios relativos a la identificación de
los procesos son los siguientes:

 Obtener el identificador de proceso

Este servicio devuelve el identificador del proceso que realiza la llamada. Su
prototipo en C lenguaje es el siguiente:
 pid_t getpid(void);

 Obtener el identificador del proceso padre

Devuelve el identificador del proceso padre. Su prototipo es el que se muestra a
continuación.

pid ti getppid(void)

Programa 3.1. Programa que imprime el identificador del proceso y el identificador

de su proceso padre.

# include <sys/types.h> #include <stdio.h> main ( )

pid_id_proceso; pid_id_padre;

id proceso = getpid ( ); id_padre = getppid ( );

printf(”identificador de proceso: %d\n”, íd_proceso>; printlf(”identificador del

proceso padre: %d\n”, Id_padre>;

 Obtener el identificador de Usuario real

Este servicio devuelve el identificador de usuario real del proceso que realiza la
llamada. Su prototipo es:

uid_t getuid(void);

 Obtener el identificador de usuario efectivo

Devuelve el identificador de usuario efectivo. Su prototipo es:
 uid_t geteuid(void);

 Obtener el identificador de grupo real

Este servicio permite obtener el identificador de grupo real. El prototipo que se
utiliza para invocar este servicio es el siguiente:

gid_t getgid (void);

 Obtener el identificador de grupo efectivo

Devuelve el identificador de grupo efectivo. Su prototipo es:

gid_t getegid (void);

El siguiente programa muestra un ejemplo de utilización de estos cuatro servicios.

Programa 3.2. Programa que imprime la información de identificación de un

proceso.

#include <sys/types.h> #include <stdio.h> main ( )

printf(”identificador de usuario: %d\n”, getuid ()); printf(”identificador de usuario

efectivo: %d\n” ,geteuid ()); printf (“identificador de grupo: %d\n”, getgid ());
printf(”identificador de grupo efectivo: %d\n”, getegid ());

El entorno de un proceso

El entorno de un proceso viene definido por una lista de variables que se pasan al
mismo en el momento de comenzar su ejecución. Estas variables se denominan
variables de entorno y son accesibles a un proceso a través de la variable externa
environ, declarada de la siguiente forma:

extern char **environ;

Esta variable apunta a una lista de variables de entorno. Esta lista no es más que
un vector de punteros a cadenas de caracteres de la forma nombre = valor,
donde nombre hace referencia al nombre de una variable de entorno y valor al
contenido de la misma.

Programa 3.3. Programa que imprime el entorno del proceso.

#include <stdio.h> #include <stdlib.h>

extern char **environ;

void main(int argc, char *argv)

int i;

printf(“ de variables de entorno de %s\n”, argv[0]);

for(i=O; environ[i] NULL; i++) printf(”environ[%d] = %s\n”, 1, environ[i]);

Cada aplicación interpreta la lista de variables de entorno de forma específica.

POSIX establece el significado de determinadas variables de entorno. Las más
comunes son:

 HOME: directorio de trabajo inicial del usuario.

 LOGNAME: nombre del usuario asociado a un proceso.
 PATH: prefijo de directorios para encontrar ejecutables.
 TERM: tipo de terminal.
 TZ: información de la zona horaria.

Obtener el valor de una variable de entorno

El servicio getenv permite buscar una determinada variable de entorno dentro de

la lista de variables de entorno de un proceso. La sintaxis de esta función es:

char *getenv(const char *name)

Esta función devuelve un puntero al valor asociado a la variable de entorno de
nombre name. Si la variable de entorno no se encuentra definida, la función
devuelve NIJLL.

Programa 3.4 Programa que imprime el valor de la variable HOME.

#include <stdio.h> #include <stdlib.h>

main ()

char *home = NULL;

home = getenv (”HOME”); if (home = = NULL)

printf(”HOME no se encuentra definida\n”>;

else

printf(”E1 valor de HOME es %s\n”, home);

Creación de procesos

En esta sección se describen los principales servicios POSIX relativos a la creación

de procesos.

 Crear un proceso
La forma de crear un proceso en un sistema operativo que ofrezca la interfaz POSIX
es invocando el servicio fork. El sistema operativo trata este servicio realizando una
donación del proceso que lo solicite. El proceso que solicita el servicio se convierte
en el proceso padre del nuevo proceso, que es, a su vez, el proceso hijo. El
prototipo de esta función es el siguiente:

Pid_t fork ();

La Figura 3.32 muestra que la donación del proceso padre se realiza copiando la
imagen de memoria y el BCP. Observe que el proceso hijo es una copia del
proceso padre en el instante en que éste solicita el servicio fork. Esto significa que
los datos y la pila del proceso hijo son los que tiene el padre en ese instante de
ejecución. Es más, dado que, al entrar el sistema operativo a tratar el servicio, lo
primero que hace es salvar los registros en el BCP del padre, al copiarse el BCP
se copian los valores salvados de los registros, por lo que el hijo tiene los mismos
valores que el padre

Figura 3.32. Creación de un proceso mediante el servicio fork.

Figura 3.33. Uso de la llamada fork.

Programa 3.5. Programa que crea un proceso.

#include <sys/ypes.h> #ineclude <stdio.h>

main ()

pid_t pid;

pid = fork (); switch(pid) {

case -1: /* error del fork<) *1

perror(”fork”) break;

case 0: /* proceso hilo */

printf(”Proceso %d; padre = %d \n”, getpidü, getppid(); break;

default: /* padre */

printf(”Proceso %d; padre = %d \n”, getpidú, getppid();

Terminación de procesos

En esta sección se presentan los servicios relacionados con la terminación de

procesos.

 Terminar la ejecucion de un proceso

Un proceso puede terminar su ejecución de forma normal o anormal. Un proceso
puede terminar su ejecución de forma normal usando cualquiera de las tres formas
siguientes:

 Ejecutando una sentencia return en la función main.

 Ejecutando la llamada exit.
 Ejecutando la llamada _exit.pidt pid;

Cuando un programa ejecuta dentro de la función main la sentencia return (valor),

ésta es similar a exit (valor). El prototipo de la función exit es:

voidexit(int status);

Estos servicios tienen por función finalizar la ejecución de un proceso. Ambos

reciben como parámetro un valor que sirve para que el proceso dé una indicación
de cómo ha terminado. Como se verá más adelante, esta información la puede
recuperar el proceso padre que, de esta forma, puede conocer cómo ha terminado
el hijo.

El Programa 3.11 finaliza su ejecución utilizando la llamada exit. Cuando se llama

a esta tuncion se ejecuta la función fin, registrada previamente por medio de la
función atexit.
Programa 3.11. Ejemplo de utilización de exit y atexit.

#include <stdio.h> #include <stdlib.h>

void íin(void)

printf(’Fin de la ejecución del proceso %d\n”, getpid()); retiu_n;

void main(void)

if (atexit(fin) O) perror(”atexit”)

exit (1)

exit(O); /~ provoca la ejecución de la función fin *7

h> Esperar por la jtnalizacion de un proceso hijo

Permite a un ~~OCCS() padre esperar hasta que termine la ejecución de un

proceso hijo (el proceso padre se queda bloqueado hasta que termina un proceso
hijo). Existen dos formas de invocar este servicio:

 pidt wait(int *status)

 pidt waitpid(pid t pid, mt *status, mt options)

Ambas llamadas esperan la finalización de un proceso hijo y permiten obtener

información.

La utilización de los servicios fork, exec, wait y exit hace variar la jerarquía de
procesos. Con el servicio fork aparecen nuevos procesos y con el exit desaparecen.

12. SERVICIOS DE W1N32

Esta sección describe los principales servicios que ofrece Win32 para la gestión de
procesos, procesos ligeros y planificación. También se presentan los servicios que
permiten trabajar con excepciones y temporizadores.

Servicios de Win32 para la gestión de procesos

En Win32 cada proceso contiene uno o más procesos ligeros. Como se indicó
anteriormente, en Windows el proceso ligero o thread es la unidad básica de
ejecución. Los procesos en Win32 se diferencian de los de POSIX, en que Win32
no mantiene ninguna relación padre-hijo. Por conveniencia, sin embargo, en el
texto se asumirá que un proceso padre crea a un proceso hijo. Los servicios que
ofrece Win32 se han agrupado, al igual que en POSIX, en las siguientes categorías:

 Identificación de procesos.
 El entorno de un proceso.
 Creación de procesos.
 Terminación de procesos.

A continuación, se presentan los servicios incluidos en las categorías anteriores.

Identificación de procesos

En Win32, los procesos se designan mediante identificadores de procesos y

manejadores. Un identificador de proceso es un objeto de tipo entero que identifica
de forma única a un proceso en el sistema. El manejador se utiliza para identificar
al proceso en todas las funciones que realizan operaciones sobre el proceso.

Existen dos funciones que permiten obtener la identificación del proceso que realiza
la llamada.

 HANDLE GetCurrentProcess (VOID);

 DWORD GetCurrentProcessld(VOID);
La primera devuelve el manejador del proceso que realiza la llamada y la segunda
su identificador de proceso.

Conocido el identificador de un proceso, se puede obtener su manejador mediante

el siguiente servicio:

 HANDLE OpenProcess(DWORD fdwAccess, BOOL flnherit, DWORD

IdProcess);

El primer argumento especifica el modo de acceso al objeto que identifica al

proceso con idcntificador Idprocess. Algunos de los posibles valores para este
argumento son:

PROCESS_ALL_ACCESS: especifica todos los modos de acceso al objeto.

SYNCHRONIZE: permite que el proceso que obtiene el manejador pueda esperar
la terminación del proceso con identificador IdProcess.

PROCESS_TER~INATE: permite al proceso que obtiene el manejador finalizar la

ejecución del proceso con identificador IdProcess.

PROCESS~QUERY_INFORMATION: el manejador se puede utilizar para obtener

información sobre el proceso.

El argumento flnherit específica si el manejador devuelto por la función puede ser

heredado por los flUC VOS procesos creados por el que realiza la llamada. Si su
valor es TRUE, el manejador se puede heredar.

La función devuelve el manejador del proceso en caso de éxito o NULL si se produjo

algún error.

El entorno de un proceso

Un proceso recibe su entorno en su creación (mediante el servicio createProcess

descrito en la siguiente sección). Cualquier proceso puede obtener el valor de una
variable de entorno o modificar su valor mediante los dos servicios siguientes:

 DWORD GetEnvironmentVariable(LPCTSTR lpszName, LPTSTR

lpszValue, DWORD cchValue);
 BOOL SetEnvironmentVariable(LPCTSTR lpszName, LPTSTR lpzsValue>;

La primera función obtiene en lpszvalue el valor de la variable de entorno con

nombre lpszName. El argumento cchValue especifica la longitud del buffer en
memoria al que apunta ¡lpszValue. La función devuelve la longitud de la cadena en
la que se almacena el valor de la variable (lpszvalue) o O si hubo algún error.

La función SetEnvironmentVariable permite modificar el valor de una variable de

en- torno. Devuelve TRTJE si se ejecutó con éxito.

Creación de procesos

En Win32, los procesos se crean mediante la llamada CreateProcess. Este servicio

es similar ala combinación fork-exec de POSIX. Win32 no permite a un proceso
cambiar su imagen de memoria y ejecutar otro programa distinto. El prototipo de la
función CreateProcess es el siguiente:
EOOL CreateProcess

LPCTSTR lpszlmageName,

LPTSTR lpszComrnandLine,

LPSECURITY_ATTRIBUTES lpsaProcess,

LPSECURITY_ATTRIBLJTES lpsaThread,

BOQL flnheritHandles,

DWORD fdwCreate,

LPVOID lpvEnvironrnent,

LPCTSTR lpszcurdir,

LPSTARTUPINFO lpsistartlnfo,

LPPROCESS_INFQRMATION

Esta función crea un nuevo proceso y su proceso ligero principal. El nuevo proceso
ejecuta el archivo ejecutable especificado en lpszlmageName. Esta cadena puede
especificar el nombre de un archivo con camino absoluto o relativo, pero la función
no utilizará el camino de búsqueda. Si lpszlmageName es NULL, se utilizará como
nombre de archivo ejecutable la primera cadena delimitada por blancos del
argumento lpszCommandLine.

El argumento lpszCommandLine especifica la línea de mandatos a ejecutar,

incluyendo el nombre del programa a ejecutar. Si su valor es NULL, la función
utilizará la cadena apuntada por lpszlmageNarne como línea de mandatos. El
nuevo proceso puede acceder a la línea de mandatos utilizando los parámetros
argc y argv de la función main de C.

El argumento lpsaProcess determina si el manejador asociado al proceso creado y

devuelto por la función puede ser heredado por otros procesos hijos. Si es NJJLL,
el manejador no puede heredarse. Lo mismo se aplica para el argumento
lpsaThread, pero relativo al manejador del proceso ligero principal devuelto por la
funcion.
El argumento flnheritHandles indica si el nuevo proceso hereda los manejadores
que mantiene el proceso que realiza la llamada. Si su valor es TRUE, el nuevo
proceso hereda todos los manejadores, con los mismos privilegios de acceso, que
tenga abiertos el proceso padre.

El argumento fdwCreate puede combinar varios valores que determinan la prioridad

y la creación del nuevo proceso.

Programa 3.20. Programa que crea un proceso que ejecuta la línea de mandatos
pasada como argumento.

#include <windows.h> #include <stdio.h>

void main(int argc, char argv)

STARTUPINFO si; PRUCESSINFORMATION pi;

i f (!Createprocess

NULL, /~ utiliza la línea de mandatos */

argv [1], NTJLL, NULL, FALSE, o, NULL, NTJLL, &s1, &pj)

/~‘ línea de mandatos pasada como argumentos */ /* manejador del proceso no

heredable*/ /* manejador del thread no heredable */ /* no hereda manejadores */

/* sin flags de creación */

/* utiliza el entorno del proceso */

/~ utiliza el directorio de trabalo del padre */

printf <“Error al crear el proceso. Error: %x\n”, GetLastError <)>; ExitProcess<O>

/* el proceso acaba ~/ exit (O)

Terminación de procesos

Los servicios relacionados con la terminación de procesos se agrupan en dos

categorías: servicios para finalizar la ejecución de un proceso y servicios para
esperar la terminación de un proceso. Estos servicios se describen a continuación:
a) Terminar la ejecución de un proceso

Un proceso puede finalizar su ejecución de forma voluntaria de tres formas:

 Ejecutando dentro de la función main la sentencia return.

 Ejecutando el servicio Exitprocess.
 La función de la biblioteca de C exit. Esta función es similar a ExitProcess.

El prototipo de la función ExitProcess es el siguiente:

 VOID ExitProcess <UINT nExitCode);

La llamada cierra todos los manejadores abiertos por el proceso y especifica el

código de salida del proceso. Este código lo puede obtener otro proceso mediante
el siguiente servicio:

 BOOL GetExitCodeprocess <HANDLE hProcess, LPDWQRD

lpdwExitCode);

Esta función devuelve el código de terminación del proceso con manejador

hProcess. El proceso especificado por hProcess debe tener el acceso
PROCESSQUERYINFORIVIATION (veáse OpenProcess). Si el proceso todavía
no ha terminado, la función devuelve en lpdwExitCode el valor STILL_ALIVE en
caso contrario almacenará en este valor el código de terminación.

Además, un proceso puede finalizar la ejecución de otro mediante el servicio:

 BOOLTerminateProcess <HANDLEhProcess, UlNTuExitCode);

Este servicio aborta la ejecución del proceso con manejador hProcess. El código
de terminación para el proceso vendrá dado por el argumento uExitCode. La
función devuelve TRUE si se ejecuta con éxito.

b) Esperar por la finalización de un proceso

En Win32 un proceso puede esperar la terminación de cualquier otro proceso

siempre que tenga permisos para ello y disponga del manejador correspondiente.
Para ello, se utilizan las funciones de espera de propósito general, las cuales
también se tratarán en el Capítulo 5. Estas funciones son:

 DWORD WaitForSingleObject(HANDLE høbject, D~PJQRD dwTimeOut);

 DWORD WaitForMultipleObjects(DWORD cobjects, LPHANDLE
lphObjects, BOOL fWaitAll, DWORD dwTimeout>;
La primera función bloquea al proceso hasta que el proceso con manejador hObject
finalice su ejecución. El argumento dwTimeOut especifica el tiempo máximo de
bloqueo expresado en rnilisegundos. Un valor de O hace que la función vuelva
inmediatamente después de comprobar si el proceso finalizó la ejecución. Si el
valor es INFINITE, la función bloquea al proceso hasta que el proceso acabe su
ejecución.

La segunda función permite esperar la terminación de varios procesos. El

argumento cObj ects especifica el número de procesos (el tamaño del vector
1phob~ects) por los que se desea esperar. El argumento lphObjects es un vector
con los manejadores de los procesos sobre los que se quiere esperar. Si el
parámetro fWaitAll es TRUE, entonces la función debe esperar por todos los
procesos, en caso contrario la función vuelve tan pronto como un proceso haya
acabado. El paráme1ro dwTimeOut tiene el significado descrito anteriormente.

El Programa 3.21 crea un proceso que ejecuta el programa pasado en la línea de

mandatos. El programa espera a continuación a que el proceso hijo termine
imprimiendo su código de salida.

#include <windows. h> #include <stdio.h>

void main(int argc, char arqv)

STARTUPINFO si; PROCESS_INFORMATION pi;

IDWORD code;

if (!Createprocess( NTJLL, argv[l], /*

NULL, NULL, FALSE, Q NULL, NULL,

&sj, &pi))
utiliza la línea de mandatos */

línea de mandatos pasada como argumentos */ manejador del proceso no

heredable*/ manejador del thread no heredable */ no hereda manejadores */

sin flags de creación */ utiliza el entorno del proceso */ utiliza el directorio de trabajo
del padre */

printf (“Error al crear el proceso. Error: %x\n”, GetLastError W; ExitProcess(O);

/“ Espera a que el proceso creado acabe */ WaitForSingleObject(pi.hProcess,

INFINITE);

/‘~ Imprime el código de salida del proceso hijo */ if <!GetExitCodeProcess

(pi.hProcess, &code) printf (“Error al acceder al codigo. Error: %x\n”, GetLastError
W;

ExitProcess (O>

printf(”codigo de salida del proceso %d\n”, code); ExitProcess(O);

Referencias bibliográficas:

JESUS CARRETERO PEREZ, F. G. (2001). SISTEMAS OPERATIVOS una vision

aplicada (primera edicion en español ed.). (C. F. Madrid, Ed.) MEXICO:
 AREA DE INFORMATICA Y COMPUTACION. Recuperado el 09 de mayo
de 2019.

William Stallings. (1997). SISTEMAS OPERATIVOS. Madrid: PEARSON

EDUCACIÓN, S.A. Recuperado el 09 de mayo de 2019.