Procesos, hilos y estados

Abrir las diapositivas de apoyo: Procesos, hilos y estados (pantalla completa)

Un sistema multitarea necesita decidir qué programa usa la CPU y cuándo. Para hacerlo no administra “aplicaciones” de forma abstracta, sino procesos concretos.

3.1. Qué es un proceso

Un programa es un conjunto de instrucciones almacenado, por ejemplo un ejecutable en el disco. Un proceso es ese programa cuando está siendo ejecutado, junto con su contexto: memoria asignada, registros, estado, archivos abiertos y recursos asociados.

Abrir dos veces el mismo editor puede crear dos procesos diferentes. Comparten el mismo programa de origen, pero cada uno mantiene su propio estado.

3.2. Procesos e hilos

Un proceso puede contener uno o varios hilos. Los hilos de un mismo proceso comparten recursos como la memoria del proceso, pero cada hilo tiene su propia secuencia de ejecución.

Un navegador puede usar hilos para atender la interfaz, reproducir contenido y realizar operaciones de red. El objetivo es mejorar la respuesta o aprovechar varios núcleos, aunque compartir datos obliga a coordinarse correctamente.

Elemento	¿Tiene un espacio de direcciones independiente?	Recursos compartidos	Uso típico
Proceso	Sí, normalmente.	Puede compartir recursos autorizados con otros procesos.	Ejecutar aplicaciones aisladas.
Hilo	No; utiliza el del proceso, aunque mantiene pila y contexto propios.	Comparte memoria y otros recursos con los hilos del mismo proceso.	Dividir tareas de una aplicación.

3.3. Estados de un proceso

Para estudiar este modelo supondremos procesos con un único hilo. En un proceso multihilo, cada hilo puede estar listo, ejecutándose o bloqueado de forma independiente: bloquear uno no bloquea necesariamente los demás.

Con esta simplificación, distinguimos cinco estados:

• Nuevo: se está creando.
• Listo: puede usar la CPU, pero espera turno.
• En ejecución: está utilizando una CPU.
• Bloqueado: espera un evento, normalmente una operación de entrada/salida.
• Terminado: ha finalizado o ha sido cancelado.

El sistema operativo tiene que decidir cuál de los procesos listos recibe CPU. El componente que toma esa decisión se llama planificador. Por eso, en el diagrama, estar listo no equivale a estar en ejecución: hace falta ser seleccionado. En el bloque 04 estudiaremos las reglas que puede seguir para elegir.

Ejemplo: pedir un número y mostrar su doble. Queremos ejecutar un programa que solicite un número por teclado, lo multiplique por dos, muestre el resultado y termine. Introduciremos 21, por lo que esperamos ver 42 en pantalla. Llamaremos P1 al proceso que se crea al abrir este programa.

Para observar los estados, suponemos un único núcleo y procesos con un solo hilo. Tardaremos un poco en introducir el número: como la lectura es bloqueante, P1 tendrá que esperar hasta que haya entrada disponible. Además, supondremos que agota un turno de CPU antes de mostrar el resultado, para ilustrar también esa transición.

Ahora seguimos paso a paso cómo el sistema operativo gestiona P1 mientras realiza esta operación, recorriendo las flechas del diagrama:

1. Nuevo → listo, por admisión. Al abrir el programa, el sistema operativo crea P1 y prepara sus recursos. Cuando está disponible para ejecutar, lo incorpora al conjunto de procesos listos. Todavía no utiliza la CPU.
2. Listo → en ejecución, por selección. El planificador selecciona P1 y el sistema le da CPU. P1 ejecuta las instrucciones que solicitan el número.
3. En ejecución → bloqueado, por espera de E/S. P1 intenta leer, pero aún no hemos introducido el dato. El sistema lo bloquea hasta que haya entrada disponible y puede dar CPU a otro proceso listo.
4. Bloqueado → listo, por evento completado. Introducimos 21 y confirmamos la entrada. Cuando el sistema dispone del dato solicitado, devuelve P1 al estado listo. P1 puede continuar, pero debe esperar a que el planificador lo seleccione.
5. Listo → en ejecución, por una nueva selección. P1 recibe CPU, continúa tras la espera y calcula el doble: 42.
6. En ejecución → listo, por fin de turno. Suponemos que su turno se agota antes de mostrar el resultado. Aunque podría continuar, el sistema lo devuelve a listo para dar paso a otro proceso. Esta vez espera CPU, no un dato.
7. Listo → en ejecución → terminado. Cuando vuelve a ser seleccionado, P1 retoma la ejecución, muestra 42 y finaliza. El sistema libera sus recursos.

La diferencia entre los pasos 3 y 6 es la causa de la espera: P1 está bloqueado cuando le falta la entrada y listo cuando solo le falta recibir CPU. El paso 4 tampoco salta directamente a ejecución: completar el evento permite competir por un turno.

Un proceso bloqueado no está esperando CPU: está esperando que ocurra algo externo, como que termine una lectura de disco. Si el sistema ejecutara solo ese proceso, la CPU quedaría desaprovechada; por eso el planificador lo sustituye temporalmente por otro listo.

3.3.1. Qué prepara el sistema al crear un proceso: el PCB

Ampliación

En el ejemplo anterior hemos dicho que el sistema «crea P1 y prepara sus recursos». Esto implica algo más que abrir el archivo del programa: el sistema debe organizar su memoria y guardar información para identificarlo, conocer su estado y poder detenerlo y reanudarlo.

Para entenderlo, distinguimos dos elementos:

• El espacio de memoria del proceso. El sistema prepara un espacio de direcciones para sus instrucciones, sus datos y su pila, donde se conserva información de las llamadas a funciones. No significa reservar de golpe una cantidad fija de RAM para todo el programa: la memoria puede asignarse conforme se necesita, como veremos en el bloque 05.
• El bloque de control de proceso, también llamado PCB por Process Control Block. Es una estructura de datos que mantiene el núcleo del sistema operativo para administrar el proceso. Ocupa memoria del sistema y contiene información de control y referencias a sus recursos.

El PCB y las estructuras asociadas permiten registrar:

Información	Para qué la necesita el sistema
Identificador del proceso (PID)	Distinguirlo de los demás, incluso si ejecutan el mismo programa.
Estado e información de planificación	Saber si está listo, ejecutándose o bloqueado y gestionar su selección, por ejemplo mediante una prioridad.
Contexto de CPU guardado	Conservar el contador de programa, los registros y el puntero de pila para poder reanudar la ejecución. El contador de programa indica por dónde continuar; el puntero de pila permite localizar la posición actual en la pila.
Referencias de memoria	Localizar las estructuras que describen el espacio de direcciones del proceso.
Referencias a archivos y otros recursos	Saber qué archivos tiene abiertos y qué recursos utiliza, incluidos los que pueda heredar al crearse.

El diagrama separa el registro de control, a la izquierda, de lo que permite gestionar, a la derecha. Las flechas representan referencias: el contenido del archivo o todos los datos del programa no se copian dentro del PCB. Este es un modelo conceptual; cada sistema distribuye la información en estructuras concretas y, en procesos multihilo, mantiene también información de ejecución propia de cada hilo.

Volvamos a P1: al crearlo, el sistema le asigna un PID, prepara su memoria e inicializa la información de control. Mientras ejecuta, utiliza los registros reales de la CPU. Cuando debe detenerse para esperar el número, el sistema guarda el contexto necesario en las estructuras de control y actualiza su estado a bloqueado. Así podrá reanudarlo después sin empezar el programa desde el principio. Este es el fundamento del cambio de contexto que veremos a continuación.

Referencia técnica: OSTEP, capítulo 4: The Abstraction: The Process.

3.4. Colas, bloqueo y cambio de contexto

Ampliación

Los procesos listos se sitúan en una cola de preparados. El planificador elige uno para la CPU. Cuando el proceso agota su turno, se bloquea o termina, el sistema guarda la información necesaria para retomar su ejecución más tarde y carga la del siguiente: es el cambio de contexto.

Podemos seguir el mecanismo con una lectura de teclado que todavía no dispone de entrada. Suponemos una lectura bloqueante y otro proceso listo:

El diagrama se lee de arriba abajo. Cada fila muestra quién usa la CPU, quién espera turno en la cola de preparados y quién espera entrada en la cola de bloqueados. Las colas son estructuras que mantiene el sistema operativo; aquí representamos solo la espera de teclado. Entre las dos primeras filas se produce el cambio de contexto, que podemos descomponer así:

1. El proceso lector solicita el dato y no puede continuar. El sistema conserva el contexto necesario para reanudarlo, como su contador de programa y registros.
2. El sistema lo sitúa en estado bloqueado, a la espera de entrada. Ya no es candidato a recibir CPU.
3. El planificador selecciona otro proceso de la cola de preparados.
4. El sistema recupera el contexto del seleccionado y este continúa desde donde había quedado.

Cuando llega una pulsación, el lector pasa a listo. Para volver a ejecutar, tendrá que ser seleccionado y recuperar su contexto. El mismo cambio de contexto puede deberse a otra causa: si vence un turno y queda trabajo pendiente, el proceso saliente vuelve a listo, en vez de quedar bloqueado. Si termina, se liberan sus recursos y no habrá que reanudarlo.

Un cambio de contexto tiene coste. Durante ese tiempo la CPU no avanza trabajo útil de la aplicación, sino que el sistema prepara el cambio. Por ello, los turnos demasiado cortos pueden perjudicar el rendimiento global.

3.5. Concurrencia y paralelismo

Concurrencia significa que varias tareas progresan durante un mismo período; pueden alternarse en un solo núcleo. Paralelismo significa que se ejecutan al mismo tiempo en distintos recursos de ejecución. Añadir núcleos no exige inventar estados nuevos en el modelo: permite que más de un hilo esté en ejecución simultáneamente.

Cada hilo mantiene su contador de programa, registros y pila. Comparte con los demás hilos del proceso el espacio de direcciones y otros recursos. Compartir facilita cooperar, pero también obliga a coordinar el acceso a datos; estudiar sincronización avanzada pertenece a otras materias.

3.6. Un proceso espera datos

RA2.b.

En esta actividad vas a seguir dos procesos para distinguir esperar un dato de esperar un turno de CPU. El objetivo es explicar cómo puede avanzar uno mientras el otro espera una operación de entrada/salida (E/S).

Imagina un equipo con un único núcleo y dos procesos, cada uno con un solo hilo:

• P1 procesa el contenido de un archivo. Para continuar, necesita leer del disco un bloque de datos que todavía no está disponible en memoria.
• P2 realiza un cálculo y tiene todo lo necesario para continuar; solo necesita que el sistema le asigne CPU.

La lectura de P1 es bloqueante: no puede seguir con su trabajo hasta recibir los datos solicitados. Los acontecimientos ocurren en este orden:

1. Situación inicial. P1 está utilizando la CPU. P2 todavía no tiene CPU y espera su turno.
2. Petición de lectura. P1 solicita el bloque al disco. Como los datos aún no han llegado, no puede continuar. El sistema conserva su contexto y da CPU a P2, que empieza a calcular mientras el dispositivo realiza la lectura.
3. Llegada de los datos. El disco termina la lectura y el sistema dispone ya del bloque que necesita P1. En este caso, el planificador mantiene a P2 en la CPU hasta que termine su turno; P1 todavía no reanuda sus instrucciones.
4. Reparto del siguiente turno. P2 agota su turno, aunque le queda cálculo pendiente. El planificador selecciona P1 y el sistema restaura su contexto para que continúe procesando el archivo.

Completa la tabla. En cada fila, indica el estado de ambos procesos después de que haya ocurrido lo descrito en ese momento. Utiliza los estados del apartado 3.3 y, en «Motivo», explica qué espera cada proceso o por qué puede ejecutar.

Momento	Estado de P1	Estado de P2	Motivo
P1 ejecuta; P2 espera CPU
P1 solicita lectura; P2 recibe CPU
Termina la lectura; P2 sigue ejecutando
P2 agota turno; se selecciona P1

Después, dibuja la secuencia de estados por los que pasa P1 desde la situación inicial hasta que vuelve a ejecutar. Une los estados con flechas e indica sobre cada una qué acontecimiento provoca el cambio. No añadas creación ni finalización: el escenario comienza con P1 ejecutándose y termina cuando retoma su trabajo.

Entrega la tabla y el esquema, junto con una explicación breve de esta pregunta: cuando el disco termina la lectura, ¿qué impedimento ha desaparecido para P1 y qué le falta todavía para volver a ejecutar? Se comprobará que distingues la espera de datos de la espera de CPU y que relacionas cada transición con su causa.

3.7. Programa, proceso e hilo

RA2.b.

Reutilizarás este producto en la práctica integrada de funcionamiento del SO, apartado 6.8; no tiene una nota ni una entrega separadas.

Un mismo editor se abre en dos instancias independientes. Una instancia utiliza un hilo para la interfaz y otro para una tarea de cálculo. Explica cuántos procesos describe el escenario, qué comparten los dos hilos y qué mantienen por separado. Razona si estos hilos pueden progresar en un solo núcleo y qué cambia si hay dos. Entrega un esquema y un párrafo; no necesitas administrar procesos ni usar comandos.

Los estados permiten saber quién puede usar CPU. En el siguiente bloque aplicaremos reglas para decidir a quién dar el turno.