Question

Microsoft propose le InterlockedCompareExchange pour effectuer des opérations de comparaison et d’échange atomiques. Il existe également un _InterlockedCompareExchange intrinsèque .

Sur x86, ceux-ci sont implémentés à l'aide de l'instruction cmpxchg .

Cependant, à la lecture de la documentation relative à ces trois approches, elles ne semblent pas s’accorder sur les exigences d’alignement.

Le

manuel de référence d'Intel ne dit rien sur l'alignement (à part cela). si la vérification de l'alignement est activée et qu'une référence de mémoire non alignée est créée, une exception est générée)

J'ai également recherché le préfixe lock , qui indique spécifiquement que

  

L'intégrité du préfixe LOCK n'est pas affectée par l'alignement du champ de mémoire.

(c'est moi qui souligne)

Intel semble donc affirmer que l’alignement n’est pas pertinent. L'opération sera atomique quoi qu'il arrive.

La documentation intrinsèque _InterlockedCompareExchange ne dit rien non plus sur l'alignement, cependant la fonction InterlockedCompareExchange indique que

  

Les paramètres de cette fonction doivent être alignés sur une limite de 32 bits. sinon, la fonction se comportera de manière imprévisible sur les systèmes multiprocesseurs x86 et tous les systèmes non x86.

Alors qu'est-ce qui donne? Les exigences d’alignement pour InterlockedCompareExchange permettent-elles uniquement de s’assurer que la fonction fonctionnera même sur les UC antérieures à 486 où l’instruction cmpxchg n’est pas disponible? Cela semble probablement basé sur les informations ci-dessus, mais je voudrais être sûr avant de compter :)

Ou bien l'ISA exige-t-elle un alignement pour garantir l'atomicité, et je cherche simplement les mauvais endroits dans les manuels de référence d'Intel?

Était-ce utile?

La solution

Le PDF à partir duquel vous citez date de 1999 et est CLAIREMENT obsolète.

La documentation Intel à jour , en particulier Le volume 3a raconte une histoire différente.

Par exemple, sur un processeur Core-i7, vous devez TOUJOURS vous assurer que vos données ne s'étendent pas sur des lignes de cache, sinon l'opération n'est PAS garantie atomique.

Sur le volume 3A, Programmation système, pour Intel x86 / x64, il est clairement indiqué:

  

8.1.1 Opérations atomiques garanties

     

Le processeur Intel486 (et les processeurs les plus récents depuis) ??garantit que   les opérations de mémoire de base seront toujours effectuées de manière atomique:

     
      
  • Lecture ou écriture d'un octet
  •   
  • Lecture ou écriture d'un mot aligné sur une limite de 16 bits
  •   
  • Lecture ou écriture d'un mot double aligné sur une limite de 32 bits
  •   
     

Le processeur Pentium (et les processeurs les plus récents depuis) ??garantit que   les opérations de mémoire supplémentaires seront toujours effectuées de manière atomique:

     
      
  • Lecture ou écriture d'un mot quadrilatère aligné sur une limite de 64 bits
  •   
  • Accès 16 bits à des emplacements de mémoire non mis en cache qui tiennent dans un bus de données 32 bits
  •   
     

Les processeurs de la famille P6 (et les nouveaux processeurs depuis) ??garantissent que   les opérations de mémoire supplémentaires seront toujours effectuées de manière atomique:

     
      
  • Accès non alignés 16, 32 et 64 bits à la mémoire en mémoire cache insérée dans un cache   ligne
  •   
     

Accès à la mémoire pouvant être mise en mémoire cache divisée entre les lignes de cache et les limites de page   Intel Core 2 Duo, Intel® Atom ™, Intel Core ne sont pas garantis atomiques   Processeurs Duo, Pentium M, Pentium 4, Intel Xeon, famille P6, Pentium et Intel486.   Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon,   et les processeurs de la famille P6 fournissent des signaux de commande de bus permettant la mémoire externe   sous-systèmes pour rendre les accès fractionnés atomiques; cependant, les accès aux données non alignés seront   avoir un impact important sur les performances du processeur et doit être évité

Autres conseils

x86 ne pas requis pour l'alignement de l'instruction cmpxchg . Cependant, l'alignement est recommandé pour la performance. Cela ne devrait pas vous surprendre: la compatibilité ascendante signifie que les logiciels rédigés avec un manuel datant d’il ya 14 ans seront toujours exécutés sur les processeurs actuels.

Pourquoi exactement Microsoft exige-t-il que l'alignement ne soit pas clair dans sa documentation? Il peut s’agir de performances, de prise en charge des architectures RISC ou des deux.

  

Manuel du développeur logiciel des architectures Intel® 64 et IA-32
  Volume 3 (3A): Guide de programmation du système
  Janvier 2013

     

8.1.2.2 Verrouillage de bus commandé par logiciel

     

Pour forcer explicitement la sémantique LOCK, le logiciel peut utiliser le préfixe LOCK avec les instructions suivantes lorsqu'il est utilisé pour modifier un emplacement mémoire. [...]

     

• Les instructions d'échange (XADD, CMPXCHG et CMPXCHG8B).
  • Le préfixe LOCK est automatiquement utilisé pour l'instruction XCHG.
  • [...]

     

[...] L'intégrité d'un verrou de bus n'est pas affectée par l'alignement du   champ de mémoire. La sémantique LOCK est suivie pour autant de cycles de bus   si nécessaire pour mettre à jour l'opérande entier. Cependant, il est recommandé   que les accès verrouillés soient alignés sur leurs limites naturelles pour une meilleure   performances du système:

     

• Toute limite pour un accès 8 bits (verrouillé ou non).
  • limite de 16 bits pour les accès par mot verrouillé.
  • Limite de 32 bits pour les accès doubles mots verrouillés.
  • limite de 64 bits pour les accès quadword bloqués.

Voir cette question SO : l’alignement naturel est important pour la performance et est requis pour la Architecture x64 (donc non seulement les systèmes PRE-x86, mais aussi POST-x86 - x64 est peut-être un cas de niche, mais sa popularité ne cesse de croître ;-); C’est peut-être pour cette raison que Microsoft la documente comme il se doit (difficile de trouver des documents indiquant si MS a décidé de FORCER le problème d’alignement en activant la vérification de l’alignement - qui peut varier selon la version de Windows; en affirmant dans la documentation que cet alignement est nécessaire, MS conserve le liberté de le forcer dans certaines versions de Windows même s’ils ne l’ont pas forcé sur d’autres).

Les API interverrouillées de Microsoft s’appliquaient également à ia64 (tant qu’il existait encore). Il n'y avait pas de préfixe de verrouillage sur ia64, seulement les instructions cmpxchg.acq et cmpxchg.rel (ou fetchadd et autres beasties similaires), et elles nécessitaient toutes un alignement si je me souviens bien.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top