On x86, if [mem] does not match 32-bit, can the "lock inc [mem]" still work fine?

Question

On x86, if mem is 32-bit, the mov operation is guaranteed to be atomic.

if [mem] does not match 32-bit, can lock inc [mem] work on the windowsill?

work fine: ensure atomicity and not get a partial value.

Answer 1

The Intel instruction set reference for x86 and x64 says nothing about alignment requirements for the INC instruction. All that is said in LOCK is the following:

This instruction can be used with the LOCK prefix so that the command is executed atomically.

The documentation for the LOCK prefix states:

The integrity of the LOCK prefix is ​​independent of the alignment of the memory field. Memory lock is observed for randomly shifted fields.

Answer 2

The lock prefix will provide atomicity for uneven access to memory. On QPI systems, this can be very slow. See this post on the Intel website:

How to solve simultaneous memory access bias errors

http://software.intel.com/en-us/forums/showthread.php?t=75386

Answer 3

While the hardware may be okay with tacit accesses, code implementation may be based on stealing the least significant 2 or 3 bits of a pointer (always zero for 32 or 64-bit aligned pointers, respectively).

For example, the function (InterlockedPushSList) (Win32) does not save low 2 or 3 bits of the pointer, so any attempt to press or pop up an unaligned object will not work as intended. Typically, for loose code, encode additional information into a pointer-sized object. In most cases, this is not a problem.

Intel processors have always had excellent incompatible access performance. On Nehalem (Core I7) they went all the way: any incorrect access completely within the cache line has no penalty, and inconsistent calls crossing the cache line border have an average fine of 4.5 cycles - very small.