El bloque de control de proceso

1. Qué es el PCB

El bloque de control de proceso, o PCB (process control block), es la estructura de datos en la que el núcleo guarda toda la información que necesita para administrar un proceso: su identidad, su estado, su posición en la CPU, su memoria, sus archivos abiertos, sus señales pendientes, su padre y sus hijos, sus tiempos de ejecución y sus límites de recursos. Mientras el proceso vive, el núcleo mantiene un PCB para él; cuando el proceso termina, el PCB se libera.

La idea aparece en los primeros sistemas operativos por una necesidad práctica: el núcleo tiene que poder detener un proceso en cualquier instante y reanudarlo más tarde exactamente donde estaba. Para eso necesita recordar, en algún lugar, todo lo que el proceso estaba haciendo y todo lo que poseía. Ese lugar es el PCB. Sin él, el núcleo no sabría como retomar un proceso después de haberle quitado la CPU.

Por eso se dice que para el núcleo un proceso «es» su PCB: todo lo que el sistema hace con un proceso —ejecutarlo, suspenderlo, enviarle una señal, cobrarle tiempo de CPU, matarlo— pasa por leer o modificar la estructura que lo representa. El programa que corre en el espacio de usuario no ve el PCB directamente; solo ve los efectos de lo que el núcleo hace con él.

2. Para que lo usa el núcleo

El núcleo consulta y modifica el PCB en muchos momentos de la vida de un proceso. Los principales son:

Todos esos accesos ocurren en modo núcleo, mientras el proceso está ejecutándose o mientras el núcleo decide que proceso ejecutar. El programa del usuario nunca toca el PCB: solo ve las consecuencias, como el valor que devuelve getpid() o el hecho de que un malloc haya funcionado.

3. Los campos de un PCB

Aunque la implementación varía entre sistemas, todo PCB guarda, como mínimo, la siguiente información. Se puede agrupar en seis categorías:

Identidad

• PID: el número que identifica al proceso.
• PPID: el PID del padre.
• UID y GID: el usuario y el grupo con cuyos permisos se ejecuta.
• Nombre: el nombre corto del programa (comm).

Estado y planificación

• Estado: si el proceso está en ejecución, listo, bloqueado, detenido o terminado (temas 6 y 7).
• Prioridad y nice: que tan urgente es ejecutarlo frente a otros.
• Punteros a colas: en que cola de planificación está (cola de listos, cola de espera de un evento).
• Tiempo de CPU usado: cuánto tiempo de procesador ha consumido.

Memoria

• Puntero a las tablas de páginas: la estructura que traduce las direcciones virtuales del proceso a direcciones físicas de la RAM.
• Límites de memoria: cuánta memoria puede usar (stack máximo, heap máximo, etc.).
• Punteros al código, datos, heap y stack: las direcciones de las zonas de su espacio de direcciones (tema 2).

Recursos y archivos

• Tabla de archivos abiertos: los descriptores de archivo (0, 1, 2, y los que abrió con open).
• Directorio de trabajo actual: cwd.
• Directorio raíz: para procesos enjaulados (chroot).
• Variables de entorno: el entorno que heredó al crearse.
• Límites de recursos: rlimit para número de archivos, tamaño de archivos, procesos por usuario, etc.

Señales

• Máscara de señales bloqueadas: cuáles no se pueden entregar ahora.
• Señales pendientes: las que llegaron pero aún no se manejaron.
• Manejadores registrados: que función se ejecuta cuando llega cada señal.

Jerarquía y sincronización

• Puntero al padre: para enviarle señales y notificarle cuando termina.
• Lista de hijos: para esperarlos con wait o recorrerlos.
• Puntero al grupo de procesos y a la sesión: para el control de la terminal.
• Mutex y semáforos: cuando el proceso usa sincronización.

Es una lista larga, y es deliberadamente así: el PCB es la estructura más importante del núcleo en lo que respecta a la administración de procesos. Todo lo que el sistema necesita saber de un proceso está ahí o se alcanza desde ahí.

4. task_struct en linux

En linux el PCB se llama task_struct, y está definido en el código fuente del núcleo en include/linux/sched.h. Es una de las estructuras más grandes y más importantes del núcleo: tiene miles de líneas de definición y contiene punteros a decenas de otras estructuras. No es un bloque contiguo simple, sino un nodo central que apunta a subestructuras especializadas.

Esta es una versión muy simplificada, con los campos que más se mencionan. Los nombres reales en el código del núcleo son exactamente estos:

struct task_struct {
    /* Identidad */
    pid_t               pid;
    pid_t               tgid;          /* thread group id */
    struct task_struct  *parent;       /* padre */
    struct list_head     children;      /* lista de hijos */
    struct list_head     sibling;      /* hermanos */

    /* Estado y planificación */
    volatile long       state;         /* TASK_RUNNING, TASK_INTERRUPTIBLE, ... */
    int                 prio;          /* prioridad dinámica */
    int                 static_prio;   /* prioridad estática (nice) */
    struct sched_entity se;            /* datos del planificador */

    /* Memoria */
    struct mm_struct    *mm;           /* espacio de direcciones */
    struct mm_struct    *active_mm;    /* mm activo en la CPU */

    /* Archivos y sistema de archivos */
    struct files_struct *files;        /* tabla de archivos abiertos */
    struct fs_struct    *fs;           /* cwd, root, umask */

    /* Señales */
    struct signal_struct *signal;      /* señales compartidas del grupo */
    struct sighand_struct *sighand;    /* manejadores de señales */
    sigset_t            blocked;       /* señales bloqueadas */
    sigset_t            pending;       /* señales pendientes */

    /* Tiempos y contabilidad */
    u64                 utime;         /* tiempo en modo usuario */
    u64                 stime;         /* tiempo en modo núcleo */
    struct timespec64   start_time;    /* cuándo se creó */

    /* Credenciales */
    const struct cred   *cred;         /* UID, GID, capacidades */

    /* Registros guardados (al hacer cambio de contexto) */
    struct thread_struct thread;       /* registros de la CPU */

    /* ... cientos de campos más ... */
};

Varias observaciones sobre esta estructura:

• No guarda todo directamente. Campos como mm, files o signal son punteros a otras estructuras. Así, cuando dos hilos de un mismo proceso comparten memoria y archivos, apuntan a las mismas subestructuras en lugar de duplicarlas.
• El estado es un número, no una cadena. Linux usa constantes como TASK_RUNNING (0), TASK_INTERRUPTIBLE (1) o TASK_UNINTERRUPTIBLE (2). La letra que muestra ps (R, S, D) es una traducción de ese número.
• Los registros de la CPU viven en thread. Cuando el proceso es desalojado, el núcleo guarda ahí el estado de los registros, incluido el contador de programa y el puntero de pila.
• La estructura es enorme. En un núcleo moderno, task_struct ocupa varios kilobytes. Por eso el núcleo no crea una para cada hilo si no es necesario, y por eso la asignación y liberación de procesos es una operación costosa.

5. El puntero current y el acceso al PCB

Mientras un proceso se está ejecutando en modo núcleo, el código del núcleo necesita saber a que proceso corresponde la ejecución actual. Para eso existe el puntero current, una variable (en realidad una macro) que apunta al task_struct del proceso que está corriendo en la CPU actual.

Por eso, dentro del núcleo, obtener el PID del proceso actual es tan simple como current->pid, y obtener su padre es current->parent->pid. La función getpid() que usa un programa en C termina llamando al núcleo, que devuelve current->tgid (el PID del grupo de hilos, que es el que el usuario ve).

El puntero current se implementa de forma distinta según la arquitectura. En x86-64, se guarda en un registro especial del procesador (el gs base) o se deriva de la pila del núcleo. La idea es que, dada la pila actual, se puede calcular la dirección del task_struct restando un desplazamiento fijo, porque el núcleo reserva la estructura del proceso justo debajo de su pila de núcleo.

Desde el espacio de usuario no se puede acceder a current ni a task_struct. El único camino es pedirle al núcleo que exponga los datos, y eso es exactamente lo que hace /proc: cada archivo de /proc/PID es una ventana controlada a los campos del task_struct correspondiente.

6. El PCB y el cambio de contexto

El cambio de contexto, que viste en el tema 1, es la operación en la que el núcleo detiene un proceso, guarda su estado y carga el de otro. El PCB es el lugar donde se guarda y se restaura ese estado.

Cuando el núcleo desaloja un proceso, hace, entre otras cosas:

1. Guarda los registros de la CPU en el campo thread del task_struct del proceso que sale: el contador de programa, el puntero de pila, los registros generales.
2. Actualiza el estado del proceso en su PCB: de «en ejecución» a «listo» o «bloqueado», según corresponda.
3. Cambia las tablas de páginas para que la CPU use las del nuevo proceso: así, las direcciones virtuales del nuevo proceso se traducen a su propia memoria física.
4. Carga los registros desde el task_struct del nuevo proceso.
5. Actualiza current para que apunte al nuevo proceso.
6. Salta a la instrucción indicada por el contador de programa restaurado.

Todo esto ocurre en modo núcleo, en unos pocos microsegundos. El proceso que fue desalojado no se entera de nada: cuando vuelve a ejecutarse, sus registros están exactamente como los dejó, y continúa desde la misma instrucción. Esa ilusión de continuidad es la que hace posible el tiempo compartido.

7. El PCB y la creación de procesos

Cuando se llama a fork(), el núcleo crea un proceso nuevo. Lo que hace, en términos del PCB, es:

1. Reserva un task_struct nuevo y un PID nuevo.
2. Copia los campos del padre al hijo: estado, prioridad, punteros a memoria, archivos abiertos, señales, credenciales. Es una copia superficial: los punteros apuntan a las mismas subestructuras.
3. Marca al hijo como distinto: le cambia el PID, le pone el PPID igual al PID del padre, le pone el estado «listo» y le prepara un valor de retorno de fork de 0.
4. Crea una copia del espacio de direcciones del padre para el hijo, usando copia en escritura (tema 13). El campo mm del hijo apunta a una nueva estructura que comparte las mismas páginas físicas hasta que uno de los dos las modifique.
5. Agrega el hijo a la lista de hijos del padre y lo pone en la cola de listos.

Por eso fork es relativamente barato: no copia toda la memoria, solo el PCB y las estructuras de control. La memoria se comparte hasta que se modifica. Y por eso el hijo «hereda» tantas cosas del padre: archivos abiertos, directorio de trabajo, variables de entorno, manejadores de señales. Todo eso está en el PCB o en las subestructuras a las que apunta.

Cuando el proceso termina con exit(), el núcleo no libera el PCB inmediatamente: lo marca como «zombi», guarda el código de salida y avisa al padre. El PCB se libera solo cuando el padre llama a wait() y lee ese código. Ese es el tema 24.

8. Consultar el PCB desde /proc

Cómo el usuario no puede tocar task_struct directamente, el núcleo expone sus campos a través de /proc/PID. Cada archivo de ese directorio es una ventana a una parte del PCB o de las subestructuras a las que apunta. Los más directos son:

El archivo stat es el más completo para programas: una sola línea con todos los campos numéricos, pensado para ser leído por scripts. El archivo status es el mismo contenido pero en formato legible por humanos, con etiquetas. La mayoría de las herramientas (ps, top) leen stat y status para mostrar la información.

$ cat /proc/self/stat
448 (cat) S 402 402 402 34816 448 4194304 107 0 0 0 0 0 0 0 20 0 1 0 12345 5652480 188 18446744073709551615 94000000000000 940000000000 7ffd... 0 0 0 0 0 0 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0

El primer campo es el PID, el segundo el nombre entre paréntesis, el tercero el estado, el cuarto el PPID. El resto son campos numéricos que corresponden a los campos de task_struct. Por eso ps y top no necesitan llamadas al sistema especiales: solo leen este archivo.

9. PCB en distintos sistemas

La idea de PCB es universal, pero cada sistema la implementa a su manera. Las diferencias principales:

La diferencia más importante entre linux y windows es que linux usa una sola estructura para procesos e hilos (un hilo es solo un proceso que comparte memoria con otros), mientras que windows los trata como entidades distintas desde el principio. Por eso, en linux, fork y la creación de un hilo usan el mismo mecanismo (clone), y la diferencia está en que se comparte.

10. Un programa que lee su propio PCB

El siguiente programa muestra como un proceso puede consultar su propio PCB a través de /proc. No puede leer task_struct directamente, pero puede leer los archivos que el núcleo genera a partir de ella:

#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void)
{
    pid_t pid = getpid();

    printf("=== PCB del proceso %d (via /proc) ===\n\n", (int) pid);

    /* status: identidad y estado */
    char ruta[64];
    snprintf(ruta, sizeof ruta, "/proc/%d/status", (int) pid);
    FILE *f = fopen(ruta, "r");
    if (f) {
        char linea[256];
        while (fgets(linea, sizeof linea, f)) {
            if (strncmp(linea, "Name:", 5) == 0 ||
                strncmp(linea, "Pid:", 4) == 0 ||
                strncmp(linea, "PPid:", 5) == 0 ||
                strncmp(linea, "State:", 6) == 0 ||
                strncmp(linea, "Threads:", 8) == 0 ||
                strncmp(linea, "Vmsize:", 7) == 0 ||
                strncmp(linea, "VmRSS:", 6) == 0) {
                fputs(linea, stdout);
            }
        }
        fclose(f);
    }

    /* stat: tiempos de CPU */
    snprintf(ruta, sizeof ruta, "/proc/%d/stat", (int) pid);
    f = fopen(ruta, "r");
    if (f) {
        unsigned long utime, stime;
        int p, pp;
        char comm[64], state;
        /* campos: pid comm state ppid ... utime stime ... */
        fscanf(f, "%d %63s %c %d", &p, comm, &state, &pp);
        /* saltar hasta utime (campo 14) y stime (campo 15) */
        for (int i = 0; i < 9; i++) fscanf(f, "%*s");
        fscanf(f, "%lu %lu", &utime, &stime);
        printf("\ntiempo en modo usuario: %lu ticks\n", utime);
        printf("Tiempo en modo núcleo:  %lu ticks\n", stime);
        fclose(f);
    }

    /* limits: límites de recursos */
    printf("\n--- Límites de recursos (/proc/PID/limits) ---\n");
    snprintf(ruta, sizeof ruta, "/proc/%d/limits", (int) pid);
    f = fopen(ruta, "r");
    if (f) {
        char linea[256];
        while (fgets(linea, sizeof linea, f)) {
            if (strncmp(linea, "Max open files", 14) == 0 ||
                strncmp(linea, "Max processes", 13) == 0 ||
                strncmp(linea, "Max stack size", 14) == 0) {
                fputs(linea, stdout);
            }
        }
        fclose(f);
    }

    printf("\ncomprueba con: cat /proc/%d/status\n", (int) pid);
    return 0;
}

El programa lee tres archivos de /proc: status para la identidad y el estado, stat para los tiempos de CPU y limits para los límites de recursos. Cada uno de esos datos vive en el task_struct del proceso, y el núcleo los formatea al leerlos. Es un ejemplo de como un programa puede inspeccionar su propio PCB sin privilegios especiales.

11. Resumen

• El PCB es la estructura donde el núcleo guarda todo lo que sabe de un proceso; para el sistema, un proceso «es» su PCB.
• Guarda identidad (PID, PPID, UID), estado y planificación, memoria (tablas de páginas, zonas), recursos (archivos, cwd, entorno, límites), señales y jerarquía (padre, hijos).
• En linux el PCB es task_struct, una estructura grande que apunta a subestructuras compartidas entre hilos.
• El puntero current apunta al task_struct del proceso que se ejecuta en la CPU actual.
• El cambio de contexto guarda y restaura los registros en el campo thread del PCB.
• fork copia el PCB del padre y crea un espacio de direcciones nuevo con copia en escritura.
• /proc/PID expone los campos del PCB: status, stat, maps, fd, limits, entre otros.
• Windows usa EPROCESS/KPROCESS; Linux y los sistemas tipo unix usan una estructura unificada para procesos e hilos.

12. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Compila y ejecuta leer_pcb.c, y compara su salida con cat /proc/PID/status y cat /proc/PID/stat.
2. Mientras un programa está corriendo, mira ls -l /proc/PID/fd y cat /proc/PID/limits.
3. Usa cat /proc/PID/wchan mientras un proceso está dormido (por ejemplo, dentro de sleep) y observa el nombre de la función del núcleo.
4. Ejecuta strace -e trace=process ./un_programa y observa las llamadas al sistema que crean y modifican el PCB.
5. Compara el tamaño de task_struct en tu sistema con el comando grep task_struct /proc/kallsyms o revisando el código fuente del núcleo.
6. Escribe un programa que abra varios archivos y luego imprima el contenido de /proc/self/fd para ver la tabla de archivos abiertos.