Le protocole MESI est-il suffisant ou des barrières de mémoire sont-elles encore nécessaires? (Les Processeurs Intel)
j'ai trouvé un document intel qui stipule que les barrières mémoire sont nécessaires lorsque la chaîne de caractères (pas std::string
, mais des instructions de chaîne de montage) est utilisée, pour éviter qu'elles ne soient ré-ordonnées par le CPU.
cependant, des barrières de mémoire sont-elles également nécessaires lorsque deux fils (sur deux cœurs différents) accèdent à la même mémoire? Le scénario que j'avais à l'esprit est celui où l'un des CPU qui ne "possède" pas la ligne de cache écrit à cette mémoire et le noyau écrit à son tampon de stockage. (par opposition à son cache). Une barrière de mémoire est nécessaire pour purger la valeur de la mémoire tampon vers le cache, de sorte que l'autre noyau puisse obtenir cette valeur?
Je ne suis pas sûr que, sur Intel, le protocole MESI gère cela?
(ce que j'ai essayé (mal) d'expliquer ci-dessus est mieux-décrit dans le papier ci-dessous, pages 6-12):
http://www.puppetmastertrading.com/images/hwViewForSwHackers.pdf
le papier ci-dessus est très général et je ne sais pas comment Intel CPUs pratiquement gérer le problème.
2 réponses
les protocoles MESI s'appliquent aux caches, le stockage tampon est essentiellement pré-cache, ce qui signifie que c'est un magasin qui n'a pas encore été "libéré" dans le monde extérieur, et son point de synchronisation n'a pas encore été déterminé.
vous devez également garder à l'esprit que la cohérence de cache garantit seulement que les Écritures ne se produisent pas sur des copies périmées d'une ligne de sécurité et se perdent en cours de route. La seule garantie de tels protocoles est de cacher le fait que vous avez des caches avec des valeurs copiées (un l'optimisation des performances en soi), et exposer au programmeur / OS l'illusion d'une mémoire physique plate à un seul niveau.
qui, par lui-même, ne vous donne aucune garantie sur l'ordre des Écritures et des lectures à partir de plusieurs cœurs, à cette fin, vous devez gérer votre code en utilisant des constructions supplémentaires que L'ISA fournit, comme les serrures, les clôtures, et en se basant sur les règles de commande de mémoire.
la situation que vous décrivez n'est pas possible car elle casse la première partie-un noyau qui ne possède pas de ligne ne peut pas écrire en mémoire car il manquerait les données mises à jour dans le noyau qui possède la ligne (si tel existe). Ce qui se produirait dans le cadre d'un protocole MESI, c'est que l'écriture sera amortie pendant un certain temps, et lorsque son tour sera émis - il enverrait une demande de propriété qui invaliderait toutes les copies de cette ligne dans d'autres noyaux (déclenchant un retour en arrière s'il y a une copie modifiée), et récupérerait les données mises à jour. Alors seulement, l'écrivain de base peut modifier la alignez et marquez comme modifié.
cependant, si 2 cœurs écrivent simultanément sur la même ligne, le protocole MESI garantit seulement que ces Écritures auront un certain ordre, pas un ordre spécifique que vous pourriez vouloir. Pire - si chaque noyau écrire plusieurs lignes et vous voulez atomicité autour de ces écrits, MESI ne garantit pas que. Vous aurez besoin d'ajouter activement un mutex ou une barrière de quelque sorte pour forcer le HW à effectuer les Écritures de la façon que vous voulez.
je pense que vous parlez D'ERMSB (fast strings) dans Intel IvB et plus tard faire rep movs
utiliser des Écritures faiblement ordonnées.
ma conclusion des Docs D'Intel est que vous n'avez toujours pas besoin de SFENCE
pour commander ces magasins par rapport à autres magasins, et bien sûr, vous ne pouvez pas exécuter SFENCE au milieu d'un rep movsb
. Voyez cette réponse pour plus de choses en général sur les barrières de mémoire sur x86.
AFAICT, tout ce que vous devez faire est d'éviter d'utiliser le même rep movs
pour écrire un tampon et le drapeau que les lecteurs vérifieront pour voir si le tampon est prêt. Un lecteur pourrait voir le drapeau avant que tous les magasins de la zone tampon soient visibles pour lui. C'est la seule façon dont la nouvelle fonctionnalité ERMSB affecte l'exactitude, pour les programmes qui étaient déjà corrects (c'est-à-dire qui ne dépendaient pas des effets de synchronisation). Il a un effet positif sur la performance pour memcpy / memset.