Transacciones - ¿Cómo evitar interbloqueos?

Question

que fue hecho esta pregunta en una entrevista # .NET/C:

Si tenemos dos hilos T1 y T2. T1 adquiere un bloqueo en obj1 y luego hace procesamiento y adquiere un bloqueo en obj2. T2 adquiere un bloqueo en obj2 y luego procesa y adquiere un bloqueo en obj1. Entonces, podemos tener un punto muerto . ¿Cuál es la técnica común que utilizamos en multihilo para evitar esta situación?

me respondió diciendo que T1 y T2 deben tener algún mecanismo para comunicarse y que deberíamos hacer la codificación de tal manera que T2 comienza a hacer su trabajo sólo después de T1 ha señalado que se hace con su trabajo. El entrevistador me preguntó si sabía sobre transacciones y cómo podemos usarlo para enfrentar esta situación de punto muerto. Tengo cierta cantidad de experiencia en subprocesos múltiples en el lado de la interfaz de usuario en winforms. Pero, nunca he usado transacciones. ¿Puede alguien decirme más sobre esto o dirigirme a una url/book,

Answer 1

Un enfoque general para evitar interbloqueos es garantizar que sus subprocesos/procesos adquieran bloqueos en los recursos en el mismo orden. por ejemplo, T2 debería bloquear obj1 primero y luego obj2 (lo mismo que T1).

De esta forma no puede tener ambos hilos con un recurso que el otro hilo desea, es decir, un interbloqueo.

Si la frase en su presupuesto fue la pregunta exacta, está mal escrita. Debe ser:

T1 adquiere un bloqueo en obj1, hace algo y luego intenta bloquear también obj2 sin desbloquear obj1. Al mismo tiempo, T2 adquiere un bloqueo en obj2, hace algo y intenta bloquear también obj1 sin desbloquear obj2. Se producirá un interbloqueo .

Recomiendo leer Concurrent Programming on Windows por Joe Duffy. Es probablemente el libro más completo sobre la teoría y la práctica de subprocesos para Windows.

Answer 2

Un enfoque es que todos los procesos deben adquirir todos los bloqueos al inicio de la transacción. Si algunos no están disponibles, el proceso libera todos los bloqueos y vuelve a intentarlos. Dependiendo de la implementación, esto aún puede llevar a livelocks.

Para ver el problema desde el otro extremo, consulte Dijkstra's banker's algorithm.

Answer 3

No estoy del todo seguro de dónde vienen las transacciones directamente en esto, aparte de la capacidad de deshacer. Lo principal de la OMI es adquirir las cerraduras en un orden consistente, y temprano; Ah, y usa un tiempo de espera cuando te encuentres con cerraduras: no te sientas ahí mirando para siempre.

La referencia a las transacciones que me hace pensar principalmente de bases de datos, en cuyo caso, otra consideración es usar trucos como UPDLOCK para asegurarse de obtener un bloqueo de escritura inicialmente para evitar problemas que promueven un (impugnada) lectura de bloqueo para una escritura - bloqueo (cambio de un bloqueo a bloqueo simple). Por supuesto, muchas bases de datos también tienen una mejor detección de punto muerto que la mayoría de los códigos regulares.

Answer 4

Creo que a lo que se refería el entrevistador es a la capacidad de deshacer una transacción. La reversión de la transacción revertirá todos los cambios realizados por la transacción como si la transacción nunca hubiera sucedido. También liberará todos los bloqueos obtenidos por él.

Ahora, cada hebra del ejemplo utiliza su propia transacción (en la base de datos, el sistema de archivos de Vista u otras interfaces que admiten transacciones). Si se produce el interbloqueo (se puede detectar fácilmente una vez que ocurre), seleccionará uno de los hilos que forman parte del punto muerto (víctima) y revertirá su transacción. Esto liberará los bloqueos para que el hilo restante pueda continuar. El hilo de la víctima podría reintentar la transacción más tarde.

Si la probabilidad del punto muerto es baja en relación con el costo de reintentar toda la transacción, esta podría ser una solución utilizable.