在 x86 上，如果 [mem] 不是 32 位对齐的，“lock inc [mem]”还能正常工作吗？答案

【问题标题】：On x86 if [mem] is not 32-bit aligned, can "lock inc [mem]" still work fine?在 x86 上，如果 [mem] 不是 32 位对齐的，“lock inc [mem]”还能正常工作吗？
【发布时间】：2012-07-26 05:01:32
【问题描述】：

在 x86 上，如果 mem 是 32 位对齐的，则 mov 操作保证是原子的。

如果 [mem] 不是 32 位对齐的，lock inc [mem] sill 可以正常工作吗？

工作正常：提供原子性而不是获得部分价值。

【问题讨论】：

“工作正常”是指它提供原子性吗？还是只是增加？
工作正常：提供原子性而不是获得部分价值。

标签： multithreading assembly x86 multiprocessing

【解决方案1】：

x86 和 x64 的 Intel Instruction Set Reference 没有提及 INC 指令的对齐要求。它提到LOCK 时所说的只是：

该指令可以与 LOCK 前缀一起使用允许指令以原子方式执行。

LOCK 前缀文档指出：

LOCK 前缀的完整性不受内存字段对齐的影响。对于任意未对齐的字段，会观察到内存锁定。

【讨论】：

我也看不到 MOV 指令的对齐要求。但是 MOV 会受到错位的影响。
MOV 对错位有何影响？无论算法如何，它都能成功读取/写入数据。
一个非常准确的答案。但是，就像@Vince 提到的那样，mov 也保证适用于未对齐的地址，但会受到惩罚。我怀疑在未对齐的地址上使用lock 语义是类似的，可能会带来更大的复杂性。
OP 询问这些说明是否会“正常工作”。他们确实做到了。
“对缓存行中的缓存内存的未对齐的 16 位、32 位和 64 位访问”将始终以原子方式执行。但是，与此同时，它说“但是，不对齐的数据访问会严重影响处理器的性能，应该避免。” --- 所以，我绝对不反对任何人认为应该避免不结盟的行动。我只是说指令将按预期执行。

【解决方案2】：

锁定前缀将为未对齐的内存访问提供原子性。在 QPI 系统上，这可能非常慢。请参阅英特尔网站上的这篇文章：

如何解决同时未对齐的内存访问的错误

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

【讨论】：

好答案。请帮助回答“Jonathon Reinhart”的其他问题。
我不确定问题是什么，或者我们在争论什么。我想我们都同意 a) 无论对齐如何，说明都会正常工作。 b) 出于性能原因，应避免未对齐的访问。

【解决方案3】：

虽然硬件可能对未对齐的访问没有问题，但代码实现可能依赖于窃取指针的低 2 位或 3 位（分别对于 32 位或 64 位对齐的指针始终为零）。

例如，(Win32) InterlockedPushSList 函数不存储指针的低 2 位或 3 位，因此任何推入或弹出未对齐对象的尝试都不会按预期工作。无锁代码通常会将额外信息塞入指针大小的对象中。但大多数时候这不是问题。

英特尔的处理器一直具有出色的未对齐访问性能。在 Nehalem（Core I7）上，他们一路走来：完全在高速缓存行内的任何未对齐访问都没有惩罚，而跨越高速缓存行边界的未对齐访问平均有 4.5 个周期的惩罚 - 非常小。

【讨论】：