E1 2026-1 (mayo 2026)

Soluciones propias

Este examen no tiene solucionario oficial. El código de la P4 se verificó con una ejecución de prueba. Intenta resolverlo en ~100 minutos antes de abrir las soluciones.

Pregunta 1 · Alternativas (cada 2 errores restan 1 pto)

Responde aquí y se corrige al instante. Las explicaciones completas están en los temas enlazados.

Pregunta 1

0/6 correctas · 0 respondidas Reiniciar

1. Modelo Many-to-One. Un hilo de usuario hace read() sobre un socket sin datos. ¿Qué pasa?

a) Solo ese hilo se bloquea y el planificador de usuario cede la CPUb) Todo el proceso se bloquea porque el único hilo del kernel pasa a esperac) read() retorna error de inmediatod) Ninguna

2. pthread_mutex_lock(&m); pid = fork(); y el hijo hace pthread_mutex_lock(&m) (mutex NORMAL). ¿Qué pasa en el hijo?

a) Funciona: hereda una copia nueva con el mutex libreb) Deadlock: hereda el mutex bloqueado y nadie en el hijo lo liberarác) Segfaultd) Ninguna

3. Productor: sem_wait(&mutex); sem_wait(&espacios_vacios); … con el buffer lleno. Resultado:

a) Correctob) Race condition en insertarc) Deadlock: el productor retiene mutex y el consumidor no puede vaciard) Ninguna

4. En un monitor Mesa, ¿qué es obligatorio?

a) if es suficiente y más óptimob) while, porque la señal no transfiere el mutex de inmediato y la condición pudo cambiarc) No usar mutex con cond_waitd) Ninguna

5. Dos hilos incrementan stats.contador_hilo1 y stats.contador_hilo2; el rendimiento es pésimo. Causa:

a) Inversión de prioridadb) Deadlock de la MMUc) False sharing: invalidaciones constantes de la línea de cachéd) Ninguna

6. Hilo A hace lock(&m); hilo B hace unlock(&m) sin tenerlo (mutex NORMAL). POSIX dice:

a) B lo desbloquea (paso de tokens)b) B recibe EPERM y sigue seguroc) Comportamiento indefinidod) Ninguna

Pregunta 2 (3 pts) · Algoritmo A

1. f[i] ← V
2. mientras (turno ≠ i) hacer:
3.     mientras (f[j]) hacer omitir
4.     turno ← i
5. /* SC */
6. f[i] ← F

¿Exclusión mutua? ¿Deadlock-free? ¿Starvation-free? Justifica con trazas.

Ver solución

Es el algoritmo de Hyman. Mutex ✘ (traza de 7 pasos: P1 pasa el while interno, se desaloja antes de turno ← 1, P0 entra porque turno = 0, P1 escribe turno = 1 y entra). Deadlock-free ✔. Starvation ✘ (P0 re-entra una y otra vez sin que P1 alcance a ver f[0] = F).

→ Traza completa y reproducible en el intercalador (elige «Algoritmo A» y pulsa Buscar contraejemplo).

Pregunta 3 (5 pts) · Morris simplificado

Semáforos débiles A = 1, M = 0, B = 1; contadores NA y NM. ¿Mantiene la protección contra inanición? Si no, da una traza y la corrección mínima.

Ver solución

Análisis completo en Problemas clásicos → Morris. En resumen: la propuesta es equivalente al algoritmo de Morris (solo mueve NM-- después de la SC y protege NM con B), así que sí mantiene la protección. Allí mismo están las dos modificaciones que sí la romperían, con su traza y su corrección.

Pregunta 4 (6 pts) · pthreads y race de argumentos

Ver solución

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;                    // [1]
pthread_mutex_lock(&mutex);                                           // [2]
pthread_mutex_unlock(&mutex);                                         // [3]
pthread_create(&threads[i], NULL, rutina_hilo, (void *) &arg_struct); // [4]
pthread_join(threads[i], NULL);                                       // [5]

Si el for termina antes de que algún hilo lea: todos leen local_id = 3, local_mult = 30 y el acumulador final es 4 × 30 = 120. Verificado con una ejecución de prueba. Detalle en threads.

Fuente ·for_partial/Evaluaciones_OS_20261 (1).pdf