Sistemas Operativos

Sesión 5: Definición, control y estados de un proceso

Cómo el kernel “ve” y gestiona la ejecución

Navegación: ← → | Home End | F pantalla completa

Plan de trabajo

0–10: Puente con Sesión 4 (RR, CS, Ready/Running/Blocked usados en la actividad).
10–30: Proceso vs programa: qué “instancia” el SO y por qué.
30–55: Control del proceso: PCB y contexto de CPU.
55–65: Pausa.
65–85: Estados y transiciones: modelo canónico + eventos que lo disparan.
85–105: Recorridos guiados (trazas) y casos: I/O, timer, excepciones, exit().
105–120: Actividad corta + socialización + exit ticket.

Propósito: formalizar qué es un proceso (vs programa), cómo se representa en el kernel (PCB), y cómo cambia de estado (New/Ready/Running/Blocked/Exit) ante eventos como interrupciones, excepciones y llamadas al sistema.

Al final podrás: (1) explicar por qué el SO necesita estados, (2) mapear eventos → transiciones, y (3) relacionar el diagrama de estados con lo que ya hiciste en scheduling (RR y context switch).

Nota de enfoque: hoy no “vemos código del kernel”; modelamos lo esencial para entender cómo el SO controla ejecución y cómo eso impacta scheduling y rendimiento.

Qué debe quedar claro hoy

Un proceso es una ejecución “con identidad” y contexto: no es solo el código.
El kernel necesita una estructura por proceso (PCB) para pausar y reanudar.
Los estados existen para decidir: “¿puede competir por CPU o no?”
Los eventos (timer, I/O, syscall, excepción) explican las transiciones.

Si entiendes esto, después FIFO/SJF/RR se vuelven “reglas sobre Ready” y no una lista de fórmulas sin sentido.

Evidencias

Completar una tabla de traza (estado → evento → estado) para 2 casos.
Explicar una transición usando el nombre correcto del evento (syscall/interrupt/exception).
Conectar “preempción” con Running → Ready y “I/O” con Running → Blocked.

Esto prepara la “Definición, control y estados de un proceso” y el puente con “Interrupciones, excepciones y llamadas” dentro de la unidad.

Programa ≠ Proceso

Un programa es el archivo en disco (código + recursos). Un proceso es la ejecución en memoria con contexto y recursos controlados por el sistema operativo.

Un mismo programa puede generar muchos procesos: por ejemplo, abrir dos veces el navegador crea dos ejecuciones distintas (dos “vidas”), aunque el archivo ejecutable sea el mismo.

Pregunta clave: ¿qué necesita el kernel para que dos ejecuciones no se “pisen”?

Ejemplo mental

Programa:  /usr/bin/python
Proceso A: python script1.py   (PID 1201)
Proceso B: python script2.py   (PID 1207)

Los dos comparten el "mismo programa",
pero NO comparten:
- PC / registros
- stack/heap
- archivos abiertos
- estado de ejecución

Componentes lógicos y recursos

Espacio de direcciones: código, datos, heap, stack.
Contexto de CPU: PC/IP, SP, registros, flags.
Recursos: archivos/sockets abiertos, permisos, credenciales.
Relación con el SO: estado actual, colas, contabilidad.

Si el kernel no separa estos componentes por proceso, cualquier multitarea sería inestable: un proceso podría continuar donde iba otro.

Qué “no es” un proceso

No es solo una ventana o una app visible (hay procesos en segundo plano).
No es solo “un hilo” (un proceso puede tener múltiples hilos).
No es el CPU: compite por CPU, pero no “lo contiene”.

En próximas sesiones se separará proceso vs hilo. Hoy nos quedamos en el proceso.

PCB: la ficha del proceso en el kernel

El PCB (Process Control Block) es la estructura de datos que el SO mantiene por proceso para poder gestionarlo: planificarlo, bloquearlo, reanudarlo, y finalmente terminarlo.

Identidad: PID, usuario, permisos.
Estado: New/Ready/Running/Blocked/Exit.
Contexto CPU: PC, SP, registros (lo mínimo para reanudar).
Scheduling: prioridad, punteros a colas, tiempos acumulados.
Memoria y archivos: mapas de memoria, descriptores abiertos.

Relación con “context switch”

Cambio de contexto (alto nivel):
1) save(Pactual.cpu_state)  -> PCB(Pactual)
2) select_next(Ready)       -> Pnext
3) load(PCB(Pnext))         -> CPU
4) return_to_user(Pnext)

En la sesión anterior modelaste el “costo” del cambio. Hoy entiendes qué se guarda y por qué.

Disparadores típicos

Interrupción de timer: habilita preempción (Running → Ready).
Interrupción de I/O: un dispositivo avisa “terminé” (Blocked → Ready).
Llamada al sistema: el proceso pide un servicio (ej. read, write, fork, exit).
Excepción: error o condición especial (división por cero, page fault).

Esta lista explica por qué el diagrama de estados no es “teoría”: es la traducción gráfica de eventos reales que ocurren en ejecución.

Idea clave

El proceso no “cambia de estado por voluntad propia”. Cambia porque ocurre un evento y el kernel decide qué hacer con él (encolarlo, bloquearlo, terminarlo, etc.).

Regla mental:
Evento -> handler del kernel -> decisión -> nuevo estado

Por qué existen dos modos

El SO necesita proteger el hardware y los datos entre procesos. Por eso separa: modo usuario (aplicaciones) y modo kernel (código privilegiado).

En modo usuario no se permite ejecutar instrucciones privilegiadas.
Una syscall (llamada al sistema) hace una transición controlada al kernel.
Al terminar el servicio, el kernel retorna al usuario.

Ejemplo

Aplicación:
  read(fd, buf, n)

Efecto:
  trap/syscall -> kernel -> driver/FS -> retorno

Si read() necesita disco:
  Running -> Blocked (espera I/O)
y luego:
  I/O interrupt -> Blocked -> Ready

Este ejemplo une: syscalls + estados + eventos (I/O interrupt).

Interrupciones, excepciones y llamadas al sistema

Tipo	Origen	Ejemplos	Efecto típico en estados
Interrupción	Hardware (asíncrona)	Timer tick, fin de I/O (disco/red)	Running → Ready (timer), Blocked → Ready (I/O)
Excepción	CPU/Proceso (sincrónica)	División por cero, page fault	Puede bloquear/esperar (page fault) o terminar (fatal)
Syscall	Proceso (intencional)	read, write, fork, exec, exit	Running → Blocked (I/O bloqueante) o Running → Exit

En la actividad: tu trabajo es tomar un enunciado y decidir “qué tipo de evento ocurrió”, para justificar cada transición en el diagrama.

Modelo canónico (5 estados)

New: el proceso se crea (PCB inicial, recursos básicos).
Ready: puede correr, está esperando turno de CPU.
Running: está ejecutando instrucciones en CPU.
Blocked/Waiting: no puede correr porque espera un evento (I/O).
Exit: terminó; el SO libera recursos (o deja “zombie” breve según el SO).

Regla central: Blocked no compite por CPU. Eso evita desperdiciar tiempo de CPU.

Ampliación (si aplica)

Algunos libros agregan estados “suspendidos” (Ready Suspended / Blocked Suspended) para modelar swapping o falta de memoria. Hoy nos quedamos con el modelo canónico.

Pregunta guía:
¿Un proceso bloqueado debería estar en Ready?
No: no puede avanzar aunque le des CPU.

Cómo leerlo

Cada rectángulo es un estado.
Cada flecha es una transición causada por un evento.
Tu objetivo no es memorizar el dibujo: es justificar flechas con eventos reales.

En la actividad vas a trazar rutas (recorridos) sobre este tipo de diagrama y escribir la tabla “estado → evento → estado”.

Diagrama de 5 estados de un proceso (español)

Imagen (ES) en Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Diagrama_de_estados5.PNG

Mapa de transiciones (versión operativa)

Transición	Qué significa	Evento típico	Ejemplo real
Ready → Running	El dispatcher asigna CPU	Decisión del scheduler	RR toma el primero de la cola Ready
Running → Ready	Se quita CPU (preempción)	Timer interrupt	Se venció el quantum
Running → Blocked	El proceso no puede seguir	Syscall bloqueante / espera	read() a disco o espera de red
Blocked → Ready	Ya puede competir por CPU	Interrupción de dispositivo	Disco termina y “despierta” al proceso
Running → Exit	Finaliza ejecución	exit() / return	El proceso terminó su trabajo

Observa: algunas transiciones dependen del hardware (timer/I-O) y otras del kernel (planificación).

Por qué el SO usa colas

Las colas son la forma simple de representar “quién espera qué”. La más importante para scheduling es Ready. Para I/O suelen existir colas por dispositivo.

Ready queue: procesos listos para ejecutar.
Device queue(s): procesos bloqueados por un dispositivo/evento.

Lo que cambia entre algoritmos (FIFO/SJF/RR) es principalmente cómo se elige desde Ready.

Diagrama mínimo

New -> Ready -> Running -> Exit
             |     |
             |     v
             |   Blocked
             |     |
             +-----+
           (I/O interrupt)

Este dibujo “explica” por qué Blocked no está en Ready: espera un evento externo.

Qué aporta esta imagen

Te recuerda que muchos eventos (sobre todo I/O) vienen de dispositivos que “hablan” con la CPU a través del chipset/buses. Esa “señal” es la interrupción que despierta procesos bloqueados.

En otras palabras: Blocked → Ready ocurre porque el hardware avisa “ya está”.

Diagrama de la comunicación entre componentes de un sistema de cómputo (español)

Imagen (ES) en Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Diagrama_de_la_comunicaci%C3%B3n_entre_componentes_de_un_sistema_de_c%C3%B3mputo.svg

Escenario: proceso con lectura a disco

“El proceso P es creado, obtiene CPU, necesita leer del disco, espera, vuelve a ejecutar y termina.”

Tu tarea al leer el escenario: detectar palabras clave (creado, obtiene CPU, espera disco, vuelve, termina) y mapearlas a estados + eventos.

Traza (modelo)

Paso	Estado	Evento	Nuevo estado
1	New	Creación finaliza	Ready
2	Ready	Dispatcher asigna CPU	Running
3	Running	Syscall read() bloqueante	Blocked
4	Blocked	Interrupción: I/O completada	Ready
5	Ready	Scheduler lo elige	Running
6	Running	exit()/return	Exit

Escenario: RR con preempción

“El proceso A está ejecutando, llega el timer (quantum), se preempta, vuelve a Ready y más tarde retoma.”

Aquí el evento que “manda” es el timer interrupt, no una decisión voluntaria del proceso.

Traza (modelo)

Paso	Estado	Evento	Nuevo estado
1	Ready	Scheduler lo elige	Running
2	Running	Timer interrupt (fin de quantum)	Ready
3	Ready	Más tarde, dispatcher lo re-elige	Running

En RR, esto se repite muchas veces. Cada repetición implica posible cambio de contexto.

Recorridos por casos (en parejas)

Elige 2 casos de la siguiente diapositiva.
Para cada caso: traza la ruta en el diagrama de estados y llena la tabla (paso/estado/evento/nuevo estado).
En 5 líneas: explica qué eventos fueron interrupciones, cuáles syscalls y si hubo excepciones.

Regla: si no puedes nombrar el evento, la transición no está justificada.

Entrega

Foto del diagrama marcado o copia en hoja.
Tabla de traza por caso (mínimo 6 pasos si hay I/O).
Explicación breve: “por qué Blocked existe” y “qué hace el timer”.

Checklist:
- ¿Usaste New y Exit?
- ¿Identificaste syscalls de I/O?
- ¿Nombraste el I/O interrupt?
- ¿Ubicaste el timer interrupt?

Selecciona 2 (o asigna por filas)

Caso A (I/O): P corre, hace read() a disco, queda esperando, vuelve a Ready al completar I/O y termina.
Caso B (preempción): P corre y es preemptado dos veces por timer (RR), sin I/O.
Caso C (exit normal): P corre y finaliza con exit()/return sin bloquearse.
Caso D (excepción fatal): P provoca división por cero y el SO lo termina (Running → Exit).
Caso E (page fault discutible): P accede a memoria no residente, ocurre page fault; discute si se bloquea brevemente o si termina (según política simplificada).

Para E: si aún no han visto memoria virtual, puedes tratarlo como “excepción manejable” que produce espera corta (Blocked) y retorno a Ready.

Preguntas para consolidar

¿Qué transición es “decisión del scheduler” y cuál depende del hardware?
¿Por qué Blocked no debería competir por CPU?
¿Cómo se conecta Running → Ready con el “quantum” de RR de la sesión anterior?
¿Qué parte del PCB explica que un proceso retome justo “donde iba”?

Si puedes responder estas preguntas, ya tienes el modelo mental que sostiene planificación, sincronización y rendimiento.

Responde (individual)

En una frase: diferencia entre programa y proceso.
Menciona 4 campos del PCB y explica para qué sirve 1 de ellos.
Da un ejemplo de transición Running → Blocked y nombra el evento.
Explica por qué el timer interrupt es esencial para scheduling preemptivo.

Entrega esperada: respuestas cortas, pero con términos correctos (estado, evento, transición).

Próxima sesión

Volvemos a planificación con más formalismo: algoritmos (FIFO, SJF, RR) + métricas (waiting, turnaround, throughput) y comparación de eficiencia en escenarios simulados.

Con lo de hoy, podrás explicar “por qué” una métrica cambia: porque cambia cuánto tiempo pasan los procesos en Ready, Running o Blocked.