Pregunta

Microsoft ofrece el InterlockedCompareExchange función para realizar operaciones de comparación e intercambio atómicas. También hay un _InterlockedCompareExchange intrínseco .

En x86, estos se implementan utilizando la instrucción cmpxchg .

Sin embargo, al leer la documentación sobre estos tres enfoques, no parecen estar de acuerdo con los requisitos de alineación.

El

manual de referencia de Intel no dice nada sobre la alineación (aparte de eso si la verificación de alineación está habilitada y se realiza una referencia de memoria no alineada, se genera una excepción)

También busqué el prefijo lock , que establece específicamente que

  

La integridad del prefijo LOCK no se ve afectada por la alineación del campo de memoria.

(énfasis mío)

Entonces Intel parece decir que la alineación es irrelevante. La operación será atómica pase lo que pase.

La documentación intrínseca _InterlockedCompareExchange tampoco dice nada sobre la alineación, sin embargo, la función InterlockedCompareExchange indica que

  

Los parámetros para esta función deben estar alineados en un límite de 32 bits; de lo contrario, la función se comportará de manera impredecible en sistemas multiprocesador x86 y en cualquier sistema que no sea x86.

Entonces, ¿qué da? ¿Los requisitos de alineación para InterlockedCompareExchange son solo para asegurarse de que la función funcionará incluso en CPU anteriores a 486 donde la instrucción cmpxchg no está disponible? Parece probable que eso se base en la información anterior, pero me gustaría estar seguro antes de confiar en ella. :)

¿O la ISA requiere alineación para garantizar la atomicidad, y solo estoy buscando los lugares equivocados en los manuales de referencia de Intel?

¿Fue útil?

Solución

El PDF del que está citando es de 1999 y está CLARAMENTE desactualizado.

La documentación actualizada de Intel , específicamente Volume-3A cuenta una historia diferente.

Por ejemplo, en un procesador Core-i7, TODAVÍA tiene que asegurarse de que sus datos no se extiendan por las líneas de caché, de lo contrario, NO se garantiza que la operación sea atómica.

En el Volumen 3A, Programación del sistema, para x86 / x64 Intel establece claramente:

  

8.1.1 Operaciones atómicas garantizadas

     

El procesador Intel486 (y los procesadores más nuevos desde entonces) garantiza que lo siguiente   las operaciones básicas de memoria siempre se realizarán atómicamente:

     
      
  • Leer o escribir un byte
  •   
  • Leer o escribir una palabra alineada en un límite de 16 bits
  •   
  • Leer o escribir una palabra doble alineada en un límite de 32 bits
  •   
     

El procesador Pentium (y los procesadores más nuevos desde entonces) garantiza que lo siguiente   operaciones de memoria adicionales siempre se llevarán a cabo atómicamente:

     
      
  • Leer o escribir una palabra cuádruple alineada en un límite de 64 bits
  •   
  • accesos de 16 bits a ubicaciones de memoria sin caché que caben dentro de un bus de datos de 32 bits
  •   
     

Los procesadores de la familia P6 (y los procesadores más nuevos desde entonces) garantizan que lo siguiente   La operación de memoria adicional siempre se realizará atómicamente:

     
      
  • Accesos no alineados de 16, 32 y 64 bits a la memoria caché que se ajusta dentro de un caché   línea
  •   
     

Accesos a memoria almacenable en caché que se dividen en líneas de caché y límites de página   Intel Core 2 Duo, Intel® Atom ™, Intel Core no garantizan que sean atómicos.   Procesadores Duo, Pentium M, Pentium 4, Intel Xeon, familia P6, Pentium e Intel486.   Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon,   y los procesadores de la familia P6 proporcionan señales de control de bus que permiten memoria externa   subsistemas para hacer accesos divididos atómicos; sin embargo, los accesos de datos no alineados   afectar seriamente el rendimiento del procesador y debe evitarse

Otros consejos

x86 no requiere alineación para la instrucción cmpxchg . Sin embargo, se recomienda la alineación para el rendimiento. Esto no debería sorprendernos, la compatibilidad con versiones anteriores significa que el software escrito con un manual de hace 14 años todavía se ejecutará en los procesadores de hoy.

Por qué exactamente Microsoft requiere alineación no está claro en su documentación. Puede ser por rendimiento o para soportar arquitecturas RISC o ambas.

  

Manual del desarrollador de software de arquitecturas Intel® 64 e IA-32
  Volumen 3 (3A): Guía de programación del sistema
  Enero 2013

     

8.1.2.2 Bloqueo de bus controlado por software

     

Para forzar explícitamente la semántica LOCK, el software puede usar el prefijo LOCK con las siguientes instrucciones cuando se usan para modificar una ubicación de memoria. [...]

     

• Las instrucciones de intercambio (XADD, CMPXCHG y CMPXCHG8B).
  • El prefijo LOCK se asume automáticamente para la instrucción XCHG.
  • [...]

     

[...] La integridad de un bloqueo de bus no se ve afectada por la alineación del   campo de memoria La semántica de BLOQUEO se sigue durante tantos ciclos de bus   según sea necesario para actualizar todo el operando. Sin embargo, se recomienda   que los accesos bloqueados se alineen en sus límites naturales para mejorar   rendimiento del sistema:

     

• Cualquier límite para un acceso de 8 bits (bloqueado o no).
  • Límite de 16 bits para accesos de palabras bloqueadas.
  • Límite de 32 bits para accesos de doble palabra bloqueados.
  • Límite de 64 bits para accesos de cuatro palabras bloqueados.

Consulte esta pregunta SO : la alineación natural es importante para el rendimiento y se requiere en el arquitectura x64 (por lo que no se trata solo de sistemas PRE-x86, sino también de POST-x86; x64 aún puede ser un caso de nicho, pero después de todo está creciendo en popularidad ;-); esa puede ser la razón por la cual Microsoft lo documenta según sea necesario (es difícil encontrar documentos sobre si MS ha decidido FORZAR el problema de alineación habilitando la verificación de alineación, que puede variar según la versión de Windows; al afirmar en los documentos que se requiere alineación, MS mantiene el libertad para forzarlo en algunas versiones de Windows, incluso si no lo hicieron en otras).

Las API entrelazadas de Microsoft también se aplicaron a ia64 (mientras todavía existía). No había prefijo de bloqueo en ia64, solo las instrucciones cmpxchg.acq y cmpxchg.rel (o fetchadd y otras bestias similares), y todo esto requería alineación si recuerdo correctamente.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top