Solución:
x86 hace no requieren alineación para un lock cmpxchg instrucción para ser atómico. Sin embargo, la alineación es necesaria para un buen desempeño.
Esto no debería sorprender, 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 actuales. Las CPU modernas incluso tienen un contador de rendimiento específico para split-lock detección porque es muy cara. (El núcleo no puede simplemente mantener el acceso exclusivo a una sola línea de caché durante la operación; tiene que hacer algo como un bloqueo de bus tradicional).
No está claro por qué exactamente Microsoft documenta un requisito de alineación. Ciertamente es necesario para admitir arquitecturas RISC, pero la afirmación específica de comportamiento impredecible en multiprocesador x86 puede que ni siquiera sea válida. (A menos que se refieran a un rendimiento impredecible, en lugar de un problema de corrección).
Su suposición de aplicar solo a sistemas anteriores a 486 sin lock cmpxchg podría tener razón; se necesitaría un mecanismo diferente que podría haber requerido algún tipo de bloqueo alrededor de cargas puras o almacenes puros. (También tenga en cuenta que 486 cmpxchg tiene un código de operación diferente y actualmente indocumentado (0f a7) de moderno cmpxchg (0f b1) que era nuevo con 586 Pentium; Es posible que Windows solo haya usado cmpxchg en Pentium P5 y posteriores, no lo sé.) Eso tal vez podría explicar la rareza en algunos x86, sin implicar rarezas en el x86 moderno.
Manual del desarrollador de software de arquitecturas Intel® 64 e IA-32
Volumen 3 (3A): Guía de programación del sistema
enero 20138.1.2.2 Bloqueo de bus controlado por software
Para forzar explícitamente la semántica de 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 LOCK se sigue durante tantos ciclos de bus como sea necesario para actualizar todo el operando. Sin embargo, se recomienda que los accesos bloqueados se alineen 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 bloqueados.
• Límite de 32 bits para accesos de palabra doble bloqueados.
• Límite de 64 bits para accesos de cuatro palabras bloqueadas.
Hecho de la diversión: cmpxchg sin a lock El prefijo sigue siendo wrt atómico. cambia de contexto, por lo que se puede utilizar para subprocesos múltiples en un sistema de un solo núcleo.
Incluso desalineado sigue siendo wrt atómico. se interrumpe (ya sea completamente antes o completamente después), y solo las lecturas de memoria de otros dispositivos (por ejemplo, DMA) podrían verse desgarradas. Pero tales accesos también podrían ver la separación entre carga y almacenamiento, por lo que incluso si el antiguo Windows lo usara para un InterlockedCompareExchange más eficiente en sistemas de un solo núcleo, aún no requeriría alineación para la corrección, solo el rendimiento. Si esto se puede usar para el acceso al hardware, Windows probablemente no lo haría.
Si la función de biblioteca necesitaba hacer una carga pura separada de la lock cmpxchg esto puede tener sentido, pero no es necesario que lo haga. (Si no está en línea, la versión de 32 bits tendría que cargar sus argumentos desde la pila, pero eso es privado, no acceso a la variable compartida).
El PDF que está citando es de 1999 y CLARAMENTE desactualizado.
La documentación de Intel actualizada, específicamente el Volumen 3A, cuenta una historia diferente.
Por ejemplo, en un procesador Core-i7, TODAVÍA debe asegurarse de que sus datos no se extiendan por líneas de caché, o 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 dice claramente:
8.1.1 Operaciones atómicas garantizadas
El procesador Intel486 (y los procesadores más nuevos desde entonces) garantiza que las siguientes operaciones básicas de memoria siempre se llevarán a cabo de forma atómica:
- 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 las siguientes operaciones adicionales de memoria siempre se llevarán a cabo de forma atómica:
- 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 la siguiente operación de memoria adicional siempre se llevará a cabo de forma atómica:
- Accesos no alineados de 16, 32 y 64 bits a la memoria en caché que caben dentro de una línea de caché
Intel Core 2 Duo, Intel® Atom ™, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, familia P6, Pentium y Procesadores Intel486. Los procesadores de la familia Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon y P6 proporcionan señales de control de bus que permiten que los subsistemas de memoria externa hagan que los accesos divididos sean atómicos; Sin embargo, los accesos a datos no alineados afectarán seriamente el rendimiento del procesador y deben evitarse.
Vea esta pregunta de SO: la alineación natural es importante para el rendimiento y se requiere en la arquitectura x64 (por lo que no son solo los sistemas PRE-x86, sino también los POST-x86; x64 puede ser un caso de nicho, pero está creciendo en popularidad después de todo ;-); Esa puede ser la razón por la que Microsoft lo documenta como requerido (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 la libertad para forzarlo en alguna versión de Windows incluso si no lo hicieron en otras).