Circular Wait es una de las cuatro condiciones necesarias de Coffman para que ocurra un deadlock en un sistema. Se produce cuando un conjunto de procesos (P0, P1, ..., Pn) están esperando recursos de forma cíclica: P0 espera un recurso poseído por P1, P1 espera un recurso poseído por P2, y así sucesivamente, hasta que Pn espera un recurso poseído por P0. Esta interdependencia circular impide que cualquiera de los procesos avance, resultando en un estancamiento del sistema. Es crucial entender que, aunque es una condición necesaria, no es suficiente por sí sola; debe coexistir con Mutual Exclusion, Hold and Wait, y No Preemption.
Este fenómeno se manifiesta en diversos sistemas concurrentes y distribuidos. En bases de datos transaccionales, un Circular Wait puede ocurrir cuando múltiples transacciones intentan adquirir bloqueos (locks) sobre los mismos datos en un orden diferente, por ejemplo, la Transacción A bloquea Recurso X y espera Recurso Y, mientras la Transacción B bloquea Recurso Y y espera Recurso X. Sistemas operativos con gestión de recursos compartidos, como la asignación de memoria o dispositivos de E/S, también son susceptibles. En microservicios, un Circular Wait puede surgir de dependencias cíclicas en la adquisición de recursos o en la invocación de servicios, donde el servicio A espera una respuesta del servicio B, que a su vez espera una respuesta del servicio C, y C espera una respuesta de A.
Para un arquitecto de sistemas, comprender Circular Wait es fundamental para diseñar sistemas robustos y de alto rendimiento. Prevenirlo o detectarlo a tiempo es clave para evitar caídas del sistema o degradación del rendimiento. Las estrategias incluyen la imposición de un orden total en la adquisición de recursos (resource ordering), lo que rompe el ciclo de espera. Otra técnica es el uso de timeouts y mecanismos de detección de deadlock, como los grafos de espera (wait-for graphs), que permiten identificar y resolver el deadlock (por ejemplo, abortando una de las transacciones). La elección entre prevención y detección implica trade-offs: la prevención puede simplificar el diseño pero a veces reduce la concurrencia, mientras que la detección permite mayor concurrencia pero añade complejidad en la recuperación y puede incurrir en costos de rollback. Un diseño cuidadoso de la concurrencia y la gestión de recursos es esencial para mitigar este riesgo.