requisitos de alineación para atomic x86 instructions

Question

Microsoft ofrece la función InterlockedCompareExchange para realizar operaciones atómicas de comparación e intercambio. También hay un _InterlockedCompareExchangeintrí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.

de Intel reference manual dice nada acerca de la alineación (excepto los de comprobación si alineación está habilitado y una referencia de memoria no alineado se hace, se genera una excepción)

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

la integridad del prefijo LOCK es no afectados por la alineación del campo de memoria.

(el énfasis es mío)

Así Intel parece decir que la alineación es irrelevante. La operación será atómica sin importar qué.

La documentación intrínseca _InterlockedCompareExchange tampoco dice nada sobre la alineación, sin embargo la función InterlockedCompareExchange establece 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 forma impredecible en sistemas multiprocesador x86 y cualquier sistema que no sea x86.

¿Qué ofrece? ¿Los requisitos de alineación para InterlockedCompareExchange solo son para asegurarse de que la función funcionará incluso en CPUs pre-486 donde la instrucción cmpxchg no está disponible? Eso parece estar basado en la información anterior, pero me gustaría estar seguro antes de confiar en él. :)

¿O es la alineación requerida por el ISA para garantizar la atomicidad, y solo estoy buscando los lugares incorrectos en los manuales de referencia de Intel?

Answer 1

El PDF you are quoting from es de 1999 y CLARAMENTE desactualizado.

El up-to-date Intel documentation, 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 abarquen las líneas de caché, de lo contrario, la operación NO garantiza que sea atómica.

Por Volumen 3A, Programación del Sistema, para x86/x64 de Intel afirma claramente:

8.1.1 garantizado operaciones atómicas

El procesador Intel486 (y más nuevos procesadores ya) garantiza que la siguiente básica las operaciones de memoria siempre se llevan a cabo de forma atómica:

• de lectura o escritura de un byte
• Re ADing o escribir una palabra alineados en un 16-bit límite
• leer o escribir una palabra doble alineados en un límite de 32 bits

El procesador Pentium (y más nuevos procesadores desde) garantiza que las siguientes operaciones de memoria adicionales siempre será llevado a cabo atómicamente:

• leer o escribir una palabra cuádruple alineados en un límite de 64 bits
• 16 bits accede a las posiciones de memoria sin almacenar en caché que se ajustan dentro de un bus de datos de 32 bits

Los procesadores de la familia P6 (y más nuevos procesadores ya) garantía de que la siguiente operación memoria adicional siempre se llevará a cabo de forma atómica:

• Unaligned 16, 32 y 64 bits accesos a caché memoria que encaja dentro de una línea de caché

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

Answer 2

Consulte this SO question: la alineación natural es importante para el rendimiento, y es necesaria en la arquitectura x64 (por lo tanto, no solo los sistemas PRE-x86, sino también POST-x86; x64 puede ser un nicho de caso, pero está creciendo en popularidad después de todo ;-); esa puede ser la razón por la cual Microsoft lo documenta según sea necesario (documentos difíciles de encontrar sobre si MS decidió FORZAR el problema de alineación habilitando la verificación de alineación, que puede variar según la versión de Windows; al reclamar en los documentos que se requiere alineación, MS mantiene el libertad para forzarlo en alguna versión de Windows, incluso si no lo forzaron en otros).

Answer 3

Las API de interbloqueo de Microsoft también se aplicaron a ia64 (mientras aún existía). No había ningún prefijo de bloqueo en ia64, solo las instrucciones cmpxchg.acq y cmpxchg.rel (o fetchadd y otras bestias similares), y todas estas requieren alineación si recuerdo correctamente.

Answer 4

x86 hace no requieren la alineación para la instrucción cmpxchg. Sin embargo, se recomienda la alineación para el rendimiento. Esto no debería ser una sorpresa, 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é Microsoft requiere exactamente la alineación no está claro en su documentación. Puede ser para rendimiento o para soportar arquitecturas RISC o ambas.

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

8.1.2.2 Software autobús bloqueo

Para forzar explícitamente controlada el software de semántica LOCK 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 cierre del bus no se ve afectada por la alineación del campo memoria. Se sigue la semántica LOCK para tantos ciclos de bus como sea necesario para actualizar todo el operando. Sin embargo, se recomienda que los accesos bloqueados estén alineados en sus límites naturales para un mejor 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.