Ok merci,
Je pense que je vais avoir besoin d'un expert X86, parce que je lis des choses assez contradictoires sur le sujet. D'un coté, je comprends qu'il existe des protocoles de cohérence de cache et des mécanismes de communication inter-caches pour fournir aux autres coeurs des valeurs modifiées par un coeur, et d'un autre coté, je lis que l'on peut parfois obtenir r2 == 0 et r4 == 0 à la fin de l'exemple suivant:
Code:
x = 0, y = 0
Processor 0 Processor 1
mov [_x], 1 mov [_y], 1
mov r1, [_x] mov r3, [_y]
mov r2, [_y] mov r4, [_x]
Hors, autant j'ai plus ou moins compris que le CPU avait le droit de faire des load/store dans le sens qu'il a envie tant que ça touche des endroits différents, autant là ça me contrarie (d'autant plus qu'en ajoutant un load sur la même addresse, après le store initial, on oblige le CPU à executer le tout dans l'ordre):
Supposons que r2 == 0 à la fin, ça signifie que du point de vue de proc 0, le proc 1 n'a encore rien executé. Quand il va executer son store/load y, puis load x, le load x devrait être intercepté par le mécanisme de snoop du protocole MESI et proc 0 devrait fournir la valeur modifiée de x, donc r4 == 1, non ?
---------- Post added at 00h24 ---------- Previous post was at 23h47 ----------
Je viens de découvrir l'existence des write buffers en lisant la doc AMD64, je pense que c'est ça qui pose problème dans l'exemple que je citais.
Les opérations en write buffer ne sont pas reflétés dans le cache tant que le buffer n'est pas flushé, mais un load va vérifier dans le write buffer local si une valeur sera été modifiée () plus tard avant de vérifier dans le cache (c'est là que le bât blesse, on ne vérifie que le write buffer du CPU ou est executé le load?). Si tout se passe dans le write buffer, le cache ne voit rien et le résultat est bien r2 == 0 et r4 == 0. C'est un peu retour vers le futur...