El problema de repartir la CPU

Lo que podremos explicar al terminar

• Por qué varios procesos listos necesitan una política de planificación.
• Cuándo puede el SO retirar la CPU a un proceso.
• Cómo calcular retorno, respuesta y espera.
• Qué nos permite evaluar una ejecución con FCFS.

Lo que ya sabemos

TemaPregunta que ayuda a resolver

Una CPU, varios programas

Un editor, una compilación y una copia de archivos están en marcha.

Con una CPU:
solo una entidad ejecuta instrucciones en cada instante.

Las ejecuciones pueden avanzar de forma intercalada.

Concurrencia no implica ejecución simultánea.

WA · E1: ¿quién puede ejecutar?

En parejas · 15 minutos

• El editor está listo para procesar una tecla.
• La compilación está lista para continuar un cálculo.
• La copia está bloqueada esperando una lectura de disco.

En la tarea «E1 · ¿Quién puede ejecutar?»:

1. Identifiquen quiénes pueden competir por la CPU.
2. Elijan uno y justifiquen el objetivo y el coste de su elección.
3. Expliquen qué ocurre cuando termina la lectura de disco.

Quién puede ejecutar

Nuestra decisión necesita un criterio

Editor y compilación pueden competir por la CPU.

La copia debe completar su espera antes de volver a competir.

• Atender al editor puede reducir la demora que percibe el usuario.
• Atender a la compilación permite adelantar ese trabajo.

¿Qué beneficio buscamos y qué demora aceptamos?

Estados y mecanismos

¿A qué proceso listo le asignamos la CPU?

Listo, ejecutando y bloqueado

EstadoSituación

Al completar una E/S, el proceso pasa de bloqueado a listo.

Eso no le garantiza ejecución inmediata.

Planificador y despachador

La política establece cómo elegir.

El mecanismo permite realizar el cambio.

Cambio de contexto

Para continuar otro proceso, el SO debe:

1. Guardar el estado de ejecución del proceso saliente.
2. Recuperar el estado del proceso entrante.
3. Reanudarlo desde la instrucción correspondiente.

Cambiar de proceso consume tiempo.

Cuándo cambia la asignación

Planificación no apropiativa

Una vez asignada la CPU, el proceso la conserva hasta que:

• termina;
• se bloquea;
• o cede voluntariamente su ejecución.

La llegada de otro proceso listo no basta para desplazarlo.

Planificación apropiativa

El SO puede retirar la CPU a un proceso que podría seguir ejecutando.

El proceso desalojado vuelve a listos.

Ejemplos de decisiones posibles:

• venció su turno de CPU;
• apareció otro listo que la política favorece.

Un quantum limita la duración de un turno de CPU.

¿Qué evento ocurrió?

Respondan con un estado y una justificación.

Planificación y corrección

Dos procesos incrementan un contador compartido sin protección.

Al finalizar, el contador tiene menos incrementos de los esperados.

¿Cambiar el orden de ejecución garantiza resolver el problema?

Expliquen qué aporta la sincronización y qué decide la planificación.

Recapitulación:

Podemos decidir:

• quién puede ejecutar, según su estado;
• quién debería ejecutar, según la política;
• cuándo puede ocupar la CPU, según la apropiación.

Nos queda otra pregunta:

¿Cómo evaluamos si esa decisión fue conveniente?

Cuándo evaluamos una política

Evaluar una política

Dos sistemas pueden mantener la CPU ocupada todo el tiempo y producir experiencias muy diferentes.

¿Qué deberíamos medir?

Pensemos en un proceso que necesita empezar pronto y en otro que necesita terminar pronto.

Objetivos de planificación

Los objetivos pueden entrar en conflicto

Un trabajo requiere mucha CPU y varios trabajos breves están esperando.

• Atender primero al largo retrasa a los breves.
• Atender primero a los breves retrasa al largo.

¿Mejorar el promedio significa mejorar para todos?

Nuestro modelo de trabajo

• Una CPU.
• Una ráfaga de CPU por proceso, sin E/S.
• Llegadas y duraciones conocidas, en unidades de tiempo: u.t.
• Coste de cambio de contexto igual a cero.
• Empates de llegada: orden A, B, C, D.

Los resultados valen bajo estos supuestos.

Tiempo de retorno

Retorno = instante de fin − instante de llegada

Mide cuánto tiempo transcurre desde que el proceso llega hasta que termina.

Incluye el tiempo que ejecuta y el tiempo que espera.

Pregunta: «¿Cuándo estará completo mi trabajo?»

Tiempo de respuesta

Respuesta = primer inicio de CPU − llegada

Mide cuánto debe esperar el proceso antes de ejecutar por primera vez.

Un proceso puede recibir CPU pronto y terminar mucho después.

Pregunta: «¿Cuándo me atienden por primera vez?»

Tiempo de espera

Es el tiempo total que el proceso permanece listo sin ejecutar.

En nuestro modelo, sin E/S:

Espera = retorno − tiempo total de CPU

La espera puede acumularse en varios intervalos.

Estar bloqueado no es esperar en la cola de listos.

Un ejemplo para distinguir las métricas

Un proceso llega en t=2, empieza en t=4, ejecuta 6 u.t. sin interrupciones y termina en t=10.

FCFS: medir y aplicar

FCFS · Primero en llegar, primero en ejecutar

First Come, First Served

1. Los procesos listos forman una cola por orden de llegada.
2. El primero recibe la CPU.
3. En esta versión no apropiativa, la conserva hasta terminar o bloquearse.

En nuestro ejercicio, cada proceso ejecuta su única ráfaga hasta terminar.

Caso A · Una misma CPU para cuatro procesos

FCFS no apropiativo, sin E/S y sin coste de cambio.

En t=0, ¿quién puede ejecutar?

WA · E2: FCFS y métricas

En equipos de tres · 15 minutos

En la tarea «E2 · FCFS y métricas»:

1. Dibujen el Gantt del caso A con todos sus límites temporales.
2. Calculen inicio, fin, retorno, espera y respuesta de cada proceso.
3. Calculen los promedios de retorno, espera y respuesta.
4. Identifiquen quién espera más y expliquen por qué.

Entreguen la tabla y una foto o imagen legible del Gantt.

FCFS · La secuencia del caso A

A: [0,8) · B: [8,12) · C: [12,14) · D: [14,15)

Cuando B llega en t=1, A continúa ejecutando.

FCFS no apropiativo no desaloja a A por la llegada de B.

FCFS · Las métricas del caso A

Todos los valores se expresan en u.t.

Utilización y productividad

Observamos el intervalo [0,15).

CPU útil = tiempo ejecutando procesos / tiempo observado

15 / 15 = 100 %

Productividad = procesos terminados / tiempo observado

4 / 15 ≈ 0,267 procesos/u.t.

Una CPU ocupada no cuenta toda la historia

La utilización fue 100 %.

Sin embargo, D esperó 11 u.t. para ejecutar 1 u.t.

Los trabajos breves quedaron detrás de uno largo: efecto convoy.

Para evaluar una política necesitamos mirar también las demoras individuales.

Qué vimos

WA · Cuestionario de cierre

«Clase 1 · Conceptos y métricas»

Individual · 10 minutos · 6 preguntas

• Procesos listos y asignación de CPU.
• Apropiación y relación con sincronización.
• Retorno y espera en FCFS.

Pueden consultar sus apuntes y su resolución de E2.

Envíen el intento antes de revisar la retroalimentación.

Lo que podemos responder ahora

Para administrar ejecuciones concurrentes necesitamos:

• identificar qué procesos están listos;
• aplicar una política de asignación de CPU;
• sostener la corrección mediante sincronización;
• evaluar las consecuencias con métricas explícitas.

Próxima clase: misma carga, otras políticas. ¿Quién mejora y quién espera más?