Estado en el que los miembros se bloquean entre sí
En computación concurrente , un bloqueo es cualquier situación en la que ningún miembro de algún grupo de entidades puede continuar porque cada uno espera que otro miembro, incluido él mismo, realice una acción, como enviar un mensaje o, más comúnmente, liberar un bloqueo . [1] Los bloqueos son un problema común en sistemas de multiprocesamiento , computación paralela y sistemas distribuidos , porque en estos contextos los sistemas a menudo usan bloqueos de software o hardware para arbitrar recursos compartidos e implementar la sincronización de procesos . [2]
En un sistema operativo , un bloqueo ocurre cuando un proceso o subproceso entra en un estado de espera porque un recurso del sistema solicitado está en poder de otro proceso en espera, que a su vez está esperando otro recurso en poder de otro proceso en espera. [3] Si un proceso permanece indefinidamente incapaz de cambiar su estado porque los recursos que solicita están siendo utilizados por otro proceso que a su vez está esperando, entonces se dice que el sistema está en un bloqueo. [4]
En un sistema de comunicaciones , los bloqueos ocurren principalmente debido a la pérdida o corrupción de señales más que a la disputa por los recursos. [5]
Condiciones individualmente necesarias y conjuntamente suficientes para el estancamiento
Una situación de bloqueo en un recurso solo puede surgir si todas las siguientes condiciones ocurren simultáneamente en un sistema: [6]
Exclusión mutua : no se pueden compartir varios recursos; solo un proceso a la vez puede usar cada recurso. [7] [8]
Retener y esperar o retención de recursos: un proceso actualmente retiene al menos un recurso y solicita recursos adicionales que están retenidos por otros procesos.
Sin prelación : un recurso sólo puede ser liberado voluntariamente por el proceso que lo posee.
Espera circular: cada proceso debe estar esperando un recurso que está en poder de otro proceso, que a su vez está esperando que el primer proceso libere el recurso. En general, hay un conjunto de procesos en espera, P = { P 1 , P 2 , ..., P N }, de modo que P 1 está esperando un recurso en poder de P 2 , P 2 está esperando un recurso en poder de P 3 y así sucesivamente hasta que P N está esperando un recurso en poder de P 1 . [4] [9]
Estas cuatro condiciones se conocen como condiciones de Coffman desde su primera descripción en un artículo de 1971 de Edward G. Coffman, Jr. [9]
Si bien estas condiciones son suficientes para producir un bloqueo en sistemas de recursos de instancia única, solo indican la posibilidad de bloqueo en sistemas que tienen múltiples instancias de recursos. [10]
Manejo de bloqueos
La mayoría de los sistemas operativos actuales no pueden evitar los bloqueos. [11] Cuando se produce un bloqueo, los distintos sistemas operativos responden a ellos de maneras no estándar. La mayoría de los enfoques funcionan evitando que se produzca una de las cuatro condiciones de Coffman , especialmente la cuarta. [12] Los enfoques principales son los siguientes.
Ignorando el punto muerto
En este enfoque, se supone que nunca se producirá un bloqueo. Esta es también una aplicación del algoritmo Ostrich . [12] [13] Este enfoque fue utilizado inicialmente por MINIX y UNIX . [9] Esto se utiliza cuando los intervalos de tiempo entre las ocurrencias de bloqueos son grandes y la pérdida de datos incurrida cada vez es tolerable.
Se puede ignorar los bloqueos si se demuestra formalmente que nunca ocurren. Un ejemplo es el marco RTIC. [14]
Detección
En el marco de la detección de interbloqueos, se permite que se produzcan. A continuación, se examina el estado del sistema para detectar que se ha producido un interbloqueo y, posteriormente, se corrige. Se emplea un algoritmo que realiza un seguimiento de la asignación de recursos y de los estados de los procesos, revierte y reinicia uno o más de los procesos para eliminar el interbloqueo detectado. Detectar un interbloqueo que ya se ha producido es fácilmente posible, ya que el programador de recursos del sistema operativo conoce los recursos que cada proceso ha bloqueado y/o solicitado actualmente. [13]
Una vez detectado un bloqueo, se puede corregir mediante uno de los siguientes métodos: [ cita requerida ]
Terminación de proceso: se pueden abortar uno o más procesos involucrados en el punto muerto. Se podría elegir abortar todos los procesos en competencia involucrados en el punto muerto. Esto garantiza que el punto muerto se resuelva con certeza y rapidez. [ cita requerida ] Pero el costo es alto ya que se perderán cálculos parciales. O bien, se podría elegir abortar un proceso a la vez hasta que se resuelva el punto muerto. Este enfoque tiene una gran sobrecarga porque después de cada aborto un algoritmo debe determinar si el sistema todavía está en punto muerto. [ cita requerida ] Se deben considerar varios factores al elegir un candidato para la terminación, como la prioridad y la antigüedad del proceso. [ cita requerida ]
Prelación de recursos: los recursos asignados a varios procesos pueden ser prendidos y asignados sucesivamente a otros procesos hasta que se rompa el punto muerto. [15] [ verificación fallida ]
Prevención
La prevención de bloqueo funciona impidiendo que se produzca una de las cuatro condiciones de Coffman.
Eliminar la condición de exclusión mutua significa que ningún proceso tendrá acceso exclusivo a un recurso. Esto resulta imposible para los recursos que no se pueden poner en cola . Pero incluso con recursos en cola, el bloqueo podría ocurrir. Los algoritmos que evitan la exclusión mutua se denominan algoritmos de sincronización sin bloqueo .
Las condiciones de retención y espera o de retención de recursos se pueden eliminar al exigir a los procesos que soliciten todos los recursos que necesitarán antes de comenzar (o antes de embarcarse en un conjunto particular de operaciones). Este conocimiento previo es con frecuencia difícil de satisfacer y, en cualquier caso, es un uso ineficiente de los recursos. Otra forma es exigir a los procesos que soliciten recursos solo cuando no tienen ninguno; primero, deben liberar todos los recursos que tienen actualmente antes de solicitar todos los recursos que necesitarán desde cero. Esto también es a menudo poco práctico. Es así porque los recursos pueden asignarse y permanecer sin usar durante largos períodos. Además, un proceso que requiere un recurso popular puede tener que esperar indefinidamente, ya que dicho recurso siempre puede asignarse a algún proceso, lo que resulta en una falta de recursos . [16] (Estos algoritmos, como la serialización de tokens , se conocen como algoritmos de todo o nada ).
La condición de no prelación también puede ser difícil o imposible de evitar, ya que un proceso debe poder disponer de un recurso durante una determinada cantidad de tiempo, o el resultado del procesamiento puede ser inconsistente o puede producirse una superación . Sin embargo, la incapacidad de hacer cumplir la prelación puede interferir con un algoritmo de prioridad . La prelación de un recurso "bloqueado" generalmente implica una reversión y se debe evitar ya que es muy costosa en términos de gastos generales. Los algoritmos que permiten la prelación incluyen algoritmos sin bloqueo y sin espera y control de concurrencia optimista . Si un proceso tiene algunos recursos y solicita otros recursos que no se le pueden asignar de inmediato, la condición se puede eliminar liberando todos los recursos que se tienen actualmente en ese proceso.
La condición final es la condición de espera circular . Los enfoques que evitan las esperas circulares incluyen la desactivación de interrupciones durante secciones críticas y el uso de una jerarquía para determinar un orden parcial de los recursos. Si no existe una jerarquía obvia, incluso se ha utilizado la dirección de memoria de los recursos para determinar el orden y los recursos se solicitan en el orden creciente de la enumeración. [4] También se puede utilizar la solución de Dijkstra .
Prevención de bloqueos
De manera similar a la prevención de interbloqueos, el enfoque de evitación de interbloqueos garantiza que no se produzcan interbloqueos en un sistema. El término "evitación de interbloqueos" parece ser muy similar a "prevención de interbloqueos" en un contexto lingüístico, pero son muy diferentes en el contexto del manejo de interbloqueos. La evitación de interbloqueos no impone ninguna condición como se ve en la prevención, pero aquí cada solicitud de recurso se analiza cuidadosamente para ver si se puede cumplir de manera segura sin causar un interbloqueo.
La prevención de bloqueos requiere que el sistema operativo reciba de antemano información adicional sobre qué recursos solicitará y utilizará un proceso durante su vida útil. El algoritmo de prevención de bloqueos analiza todas y cada una de las solicitudes examinando que no haya posibilidad de que se produzca un bloqueo en el futuro si se asigna el recurso solicitado. El inconveniente de este enfoque es que requiere información de antemano sobre cómo se solicitarán los recursos en el futuro. Uno de los algoritmos de prevención de bloqueos más utilizados es el algoritmo de Banker . [17]
Bloqueo de vida
Un bloqueo activo es similar a un bloqueo mutuo, excepto que los estados de los procesos involucrados en el bloqueo activo cambian constantemente unos con respecto a otros y ninguno progresa.
El término fue acuñado por Edward A. Ashcroft en un artículo de 1975 [18] en relación con un examen de los sistemas de reserva de aerolíneas. [19] Livelock es un caso especial de escasez de recursos ; la definición general solo establece que un proceso específico no está progresando. [20]
El bloqueo activo es un riesgo que presentan algunos algoritmos que detectan y se recuperan de un bloqueo . Si más de un proceso realiza una acción, el algoritmo de detección de bloqueo puede activarse repetidamente. Esto se puede evitar garantizando que solo un proceso (elegido arbitrariamente o por prioridad) realice una acción. [21]
Los bloqueos distribuidos se pueden detectar construyendo un gráfico de espera global a partir de gráficos de espera locales en un detector de bloqueos o mediante un algoritmo distribuido como la búsqueda de bordes.
Los interbloqueos fantasma son interbloqueos que se detectan de forma errónea en un sistema distribuido debido a retrasos internos del sistema, pero que en realidad no existen. Por ejemplo, si un proceso libera un recurso R1 y emite una solicitud para R2 , y el primer mensaje se pierde o se retrasa, un coordinador (detector de interbloqueos) podría concluir erróneamente que existe un interbloqueo (si la solicitud para R2 mientras se tiene R1 provocaría un interbloqueo).
^ Coulouris, George (2012). Conceptos y diseño de sistemas distribuidos . Pearson. pág. 716. ISBN.978-0-273-76059-7.
^ Padua, David (2011). Enciclopedia de computación paralela. Springer. pág. 524. ISBN9780387097657Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ Falsafi, Babak; Midkiff, Samuel; Dennis, Jack B; Dennis, Jack B; Ghoting, Amol; Campbell, Roy H; Klausecker, Christof; Kranzlmüller, Dieter; Emer, Joel; Fossum, Tryggve; Smith, Burton; Philippe, Bernard; Sameh, Ahmed; Irigoin, François; Feautrier, Paul; Praun, Christoph von; Bocchino, Robert L.; Snir, Marc; George, Thomas; Sarin, Vivek; Jann, Joefon (2011). "Bloqueos". Enciclopedia de computación paralela . Boston, MA: Springer US. págs. 524–527. doi :10.1007/978-0-387-09766-4_282. ISBN 978-0-387-09766-4_282 .978-0-387-09765-7. S2CID 241456017. Un interbloqueo es una condición que puede ocurrir en un sistema compuesto por múltiples procesos que pueden acceder a recursos compartidos. Se dice que se produce un interbloqueo cuando dos o más procesos esperan que el otro libere un recurso. Ninguno de los procesos puede avanzar.
^ abc Silberschatz, Abraham (2006). Principios de sistemas operativos (7.ª ed.). Wiley-India. pág. 237. ISBN9788126509621Archivado del original el 25 de enero de 2022 . Consultado el 16 de octubre de 2020 .
^ Schneider, G. Michael (2009). Invitación a la informática. Cengage Learning. pág. 271. ISBN978-0324788594Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ Silberschatz, Abraham (2006). Principios de sistemas operativos (7.ª ed.). Wiley-India. pág. 239. ISBN9788126509621Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ "ECS 150 Primavera 1999: Cuatro condiciones necesarias y suficientes para el bloqueo". nob.cs.ucdavis.edu . Archivado desde el original el 29 de abril de 2018 . Consultado el 29 de abril de 2018 .
^ abc Shibu, K. (2009). Introducción a los sistemas integrados (1.ª ed.). Tata McGraw-Hill Education. pág. 446. ISBN9780070145894Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ "Sistemas operativos: bloqueos". www.cs.uic.edu . Archivado desde el original el 28 de mayo de 2020 . Consultado el 25 de abril de 2020 . Si una categoría de recursos contiene más de una instancia, la presencia de un ciclo en el gráfico de asignación de recursos indica la posibilidad de un bloqueo, pero no lo garantiza. Considere, por ejemplo, las figuras 7.3 y 7.4 a continuación:
^ Silberschatz, Abraham (2006). Principios de sistemas operativos (7.ª ed.). Wiley-India. pág. 237. ISBN9788126509621Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ ab Stuart, Brian L. (2008). Principios de los sistemas operativos (1.ª ed.). Cengage Learning. pág. 446. ISBN9781418837693Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ ab Tanenbaum, Andrew S. (1995). Sistemas operativos distribuidos (1.ª ed.). Pearson Education. pág. 117. ISBN9788177581799Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ "Prefacio - Concurrencia impulsada por interrupciones en tiempo real". Archivado desde el original el 18 de septiembre de 2020 . Consultado el 1 de octubre de 2020 .
^ "IBM Knowledge Center". www.ibm.com . Archivado desde el original el 19 de marzo de 2017 . Consultado el 29 de abril de 2018 .
^ Silberschatz, Abraham (2006). Principios de sistemas operativos (7.ª ed.). Wiley-India. pág. 244. ISBN9788126509621Archivado del original el 18 de abril de 2021 . Consultado el 16 de octubre de 2020 .
^ "Algoritmos para evitar bloqueos en sistemas operativos (OS)". Electronics Mind . 26 de enero de 2022.
^ Ashcroft, EA (1975). "Probar afirmaciones sobre programas paralelos". Journal of Computer and System Sciences . 10 : 110–135. doi : 10.1016/S0022-0000(75)80018-3 .
^ Kwong, YS (1979). "Sobre la ausencia de bloqueos activos en programas paralelos". Semántica de computación concurrente . Apuntes de clase en informática. Vol. 70. págs. 172–190. doi :10.1007/BFb0022469. ISBN.3-540-09511-X.
^ Anderson, James H. ; Yong-jik Kim (2001). «Exclusión mutua en memoria compartida: principales tendencias de investigación desde 1986». Archivado desde el original el 25 de mayo de 2006.
^ Zöbel, Dieter (octubre de 1983). "El problema del bloqueo: una bibliografía clasificatoria". ACM SIGOPS Operating Systems Review . 17 (4): 6–15. doi : 10.1145/850752.850753 . ISSN 0163-5980. S2CID 38901737.
Lectura adicional
Kaveh, Nima; Emmerich, Wolfgang. "Detección de bloqueos en sistemas de objetos distribuidos" (PDF) . Londres: University College London. {{cite journal}}: Requiere citar revista |journal=( ayuda )
Bensalem, Saddek; Fernandez, Jean-Claude; Havelund, Klaus; Mounier, Laurent (2006). "Confirmación de potenciales de bloqueo detectados por análisis de tiempo de ejecución". Actas del taller de 2006 sobre sistemas paralelos y distribuidos: pruebas y depuración . ACM. págs. 41–50. CiteSeerX 10.1.1.431.3757 . doi :10.1145/1147403.1147412. ISBN .978-1595934147. Número de identificación del sujeto 2544690.
Coffman, Edward G. Jr.; Elphick, Michael J.; Shoshani, Arie (1971). "Bloqueos del sistema" (PDF) . Encuestas de computación de ACM . 3 (2): 67–78. doi :10.1145/356586.356588. S2CID 15975305.
Mogul, Jeffrey C.; Ramakrishnan, KK (1997). "Eliminación del bloqueo activo de recepción en un núcleo controlado por interrupciones". ACM Transactions on Computer Systems . 15 (3): 217–252. CiteSeerX 10.1.1.156.667 . doi :10.1145/263326.263335. ISSN 0734-2071. S2CID 215749380.
Havender, James W. (1968). "Cómo evitar el bloqueo en sistemas multitarea". IBM Systems Journal . 7 (2): 74. doi :10.1147/sj.72.0074. Archivado desde el original el 24 de febrero de 2012 . Consultado el 27 de enero de 2009 .
Holliday, JoAnne L.; El Abbadi, Amr. «Distributed Deadlock Detection». Encyclopedia of Distributed Computing . Archivado desde el original el 2 de noviembre de 2015. Consultado el 29 de diciembre de 2004 .
Knapp, Edgar (1987). "Detección de bloqueos en bases de datos distribuidas". ACM Computing Surveys . 19 (4): 303–328. CiteSeerX 10.1.1.137.6874 . doi :10.1145/45075.46163. ISSN 0360-0300. S2CID 2353246.
Ling, Yibei; Chen, Shigang; Chiang, Jason (2006). "Sobre la programación óptima de detección de interbloqueos". IEEE Transactions on Computers . 55 (9): 1178–1187. CiteSeerX 10.1.1.259.4311 . doi :10.1109/tc.2006.151. S2CID 7813284.
Enlaces externos
"Sincronización avanzada en subprocesos Java" por Scott Oaks y Henry Wong
Agentes de detección de bloqueos
DeadLock en el repositorio de patrones de Portland