Diferencia entre condición de carrera y punto muerto

Question

¿Cuál es la diferencia entre un bloqueo muerto y una condición de carrera en términos de programación?

Answer 1

Piense en una condición de carrera utilizando el ejemplo tradicional. Supongamos que usted y un amigo tienen tarjetas de cajero automático para la misma cuenta bancaria. Ahora supongamos que la cuenta tiene $ 100. Considere lo que sucede cuando intenta retirar $ 10 y su amigo intenta retirar $ 50 al mismo tiempo.

Piensa en lo que debe suceder. El cajero automático debe tomar su entrada, leer lo que está actualmente en su cuenta, y luego modificar la cantidad. Tenga en cuenta que, en términos de programación, una instrucción de asignación es un proceso de varios pasos.

Por lo tanto, marque sus dos transacciones T1 (retira $ 10) y T2 (su amigo retira $ 50). Ahora, los números a continuación, a la izquierda, representan los pasos de tiempo.

 T1      T2 
     ----------------   ------------------------ 
1. Read Acct ($100)   
2.        Read Acct ($100) 
3. Write New Amt ($90) 
4.        Write New Amt ($50) 
5.        End 
6. End 

Después de que ambas transacciones completas, usando esta línea de tiempo, lo cual es posible si no se utiliza ningún tipo de mecanismo de bloqueo, la cuenta tiene $ 50 en él. Esto es $ 10 más de lo que debería (su transacción se pierde para siempre, pero todavía tiene el dinero).

Se trata de una condición de carrera llamada. Lo que desea es que la transacción sea serializable, es decir, independientemente de cómo se entrelacen las ejecuciones de instrucción individuales, el resultado final será exactamente el mismo que algún horario serie (lo que significa que los ejecuta uno después del otro con sin entrelazado) de las mismas transacciones. La solución, nuevamente, es introducir el bloqueo; sin embargo, un bloqueo incorrecto puede conducir a un bloqueo muerto.

El bloqueo se produce cuando hay un conflicto de un recurso compartido. Es una especie de Catch-22.

T1   T2 
    -------  -------- 
1. Lock(x) 
2.    Lock(y) 
3. Write x=1 
4.    Write y=19 
5. Lock(y) 
6. Write y=x+1 
7.    Lock(x) 
8.    Write x=y+2 
9. Unlock(x) 
10.    Unlock(x) 
11. Unlock(y) 
12.    Unlock(y) 

se puede ver que se produce un interbloqueo en el momento T2 7, porque intenta adquirir un bloqueo en x pero T1 ya es titular de la cerradura de x pero está esperando en un bloqueo para y, que sostiene T2.

Esto malo. Puede convertir este diagrama en un gráfico de dependencia y verá que hay un ciclo. El problema aquí es que xey son recursos que pueden modificarse juntos.

Una forma de evitar este tipo de problema de interbloqueo con múltiples objetos de bloqueo (recursos) es introducir un pedido. Verá, en el ejemplo anterior, T1 bloqueó x y luego y pero T2 bloqueó y y luego x. Si ambas transacciones se adhieren aquí a alguna regla de pedido que dice "x siempre estará bloqueado antes de y", entonces este problema no ocurrirá. (Puede cambiar el ejemplo anterior teniendo en cuenta esta regla y ver que no se produce un punto muerto).

Estos son ejemplos triviales y realmente acabo de utilizar los ejemplos que ya has visto si has realizado algún tipo de curso de pregrado en esto. En realidad, resolver problemas de interbloqueo puede ser mucho más difícil porque tiende a tener más de un par de recursos y un par de transacciones interactuando.

Espero que esto ayude un poco. Como siempre, usar Wikipedia como punto de partida para los conceptos CS:

http://en.wikipedia.org/wiki/Deadlock

http://en.wikipedia.org/wiki/Race_condition

Answer 2

supongo que te refieres "condiciones de carrera" y no "de carreras alrededor de condiciones" (He oído ese término ...)

Básicamente, un bloqueo de la muerte es una condición en la que el hilo está esperando un recurso X mientras mantiene un bloqueo en el recurso Y, y el subproceso B está esperando el recurso Y mientras mantiene un bloqueo en el recurso X. Los subprocesos bloquean esperando que el otro libere sus bloqueos.

La solución a este problema es (por lo general) para asegurarse de tomar bloqueos en todos los recursos en el mismo orden en todos los hilos. Por ejemplo, si siempre bloquea el recurso X antes del recurso Y, entonces mi ejemplo nunca puede provocar un interbloqueo.

Una condición de carrera es algo en lo que confía en una secuencia particular de eventos que suceden en un cierto orden, pero que puede dañarse si se está ejecutando otro subproceso al mismo tiempo. Por ejemplo, para insertar un nuevo nodo en una lista enlazada, es necesario modificar el cabeza de lista, por lo general algo así:

newNode->next = listHead; 
listHead = newNode; 

Pero si dos hilos de hacerlo al mismo tiempo, entonces es posible que tenga una situación donde se ejecutan de esta manera:

Thread A      Thread B 
newNode1->next = listHead 
           newNode2->next = listHead 
           listHead = newNode2 
listHead = newNode1 

Si esto llegara a suceder, luego pase modificación de la lista de B se perderá debido Tema a hubiera sobrescrito él. Puede ser aún peor, dependiendo de la situación exacta, pero eso es lo básico.

La solución a este problema suele ser asegurarse de incluir los mecanismos de bloqueo adecuados (por ejemplo, sacar un bloqueo cada vez que desee modificar la lista vinculada para que solo un hilo lo modifique a la vez).

Answer 3

Un punto muerto es cuando dos (o más) subprocesos se bloquean entre sí. Por lo general, esto tiene algo que ver con los hilos que intentan adquirir recursos compartidos. Por ejemplo, si los hilos T1 y T2 necesitan adquirir los recursos A y B para hacer su trabajo. Si T1 adquiere el recurso A, entonces T2 adquiere el recurso B, T1 podría estar esperando el recurso B mientras T2 esperaba el recurso A. En este caso, ambos hilos esperarán indefinidamente por el recurso que tiene el otro hilo. Se dice que estos hilos están estancados.

Las condiciones de carrera se producen cuando dos hilos interactúan de forma negativa (con errores) dependiendo del orden exacto en que se ejecutan sus diferentes instrucciones. Si un hilo establece una variable global, por ejemplo, un segundo hilo lee y modifica esa variable global, y el primer hilo lee la variable, el primer hilo puede experimentar un error porque la variable ha cambiado inesperadamente.