blocks|key|707050|text|在x86上，lock前缀锁定所有核心并允许原子性。为了在没有LOCK的其他系统上实现这一点，可以使用CMPXCHG循环，或者使用带有重试逻辑的紧密循环，尝试将某些内容的值设置为预期值。正如你所看到的，第二种方法在大多数情况下更有害，因为它只是不断地循环，试图设置值(并一直这样做，直到它完成)。对于x86，延迟是最小的，可能范围是停止指令流水线或刷新它，然后自动执行该指令(通常是几个周期)，第二种方法不能真正估计，因为它取决于需要自动修改的值的争用程度。对于互斥锁，我认为它是一个必须获取的标志值(检查互斥锁是否未被获取，并持续等待，直到互斥锁被抓取，然后尝试自动更改标志以获取它)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|707051|AFAIK+IBM处理器使用第二种方法，因为在linux内核上工作时，我发现原子增量函数使用它(可能它只适用于较老的处理器)。x86平台仍然使用|707052|lock+addl+...;|code-block|syntax|javascript|707053|我承认，我在内核的这一部分工作已经有一年了，所以在某些方面我可能是错的。|707054|entityMap^0|U|4|1E|7|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|P|$]]

On x86 lock prefix locks all cores and allows atomicity. For implementing this on other systems without <code>LOCK</code>, <code>CMPXCHG</code> loops are used or tight loops with retry logic that attempt to set the value of something to the expected value. As you can see the 2nd way is more detrimental in most cases as it's just constantly looping trying to set the value (and keeps doing so until it's done). For x86 the delay is minimal and might range from halting the instruction pipeline or flushing it and then executing that instruction atomically (typically a couple of cycles), the 2nd method can't really be estimated as it depends how much contention there is for the value that needs to be modified atomically. For mutex's I believe that it's a flag value that must be acquired (check that the mutex isn't acquired and continuously wait until the mutex is up for grabs then attempt to atomically change a flag to acquire it).

AFAIK IBM processors use the 2nd method as when working on the linux kernel I found that the atomic increment function uses it (maybe it's only for older processors). The x86 platform still uses

<pre><code>lock addl ...;
</code></pre>

I will admit though that it's been about a year since I worked in this part of the kernel so I could be wrong on some points.

blocks|key|713429|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|713430|在x86程序集中有一个锁前缀，它可以应用于指令，使其成为原子指令。这是跨所有内核的原子性吗？|blockquote|713431|713432|713433|是。|713434|713435|通常涉及的延迟是多少？|713436|713437|713438|成本因多种因素而异(CPU型号、CPU速度、总线速度、RAM速度、数据在此时的实际位置以及尝试使用总线的其他因素)。对于非常旧的CPU+(8086、80186、80286、80386)，没有缓存，并且LOCK锁定总线以确保其他任何东西都不能干扰。这不会比没有LOCK的相同指令的开销多很多，除了在指令持续时间内尝试使用的所有其他东西都必须等待(它减慢了其他所有东西，而不是代码本身)。|offset|length|style|CODE|713439|对于所有现代CPU(我猜是"Pentium+III或更高版本“)，它被更改为在可能的情况下依赖MESI缓存一致性协议。具体地说，将高速缓存线带入高速缓存并将其改变为“独占”状态，然后单独使用本地高速缓存来完成指令，而无需锁定总线。这样做的成本取决于数据所在的位置--例如，如果数据已经在同一个CPU的L1数据缓存中(而不在其他CPU的缓存中)，那么LOCK不会花费任何成本。然而，(由于多CPU代码的性质)高速缓存线通常位于不同CPU的高速缓存中，并且需要从一个高速缓存传输到另一个高速缓存和/或在其他CPU的高速缓存中无效(通过。在MESI缓存一致性协议中称为“读取所有权”)，因此它的成本更高(但仍然没有锁定总线那么多)。|713440|713441|对于常规互斥锁，锁定的是什么指令？|713442|713443|713444|多年来，我已经看到互斥锁以大约20种不同的方式实现。在所有不同的实现中，没有一条指令是相同的。|713445|注意，当您不能获得互斥锁时，内核被告知在互斥锁释放之前不要给任务分配任何CPU时间；然后，当互斥锁被释放时，内核需要被告知该任务可能会再次消耗CPU时间。这具有竞争条件，并最终成为内核调度程序中的一个原子“检查是否可以获得互斥量，然后更改任务的状态”。|713446|还要注意，这是相当昂贵的，所以大多数实现都试图在用户空间中乐观地做尽可能多的事情；这样，如果没有争用，那么在获取互斥锁时不需要涉及内核；因此，如果没有阻塞等待互斥锁，则内核不会被告知解锁不存在的等待任务。如果互斥锁争用来增加内核不参与的可能性，也有一些变体会旋转一小段时间。|713447|换句话说，获取和释放互斥锁的代码通常不在一个地方--它是两个部分，一个部分在用户空间，另一个部分在内核中。|713448|entityMap^0|0|0|0|0|0|0|0|0|0|2S|4|3L|4|0|4U|4|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|19|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1A|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1C|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1D|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|1F|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|1H|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|1I|7|@$O|1J|P|1K|Q|R]|$O|1L|P|1M|Q|R]]|8|@]|9|$]]|$1|S|3|T|4|5|6|1N|7|@$O|1O|P|1P|Q|R]]|8|@]|9|$]]|$1|U|3|-4|4|5|6|1Q|7|@]|8|@]|9|$]]|$1|V|3|W|4|C|6|1R|7|@]|8|@]|9|$]]|$1|X|3|-4|4|5|6|1S|7|@]|8|@]|9|$]]|$1|Y|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|Z|3|10|4|5|6|1U|7|@]|8|@]|9|$]]|$1|11|3|12|4|5|6|1V|7|@]|8|@]|9|$]]|$1|13|3|14|4|5|6|1W|7|@]|8|@]|9|$]]|$1|15|3|16|4|5|6|1X|7|@]|8|@]|9|$]]|$1|17|3|-4|4|5|6|1Y|7|@]|8|@]|9|$]]]|18|$]]

<blockquote>
 In x86 assembly there is a LOCK prefix that can be applied to an instruction to make it atomic. Is this atomicity across all cores?
</blockquote>

Yes.

<blockquote>
 What is the usual delay involved?
</blockquote>

The cost varies depending on multiple factors (CPU model, CPU speed, bus speed, RAM speed, where the data actually is at the time and what else is trying to use the bus). For extremely old CPUs (8086, 80186, 80286, 80386) there were no caches, and the <code>LOCK</code> locked the bus to ensure that nothing else can interfere. This wouldn't have costed much more than the same instruction without the <code>LOCK</code>, except that everything else trying to use the for the duration of the instruction had to wait (it slowed down everything else more than it slowed down the code itself).

For all modern CPUs (I'm guessing "Pentium III or later") it was changed to rely on the MESI cache coherency protocol where possible. Specifically, the cache line is brought into the cache and changed to the "exclusive" state, then the instruction is done using the local cache alone without locking the bus. The cost of this depends on where the data is - e.g. if it's already in the same CPU's L1 data cache (and not in other CPU's caches) then the <code>LOCK</code> can cost nothing. However, (due to the nature of multi-CPU code) often the cache line is in a different CPU's cache and needs to be transferred from one cache to another and/or invalidated in other CPU's caches (via. something called a "read for ownership" in the MESI cache coherency protocol) so it costs more (but still not as much as locking a bus).

<blockquote>
 For a regular mutex, what instruction is it that's locked?
</blockquote>

Over the years I've seen mutexes implemented about 20 different ways. There's no single instruction that is the same in all of the different implementations.

Note that when you can't acquire a mutex the kernel is told not to give your task any CPU time until the mutex is released; and then when the mutex is released the kernel needs to be told that the task can consume CPU time again. This has race conditions and ends up being an atomic "check if mutex can be acquired and then change a task's state" deep in the kernel's scheduler.

Also note that this is considerably expensive so most implementations try to optimistically do as much as possible in user-space; so that the kernel needn't be involved when the mutex is being acquired if there's no contention; and so that if nothing was blocked waiting for the mutex then the kernel isn't told to unblock waiting tasks that don't exist. There are also variations that spin for a short while if the mutex is contended to increase the chance that the kernel isn't involved.

In other words; the code to acquire and release a mutex typically isn't even in one place - it's two pieces, with one piece is in user-space and another piece is in the kernel.

In x86 assembly there is a LOCK prefix that can be applied to an instruction to make it atomic. Is this atomicity across all cores? What is the usual delay involved? For a regular mutex, what instruction is it that's locked?

Thanks.
PS: I was taught that on systems that lack such an instruction that mutexes can still be done but it is more laborious. I wonder if anyone does it that way any more.

On multicore x86 systems, are mutexes implemented using a LOCK'd instruction?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在x86汇编中，有一个锁前缀，它可以应用于指令，使其成为原子指令。这是跨所有内核的原子性吗？通常涉及的延迟是多少？对于常规互斥锁，锁定的是哪条指令？谢谢。PS:我被教导说，在缺乏这样的指令的系统上，互斥锁仍然可以完成，但它更费力。我想知道还有没有人这样做。

问在多核x86系统上，互斥是使用锁定指令实现的吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在多核x86系统上，互斥是使用锁定指令实现的吗？EN