5
votes

L'ordre de modification contribue-t-il à la relation qui se produit avant?

// Thread 1
// do A
x.store(1, std::memory_order_release); // operation1

// Thread 2
// do B
x.store(2, std::memory_order_release); // operation2

// Thread 3
x.load(std::memory_order_acquire); // operation3
I've understood that if thread3 reads the value written by thread1, the release and acquire operations are synchronized-with, and effect of A is visible to thread3.
But what if the case is that:
the modification order for x is 1, 2
thread3 reads the value written by thread2, thus 2 happens-before 3.
Is there happens-before relationship between 1 and 3 ?
or intrinsically, does modification order contribute to happens-before relationship ?

c++ multithreading atomic c++11 happens-before

3 commentaires

La causalité va dans le sens inverse: " [intro.races] / 14 Si une opération A qui modifie un objet atomique M se produit avant un opération B qui modifie M , alors A doit être antérieur à B dans l'ordre de modification de M . "

C'est vrai, mais je me demande juste la visibilité de A sur 3. Comme vous ne pouvez jamais charger une valeur antérieure dans l'ordre de modification, cela signifie-t-il que A est visible par 3?

Si le fil 3 lit B, alors comment savez-vous que A précède B dans l'ordre de modification en premier lieu? Pourquoi pensez-vous cela? Pourquoi est-il même important que A se produise - avant une lecture dans le thread 3 - comment un programme conforme peut-il faire la différence? L'ordre de modification n'est pas en soi un comportement observable - c'est juste un outil pour raisonner sur quel comportement observable est ou n'est pas possible lorsque la machine abstraite non déterministe exécute un programme particulier.

3 Réponses :

0
votes

Dans votre exemple, vous montrez le thread 1 et le thread 2 fonctionnant tous les deux sur x exactement de la même manière. Par conséquent, la relation entre le thread 1 et le thread 3 doit être exactement la même que la relation entre le thread 2 et le thread 3.

Votre exemple ne montre pas de lignes de code qui contraindraient l'ordre dans lequel les trois opérations se produiraient réellement. En d'autres termes, rien qu'en regardant ces trois instructions, il n'y a aucun moyen de dire si l'opération de chargement renverrait 1 , ou 2 , ou une valeur précédente de x .

0 commentaires

1
votes

Si je comprends bien votre question, non, il n'y a aucune garantie supplémentaire sur la commande globale en raison de la commande de mémoire que vous utilisez. Il n'y a aucun blocage pour permettre que cela se produise.

0 commentaires

4
votes

Non. il n'y a pas de relation entre l'opération 1 et l'opération 3.

Depuis [atomics.order] / 2 :

Une opération atomique A qui effectue une opération de libération sur un atomique l'objet M se synchronise avec une opération atomique B qui effectue un acquérir l'opération sur M et prend sa valeur de tout effet secondaire dans le séquence de publication dirigée par A.

... et malheureusement, l'opération 2 ne fait pas partie de la séquence de publication dirigée par l'opération 1 selon [intro.races] / 5 :

Une séquence de libération dirigée par une opération de libération A sur un objet atomique M est une sous-séquence maximale contiguë d'effets secondaires dans l'ordre de modification de M, où la première opération est A, et chaque opération suivante est une opération atomique de lecture-modification-écriture .

En conséquence, nous ne pouvons pas créer de relation inter-thread-before entre l'opération 1 et d'autres opérations, il n'y a donc pas de qui se produit avant relation entre l'opération 1 et l'opération 3.

0 commentaires