Hilos en C: pthreads y el hilo estándar

Un hilo no es una función que corre a la vez que otra: es un flujo de ejecución con su propia pila y su propio juego de registros, pero con acceso indiscriminado a toda la memoria del proceso. Lo primero que conviene interiorizar no es la llamada que lo crea, sino dónde está exactamente la frontera entre lo privado y lo compartido, porque de esa frontera salen todos los errores de las tres lecciones siguientes.

Dos APIs sobre el mismo hardware

En C conviven dos interfaces de hilos y no son alternativas equivalentes. pthreads es de 1995, vive en pthread.h, forma parte de POSIX y está en todos los Unix. Los hilos de C11 viven en threads.h, forman parte de la norma del lenguaje y son opcionales: una implementación conforme puede no ofrecerlos y anunciarlo definiendo la macro __STDC_NO_THREADS__.

#if defined(__STDC_NO_THREADS__)
#  include <pthread.h>          /* plan B: POSIX */
#else
#  include <threads.h>          /* hilos de la norma */
#endif

La diferencia práctica es de disponibilidad y de potencia. glibc implementa threads.h desde la versión 2.28 y musl también, en ambos casos como una capa finísima sobre la misma maquinaria de pthreads. La libc de Apple no lo trae, y en Windows llegó tarde. Del otro lado, pthreads ofrece atributos de creación —tamaño de pila, política de planificación, estado de separación—, cancelación, mutex robustos y afinidad de núcleo; la API de C11 no ofrece nada de eso. No tiene atributos en absoluto.

/* C11: el punto de entrada devuelve int y recibe void * */
int trabajador(void *arg);
thrd_t h;
thrd_create(&h, trabajador, &datos);

/* POSIX: el punto de entrada devuelve void * y recibe void * */
void *trabajador_posix(void *arg);
pthread_t p;
pthread_create(&p, nullptr, trabajador_posix, &datos);

Hay un detalle que confunde a casi todo el mundo la primera vez: pthread_create devuelve 0 en éxito y un número de error en caso contrario —no toca errno—, mientras que thrd_create devuelve thrd_success, y la norma no garantiza que thrd_success valga cero. Comparar contra cero es un error de portabilidad silencioso.

El ciclo de vida de un hilo

Un hilo nace ejecutable, corre y termina de una de tres formas: retornando de su función de entrada, llamando a thrd_exit, o muriendo con el proceso entero. Al terminar entra en uno de dos estados según se creara unible o separado.

flowchart LR
A[thrd create] --> B[Ejecutando]
B --> C[Retorno o thrd exit]
C --> D[Terminado y unible]
D --> E[thrd join recoge el codigo]
C --> F[Terminado y separado]
F --> G[Recursos liberados solos]
B -.-> H[thrd detach renuncia al resultado]
style E fill:#a6e3a1,color:#11111b
style G fill:#89b4fa,color:#11111b

Un hilo unible que nadie une deja su bloque de control vivo para siempre: es una fuga de recursos del sistema que ni valgrind clasifica de forma obvia. Un hilo separado libera lo suyo al morir, pero pierdes toda posibilidad de saber cuándo lo hizo o qué devolvió.

thrd_t h;
if (thrd_create(&h, trabajador, &datos) != thrd_success)
    return 1;

int codigo;
thrd_join(h, &codigo);      /* bloquea hasta que termine; recoge el int */

Tres reglas que la norma marca como comportamiento indefinido si las rompes: unir dos veces el mismo hilo, unir un hilo separado, y separar un hilo ya unido. Y una cuarta que sorprende: thrd_t no tiene por qué ser un entero, así que no puedes imprimirlo; para compararlo existe thrd_equal.

El hilo principal es especial. Si main retorna, el proceso entero termina y todos los demás hilos mueren de golpe, en mitad de lo que estuvieran haciendo, sin desenrollar nada. Si lo que quieres es que main se aparte pero los demás sigan, la salida correcta es thrd_exit, que termina ese hilo sin terminar el proceso.

Pasar datos y recogerlos

El error clásico de todo el que empieza cabe en cuatro líneas y no es un fallo de sintaxis sino una carrera:

for (int i = 0; i < N; i++)
    thrd_create(&h[i], trabajador, &i);   /* MAL: todos ven la misma i */

Los hilos reciben la dirección de una variable que el bucle está modificando y que además muere al salir de él. El resultado no es que cada hilo vea un valor equivocado, sino que el programa tiene una carrera de datos y por tanto comportamiento indefinido. La corrección es dar a cada hilo un objeto propio cuya vida sobrepase claramente la del hilo:

typedef struct { int id; const double *entrada; size_t n; double parcial; } Tarea;

Tarea tareas[N];                       /* vive en main, que hace el join */
for (int i = 0; i < N; i++) {
    tareas[i] = (Tarea){ .id = i, .entrada = datos, .n = n };
    thrd_create(&h[i], trabajador, &tareas[i]);
}
for (int i = 0; i < N; i++)
    thrd_join(h[i], nullptr);          /* aqui, y solo aqui, parcial es legible */

Fíjate en dónde queda el resultado: cada hilo escribe en su casilla, así que no hay dos hilos tocando la misma memoria, y el thrd_join establece la relación de orden que permite al hilo principal leer lo escrito sin sincronización adicional. Unir un hilo no es solo esperar: es un punto de sincronización con todas las garantías de visibilidad que veremos en la lección de atómicos.

La vía de retorno es más pobre de lo que parece. C11 solo te deja devolver un int; POSIX te deja devolver un void *, y ahí la tentación es devolver la dirección de una variable local, que para cuando el join la recoge ya no existe. Si vas a devolver algo grande por esa vía, tiene que estar en el montón y el que une es quien libera.

Estado propio del hilo e inicialización única

No todo el estado quiere compartirse. C23 convierte thread_local en una palabra clave del lenguaje —antes era una macro de threads.h para _Thread_local— y con ella cada hilo obtiene su propia copia de la variable, inicializada al arrancar.

thread_local int profundidad = 0;      /* una copia por hilo, sin sincronizar */
static thread_local char buffer[256];  /* util para formateo temporal */

errno funciona exactamente así desde hace décadas, y por eso una llamada fallida en un hilo no pisa el código de error de otro. La limitación de thread_local en C es que no hay destructores: si la copia del hilo posee memoria del montón, nadie la libera al morir el hilo. Para eso existe el almacenamiento específico con tss_create, que sí acepta una función de limpieza, o pthread_key_create en POSIX.

El otro problema recurrente es inicializar algo compartido exactamente una vez sin que dos hilos lo hagan a la vez. Escribirlo a mano con un booleano es una carrera de manual; la norma trae la primitiva hecha:

static once_flag inicializada = ONCE_FLAG_INIT;
static Registro *registro;

static void construir(void) { registro = registro_nuevo(); }

Registro *obtener(void) {
    call_once(&inicializada, construir);   /* exactamente una vez, en total */
    return registro;
}