Procesos e hilos — ejercicios tipo examen con estados que trazar, fork() que contar e hilos que lo comparten casi todo (y el «Hola» que salió ocho veces)

Respuesta: Un programa en ejecución, con los recursos que el SO le asigna

Un proceso es un programa en ejecución: el código más todo lo que hace falta para ejecutarlo (memoria, registros, PC, archivos abiertos y tiempo de CPU). El mismo programa puede dar lugar a varios procesos a la vez.

• V — Para ejecutarse, un proceso necesita memoria principal, tiempo de CPU y dispositivos de E/S.
• F — Un proceso nuevo se crea mediante una rutina de servicio de interrupción.
• V — Dos procesos pueden estar ejecutando el mismo programa al mismo tiempo.
• F — Un programa guardado en el disco es una entidad activa.
• V — Los procesos compiten por el tiempo de CPU y por las zonas de memoria.

Necesita memoria principal (la RAM), no secundaria: el disco guarda el programa, pero para ejecutarlo hay que cargarlo en RAM.

Un proceso se crea con una llamada al sistema (fork o CreateProcess), no con una rutina de interrupción. Y abrir dos terminales con bash da dos procesos del mismo programa.

• text → El código máquina del programa
• data → Las variables globales y estáticas
• heap → La memoria que se pide con malloc
• stack → Variables locales, parámetros y direcciones de retorno

De abajo arriba: text (código), data (globales), heap (memoria dinámica, crece hacia arriba) y stack (pila, crece hacia abajo). Los registros no están en ninguna zona de memoria: viven en la CPU y, cuando el proceso sale, en su PCB.

Respuesta: text y data

text y data salen del ejecutable; heap y stack se crean y crecen mientras el proceso se ejecuta.

Respuesta: El estado del proceso · El contador de programa · Una copia de los registros de la CPU · Los archivos abiertos y el estado de E/S

El PCB guarda: estado, PC, registros, información de planificación (prioridad, tiempo esperando), de memoria, de E/S y archivos, y contable (tiempo de CPU consumido, PID). Ojo: es múltiple con penalización, así que marcar el código o las locales resta.

• Nuevo → El SO acaba de crearlo y aún no lo ha admitido
• Preparado → Lo tiene todo y solo espera a que le den la CPU
• En ejecución → Está en la CPU ejecutando instrucciones
• Bloqueado → Espera a que ocurra un evento, como el fin de una E/S
• Terminado → No ejecutará más y el SO le retira los recursos

La pareja que más se confunde es preparado frente a bloqueado: preparado espera a la CPU; bloqueado espera a otra cosa (el disco, la red, un hijo). Aunque le dieras la CPU a uno bloqueado, no podría avanzar.

Respuesta: Bloqueado

Pedir una E/S lleva de ejecución a bloqueado. Cuando el disco termine, una interrupción lo pasará a preparado.

Respuesta: Preparado

Preparado = esperando a que le asignen un procesador. Está en la cola de preparados, y el despachador lo elegirá cuando le toque.

• F — Un proceso bloqueado pasa directamente a ejecución cuando termina su E/S.
• V — Un proceso en ejecución vuelve a preparado cuando salta el temporizador.
• F — Un proceso preparado puede pasar a bloqueado sin haberse ejecutado.
• V — Un proceso nuevo pasa a preparado cuando el SO lo admite.
• F — Un proceso terminado puede volver a preparado si el usuario lo pide.

Las seis flechas son: nuevo → preparado, preparado → ejecución, ejecución → preparado, ejecución → bloqueado, bloqueado → preparado y ejecución → terminado.

Para bloquearse hay que pedir algo (una E/S, un wait), y eso solo se puede hacer ejecutando instrucciones. Por eso a bloqueado solo se llega desde ejecución, y de bloqueado solo se sale a preparado: al terminar la E/S vuelve a la cola, no a la CPU.

Orden correcto:

1. bash hace fork(): el hijo nace en estado nuevo
2. El SO lo admite y lo pone en la cola de preparados
3. El despachador le da la CPU: pasa a ejecución
4. Pide el archivo al disco: pasa a bloqueado
5. La interrupción del disco lo devuelve a preparado
6. Vuelve a la CPU y termina con exit(0)

nuevo → preparado → ejecución → bloqueado → preparado → ejecución → terminado. Fíjate en el quinto paso: tras la E/S no vuelve a la CPU directamente, sino a la cola de preparados.

Paso 1: pedir E/S lleva de ejecución a bloqueado; B sigue preparado porque nadie lo ha elegido todavía (eso es el paso 2).

Paso 3: la interrupción solo despierta a A (a preparado); B sigue en la CPU. Paso 4: el temporizador saca a B a preparado, y en ese momento los dos están en la cola. En cada fila hay como mucho un proceso en ejecución: solo hay una CPU.

El SO organiza los PCB en colas de espera por el procesador o por los dispositivos de E/S. Las colas se implementan con listas enlazadas, tablas o árboles, y el planificador inserta y extrae procesos de cada cola según su política.

Lo que se mueve de cola en cola no es el proceso entero sino su PCB. Cada recurso (la CPU, cada disco) tiene su cola, y la política de planificación decide el orden.

• Corto plazo (PCP) → Asigna y quita la CPU a los procesos preparados
• Largo plazo (PLP) → Decide qué trabajos entran en la cola de preparados
• Medio plazo (PMP) → Si la RAM está saturada, lleva al disco procesos bloqueados

El PCP trabaja continuamente; el PLP, de vez en cuando (en sistemas por lotes o granjas de servidores) para conseguir una buena mezcla de trabajos; el PMP hace intercambio (swapping) cuando falta memoria.

Respuesta: El de corto plazo

Corto, medio y largo hablan de cada cuánto actúan: el de corto plazo, constantemente.

Respuesta: intercambio

Intercambio (swapping), y lo hace el planificador de medio plazo.

• V — Consiste en sacar un proceso de la CPU y reanudar otro.
• V — El estado del proceso que sale se guarda en su PCB.
• F — Se realiza en modo usuario para que sea más rápido.
• V — Mientras dura, ningún proceso de usuario avanza.
• F — El contexto del proceso desalojado se guarda en la memoria secundaria.

Es trabajo del SO, así que se hace en modo núcleo; el contexto va al PCB, que está en memoria principal. Es tiempo perdido, y por eso el hardware ofrece instrucciones para guardar y cargar registros de golpe (PUSHA/POPA en x86, LDM/STM en ARM).

Respuesta: despachador

El despachador (dispatcher). No lo confundas con el planificador: el planificador decide quién va a la CPU; el despachador hace el cambio.

Respuesta: Su PID

Cada proceso tiene un PID único, y como cada uno lo crea otro (su padre), se forma un árbol de procesos con systemd (PID 1) en la raíz.

• V — Padre e hijo ejecutan el mismo código.
• F — Padre e hijo usan la misma zona de memoria: si el hijo cambia una variable, el padre ve el cambio.
• V — Los archivos que el padre tenía abiertos quedan compartidos con el hijo.
• F — fork() devuelve 0 en el padre.
• F — Todo proceso se crea escribiendo una orden en la terminal.

El hijo es un duplicado del padre: mismo código, pero su propia copia de la memoria. Si el hijo hace contador++, el padre sigue con su valor. Los archivos abiertos sí se comparten.

fork() devuelve 0 al hijo y el PID del hijo al padre. Y no todo nace en la terminal: cualquier proceso puede crear otros con una llamada al sistema (systemd crea los servicios al arrancar).

• fork() → Crea un hijo que es un duplicado del padre
• exec() → Sustituye el código del proceso por otro ejecutable
• wait() → Espera a que termine un hijo
• exit() → Termina el proceso que la llama
• kill() → Aborta otro proceso
• CreateProcess() → Crea en Windows un proceso indicando su ejecutable

En Unix, crear un proceso que ejecute otro programa son dos pasos: fork() (duplicar) y exec() (cambiar el código). En Windows, CreateProcess() lo hace en uno, indicando el ejecutable.

Respuesta: Ninguno: el proceso 3151 sigue siendo el mismo, con el código de gcc

exec() conserva el PID, el PCB y los archivos abiertos, y cambia el código y los datos por los del nuevo programa. Si exec() funciona, nunca vuelve: el código que la llamó ya no existe.

Fila 1: el primer fork() deja 2 procesos y los dos hacen el segundo: 2 × 2 = 4. Fila 2: cada vuelta duplica a todos, 2⁴ = 16, y los 16 imprimen.

Fila 3: solo el hijo (al que fork() devuelve 0) hace el segundo fork(): original + hijo + nieto = 3. Fila 4: tras el primer fork() hay 2 procesos; cada uno crea un hijo con el segundo fork() (ya son 4), pero esos dos hijos hacen exit(0) antes del printf: solo imprimen los 2 primeros.

Respuesta: El PID del hijo que acaba de crear

Un fork(), dos vueltas: el padre recibe el PID del hijo y el hijo recibe 0. Por eso el típico if (pid == 0) separa lo que hace cada uno.

• V — Un proceso termina cuando llama a exit().
• F — Un proceso solo puede terminar si otro le envía kill().
• V — Si provoca una excepción, el SO puede decidir abortarlo.
• F — Un hijo termina en el momento en que su padre llama a wait().
• F — Un proceso zombi sigue ejecutando instrucciones indefinidamente.

Termina con exit(), porque lo aborta otro con kill() o porque el SO lo aborta tras una excepción. wait() no mata a nadie: el padre espera a que el hijo acabe.

Un zombi ya terminó: no ejecuta nada, solo conserva su entrada (PID y estado de salida) hasta que el padre la recoja con wait().

Respuesta: Memoria compartida · Paso de mensajes

Dos modelos: memoria compartida y paso de mensajes. Los mecanismos concretos (tuberías, sockets, RPC…) son formas de implementarlos.

Dos procesos pueden comunicarse mediante tuberías (pipes), sockets, zonas de memoria compartida, llamadas a procedimiento remoto (RPC) o, la forma menos eficiente, ficheros normales.

Los ficheros funcionan, pero cada intercambio pasa por el disco: por eso son el mecanismo más lento. Tuberías y sockets son paso de mensajes.

• V — El contador de programa
• V — La pila (y su puntero de pila)
• V — Los registros de la CPU
• F — Las variables globales
• F — Los archivos abiertos
• F — El código del programa

Lo propio de un hilo es lo que hace falta para ejecutar por su cuenta: PC, registros, pila y su tiempo de CPU. Código, datos, archivos y recursos de E/S son del proceso y se comparten.

Respuesta: Crear un hilo cuesta menos que crear un proceso · Se comunican más fácilmente, porque comparten la memoria · Consiguen más concurrencia con menos recursos · Cambiar de un hilo a otro del mismo proceso puede ser más rápido

Las cuatro primeras son los beneficios de los apuntes. Precisamente por compartir memoria, crear hilos es más barato que crear procesos, y no al revés.

• Muchos a uno → Muchos hilos de usuario sobre un solo hilo del núcleo; si uno se bloquea, se bloquean todos
• Uno a uno → Cada hilo de usuario tiene su hilo del núcleo; es el de Linux y Windows
• Muchos a muchos → Muchos hilos de usuario repartidos sobre varios hilos del núcleo
• Dos niveles → Como muchos a muchos, pero permite unir un hilo de usuario a uno del núcleo

Muchos a uno es el más antiguo (Solaris Green Threads, GNU Portable Threads) y casi no se usa: no aprovecha varios núcleos. Uno a uno da más concurrencia, a costa de limitar a veces el número de hilos.

Respuesta: Se bloquea el proceso pesado entero

Con hilos de usuario, el núcleo no sabe que el proceso tiene concurrencia interna: si un hilo se bloquea, se bloquea todo. Por eso hoy lo normal son los hilos del núcleo.

Respuesta: ligero

Proceso ligero (lightweight process), frente al proceso pesado, que es la aplicación entera con uno o varios hilos. A los hilos también se les llama hebras.

Respuesta modelo:

Un programa es un fichero ejecutable en el disco: una entidad pasiva. Un proceso es un programa en ejecución: una entidad activa que el SO crea con una llamada al sistema y a la que asigna recursos (memoria principal, CPU, E/S). Un mismo programa puede dar lugar a varios procesos.

La memoria de un proceso tiene cuatro zonas: text (código), data (variables globales), heap (memoria dinámica, que crece hacia arriba) y stack (pila con locales, parámetros y direcciones de retorno, que crece hacia abajo). text y data se copian del ejecutable.

El PCB es la estructura del SO con su estado, contador de programa, registros, información de planificación, de memoria, de E/S y archivos, y contable (PID, tiempo de CPU). Gracias a él el SO puede sacar el proceso de la CPU y reanudarlo después.

Si te falta tiempo, prioriza la definición y los campos del PCB: son lo que más se pregunta.

Respuesta modelo:

Estados: nuevo, preparado, en ejecución, bloqueado y terminado. Transiciones: nuevo → preparado (el SO lo admite); preparado → ejecución (el despachador lo elige); ejecución → preparado (interrupción, por ejemplo el temporizador); ejecución → bloqueado (pide una E/S o espera un evento); bloqueado → preparado (termina la E/S u ocurre el evento); ejecución → terminado (exit o aborto).

No existe bloqueado → ejecución porque cuando llega el evento puede haber otro proceso usando la CPU, y quien decide quién la usa es el planificador de corto plazo, que elige entre los preparados. El proceso despertado entra en la cola de preparados y espera su turno como los demás.

Un dibujo limpio con las flechas etiquetadas suele valer más que un párrafo largo.

Respuesta modelo:

bash llama a fork(): el SO crea un hijo, duplicado de bash, con un PID nuevo. fork() devuelve el PID del hijo a bash y 0 al hijo. El hijo tiene el mismo código y una copia propia de la memoria, y comparte los archivos abiertos (la terminal).

El hijo llama a exec() con gcc: su código y sus datos se sustituyen por los de gcc, pero sigue siendo el mismo proceso, con el mismo PID. Mientras, bash llama a wait() y pasa a bloqueado.

Cuando gcc termina de compilar, llama a exit(0). Queda como zombi (ya no ejecuta, solo guarda su estado de salida) hasta que wait() de bash lo recoge. Entonces bash pasa a preparado, vuelve a la CPU y enseña el prompt.

Es la secuencia de cada orden que escribes en la terminal; si la cuentas con un ejemplo concreto se entiende mucho mejor.

Respuesta modelo:

Un hilo (hebra o proceso ligero) es la unidad básica de ejecución dentro de un proceso. Cada hilo tiene su propio contador de programa, registros, pila y tiempo de CPU. Comparte con los demás hilos el código, los datos (variables globales, heap) y los recursos del SO (archivos abiertos, E/S).

Ventajas: se crean más rápido que los procesos, se comunican fácilmente porque comparten memoria, dan más concurrencia con menos recursos y cambiar de hilo puede ser más barato (no hay que vaciar cachés ni cambiar tablas de páginas).

Los hilos de usuario los gestiona una biblioteca y el núcleo no los conoce. En el modelo muchos a uno, todos van sobre un único hilo del núcleo: si uno hace una llamada bloqueante se bloquea el proceso entero, y no pueden ejecutarse en paralelo en varios núcleos. Por eso hoy se usa sobre todo el modelo uno a uno (Linux, Windows).

Un esquema de un proceso con tres hilos (como el de spotify del artículo de teoría) resume media respuesta.