golang锁记

Posted 2020-11-20 a-xu

golang中有两个锁实现

atomic的CAS实现锁

首先是inter cpu，熟悉汇编的人都知道，inter指令集有个lock，如果某个指令集前面加个lock，那么在多核状态下，某个核执行到这个前面加lock的指令的时候，inter会让总线锁住，当这个核把这个指令执行完了，再开启总线！这是一种最最底层的锁！！

　HLT 指令(停止处理器)停止处理器直至接收到一个启用中断(比如 NMI 或 SMI，正 常情况下这些都是开启的)、调试异常、BINIT#信号、INIT#信号或 RESET#信号。处理 器产生一个特殊的总线周期以表明进入停止模式。 硬件对这个信号的响应有好几个方面。前面板上的指示灯会打亮，产生一个记录 诊断信息的 NMI 中断，调用复位初始化过程(注意 BINIT#引脚是在 Pentium Pro 处理器 引入的)。如果停机过程中有非唤醒事件（比如 A20M#中断）未处理，它们将在唤醒停 机事件处理之后的进行处理。

　　　　在修改内存操作时，使用 LOCK 前缀去调用加锁的读-修改-写操作(原子的)。这种 机制用于多处理器系统中处理器之间进行可靠的通讯，具体描述如下： 在 Pentium 和早期的 IA-32 处理器中，LOCK 前缀会使处理器执行当前指令时产生 一个 LOCK#信号，这总是引起显式总线锁定出现。 在 Pentium 4、Intel Xeon 和 P6 系列处理器中，加锁操作是由高速缓存锁或总线 锁来处理。如果内存访问有高速缓存且只影响一个单独的高速缓存线，那么操作中就 会调用高速缓存锁，而系统总线和系统内存中的实际内存区域不会被锁定。同时，这 条总线上的其它 Pentium 4、Intel Xeon 或者 P6 系列处理器就回写所有的已修改数据 并使它们的高速缓存失效，以保证系统内存的一致性。如果内存访问没有高速缓存且/ 或它跨越了高速缓存线的边界，那么这个处理器就会产生 LOCK#信号，并在锁定操作期 间不会响应总线控制请求。

　　　　IA-32 处理器提供有一个 LOCK#信号，会在某些关键内存操作期间被自动激活，去锁定系统总线。当这个输出信号发出的时候，来自其它处理器或总线代理的总线控制请求将被阻塞。软件能够通过预先在指令前添加 LOCK 前缀来指定需要 LOCK 语义的其它场合。在 Intel386、Intel486、Pentium 处理器中，明确地对指令加锁会导致 LOCK#信号的产生。由硬件设计人员来保证系统硬件中 LOCK#信号的可用性，以控制处理器间的内IA-32 架构软件开发人员指南 卷 3：系统编程指南170存访问。对于 Pentium 4、Intel Xeon 以及 P6 系列处理器，如果被访问的内存区域是在处理器内部进行高速缓存的，那么通常不发出 LOCK#信号；相反，加锁只应用于处理器的高速缓存（参见 7.1.4.LOCK 操作对处理器内部高速缓存的影响） 。

　当然inter还有其他方式保证原子操作！

　　　　然后是ARM cpu, arm主要是靠两个指令来保证原子操作的，LDREX 和 STREX

　　　　LDREX
　　　　　　LDREX 可从内存加载数据。

　　　　　　如果物理地址有共享 TLB 属性，则 LDREX 会将该物理地址标记为由当前处理器独占访问，并且会清除该处理器对其他任何物理地址的任何独占访问标记。

　　　　　   否则，会标记：执行处理器已经标记了一个物理地址，但访问尚未完毕。

　　　　STREX
　　　　　　STREX 可在一定条件下向内存存储数据。 条件具体如下：

　　　　　　如果物理地址没有共享 TLB 属性，且执行处理器有一个已标记但尚未访问完毕的物理地址，那么将会进行存储，清除该标记，并在Rd 中返回值 0。

　　　　　　如果物理地址没有共享 TLB 属性，且执行处理器也没有已标记但尚未访问完毕的物理地址，那么将不会进行存储，而会在Rd 中返回值 1。

　　　　　　如果物理地址有共享 TLB 属性，且已被标记为由执行处理器独占访问，那么将进行存储，清除该标记，并在Rd 中返回值 0。

　　　　　　如果物理地址有共享 TLB 属性，但没有标记为由执行处理器独占访问，那么不会进行存储，且会在Rd 中返回值 1。

mutex 是互诉锁

mutex lock 后，另外的线程lock时context就休眠了，当主线程执行完后唤醒等待的线程的实现方式。

mutex和atomic性能哪个好？

当然是atomic，因为mutex的实现lock时就调用了atomic。而mutex才是真正线程安全的，而atomic不一定,因为atomic要依靠cpu的lock指令的支持，不过我觉得golang应该做这些兼容实现。atomic是实现整个低核的lock，不适合在长时间锁定场景，因为很有可能引起整个系统卡住，所以一般是短锁场景，比如addint32，一个简单的计算或交换操作。而在长计算锁定的场景，还是使用mutex靠谱!

type Mutex struct {
        key  int32
        sema uint32
}

func (m *Mutex) Lock() {
        if atomic.AddInt32(&m.key, 1) == 1 {
                // changed from 0 to 1; we hold lock
                return
        }
        runtime_Semacquire(&m.sema)
}

func (m *Mutex) Unlock() {
        switch v := atomic.AddInt32(&m.key, -1); {
        case v == 0:
                // changed from 1 to 0; no contention
                return
        case v == -1:
                // changed from 0 to -1: wasn‘t locked
                // (or there are 4 billion goroutines waiting)
                panic("sync: unlock of unlocked mutex")
        }
        runtime_Semrelease(&m.sema)
}