在多核x86上，是否需要使用LOCK作为XCHG的前缀? [英] On a multicore x86, is a LOCK necessary as a prefix to XCHG?

问题描述

如果mem是共享内存位置，我是否需要:

If mem is a shared memory location, do I need:

XCHG EAX,mem

或:

LOCK XCHG EAX,mem

原子交换吗?

使用谷歌搜索会得到肯定和否定答案.谁能确切地知道这一点?

Googling this yields both yes and no answers. Does anyone know this definitively?

推荐答案

Intel的文档似乎很清楚，它是多余的.

Intel's documentation seems pretty clear that it is redundant.

IA-32英特尔®架构 软件开发人员手册 第3A卷: 系统编程指南，第1部分

IA-32 Intel® Architecture Software Developer’s Manual Volume 3A: System Programming Guide, Part 1

7.1.2.1说:

处理器自动遵循LOCK语义的操作如下 如下:

The operations on which the processor automatically follows the LOCK semantics are as follows:

• 在执行引用内存的XCHG指令时.

类似地，

英特尔®64和IA-32架构 软件开发人员手册 第2B卷: 指令集参考，N-Z

Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, N-Z

XCHG:

如果引用了内存操作数，则处理器的锁定协议将自动 在交换操作期间实现，而不考虑是否存在LOCK前缀或IOPL的值.

If a memory operand is referenced, the processor’s locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL.

请注意，这实际上并不意味着无论是否使用LOCK前缀都将声明LOCK#信号.7.1.4描述了在以后的处理器上，如果缓存了内存位置，则如何在不使用LOCK#的情况下保留锁定语义.聪明，绝对在我头上.

Note that this doesn't actually meant that the LOCK# signal is asserted whether or not the LOCK prefix is used, 7.1.4 describes how on later processors locking semantics are preserved without a LOCK# if the memory location is cached. Clever, and definitely over my head.

这篇关于在多核x86上，是否需要使用LOCK作为XCHG的前缀?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！