V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Orlion
V2EX  ›  汇编

Lock 指令到底有什么用?

  •  
  •   Orlion · 2021-01-14 11:38:19 +08:00 · 2211 次点击
    这是一个创建于 1404 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近在看原子操作的原理,得知是通过 Lock 指令保证了内存读写原子性,其原理是

    • CPU 保证 Lock 后缀后跟的指令原子性
    • 老 CPU 上通过锁总线来保证可见性
    • 新 CPU 上如果数据存在于 cpu cache 上时通过 MESI 协议来实现可见性,否则还是锁总线

    对此我产生了几个问题:

    1. 难道不声明 Lock CPU 就不通过 MESI 协议保证 cache 一致性吗?我觉得不是, https://strikefreedom.top/cpu-caches-theory-and-application 这篇文章的 demo 中并没有声明 Lock 指令,但仍然出现了缓存失效。
    2. 是不是除了 cpu cache 外还有 store buffer 和 invalid queue 会影响可见性,所以 CPU 只能保证 cache 的一致性但保证不了其他硬件缓存层面的一致性,所以还是需要 Lock 指令?
    7 条回复    2021-01-14 18:51:15 +08:00
    Jooooooooo
        1
    Jooooooooo  
       2021-01-14 11:40:28 +08:00
    MESI 我理解保证的是 L1, L2 cache 上的一致性吧, 对于 cpu 寄存器中的值不保证.
    Orlion
        2
    Orlion  
    OP
       2021-01-14 12:11:17 +08:00 via Android
    @Jooooooooo lock 与寄存器无关
    yzbythesea
        3
    yzbythesea  
       2021-01-14 13:07:06 +08:00
    Lock 是一个 prefix,就是指定接下来的 instruction 一定是原子操作的。Lock 只能和极少数指令一起使用,通常是 read-modify-write,比如 INCL(i),就是 i = i + 1 。在 Lock 指令执行的时候,CPU 对于这个 cache line 有绝对控制权,不会共享给其他 CPU 。你不用 Lock,CPU 不会保证该 cache line 只有他能用。
    Orlion
        4
    Orlion  
    OP
       2021-01-14 13:37:58 +08:00
    @yzbythesea CPU 操作 L3 cache 上同一个 cacheline 同一位置数据,不加 Lock 就不是原子的,这样理解吗?如果不加 Lock 也是原子的,那 CPU 没必要锁吧
    yzbythesea
        5
    yzbythesea  
       2021-01-14 13:42:50 +08:00 via iPhone
    是啊 cache 都是 CPU 共享的 除非你是单核
    yzbythesea
        6
    yzbythesea  
       2021-01-14 13:43:37 +08:00 via iPhone
    这个要看你是什么操作 比如 读,肯定是原子啊,所以 Lock 不能用于这个指令
    Orlion
        7
    Orlion  
    OP
       2021-01-14 18:51:15 +08:00
    @yzbythesea 感谢提醒,突然意识到了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5876 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 02:46 · PVG 10:46 · LAX 18:46 · JFK 21:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.