PDF de programación - Procesos y Threads

2



PROCESOS Y THREADS





Vamos a embarcarnos ahora en un estudio detallado de cómo están diseñados y
construidos los sistemas operativos. El concepto fundamental en cualquier sistema operativo es
el concepto de proceso que consiste en una abstracción de lo que es un programa en ejecución.
Todo lo demás depende de este concepto y es importante que el diseñador del sistema operativo
(y el estudiante) comprenda lo antes posible lo que es un proceso.


2.1 PROCESOS


Todos los ordenadores modernos pueden hacer varias cosas a la vez. Mientras un
ordenador está ejecutando un programa de usuario puede perfectamente también estar leyendo
de un disco e imprimiendo texto en una pantalla o una impresora. En un sistema
multiprogramado la CPU también conmuta de unos programas a otros, ejecutando cada uno de
ellos durante decenas o cientos de milisegundos. Aunque, estrictamente hablando, en cualquier
instante de tiempo la CPU sólo está ejecutando un programa, en el transcurso de 1 segundo ha
podido estar trabajando sobre varios programas, dando entonces a los usuarios la impresión de
un cierto paralelismo. En este contexto a veces la gente habla de pseudoparalelismo, en
contraste con el auténtico paralelismo del hardware de los sistemas multiprocesador (que
tienen dos o más CPUs compartiendo la misma memoria física). Seguir la pista de múltiples
actividades paralelas resulta muy complicado para las personas. Por ese motivo los diseñadores
del sistema operativo han desarrollado a través de los años un modelo conceptual evolucionado
(el de los procesos secuenciales) que permite tratar el paralelismo de una forma más fácil. Este
modelo, sus usos, y algunas de sus consecuencias constituyen el tema de este capítulo.


2.1.1 El Modelo de los Procesos Secuenciales


En este modelo, todo el software ejecutable en el ordenador, incluyendo a veces al
propio sistema operativo, se organiza en un número de procesos secuenciales, o simplemente
procesos para acortar. Un proceso es justamente un programa en ejecución, incluyendo los
valores actuales del contador de programa, registros y variables. Conceptualmente cada proceso
tiene su propia CPU virtual. En realidad, por supuesto, la CPU real conmuta sucesivamente de
un proceso a otro, pero para entender el sistema, es mucho más fácil pensar sobre una colección
de procesos ejecutándose en (pseudo) paralelo, que intentar seguir la pista de cómo la CPU
conmuta de un programa a otro. Esta rápida conmutación de un proceso a otro en algún orden se
denomina multiprogramación como vimos en el capítulo 1.


En la Figura 2-1(a) vemos un ordenador multiprogramado con cuatro programas en
memoria. En la Figura 2-1(b) vemos cuatro procesos cada uno con su propio flujo de control (es
decir su propio contador de programa lógico), y cada uno ejecutándose independientemente de
los otros. Por supuesto que existe un único contador de programa físico, por lo que cada vez que
un proceso retoma su ejecución, su contador de programa lógico debe cargase en el contador de
programa real. Cuando el proceso agota el intervalo de tiempo que se le ha concedido, se salva



1

su contador de programa físico en su contador de programa lógico en memoria. En la Figura 2-
1(c) vemos que desde la perspectiva de un intervalo de tiempo suficientemente largo, todos los
procesos han progresado, pero que en cualquier instante dado solamente un único proceso está
realmente ejecutándose.

Un único contador
de programa

Cuatro contadores de programa

Cambio de
proceso



o
s
e
c
o
r
P

Tiempo



Figura 2-1. (a) Multiprogramación de cuatro programas. (b) Modelo
conceptual de cuatro procesos secuenciales independientes. (c) Sólo un
programa está activo en cada momento.







Con la CPU conmutando de un proceso a otro, la velocidad a la cual un proceso realiza
su computación no es uniforme y probablemente ni siquiera es reproducible si los mismos
procesos se ejecutan de nuevo. Por ese motivo los procesos no deben programarse bajo
suposiciones preconcebidas sobre su velocidad de ejecución. Consideremos, por ejemplo, un
proceso de E/S que restaura los ficheros de un backup en cinta. El proceso comienza poniendo
en marcha la cinta, ejecuta 10.000 veces un bucle para esperar a que la cinta adquiera la
velocidad adecuada, y en ese preciso momento envía un comando para leer el primer registro de
la cinta. Si la CPU decide conmutar a otro proceso durante el bucle de retardo, el proceso de la
cinta puede no volver a ejecutarse antes de que el primer registro sobrepase la cabeza de lectura.
Cuando un proceso tiene requerimientos de tiempo real críticos como el anterior, esto es, que
ciertos sucesos particulares deben ocurrir dentro de un número de milisegundos especificado,
entonces es necesario tomar medidas especiales para asegurar que efectivamente esos sucesos
ocurran dentro de esos límites de tiempo. Sin embargo, normalmente la mayoría de los procesos
no se ven afectados por la multiprogramación subyacente de la CPU o por las velocidades
relativas de los diferentes procesos.


La diferencia entre un proceso y un programa es sutil, pero crucial. Para explicar esto
puede servirnos de ayuda una analogía. Consideremos un científico informático con aptitudes
culinarias que está preparando una tarta de cumpleaños para su hija. Para ello dispone de una
receta de la tarta de cumpleaños y una cocina bien surtida con todos los ingredientes: harina,
huevos, azúcar, extracto de vainilla, etc. En esta analogía, la receta representa el programa (es
decir un algoritmo expresado mediante alguna notación apropiada), el científico informático
representa el procesador (CPU), y los ingredientes de la tarta representan los datos de entrada.
El proceso es la actividad consistente en nuestro pastelero leyendo la receta, añadiendo los
ingredientes y preparando la tarta.


Imaginemos ahora que el hijo del científico informático entra corriendo y gritando,
diciendo que le ha picado una abeja. El científico informático apunta por donde iba en la receta
(salva el estado del proceso actual), coge un libro de primeros auxilios y comienza a seguir las
instrucciones para la cura. Aquí vemos cómo el procesador conmuta de un proceso (preparar la
tarta) a un proceso de mayor prioridad (administrar cuidados médicos), cada uno de los cuales
sigue un programa diferente (la receta frente al libro de primeros auxilios). Una vez que termina
de curar la picadura de la abeja, el científico vuelve a su tarta, continuando en el punto donde la
dejó.



2

La idea clave aquí es que un proceso es una actividad de algún tipo. Tiene un programa,

entrada, salida y un estado. Un único procesador puede compartirse entre varios procesos
utilizando un algoritmo de planificación que determine cuándo hay que detener el trabajo sobre
un proceso y pasar a atender a otro diferente.


2.1.2 Creación de Procesos


Los sistemas operativos necesitan asegurar de alguna forma que puedan existir todos los
procesos necesarios. En sistemas muy sencillos, o en sistemas diseñados para ejecutar tan solo
una única aplicación (por ejemplo el controlador de un microondas), puede conseguirse que
cuando el sistema termine de arrancar estén presentes ya todos los procesos que puedan
necesitarse en el futuro. Sin embargo, en sistemas de propósito general es necesaria alguna
manera de poder crear y destruir los procesos según sea necesario durante la operación del
sistema. Vamos a fijarnos ahora en algunas de estas cuestiones.




Los cuatro principales sucesos que provocan la creación de nuevos procesos son:

1. La inicialización del sistema







2. La ejecución por parte de un proceso (en ejecución) de una llamada al sistema de

creación de un nuevo proceso.

3. La petición por parte del usuario de la creación de un nuevo proceso.

4. El inicio de un trabajo en batch.


Cuando un sistema operativo arranca, se crean típicamente varios procesos. Algunos de esos
procesos son procesos de superficie (o en primer plano), esto es, procesos que interactúan con
los usuarios (humanos) y realizan trabajo para ellos. Otros son procesos de fondo (o en segundo
plano), que no están asociados con usuarios particulares, sino que tienen alguna función
específica. Por ejemplo, un proceso de fondo puede diseñarse para que se encargue de aceptar el
correo electrónico entrante, de manera que esté durmiendo la mayor parte del día pero vuelva
repentinamente a la vida tan pronto como llegue algún correo. Otro proceso de fondo puede
diseñarse para aceptar peticiones entrantes de páginas web residentes en esa máquina,
despertándose cada vez que llegue una nueva petición para servir una cierta página. Los
procesos que se ejecutan como procesos de fondo para llevar a cabo alguna actividad tal como
el correo electrónico, las páginas web, las news o la impresión de ficheros de salida, etc, se
denominan demonios. Los sistemas grandes tienen comúnmente docenas de ellos. En UNIX, el
programa ps puede utilizarse para listar los procesos que están en marcha. En Windows
95/98/Me tecleando CTRL-ALT-SUPR una vez, se muestra todo lo que está en marcha. En
Windows 2000 se utiliza el administrador de tareas.


Adicionalmente a los procesos creados en el momento del arranque, también pueden
crearse nuevos procesos después. A menudo un proceso en ejecución puede hacer llamadas al
sistema para crear uno o más procesos nuevos para que le ayuden en su trabajo. Crear nuevos
p