Les «courses de données» et les «conditions de concurrence» sont-elles en fait la même chose dans le contexte d'une programmation simultanée
Je trouve souvent ces termes utilisés dans le contexte d'une programmation simultanée. Sont-ils la même chose ou différents?
Non, ils ne sont pas la même chose. Ils ne sont pas un sous-ensemble les uns des autres. Ils ne sont pas non plus la condition nécessaire ni suffisante pour l'autre.
La définition d'une course aux données est assez claire et, par conséquent, sa découverte peut être automatisée. Une course aux données se produit lorsque 2 instructions de threads différents accèdent au même emplacement mémoire, au moins l'un de ces accès est une écriture et il n'y a pas de synchronisation qui en rend obligatoire ordre particulier parmi ces accès.
Une condition de concurrence est une erreur sémantique. C'est une faille qui se produit dans le timing ou l'ordre des événements qui conduit à un comportement erroné du programme. De nombreuses conditions de course peuvent être causées par des courses de données, mais ce n'est pas nécessaire.
Prenons l'exemple simple suivant où x est une variable partagée:
Thread 1 Thread 2
lock(l) lock(l)
x=1 x=2
unlock(l) unlock(l)
Dans cet exemple, les écritures sur x à partir des threads 1 et 2 sont protégées par des verrous, donc elles se produisent toujours dans un ordre imposé par l'ordre avec lequel les verrous sont acquis au moment de l'exécution. Autrement dit, l'atomicité des écritures ne peut pas être rompue; il y a toujours un événement avant que la relation entre les deux écritures ne soit exécutée. Nous ne pouvons tout simplement pas savoir quelle écriture se produit avant l'autre a priori.
Il n'y a pas d'ordre fixe entre les écritures, car les verrous ne peuvent pas fournir cela. Si l'exactitude des programmes est compromise, par exemple lorsque l'écriture sur x par le thread 2 est suivie par l'écriture sur x dans le thread 1, nous disons qu'il y a une condition de concurrence, bien que techniquement il n'y ait pas de course de données.
Il est beaucoup plus utile de détecter les conditions de course que les courses de données; mais cela est également très difficile à réaliser.
La construction de l'exemple inverse est également triviale. This blog post explique également très bien la différence, avec un simple exemple de transaction bancaire.
Selon Wikipedia, le terme "condition de concurrence" est utilisé depuis l'époque des premières portes logiques électroniques. Dans le contexte de Java, une condition de concurrence critique peut concerner n'importe quelle ressource, telle qu'un fichier, une connexion réseau, un thread d'un pool de threads, etc.
Le terme "course aux données" est mieux réservé à sa signification spécifique définie par le JLS .
Le cas le plus intéressant est une condition de concurrence qui est très similaire à une course de données, mais n'en est toujours pas une, comme dans cet exemple simple:
class Race {
static volatile int i;
static int uniqueInt() { return i++; }
}
Puisque i est volatile, il n'y a pas de course aux données; cependant, du point de vue de l'exactitude du programme, il existe une condition de concurrence due à la non-atomicité des deux opérations: lire i, écrire i+1. Plusieurs threads peuvent recevoir la même valeur de uniqueInt.
Non, ils sont différents et aucun d'eux n'est un sous-ensemble de l'un ou vice-versa.
Le terme condition de concurrence est souvent confondu avec le terme race de données associé, qui survient lorsque la synchronisation n'est pas utilisée pour coordonner tous les accès à un champ non final partagé. Vous risquez une course aux données chaque fois qu'un thread écrit une variable qui pourrait ensuite être lue par un autre thread ou lit une variable qui pourrait avoir été écrite en dernier par un autre thread si les deux threads n'utilisent pas la synchronisation; le code avec les courses de données n'a pas de sémantique définie utile sous le modèle de mémoire Java. Toutes les conditions de course ne sont pas des courses de données, et toutes les courses de données ne sont pas des conditions de course, mais elles peuvent toutes deux entraîner l'échec de programmes simultanés de manière imprévisible.
Tiré de l'excellent livre - Java Concurrency in Practice par Joshua Bloch & Co.