Hoy pasamos de “sé que existe un scheduler” a “puedo demostrar con números y con una línea de tiempo qué algoritmo favorece respuesta, espera promedio, equidad o throughput”.
Navegación: ← → | Home End | F pantalla completa | Táctil: desliza la página actual ←/→
Resultado esperado: al final tendrás una “plantilla mental” reutilizable para ejercicios y para el proyecto: (1) Gantt, (2) FirstRun/Finish, (3) T/W/R, (4) argumento de decisión.
En el modelo de estados, un proceso que está en Ready está “listo para correr” pero no tiene CPU. El scheduler decide cuál Ready pasa a Running (y, si hay preempción, cuándo vuelve a Ready).
El proceso mantiene CPU hasta que termina o se bloquea (no se le quita a la fuerza).
Ejemplo típico: FCFS clásico y SJF clásico (versión simple).
Un evento (como el timer) puede quitarle la CPU y devolverlo a Ready.
Ejemplo típico: Round Robin.
Idea clave: el algoritmo cambia el “orden de paso” por Running, y eso cambia tiempos medibles.
Para cada proceso i:
• FirstRun: primer instante en que recibe CPU.
• Finish: instante en que termina su burst total (en este ejercicio, todo es CPU).
Tiempo total en el sistema: desde llegada hasta fin.
Tiempo total “listo pero sin CPU”.
Tiempo hasta la primera vez que corre (clave para interactividad).
Lo importante no es memorizar fórmulas: es saber “de dónde salen” mirando el Gantt. Si el Gantt es correcto, la tabla sale casi sola.
FCFS es la política más simple: se ejecutan en el orden de llegada a la cola Ready. Funciona bien cuando quieres minimizar complejidad y la carga es “parecida” (procesos de tamaño similar), pero puede ser mala para interactividad cuando hay procesos largos que “arrastran” a muchos cortos.
Convoy effect: un trabajo largo al frente hace que los cortos esperen demasiado, incluso si el sistema podría “atender rápido” varias tareas pequeñas.
SJF elige, entre los procesos que ya llegaron y están listos, el que tiene menor burst de CPU. En escenarios “ideales” tiende a reducir la espera promedio, pero plantea una pregunta práctica: ¿cómo sabe el sistema cuál será el burst real? En la vida real se estima y se controla equidad.
Starvation: si siguen llegando trabajos cortos, los largos pueden esperar “demasiado”. La solución real suele incluir envejecimiento (aging) o políticas híbridas.
Hoy lo usamos como herramienta didáctica: si entiendes SJF, entiendes por qué “ordenar por tamaño” cambia drásticamente W y T.
Round Robin reparte CPU por turnos: cada proceso recibe un quantum fijo (por ejemplo, 2 ms), y si no termina, el timer lo preempta y vuelve al final de la cola Ready. Es una política natural para sistemas interactivos: busca que “todos avancen” y que la respuesta sea rápida.
Si el quantum es muy pequeño, el número de cambios de contexto aumenta, y con él la sobrecarga. Si es muy grande, RR se parece a FCFS.
El “arte” de RR no es la idea, es el quantum: balancea interactividad vs overhead.
Vas a resolver un caso único con tres políticas (FCFS, SJF, RR) y vas a entregar evidencia de proceso: tu Gantt, tu tabla de métricas y tu conclusión argumentada.
En la siguiente diapositiva verás un ejemplo completo (formato “exacto”) de lo que se espera.
Caso Procesos con llegada (A) y ráfaga CPU (Burst)
| Proceso | A | Burst | FirstRun | Finish | T = Finish-A | W = T-Burst | R = FirstRun-A |
|---|---|---|---|---|---|---|---|
| P1 | 0 | 5 | 0 | 5 | 5 | 0 | 0 |
| P2 | 1 | 3 | 5 | 8 | 7 | 4 | 4 |
| P3 | 2 | 1 | 8 | 9 | 7 | 6 | 6 |
| P4 | 3 | 2 | 9 | 11 | 8 | 6 | 6 |
Observa el procedimiento: el Gantt te “regala” FirstRun y Finish. De ahí salen T, W y R. En tu entrega, escribe al menos dos frases de interpretación (por ejemplo: “P3 espera mucho en FCFS porque llega temprano pero queda detrás de P1 y P2”).
En Round Robin, dos personas pueden terminar con Gantt diferentes si aplican reglas distintas sin notarlo (por ejemplo, “¿re-encolo primero al que fue preemptado o primero a los que llegaron durante el quantum?”). Para que tu solución sea válida, debes poder mostrar el estado de la cola en cada corte de quantum.
En tu entrega, si tu RR difiere del de otro grupo, no “pelees el dibujo”: comparen la cola en cada corte. Si la cola está bien, el Gantt está bien.
Caso (mismo del ejemplo): P1(A=0,B=5), P2(A=1,B=3), P3(A=2,B=1), P4(A=3,B=2).
RR: quantum=2.
Si terminas: discute con tu pareja qué pasaría si quantum=5 y escribe una frase de predicción (“RR se acerca a FCFS porque…”).
Regla de oro: si tu tabla no “cierra” con W = T - Burst, tu Gantt o tus tiempos están mal. Esa ecuación funciona como prueba de consistencia.
Criterio claridad + precisión + coherencia con lo trabajado hoy.
Vamos a ampliar el modelo: ya no basta con “procesos”, porque los hilos cambian el costo de alternancia y la forma de pensar la planificación.
Recuerda: el objetivo del curso no es “dibujar bonito”, es argumentar decisiones de sistema.