教程集 www.jiaochengji.com
教程集 >  Golang编程  >  golang教程  >  正文 golang锁记

golang锁记

发布时间:2021-05-15   编辑:jiaochengji.com
教程集为您提供golang锁记等资源,欢迎您收藏本站,我们将为您提供最新的golang锁记资源

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)
}

 

转载于:https://www.cnblogs.com/a-xu/p/9240957.html

到此这篇关于“golang锁记”的文章就介绍到这了,更多文章或继续浏览下面的相关文章,希望大家以后多多支持JQ教程网!

您可能感兴趣的文章:
用Go学UNIX环境编程 - 记录锁
GO 互斥锁实现原理剖析
golang锁记
用Go 学UNIX环境编程 - 记录锁
一道并发和锁的golang面试题
golang sync.Mutex互斥锁的实现原理
golang读写锁实现与核心原理分析
mysql如何锁定单个表
golang key map 所有_缓存击穿导致 golang 组件死锁的问题分享
golang debug 配置_缓存击穿导致 golang 组件死锁的问题分享

[关闭]
~ ~