xacquire/xrelease只是 F2/F3 REP 前缀并且是被所有不支持该功能的 CPU 安全地忽略，包括非英特尔。这就是英特尔选择这种前缀编码的原因。它甚至比必须作为单独指令解码的 NOP 更好。
一般来说（跨供应商），CPU 会忽略它们不理解的 REP 前缀。因此，如果新扩展在旧 CPU 上解码为其他内容有用，则可以使用 REP 作为其编码的一部分，而不是#UD.
我认为 AMD 为 引入不兼容的含义是不合理的rep前缀于locked 指令或 mov-stores - 这会破坏已经使用这些前缀的现实世界二进制文件。例如，我非常确定主流 GNU/Linux 发行版中的一些 libpthread 版本已经使用它来启用硬件锁省略，并且不使用动态 CPU 调度来基于 CPUID 运行不同的代码。
之前已经使用 REP 作为向后兼容新指令的强制前缀，例如和rep nop = pause or rep bsf = tzcnt。 （对编译器有用，因为tzcnt在某些 CPU 上速度更快，并且如果已知输入非零，则给出相同的结果。）并且rep ret作为 AMD 预推土机分支预测器的解决方法，被 GCC 广泛使用 -“rep ret”是什么意思？。这个毫无意义的 REP 在 AMD 上的实践中确实有效（默默地被忽略）。
（相反的是not真的。您无法编写依赖于被忽略的无意义 REP 前缀的软件futureCPU。后来的一些扩展可能会给它一个含义，例如喜欢与rep bsr其运行方式为lzcnt并给出不同的结果。这就是为什么英特尔将无意义前缀的影响记录为“未定义”。）
我想使用 Intel TSX 前缀（特别是 XACQUIRE 和 XRELEASE）来增强它。
不幸的是，微代码更新显然禁用了所有 Intel CPU 上 TSX 的 HLE（硬件锁消除）部分。 （也许是为了减轻TAA 侧信道攻击）。这与进行的更新相同jcc在 32 字节块的末尾，在 uop 缓存中是不可缓存的，因此很难通过对现有代码进行基准测试来判断无 HLE 部分对性能有何影响。
https://news.ycombinator.com/item?id=21533791 / 由于 Spectre 缓解措施，硬件锁消除是否会永远消失？（是的，消失了，但不，原因可能不是幽灵。我不知道它是否会回来。）
如果你想在 x86 上使用硬件事务内存，我认为你唯一的选择是 RTM (xbegin/xend），多伦多证券交易所的另一半。在最近的微代码更新后，操作系统也可以禁用它；我不确定典型系统的默认值是什么，并且将来可能会发生变化，因此在将开发时间投入到任何内容之前需要检查这一点。
AFAIK 没有一种方法可以使用 RTM，但可以透明地回退到锁定； xbegin / xend 是非法指令，会导致错误#UD如果 CPUID 功能位不存在。
如果您想要透明的向后兼容，您应该使用 HLE，因此它（以及一般的 TSX）经历了如此艰难的时期，反复被微代码更新禁用，这真是令人遗憾。 （之前在 Haswell 和 Broadwell 中，因为可能存在正确性错误。现在它变成了查理·布朗的情况.)
更新：由于 TAA 等漏洞（https://docs.kernel.org/admin-guide/hw-vuln/tsx_async_abort.html），从 2021 年起，大多数 Skylake 系列 CPU 在微代码中禁用了 TSX（没有 HLE，RTM 总是中止。）https://www.intel.com/content/www/us/en/support/articles/000059422/processors.html
操作系统现在无法在受影响的 CPU 上重新启用 RTM，只能设置一点，以便 CPUID 不会公布现在无用的功能。 （如果有任何 Whiskey Lake、Comet Lake 或 Amber Lake CPU 的步进为 0xD 或 0xE 或更高，则可能有一些后期步进的 CPU 不受 2021 年更新的影响。）
TSX 功能也已从 Ice Lake 中删除。https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs- 显然蓝宝石急流中有一个新的 TSXLDTRK。
