¿Cómo prevenir, detectar y recuperarse de interbloqueos (deadlocks)?

Planteamiento y contexto aplicable

Un servicio de transferencias se congela ocasionalmente: el hilo A retiene el bloqueo para la cuenta 42 y espera por la cuenta 84, mientras que el hilo B retiene la cuenta 84 y espera por la cuenta 42. Ninguno de los hilos libera su primer bloqueo. ¿Es esto un interbloqueo (deadlock)? Explica las cuatro condiciones necesarias y diseña la prevención, detección, recuperación y validación.

Esta es una pregunta general de ingeniería de software y sistemas operativos para roles de backend, sistemas, infraestructura, SRE y otros que escriben código concurrente. El material de entrevistas actual en inglés y chino para 2026 sigue preguntando por separado sobre la definición, las cuatro condiciones necesarias y las estrategias de manejo. Este artículo no hace atribuciones a empresas ni afirma una frecuencia de entrevista no respaldada.

Las cuentas 42 y 84 son identificadores ficticios. La tarea va más allá de recitar cuatro nombres. Una respuesta sólida distingue una espera prolongada de un ciclo de espera irreductible y luego conecta la teoría con un protocolo de bloqueos, evidencia en tiempo de ejecución, recuperación ante fallos y pruebas. El alcance principal son los mutexes de una sola instancia y los bloqueos de filas en bases de datos. Los leases distribuidos, las particiones de red y el consenso quedan fuera de la primera respuesta.

Qué evalúa el entrevistador

La primera señal es si el diagnóstico utiliza relaciones de espera. Un uso bajo de CPU, solicitudes con tiempo de espera agotado (timeouts) o dos hilos bloqueados muestran falta de progreso, pero no demuestran de forma independiente un interbloqueo. Una respuesta sólida construye un grafo de espera (wait-for graph) cuyos nodos son hilos o transacciones y cuyas aristas significan "espera por un recurso propiedad de", para luego buscar un ciclo.

La segunda señal es el uso preciso de las cuatro condiciones necesarias: exclusión mutua, retención y espera (hold and wait), no apropiación (no preemption) y espera circular. Estas explican por qué el interbloqueo es posible. Listarlas sin mapear cada una a la ruta de transferencia sigue siendo una respuesta memorizada.

La tercera señal es una estrategia de prevención con un invariante global demostrable. La opción práctica suele ser un orden total estable para cada bloqueo, aplicado en todos los puntos de entrada. Intercambiar dos líneas en una sola función es insuficiente. Las tareas por lotes, reembolsos, herramientas de reparación y rutas futuras pueden recrear el ciclo si alguna adquiere en orden inverso.

Por último, el entrevistador evalúa los límites de recuperación. Una base de datos puede detectar un ciclo y revertir una transacción. Por lo general, un mutex dentro del proceso no puede ser expropiado de forma segura para reanudar la ejecución, ya que el código interrumpido podría haber cambiado solo la mitad de un invariante. Una respuesta sólida separa la prevención, la evasión, la detección y la recuperación, establece el costo de los tiempos de espera y reproduce el entrelazado en lugar de esperar que una prueba de estrés se tope con él.

Preguntas para clarificar antes de responder

• ¿Son todos los recursos mutexes de una sola instancia? Un ciclo en un grafo de espera sobre recursos de una sola instancia demuestra que ese grupo no puede progresar. Si un tipo de recurso tiene múltiples instancias, un ciclo en el grafo de asignación de recursos indica una posibilidad; las instancias disponibles y las necesidades restantes siguen importando.
• ¿Son los bloqueos reentrantes? Readquirir un bloqueo no reentrante en el mismo hilo puede provocar un auto-interbloqueo. Cuando el origen y el destino son la misma cuenta, deduplica antes de bloquear en lugar de asumir que la ordenación manejará el duplicado.
• ¿Están ambos cambios de cuenta en una sola transacción capaz de rollback? Un límite transaccional puede abandonar a una víctima y reintentar. Un flujo que ya envió un pago externo o un correo electrónico necesita una clave de idempotencia o una bandeja de salida (outbox) post-commit, no una repetición a ciegas.
• ¿Pueden todas las rutas de adquisición compartir una regla de ordenación? De ser así, prefiere el ordenamiento global. Si un componente de terceros o un recurso entre servicios no puede unirse a ese protocolo, reduce la propiedad simultánea, rediseña la propiedad o coloca detección y reversión alrededor de un límite seguro.
• ¿Cuánto tiempo puede esperar una solicitud y qué significa un timeout? Un tiempo de espera de bloqueo acota la latencia de cola, pero puede terminar una solicitud lenta legítima. Los clientes que llaman necesitan saber si la operación es reintentable, definitiva o de resultado desconocido.
• ¿Qué herramientas de diagnóstico expone el entorno de ejecución? La gestión de hilos de la JVM, las vistas de espera de la base de datos y los validadores de bloqueos del kernel cubren diferentes clases de bloqueos. Que una herramienta no reporte nada no descarta esperas asíncronas, hilos virtuales o recursos externos.
• ¿La sección crítica llama a una operación de red, disco o controlada por el usuario? Las dependencias no acotadas extienden la posesión del bloqueo y amplifican los bloqueos. Muévelas afuera a menos que el protocolo de consistencia requiera explícitamente la espera y maneje su fallo.

Estructura de respuesta en 30 segundos

"Esto es un interbloqueo: A espera que B libere el 84, mientras B espera que A libere el 42, por lo que el grafo de espera contiene A → B → A. El caso presenta exclusión mutua, retención y espera, no apropiación y espera circular. Deduplicaría los IDs de cuenta y adquiriría todos los bloqueos de cuenta en un orden ascendente estable, liberándolos en orden inverso, lo que rompe la espera circular por protocolo. En producción confirmaría el ciclo a partir de datos de espera de hilos o de la base de datos. Una víctima en la base de datos se revierte y reintenta con un límite; para un interbloqueo en el proceso, preservo los diagnósticos y me recupero solo en un límite de estado seguro. Una prueba con barreras hace que el entrelazado anterior sea determinista y verifica que la versión ordenada preserve el invariante de balance."

Una respuesta completa debe agregar por qué la ordenación descarta un ciclo, por qué un timeout no es una prueba, qué esperas cubre un detector y si la recuperación puede duplicar un efecto secundario externo.

Respuesta profunda paso a paso

Paso 1: Demostrar un ciclo de espera en lugar de diagnosticar a partir de síntomas

Representa el estado en tiempo de ejecución como un grafo de espera. El hilo A retiene el bloqueo 42 y solicita el 84, que pertenece a B, por lo que se agrega A → B. El hilo B retiene el 84 y solicita el 42, que pertenece a A, por lo que se agrega B → A. Cada hilo libera su primer bloqueo solo después de adquirir el segundo. Ningún nodo en el ciclo puede terminar primero, por lo que el grupo no puede progresar por sí mismo.

El diagnóstico en producción necesita propietarios, hilos en espera y trazas de pila (stacks) de aproximadamente el mismo momento. Una sola captura de hilos puede registrar contención inofensiva. Capturas repetidas con los mismos stacks y aristas proporcionan una evidencia más sólida. Una espera larga pero ordinaria no tiene arista de retorno: A puede esperar a B mientras B se ejecuta y eventualmente libera su recurso. Llamar interbloqueo a cualquier bloqueo lento diagnostica erróneamente la latencia de capacidad o de dependencias como un error del protocolo de bloqueos.

La conclusión del grafo tiene un límite de modelo. Cuando cada mutex tiene un solo propietario, un ciclo de espera es condición suficiente para un interbloqueo entre esos hilos. Cuando una categoría de recursos tiene múltiples instancias, un ciclo en el grafo de asignación de recursos muestra riesgo en lugar de una prueba certera; una instancia externa puede liberarse y permitir que un participante continúe. El análisis entonces requiere conocer la demanda disponible, asignada y máxima restante.

Paso 2: Mapear las cuatro condiciones necesarias al código

Las cuatro condiciones son concretas en esta transferencia:

1. Exclusión mutua: un solo hilo a la vez posee el bloqueo de escritura de una cuenta.
2. Retención y espera: A retiene 42 mientras solicita 84; B retiene 84 mientras solicita 42.
3. No apropiación: el entorno de ejecución no retira de forma segura el bloqueo de una cuenta a su propietario; el propietario debe liberarlo.
4. Espera circular: A espera a B y B espera a A.

Todas las condiciones están presentes cuando ocurre este interbloqueo, y romper cualquiera de ellas previene esta clase de problemas. No trates "el sistema usa mutexes" o "el código anida bloqueos" como prueba de un interbloqueo activo. Las condiciones necesarias describen qué permite el interbloqueo; el estado en tiempo de ejecución aún requiere un ciclo irreductible.

La exclusión mutua puede proteger el invariante de saldo, por lo que eliminarla y competir sobre el estado compartido no es una solución. La apropiación segura también es difícil para una sección crítica ordinaria en memoria. Los sistemas de ingeniería eliminan más a menudo la espera circular o, en límites con capacidad de rollback, detectan y abandonan una transacción.

Paso 3: Eliminar la espera circular con un orden de bloqueo global

Define un orden total para cada bloqueo que pueda retenerse conjuntamente, como el rango del tipo de recurso seguido del ID del recurso. Cuando solo intervienen bloqueos de cuenta, ordena por ID de cuenta. Deduplica primero para manejar una transferencia cuyo origen y destino coincidan. Adquiere en orden, realiza solo la validación y la mutación de estado en la sección crítica, y libera en orden inverso.

Pseudocódigo neutral respecto al lenguaje:

transfer(fromid, toid, amount): ids = unique(sortascending([fromid, to_id])) acquired = [] try: for id in ids: acquired.append(lock_account(id)) validateandapplytransfer(fromid, to_id, amount) finally: for lock in reverse(acquired): unlock(lock)

El argumento de corrección es breve. Si un hilo que retiene un bloqueo de menor rango solo puede esperar por un bloqueo de mayor rango, un ciclo de espera requeriría que los rangos aumenten estrictamente:

r1 < r2 < … < rn < r1

Un orden estricto no puede regresar a su punto de partida, por lo que la espera circular es imposible. La prueba depende de que todas las rutas obedezcan el mismo orden. Adquirir por orden de solicitud, orden de iteración de listas o el orden de retorno de la base de datos en una ruta secundaria invalida el invariante.

La liberación inversa facilita razonar sobre la propiedad anidada, pero no es lo que previene el ciclo. La regla más importante es evitar llamadas remotas, entradas del usuario y E/S no acotada mientras se retienen bloqueos. Una sección crítica larga tal vez no cause interbloqueo, pero magnifica la contención, los timeouts y el costo de recuperación.

Paso 4: Saber cuándo se adapta otra estrategia

Solicitar todos los recursos antes de realizar el trabajo rompe la retención y espera, pero los invocadores deben conocer el conjunto completo por adelantado. Un conjunto grande también alarga la retención y reduce la concurrencia. Se adapta a un conjunto de bloqueos pequeño y conocido, pero funciona mal cuando el recorrido descubre recursos de forma incremental.

La evasión de interbloqueos evalúa si conceder una solicitud preserva un estado seguro. El algoritmo del banquero requiere demandas máximas por adelantado y rastrea los recursos disponibles, máximos, asignados y restantes. Una solicitud web dinámica rara vez conoce cada objeto que tocará más adelante, por lo que el algoritmo es útil para explicar estados seguros, pero generalmente no se copia en el código de aplicación. Un estado seguro garantiza una secuencia de finalización. Un estado no seguro puede conducir a un interbloqueo, pero no está necesariamente interbloqueado de antemano.

Reducir el estado mutable compartido, asignar un único propietario o utilizar contenedores concurrentes maduros puede eliminar rutas de bloqueo manuales. Esto no justifica la afirmación de que "los mensajes no pueden interbloquearse". Dos colas acotadas pueden esperar por la capacidad de la otra, y las tareas en un ejecutor pueden esperar cíclicamente por resultados. La alternativa todavía necesita un grafo de espera.

El uso de try-lock y tiempos de espera son mecanismos de escape con pérdida, no una prueba de un protocolo acíclico. Si la ruta de timeout revierte el estado parcial y libera cada bloqueo retenido, rompe la retención y espera después del umbral y disuelve este ciclo. Las solicitudes aún se estancan antes del umbral, y un umbral corto aborta trabajo legítimo. Ambos lados pueden agotar el tiempo de espera y reintentar juntos, produciendo un bloqueo activo (livelock). Utiliza un conteo máximo de intentos, retroceso aleatorio (randomized backoff), semántica idempotente y un error terminal.

Paso 5: Especificar qué cubre realmente cada detector

La clase ThreadMXBean de la JVM puede encontrar ciclos entre hilos de plataforma que esperan por monitores de objetos o sincronizadores con propietario y retornar sus IDs. La documentación de Java SE 25 establece que este método no encuentra ciclos que contengan hilos virtuales y que la operación es para diagnóstico de problemas, no para control de sincronización. Un resultado nulo solo descarta dentro de la cobertura del detector.

El validador lockdep del kernel de Linux registra las dependencias de adquisición observadas entre clases de bloqueos. Si la ejecución expone L1 → L2 y L2 → L1, puede reportar una posible inversión incluso cuando esta ejecución particular no haya llegado a congelarse. Esto demuestra cómo los entornos de desarrollo y prueba pueden validar un protocolo de ordenación; el código de aplicación no puede asumir que todo runtime ofrezca el mismo validador.

PostgreSQL detecta automáticamente interbloqueos de transacciones y aborta una de las transacciones participantes para que las demás puedan continuar. Su documentación indica que la víctima es difícil de predecir, por lo que la lógica de negocio no debe depender de que "la solicitud más nueva siempre pierde". PostgreSQL también recomienda un orden de adquisición consistente en todas las aplicaciones y reintentar las transacciones que se aborten cuando la prevención total sea inviable.

Las señales de producción deben incluir la duración de espera de bloqueo, la duración de retención de bloqueo, el conteo de interbloqueos, las transacciones revertidas, los intentos de reintento y los fallos terminales. Un registro de diagnóstico debe correlacionar el hilo en espera, el propietario, la clase de bloqueo y el stack sin registrar datos completos de cuentas, parámetros de consulta o cargas útiles sensibles.

Paso 6: Recuperarse en el límite de consistencia del recurso

Después de que una base de datos elija una víctima, revierte la transacción completa, vuelve a leer el estado y ejecuta de nuevo. No reanudes desde "después del primer bloqueo". Acota los reintentos y agrega un retraso aleatorio. Si pueden llegar solicitudes duplicadas, utiliza una clave de idempotencia de negocio. Dispara correos electrónicos, mensajería o pagos externos después del commit a través de una ruta idempotente tipo outbox, ya que un rollback de base de datos no puede deshacer un efecto secundario emitido.

Cuando los hilos en el proceso están atascados en mutexes, terminar forzosamente uno puede dejar un invariante en memoria a medio actualizar. Una ruta de recuperación común captura volcados de hilos (thread dumps) y métricas clave, y luego permite que un supervisor reinicie un proceso o instancia cuyo estado pueda reconstruirse de forma segura. Si el proceso posee un estado único y no recuperable, reiniciar tampoco es seguro; la persistencia y la recuperación necesitan un rediseño.

La selección de la víctima puede considerar el trabajo ya realizado, el costo de reversión, la prioridad y el historial de reintentos, pero la corrección es lo primero. La recuperación restaura el progreso y no elimina la causa. Sin corregir el orden de bloqueo, el mismo tráfico puede volver a interbloquearse.

Paso 7: Validar la solución con un entrelazado determinista

No confíes únicamente en que una prueba de alta concurrencia tenga suerte. Agrega una barrera de prueba a la implementación anterior. A alcanza la barrera después de bloquear el 42, y B la alcanza después de bloquear el 84. Libera ambos para que soliciten su segundo bloqueo. Un watchdog debe capturar ambas aristas de espera dentro del límite de tiempo de la prueba, demostrando A → B → A en lugar de limitarse a detectar una máquina de prueba lenta.

Ejecuta las mismas entradas invertidas contra la solución. Tanto A como B intentan primero el ID menor, 42. Uno espera sin poseer el 84; el ganador adquiere el 84, completa y libera, tras lo cual el otro procede. Verifica que ambas solicitudes reciban un resultado válido según el contrato, que el balance total permanezca inalterado y que ninguna transferencia se ejecute dos veces.

Cubre también:

• IDs de origen y destino idénticos, demostrando que la deduplicación evita una segunda adquisición de un bloqueo no reentrante;
• tres o más cuentas y múltiples tipos de recursos, demostrando que la clave de ordenación es idéntica en todas las rutas;
• saldo insuficiente, excepciones, cancelación y fallo de adquisición parcial, demostrando que el bloque finally libera cada bloqueo adquirido;
• rutas de lotes, reembolsos y reparación concurrentes con transferencias en línea, detectando inversiones en rutas secundarias;
• detección en base de datos y reversión de víctimas, validando el reintento completo, los efectos secundarios idempotentes y el límite de reintentos;
• una prueba de estrés prolongada (soak test) aleatorizada de alta contención que verifique continuamente balances, esperas de bloqueos, interbloqueos e inanición (starvation).

La prueba determinista cierra el contraejemplo conocido. La prueba de estrés busca rutas no modeladas. Ambas son necesarias antes de afirmar que el protocolo está validado.

Ejemplo de respuesta de alta calidad

"Primero demostraría que esto es más que una espera lenta. A posee el 42 y espera el 84 de B, por lo que A → B. B posee el 84 y espera el 42 de A, por lo que B → A. Cada mutex de una sola instancia se libera solo después de que su propietario obtiene el segundo, lo que convierte este ciclo en un interbloqueo.

Las cuatro condiciones necesarias están presentes: los bloqueos de escritura de cuenta son mutuamente excluyentes; ambos hilos retienen uno mientras esperan por otro; los bloqueos no pueden ser expropiados de forma segura; y las esperas forman un ciclo. No eliminaría la exclusión mutua porque protege los balances. Rompería la espera circular definiendo un orden total para los bloqueos de cuenta, deduplicando IDs, adquiriendo en orden ascendente y liberando en orden inverso. Si cada ruta espera únicamente desde un rango menor hacia un rango mayor, un ciclo requeriría que los rangos aumenten y luego regresen a un punto de partida menor, lo cual es imposible.

La regla debe cubrir transferencias en línea, reembolsos, trabajo por lotes y herramientas de reparación. Las secciones críticas contienen únicamente validación y mutación de estado, no llamadas remotas. Un timeout puede disolver esta espera tras la liberación completa, pero no demuestra que el protocolo de bloqueo sea acíclico. Tiempos de espera y reintentos simultáneos pueden convertirse en un livelock, por lo que cualquier ruta con timeout necesita intentos acotados, retroceso aleatorio y una clave de idempotencia.

En producción construiría el grafo de espera-propietario a partir de volcados de hilos o datos de espera de base de datos, respetando la cobertura de cada detector. Si PostgreSQL detecta un interbloqueo de transacciones, aborta una de ellas. Revertiría y reintentaría toda la transacción con un límite, sin asumir qué solicitud se convertirá en víctima, y publicaría mensajes externos solo a través de una ruta post-commit idempotente.

Para la verificación, una barrera permite que A bloquee el 42 y B bloquee el 84 antes de que ambos soliciten el segundo bloqueo, reproduciendo de manera confiable la implementación anterior. La versión ordenada recibe las mismas entradas invertidas y debe mostrar únicamente esperas acíclicas antes de completarse. También probaría cuentas idénticas, operaciones con tres cuentas, limpieza tras excepciones, tareas secundarias y rollback de base de datos mientras compruebo el balance total, efectos secundarios duplicados, conteo de interbloqueos y fallos terminales."

Esta respuesta conecta la definición, la demostración, la decisión de ingeniería, la recuperación y la validación. Si el entrevistador solo pregunta por las cuatro condiciones, detente tras el segundo párrafo. Expándete hacia herramientas y límites de reintento cuando el seguimiento gire en torno al manejo en producción.

Errores comunes

• Declarar interbloqueo siempre que un hilo se bloquea → Quien retiene el bloqueo por mucho tiempo aún puede estar progresando → Dibuja aristas de espera-propietario y confirma un ciclo bajo el modelo correcto de instancias de recursos.
• Recitar solo las cuatro condiciones → La respuesta no mapea el código ni selecciona una solución → Mapea cada condición al escenario e indica cuál de ellas rompe el diseño.
• Ordenar independientemente dentro de cada función → Los módulos pueden discrepar en la clave o en el rango del tipo de recurso → Define una jerarquía de bloqueos para todo el repositorio e inspecciona cada punto de entrada.
• Ignorar IDs de recursos duplicados → Un hilo puede adquirir el mismo bloqueo no reentrante dos veces → Deduplica antes de ordenar y define la semántica para transferencias entre la misma cuenta.
• Tratar un timeout como un diseño acíclico → El orden inverso permanece, y el timeout puede abortar esperas legítimas → Libera todos los bloqueos retenidos y añade retroceso acotado, idempotencia y fallo terminal.
• Reanudar a mitad del camino tras detectar un ciclo → El estado parcial puede estar obsoleto y los efectos secundarios pueden repetirse → Revierte y vuelve a ejecutar la transacción completa con una ruta post-commit idempotente.
• Asumir que cada ciclo en el grafo de recursos demuestra interbloqueo → Una instancia externa puede liberar un recurso de múltiples instancias → Separa los grafos de espera de instancia única del análisis de asignación de instancias múltiples.
• Matar forzosamente al propietario del bloqueo → Los invariantes en memoria pueden quedar a medio actualizar → Captura evidencia y reinicia solo en un límite donde el estado sea reconstruible.
• Ejecutar únicamente pruebas de estrés aleatorizadas → Que no se reproduzca no dice nada sobre un orden inverso → Fija el entrelazado con barreras, luego añade una prueba de esfuerzo prolongada para rutas desconocidas.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Sigue funcionando la ordenación cuando una transferencia bloquea tres cuentas?

Sí, siempre que el conjunto completo y deduplicado de bloqueos se conozca antes de la adquisición y se ordene mediante la misma clave estable. Si la ejecución descubre cuentas dinámicamente, lee un conjunto candidato sin bloqueos, adquiérelo junto y revalida las versiones. Si el conjunto no puede conocerse, divide la transacción o usa detección alrededor de un límite con capacidad de rollback en lugar de adquirir incrementalmente por orden local.

Pregunta de seguimiento 2: ¿Cómo se ordenan diferentes tipos de recursos?

Crea un rango compuesto, como cliente antes de cuenta y antes de fragmento de libro mayor (ledger shard), y luego el ID estable dentro de cada tipo. Un protocolo de bloqueo compartido rige la regla, y la revisión más las pruebas validan las aristas entre tipos. Si una operación debe entrar en orden inverso, rediseña la dirección de la llamada o libera el recurso de nivel inferior antes de cruzar el límite en lugar de agregar una excepción aislada.

Pregunta de seguimiento 3: ¿Ha resuelto el interbloqueo usar tryLock con un timeout de 100 milisegundos?

Acota la espera de este intento a la ventana configurada, pero no demuestra un protocolo acíclico. Cien milisegundos también pueden estar por debajo de la cola legítima de una sección crítica y generar falsos fallos. Define la liberación de bloqueos adquiridos, la reversión del estado parcial, retroceso aleatorio acotado, idempotencia y un error terminal; de lo contrario, el interbloqueo puede convertirse en un livelock de reintentos.

Pregunta de seguimiento 4: ¿Por qué es peligroso promover un bloqueo de lectura a uno de escritura?

Si dos hilos poseen bloqueos de lectura compartidos y ambos esperan promoverlos a escritura exclusiva, cada bloqueo de lectura bloquea la promoción del otro y forma un ciclo. Prefiere un protocolo de actualización explícito proporcionado por la biblioteca. Si no hay ninguno, libera el bloqueo de lectura, compite por el bloqueo de escritura y revalida la condición, ya que el estado puede haber cambiado durante el intervalo.

Pregunta de seguimiento 5: Si PostgreSQL detecta interbloqueos automáticamente, ¿qué le queda por hacer a la aplicación?

Utilizar un orden consistente de múltiples objetos para reducir su ocurrencia y tratar un error de interbloqueo como un fallo de toda la transacción. Releer y reintentar con un límite, hacer que la solicitud sea idempotente y registrar los reintentos más los fallos terminales. No asumas que una transacción específica siempre pierde ni repitas una acción externa irreversible tras un rollback.

Pregunta de seguimiento 6: ¿En qué se diferencian interbloqueo (deadlock), bloqueo activo (livelock) e inanición (starvation)?

Los participantes interbloqueados no pueden progresar debido a un ciclo de espera. Los participantes en livelock se ejecutan y cambian de estado, pero ceden o reintentan repetidamente sin completar. La inanición significa que a un participante se le niega un recurso por un tiempo indefinido mientras otros pueden terminar. Su evidencia difiere: un ciclo de espera, cambios de estado continuos sin finalización, y una espera injusta sostenida.