Multithreading 在x86上，如果[mem]不是32位对齐的，则可以；洛克股份有限公司[mem]”；还可以吗？

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

如果[mem]未32位对齐，则

lock inc[mem]

sill是否可以正常工作

---

工作正常：提供原子性，不获取部分值。

对于x86和x64，没有提到INC指令的对齐要求。关于

LOCK

的所有说明如下：

此指令可与锁定前缀一起使用 允许指令以原子方式执行

锁定

前缀文档说明：

锁定前缀的完整性不受内存字段对齐方式的影响。 对于任意未对准的场，可以观察到内存锁定

---

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

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

---

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

例如，（Win32）InterlocatedPushSlist函数不存储指针的低位2或3位，因此任何尝试推送或弹出未对齐对象的操作都不会按预期进行。无锁代码通常将额外信息塞进指针大小的对象中。但大多数情况下，这不是一个问题

---

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

你说的“工作正常”是指它提供原子性吗？或者只是它是否会增加？工作正常：提供原子性，而不是获取部分值。我也看不到MOV指令的对齐要求。但是MOV会受到不对中的影响。

MOV

是如何受到不对中的影响的？它成功地读取/写入数据，而不受限制。这是一个非常精确的答案。然而，正如@Vince所提到的，

mov

也保证对未对齐的地址有效，但会受到惩罚。我怀疑在未对齐的地址上使用

lock

语义是类似的，可能会有更大的复杂性。OP询问指令是否“工作正常”。确实如此。“对适合缓存线的缓存内存进行未对齐的16、32和64位访问”将始终以原子方式执行。但是，同时，它说“然而，不一致的数据访问将严重影响处理器的性能，应该避免。”——因此，我绝对不反对任何人认为应该避免不一致的操作。我只是说指令将按预期执行。回答得好。请帮助回答“乔纳森·莱因哈特”的其他问题。我不确定问题是什么，或者我们在争论什么。我想我们都同意a）无论对齐情况如何，说明都能正确工作。b） 出于性能原因，应避免未对齐的访问。