Livelock: qué es, ejemplo, diferencia con Deadlock

Por: Natalia Brooks Natalia Brooks
Hours Actualizado

⚡ Resumen inteligente

El Livelock es una situación de concurrencia en la que los procesos cambian constantemente de estado en respuesta unos a otros, pero no logran ningún progreso real, permaneciendo activos y consumiendo ciclos de CPU sin completar nunca sus tareas ni quedar bloqueados.

  • 🔁 Definición: El bloqueo mutuo se produce cuando los procesos cambian de estado constantemente para adaptarse unos a otros, pero nunca avanzan, a diferencia de los procesos congelados en un interbloqueo.
  • 🚶 Ejemplo: Dos personas dan un pasoping El ir uno al lado del otro en un pasillo para dejarse pasar ilustra el punto muerto, moviéndose continuamente pero sin cruzarse nunca.
  • 🧮 Causa: El sondeo repetido y los reintentos para obtener bloqueos, limitados por un número finito de ranuras en la tabla de procesos, provocan que los procesos entren en un estado de interbloqueo sin que ninguno de ellos se bloquee.
  • 🇧🇷 Comparación: El interbloqueo congela los procesos, la inanición niega los recursos indefinidamente y el bloqueo continuo mantiene los procesos ocupados sin que se produzca ningún progreso.
  • 🛡️ Prevención: El retroceso aleatorio, los límites de reintentos y el orden de prioridad rompen los reintentos simétricos que crean un bloqueo permanente.
  • 🤖 Perspectiva de la IA: El aprendizaje automático detecta patrones de CPU sin progreso, y Copilot ayuda a escribir código de retroceso y ordenación de bloqueos que evita el bloqueo mutuo.
Descubre más

Enredo en Operating sistema

¿Qué es LiveLock?

A livelock es una situación en la que se deniega repetidamente una solicitud de bloqueo exclusivo, ya que muchos se superponenping Los bloqueos compartidos interfieren constantemente entre sí. Los procesos cambian continuamente de estado, lo que impide que completen la tarea.

Ejemplos de Livelock

Ejemplo 1:

El ejemplo más sencillo de bloqueo mutuo es el de dos personas que se encuentran cara a cara en un pasillo y ambas se apartan para dejar pasar a la otra. Siguen moviéndose de un lado a otro sin avanzar porque se desplazan en la misma dirección al mismo tiempo. En este caso, nunca se cruzan.

Ejemplo 2:

Ejemplos de Livelock en Operating sistema

En la imagen superior, cada uno de los dos procesos necesita dos recursos y utiliza un método de sondeo primitivo para intentar adquirir los bloqueos necesarios. Si un intento falla, el método vuelve a intentarlo.

  1. El proceso A posee el recurso Y.
  2. El proceso B retiene el recurso X
  3. El proceso A requiere el recurso X.
  4. El proceso B requiere el recurso Y.

Supongamos que el proceso A se ejecuta primero y adquiere el recurso X, y luego el proceso B se ejecuta y adquiere el recurso Y. Independientemente de qué proceso se ejecute primero, ninguno de ellos avanza más.

Sin embargo, ninguno de los dos procesos se bloquea. Ambos consumen recursos de la CPU repetidamente sin avanzar, pero nunca se detienen por un bloqueo de procesamiento.

Por lo tanto, esta situación no es una punto muerto, porque no se bloquea ningún proceso; en cambio, nos enfrentamos a una situación equivalente a un interbloqueo, que se denomina LIVELOCK.

¿Qué lleva a Livelock?

El bloqueo mutuo está ligado al número de procesos que permite un sistema, el cual se define por el número total de entradas en la tabla de procesos. Por lo tanto, estos espacios en la tabla de procesos se consideran recursos finitos. Cuando los procesos intentan repetidamente acceder a estos recursos limitados, cediéndose el paso entre sí, ninguno avanza y el sistema entra en un bloqueo mutuo.

¿Qué es un bloqueo?

A punto muerto Es una situación que ocurre en un sistema operativo cuando un proceso entra en estado de espera porque otro proceso en espera está utilizando el recurso solicitado. El interbloqueo es un problema común en el procesamiento paralelo, donde varios procesos comparten un tipo específico de recurso mutuamente excluyente conocido como bloqueo suave o bloqueo de software.

Ejemplo de bloqueo

  • Un ejemplo real sería el tráfico que circula en una sola dirección.
  • Aquí, un puente se considera un recurso.
  • Cuando se produce un bloqueo, se puede resolver fácilmente si un coche retrocede (se apropian los recursos y se revierte la operación).
  • Es posible que sea necesario hacer marcha atrás con varios vehículos si se produce una situación de bloqueo.
  • Por lo tanto, es posible que muera de hambre.

Ejemplo de interbloqueo en Operating sistema

Ejemplo de bloqueo

ARTÍCULOS RELACIONADOS

¿Qué es el hambre?

La inanición se produce cuando los procesos de baja prioridad se bloquean mientras que los de alta prioridad continúan. En cualquier sistema, las solicitudes de recursos de alta y baja prioridad se suceden de forma dinámica. Por lo tanto, se requiere una política para decidir quién recibe atención y cuándo.

Con algunos algoritmos, ciertos procesos pueden no recibir el servicio deseado aunque no se produzca un interbloqueo. El bloqueo por inanición ocurre cuando algunos hilos impiden el acceso a recursos compartidos durante un período prolongado.

Ejemplo de hambruna

Por ejemplo, un objeto ofrece un método sincronizado que probablemente tarde mucho tiempo en devolver un resultado. Si un hilo utiliza este método con frecuencia, otros hilos que también necesitan acceso sincronizado frecuente al mismo objeto suelen quedar bloqueados.

Diferencia entre punto muerto, inanición y punto muerto

  • Un interbloqueo es una situación que se produce en un sistema operativo cuando un proceso entra en estado de espera porque el recurso solicitado está siendo utilizado por otro proceso que también está en espera.
  • Por otro lado, un bloqueo mutuo es casi similar a un interbloqueo, excepto que los estados de los procesos involucrados en un bloqueo mutuo cambian constantemente en respuesta unos a otros, sin que ninguno progrese.
  • Por lo tanto, el estancamiento vital es un caso único de escasez de recursos.

Preguntas Frecuentes

El bloqueo continuo se reduce añadiendo aleatoriedad u ordenación a los reintentos. Las técnicas incluyen retroceso aleatorio o exponencial antes de reintentar, límiteping el número de intentos de reintento y la imposición de un orden fijo de adquisición de bloqueos para que los procesos dejen de imitar los movimientos de los demás.

No. Los procesos en estado de interbloqueo nunca se bloquean; siguen ejecutándose y consumiendo ciclos de CPU mediante reintentos constantes sin avanzar. En un interbloqueo, los procesos involucrados se detienen y esperan, por lo que no utilizan la CPU.

A menudo, sí. Los procesos bloqueados se quedan congelados, lo cual es fácil de detectar, mientras que los procesos en estado de bloqueo permanente permanecen activos y cambian de estado constantemente. La detección suele basarse en un alto uso de la CPU combinado con un progreso nulo a lo largo del tiempo.

Una condición de carrera es un resultado incorrecto o impredecible causado por el acceso no sincronizado a datos compartidos. En cambio, el bloqueo mutuo implica procesos que permanecen activos y cambian de estado constantemente en respuesta entre sí, sin llegar a completar su trabajo.

Sí. Los hilos que reaccionan repetidamente entre sí —por ejemplo, liberando y solicitando un bloqueo al mismo tiempo— pueden sufrir un bloqueo mutuo sin llegar a bloquearse. Esto suele ocurrir en la lógica de reintentos y retrocesos que carece de aleatoriedad.

Los modelos de aprendizaje automático estudian los patrones de uso de CPU, planificación y recursos para identificar procesos que consumen recursos sin avanzar. Esto ayuda a los operadores a detectar bloqueos antes de que se alcancen umbrales fijos, especialmente en grandes cargas de trabajo en la nube y centros de datos con muchos procesos que interactúan entre sí.

Sí. GitHub Copilot puede sugerir retrocesos aleatorios, tiempos de espera y patrones de ordenación de bloqueo consistentes que reducen el riesgo de bloqueos mutuos e interbloqueos. Aun así, los desarrolladores deben revisar cuidadosamente la lógica de concurrencia generada, ya que los errores de sincronización sutiles son fáciles de pasar por alto.

A veces. Si la sincronización se modifica —por ejemplo, mediante intervalos de reintento aleatorios— los procesos pueden romper el patrón y continuar. Sin tales cambios, el bloqueo mutuo puede persistir indefinidamente, desperdiciando CPU mientras ningún proceso finaliza su tarea.

Resumir este post con: