Procesos e hilos

Un programa en disco es un archivo. Cuando se ejecuta se vuelve un proceso: memoria propia, registros, archivos abiertos, una identidad ante el sistema. Los hilos son flujos de ejecución dentro de ese mismo espacio, y esa única diferencia explica todo lo demás.

El proceso y su espacio aislado

Un proceso tiene su propio espacio de direcciones, aislado del resto. Contiene el código, los datos globales, el heap donde vive lo reservado dinámicamente y la pila.

El sistema operativo guarda por proceso un bloque de control: identificador, estado, registros salvados, tabla de páginas, archivos abiertos, permisos. Ese bloque es lo que se guarda y restaura en cada cambio de contexto, y es el objeto que el planificador manipula.

Listo, en ejecución y bloqueado

Un proceso pasa por tres estados principales: listo —podría correr y espera CPU—, en ejecución y bloqueado —esperando que termine una operación de E/S o un evento—.

Esa distinción importa para diagnosticar. Un sistema con procesos bloqueados no gana nada con más CPU: el cuello de botella está en el disco o en la red. Un sistema con muchos listos sí está limitado por procesador. Es la primera lectura útil frente a una máquina lenta.

Los hilos comparten memoria, y ahí está todo

Los hilos de un mismo proceso comparten el espacio de direcciones: ven las mismas variables globales y el mismo heap. Cada uno tiene lo mínimo propio: registros, contador de programa y su pila.

De ahí sale todo. Crear un hilo es mucho más barato que crear un proceso, y comunicarse entre hilos es tan simple como escribir una variable. Y por eso mismo, un error en un hilo puede corromper la memoria de todos, y aparecen las condiciones de carrera: dos hilos escribiendo lo mismo sin coordinación.

Crear un proceso: fork y exec

En sistemas tipo Unix, crear un proceso es fork, que duplica el actual, seguido en general de exec, que reemplaza la imagen por otro programa. La copia se hace con copia al escribir: las páginas se comparten hasta que alguien las modifique, así que duplicar no cuesta lo que parece.

El proceso hijo queda vinculado al padre, que debe recoger su código de salida. Si no lo hace, queda un proceso zombi: una entrada en la tabla que ya no ejecuta nada. Es la razón por la que un contenedor necesita un proceso inicial que adopte huérfanos.

Comunicar procesos requiere mecanismos explícitos

Como los procesos están aislados, comunicarlos requiere mecanismos explícitos: tuberías, colas de mensajes, sockets, memoria compartida, señales. Todos pasan por el núcleo, y por eso cuestan más que compartir una variable entre hilos.

Ese costo es también la garantía: un proceso no puede corromper la memoria de otro por accidente. La elección entre procesos e hilos es, en el fondo, entre aislamiento y costo de comunicación. Los navegadores eligieron procesos por pestaña justamente por aislamiento, aceptando el gasto.

Concurrencia sin hilos del sistema

Hay un tercer camino cada vez más común: concurrencia sin hilos del sistema. Corrutinas, hilos virtuales o bucles de eventos multiplexan muchas tareas lógicas sobre pocos hilos reales.

Sirve cuando las tareas pasan la mayor parte del tiempo esperando E/S, que es el caso típico de un servidor. No sirve para trabajo intensivo de CPU: ahí hacen falta hilos o procesos de verdad, uno por núcleo. Confundir los dos casos es el error más frecuente al elegir un modelo de concurrencia.

Qué modelo de concurrencia elegir

Cierre

Proceso es aislamiento con memoria propia; hilo es un flujo dentro de la misma memoria, barato de crear y peligroso de compartir. El estado bloqueado frente al listo dice si falta CPU o si se espera E/S, y la concurrencia liviana sirve para esperar, no para calcular.