On x86 if [mem] is not 32-bit aligned, can "lock inc [mem]" still work fine?

Question

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

if [mem] is not 32-bit aligned, can lock inc [mem] sill work fine?

work fine:provide atomicity and not get partial value.

Answer 1

While the hardware might be fine with unaligned accesses, the code implementation might be relying on stealing the low 2 or 3 bits of the pointer (always zero for 32 or 64 bit aligned pointers respectively).

For example, the (Win32) InterlockedPushSList function doesn't store the low 2 or 3 bits of the pointer, so any attempt to push or pop an unaligned object will not work as intended. It is common for lock-free code to cram extra information into a pointer sized object. Most of the time this is not an issue though.

Intel's processors have always had excellent misaligned access performance. On the Nehalem (Core I7), they went all the way: any misaligned access fully within a cache line has no penalty, and misaligned accesses that cross a cache line boundary have an average 4.5-cycle penalty - very small.

Answer 2

The lock prefix will provide atomicity for unaligned memory access. On QPI systems this could be very slow. See this post on Intel website:

How to solve bugs of simultaneously misaligned memory accesses

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

Answer 3

The Intel Instruction Set Reference for x86 and x64 mentions nothing about alignment requirements for the INC instruction. All it says in reference to LOCK is:

This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.

The LOCK prefix documentation states:

The integrity of the LOCK prefix is not affected by the alignment of the memory field. Memory locking is observed for arbitrarily misaligned fields.