Unidad 1: Gestión de procesos — de “eventos” (timer) a “turnos de CPU”.
Resultado esperado hoy: podrás explicar (1) por qué el timer habilita la preempción, (2) cómo funciona un cambio de contexto y (3) por qué el quantum es un trade-off.
Navegación: ← → | Home End | F pantalla completa
Tip didáctico: hoy no buscamos memorizar algoritmos, buscamos entender “qué información necesita el kernel” para repartir CPU de forma justa y eficiente.
El timer interrupt le permite al kernel recuperar el control *periódicamente*, incluso si el proceso en CPU no “coopera”.
Idea clave: si el kernel puede interrumpir y decidir, entonces puede repartir CPU en “turnos” y evitar que un proceso monopolice.
En términos prácticos: el timer es el “reloj de arbitraje” que habilita preempción y scheduling en sistemas multitarea.
En un PC real, hay procesos interactivos (IDE, navegador) y procesos “silenciosos” (servicios, actualizaciones) compitiendo por CPU.
El scheduler es el módulo del kernel que decide cuál proceso corre ahora y cuál espera. Su objetivo no es solo “rapidez”, sino una combinación de: respuesta, justicia, throughput y estabilidad.
Hoy trabajamos con un modelo simplificado (suficiente para entender estados de proceso y algoritmos después).
Un proceso no “usa CPU todo el tiempo”: normalmente alterna entre ejecutar (CPU burst) y esperar por I/O (disco, red, teclado).
Cuando un proceso está esperando I/O, mantenerlo en CPU sería desperdicio; lo correcto es que el kernel le dé la CPU a otro listo.
Consecuencia: el kernel necesita colas y estados (listo, ejecutando, bloqueado) para organizar este flujo.
Modelo mental:
- CPU burst: instrucciones, cálculo, ejecución.
- I/O wait: esperando respuesta del dispositivo.
- Interrupt: el dispositivo "avisa" cuando terminó.
Pregunta guía:
Si P1 queda bloqueado esperando disco,
¿qué debería hacer la CPU mientras tanto?
Un proceso está Ready si *puede* ejecutar, pero no está ejecutando porque la CPU está ocupada con otro.
La cola Ready es la “fila” de procesos listos. El scheduler toma el siguiente según la política (hoy: Round Robin).
En la próxima sesión formalizamos estados y transiciones; hoy los usamos para explicar scheduling.
CPU (Running) -> Tick -> Kernel:
- Puede seguir mismo proceso
- O hacer preempción (cambiar al siguiente Ready)
Blocked:
- Sale de Ready/Running
- Vuelve a Ready cuando llega la interrupción del dispositivo
El quantum es la cantidad máxima de CPU continua que un proceso puede usar antes de que el kernel re-evalúe.
Quantum pequeño: mejor respuesta al usuario, pero más cambios de contexto (más overhead).
Quantum grande: menos overhead, pero peor respuesta (los procesos “esperan más” su turno).
Regla mental:
Más cambios de contexto = más tiempo del kernel
guardando/restaurando en vez de ejecutar trabajo útil.
Es cuando el kernel puede quitarle la CPU a un proceso (aunque no quiera), típicamente al llegar el tick del timer.
Sin preempción, un proceso que no libere CPU voluntariamente puede degradar la respuesta del sistema.
Con preempción, el kernel impone turnos.
Hoy lo simularemos de manera explícita con un rol “Timer”.
Tick (timer interrupt) llega:
1) CPU entra a handler del kernel
2) Kernel decide: ¿cambio o no?
3) Si cambia: context switch
4) Retorna a user mode con otro proceso
Para pausar P1 y continuar P2 sin “romper” nada, el kernel debe guardar la “foto” del estado de CPU de P1.
Esa foto vive en una estructura tipo PCB (Process Control Block). No necesitas memorizar campos exactos hoy; sí entender la necesidad.
Context switch (alto nivel):
save(P1.cpu_state) -> PCB1
pick_next(Ready) -> P2
load(PCB2.cpu_state)
return_to_user(P2)
Pregunta guía:
Si no guardas PC/SP/registros,
¿cómo retomas P1 exactamente donde iba?
Meta de la actividad: sentir ese overhead de forma visible (por eso el juego introduce un “costo” de cambio).
En Round Robin la cola Ready rota: cada proceso recibe un quantum; al terminar el quantum (tick), vuelve al final si no terminó.
Ventaja: es intuitivamente “justo” y muy usado para interacción.
Desventaja: si el quantum es demasiado pequeño, sube el overhead.
En sesiones posteriores compararás RR con FIFO/SJF, y medirás eficiencia en escenarios simulados.
Cola Ready inicial: P1, P2, P3
Quantum = 10s
Tick:
- Si P1 no terminó -> vuelve al final
Nueva cola: P2, P3, P1
En equipos (3 o 4), cada equipo resuelve un contexto (A, B, C o D) usando el mismo algoritmo (RR), y luego comparamos cómo cambian el Gantt, el makespan y el overhead por conmutaciones.
Producto: (1) diagrama de Gantt con bloques “CS”, (2) métricas: makespan, #CS, overhead, (3) interpretación corta (4–6 líneas).
Todos tienen los 4 contextos en los siguientes slides (nadie se queda sin datos).
Tiempo sugerido:
- 15 min: Gantt
- 10 min: métricas
- 10 min: interpretación
- 5 min: preparar socialización
Regla visual:
Cada vez que la CPU cambia P→Q,
dibujar un bloque "CS" con duración costo_CS.
En Contexto D hay I/O: cuando un proceso pide I/O se va a Blocked y vuelve a Ready cuando termina el I/O.
Definiciones útiles:
Turnaround(P) = Finish(P) - Arrival(P)
Waiting(P) = Turnaround(P) - CPU_total(P) - IO_total(P)
(solo si hay I/O)
Si te falta tiempo, prioriza: Gantt correcto → makespan → #CS → overhead.
Objetivo: ver overhead con quantum pequeño + tareas cortas.
| Parámetros | Datos |
|---|---|
| RR | Quantum = 2, costo_CS = 1 |
| Procesos |
P1: arrival 0, CPU 4 P2: arrival 1, CPU 3 P3: arrival 2, CPU 2 P4: arrival 3, CPU 1 |
Objetivo: ver efecto de quantum mayor + llegadas tardías.
| Parámetros | Datos |
|---|---|
| RR | Quantum = 4, costo_CS = 1 |
| Procesos |
P1: arrival 0, CPU 8 P2: arrival 0, CPU 6 P3: arrival 2, CPU 7 P4: arrival 4, CPU 3 |
En A y B no hay I/O: solo CPU_total. En el Gantt, “CS” cuenta como tiempo real pero no ejecuta CPU útil.
Objetivo: ver cómo el Gantt cambia cuando “aparecen” procesos a mitad de ejecución.
| Parámetros | Datos |
|---|---|
| RR | Quantum = 3, costo_CS = 1 |
| Procesos |
P1: arrival 0, CPU 5 P2: arrival 1, CPU 4 P3: arrival 2, CPU 6 P4: arrival 6, CPU 2 |
Objetivo: ver por qué existen Ready/Running/Blocked y el rol de interrupciones del dispositivo.
| Parámetros | Datos |
|---|---|
| RR | Quantum = 2, costo_CS = 1 |
| Procesos |
P1: arrival 0, CPU1 2 → I/O 3 → CPU2 2 P2: arrival 0, CPU 5 (sin I/O) P3: arrival 1, CPU1 1 → I/O 2 → CPU2 3 |
Regla D: si un proceso termina su CPU1 y solicita I/O, pasa a Blocked inmediatamente (sin esperar tick); cuando se cumple su tiempo de I/O, vuelve a Ready al final de la cola.
Tip: si dos equipos terminan rápido, intercambian contexto y verifican el Gantt del otro (control cruzado).
Preguntas guía rápidas:
1) ¿Qué subió #CS (quantum, llegadas, I/O)?
2) ¿Qué contexto evidencia Blocked?
3) ¿Dónde se ve “tiempo perdido” por CS?
Puente a la siguiente sesión: formalizaremos estados de proceso y transiciones (Ready/Running/Blocked/Exit) y ahí el scheduling queda “amarrado” a un modelo estándar.
Sesión 5: Estados de proceso, control y transiciones
Lo de hoy (Ready queue, quantum, preempción, context switch) se formaliza cuando modelamos el ciclo de vida del proceso y su control.