我是靠谱客的博主 靓丽萝莉,最近开发中收集的这篇文章主要介绍kali锁屏后无法唤醒_Go语言 读写锁&互斥锁原理剖析(2),觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

前言

99567938a7c662cc62a57b1050ffc9df.png 互斥锁( 百科)定义:“在编程中,引入了对象互斥锁的概念,来保证共享数据操作的完整性。每个对象都对应于一个可称为" 互斥锁" 的标记,这个标记用来保证在任一时刻,只能有一个线程访问该对象。”,顾名思义就是 互相排斥的锁了。当程序中就一个协程时,不需要加锁,但是实际工程中不会只有单协程,可能有很多协程同时访问公共资源,所以这个时候就需要用到锁,互斥锁的使用场景一般有:
  1. 多个协程同时读相同的数据时
  2. 多个协程同时写相同的数据时
  3. 同一个资源,同时有读和写操作时
读写锁之后,我们继续来说说互斥锁,互斥锁从原理上来说要比读写锁复杂一些,在Go语言中提供了 sync.Mutex标准库, sync包中Mutex、RWMutex的方法的 inline 化带来的性能提升,官方说法是10%,Mutex结构体来定义。Mutex同样继承于Locker接口。 源码基于: go version go1.13.4 windows/amd64

互斥锁特点

99567938a7c662cc62a57b1050ffc9df.png一次只能一个协程拥有互斥锁,其他线程只有等待。

两种操作模式

99567938a7c662cc62a57b1050ffc9df.png
  1. 正常模式:所有协程以先进先出(FIFO)方式进行排队,被唤醒的协程同样需要竞争方式争夺锁,新协程争抢会有优势,因为他们已经运行在CPU上,更容易抢到锁,如果一个协程在等待超过1毫秒会自动切换到饥饿模式下。
  2. 饥饿模式:互斥锁会直接由解锁的协程交给队列头部的等待者,新争抢者不能直接获得锁,不尝试自旋,会老老实实的等。

两种工作模式

99567938a7c662cc62a57b1050ffc9df.png
  1. 竞争模式:所有协程一起抢
  2. 队列模式:所有协程一起排队,这两种工作模式会通过一些情况进行切换的。

互斥锁的定义

99567938a7c662cc62a57b1050ffc9df.png
type Mutex struct {  state int32  // 互斥锁上锁状态  sema  uint32 // 信号量}
state=0时是未上锁,state=1时是锁定状态。

互斥锁常量的定义

99567938a7c662cc62a57b1050ffc9df.png
> iota // 十进制:1,二进制:0001ntmutexWoken                        // 十进制:2,二进制:0010ntmutexStarving                     // 十进制:4,二进制:0100ntmutexWaiterShift      = iota      // 十进制:3,二进制:0011ntstarvationThresholdNs = 1e6       // 1e+06n)","classes":[]}"   >
const (  mutexLocked           = 1 << iota // 十进制:1,二进制:0001  mutexWoken                        // 十进制:2,二进制:0010  mutexStarving                     // 十进制:4,二进制:0100  mutexWaiterShift      = iota      // 十进制:3,二进制:0011  starvationThresholdNs = 1e6       // 1e+06)
看一下互斥锁的结构主要方法,主要有Lock()和Unlonk()方法组成,使用Lock()加锁后便不能再次对其加锁操作,直到Unlock()解锁后才能再次加锁,适用于读写不确定的场景,并且只允许只有一个读或者写的场景。 69ed775bc106129994ddaf3ab7028abe.png

Lock()

99567938a7c662cc62a57b1050ffc9df.png
func (m *Mutex) Lock() {  // ①CAS尝试获取锁,state为0表示没有协程持有锁,直接获得锁,将mutexLocked置为1。  // 如果设置成功,直接返回。如果获取锁失败会进入lockSlow方法进行自旋抢锁,直到抢到锁后返回。  if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {    if race.Enabled {      race.Acquire(unsafe.Pointer(m))    }    return  }  m.lockSlow()}
首先、尝试CAS获取锁,这里直接调用CompareAndSwapInt32方法来原子操作检测锁的状态,可以加锁会将状态转为1,不可以加锁则状态为0。state为0表示没有协程持有锁,这个时候直接获得锁并将mutexLocked设置成1。如果设置成功了直接返回。如果获取锁失败了会进入lockSlow方法进行自旋抢锁,直到抢到锁为止。

lockSlow()

99567938a7c662cc62a57b1050ffc9df.png
> mutexWaiterShiftntt}ntt// 6、切换到饥饿模式,解锁时不切换nttif starving && old&mutexLocked != 0 {ntttnew |= mutexStarvingntt}ntt// 7、唤醒nttif awoke {nttt// 8、互斥状态不相同就panicntttif new&mutexWoken == 0 {nttttthrow("sync: inconsistent mutex state")nttt}nttt// 同时把awoke位清掉ntttnew &^= mutexWokenntt}nnttif atomic.CompareAndSwapInt32(&m.state, old, new) {nttt// 9、old的第1位和第3位一定不是1,未锁定而且处于饥饿模式。获取锁成功ntttif old&(mutexLocked|mutexStarving) == 0 {nttttbreak // locked the mutex with CASnttt}nttt// 10、被唤醒的协程抢锁失败,重新放到队列首部ntttqueueLifo := waitStartTime != 0ntttif waitStartTime == 0 {nttttwaitStartTime = runtime_nanotime()nttt}nttt// 11、进入休眠状态,等待信号唤醒ntttruntime_SemacquireMutex(&m.sema, queueLifo, 1)nttt// 确认当前的锁的状态ntttstarving = starving || runtime_nanotime()-waitStartTime < starvationThresholdNsntttold = m.statentttif old&mutexStarving != 0 {ntttt// 12、饥饿模式不会出现mutex被锁住|唤醒,等待队列不能为0nttttif old&(mutexLocked|mutexWoken) != 0 || old<>mutexWaiterShift)ntttt// 非饥饿模式,等待者只有一个时,退出饥饿模式nttttif !starving || old<
func (m *Mutex) lockSlow() {  var waitStartTime int64 // 协程等待时间  starving := false       // 锁的模式  awoke := false          // 循环标记  iter := 0               // 计数器  old := m.state          // 当前的锁状态  for {    // 1、old&0101==0001等于1说明已经加过锁,(old第1位一定是1,第3位一定是0)这时候未处于饥饿模式,开始自旋。    if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {      // 2、当前协程未能成功更新mutexWoken位,mutexWoken位仍然为0,等待队列为空,更新mutexWoken成功开始自旋。      if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&        atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {        awoke = true      }      // 3、将当前的协程标识为唤醒状态后,执行自旋操作,计数器+1,当前状态更新到old。      runtime_doSpin()      iter++      old = m.state      continue    }    new := old    // 4、新到的协程第三位等于0为正常模式需要排除    if old&mutexStarving == 0 {      new |= mutexLocked    }    // 5、当old的1和3位为1时,为饥饿模式,需要去排队    if old&(mutexLocked|mutexStarving) != 0 {      new += 1 << mutexWaiterShift    }    // 6、切换到饥饿模式,解锁时不切换    if starving && old&mutexLocked != 0 {      new |= mutexStarving    }    // 7、唤醒    if awoke {      // 8、互斥状态不相同就panic      if new&mutexWoken == 0 {        throw("sync: inconsistent mutex state")      }      // 同时把awoke位清掉      new &^= mutexWoken    }    if atomic.CompareAndSwapInt32(&m.state, old, new) {      // 9、old的第1位和第3位一定不是1,未锁定而且处于饥饿模式。获取锁成功      if old&(mutexLocked|mutexStarving) == 0 {        break // locked the mutex with CAS      }      // 10、被唤醒的协程抢锁失败,重新放到队列首部      queueLifo := waitStartTime != 0      if waitStartTime == 0 {        waitStartTime = runtime_nanotime()      }      // 11、进入休眠状态,等待信号唤醒      runtime_SemacquireMutex(&m.sema, queueLifo, 1)      // 确认当前的锁的状态      starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs      old = m.state      if old&mutexStarving != 0 {        // 12、饥饿模式不会出现mutex被锁住|唤醒,等待队列不能为0        if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {          throw("sync: inconsistent mutex state")        }        // 13、拿到锁,等待数-1        delta := int32(mutexLocked - 1<        // 非饥饿模式,等待者只有一个时,退出饥饿模式        if !starving || old>>mutexWaiterShift == 1 {          delta -= mutexStarving        }        // 14、更新状态,高位原子计数,直接添加        atomic.AddInt32(&m.state, delta)        break      }      // 15、awoke=true,不处于饥饿模式,新到达的协程先获得锁      awoke = true      iter = 0    } else {      // 16、old = m.state,自旋没成功,更新new,记录当前的状态      old = m.state    }  }  if race.Enabled {    race.Acquire(unsafe.Pointer(m))  }}
lockSlow方法中首先设置循环标记awoke,初始化计数器,将当前锁的状态赋值给old等参数后进入循环,
1、old&0101==0001等于1说明已经加过锁,(old第1位一定是1,第3位一定是0)这时候未处于饥饿模式,开始自旋。
2、当前协程未能成功更新mutexWoken位,mutexWoken位仍然为0,等待队列为空,更新mutexWoken成功开始自旋。
3、将当前的协程标识为唤醒状态后,执行自旋操作,计数器+1,当前状态更新到old。
4、新到的协程第三位等于0为正常模式需要排除
5、当old的1和3位为1时,为饥饿模式,需要去排队
6、切换到饥饿模式,解锁时不切换
7、唤醒
8、互斥状态不相同就panic,同时把awoke位清掉
9、old的第1位和第3位一定不是1,未锁定而且处于饥饿模式。获取锁成功
10、被唤醒的协程抢锁失败,重新放到队列首部
11、进入休眠状态,等待信号唤醒,确认当前的锁的状态
12、饥饿模式不会出现mutex被锁住|唤醒,等待队列不能为0
13、拿到锁,等待数-1。非饥饿模式,等待者只有一个时,退出饥饿模式
14、更新状态,高位原子计数,直接添加
15、awoke=true,不处于饥饿模式,新到达的协程先获得锁
16、old = m.state,自旋没成功,更新new,记录当前的状态

Unlock()

99567938a7c662cc62a57b1050ffc9df.png
func (m *Mutex) Unlock() {  if race.Enabled {    _ = m.state    race.Release(unsafe.Pointer(m))  }  // 直接更新第一位即锁位置为0,直接解锁  new := atomic.AddInt32(&m.state, -mutexLocked)  if new != 0 {    m.unlockSlow(new)  }}
unlock()方法进入后直接更新第一位即锁位置为0,直接解锁,new!=0解锁失败后进入unlockSlow()方法进行解锁操作。

unlockSlow()

99567938a7c662cc62a57b1050ffc9df.png
>mutexWaiterShift) | mutexWokenntttif atomic.CompareAndSwapInt32(&m.state, old, new) {ntttt// 唤醒一个阻塞的协程,唤醒的不是第一个等待协程nttttruntime_Semrelease(&m.sema, false, 1)nttttreturnnttt}ntttold = m.statentt}nt} else {ntt// ④饥饿模式下,将持有锁交给下一个等待者,此时mutexLocked还为0,但是在饥饿模式下,新协程不会更新mutexLocked位。nttruntime_Semrelease(&m.sema, true, 1)nt}n}n","classes":[]}"   >
func (m *Mutex) unlockSlow(new int32) {  // ①状态不一致,直接抛异常  if (new+mutexLocked)&mutexLocked == 0 {    throw("sync: unlock of unlocked mutex")  }  // ②饥饿模式直接唤醒队列首部的协程  if new&mutexStarving == 0 {    old := new    for {      // ③如果没有等待者或协程,不用唤醒就返回      if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {        return      }      // 等待者数量-1,将唤醒位改成1      new = (old - 1<      if atomic.CompareAndSwapInt32(&m.state, old, new) {        // 唤醒一个阻塞的协程,唤醒的不是第一个等待协程        runtime_Semrelease(&m.sema, false, 1)        return      }      old = m.state    }  } else {    // ④饥饿模式下,将持有锁交给下一个等待者,此时mutexLocked还为0,但是在饥饿模式下,新协程不会更新mutexLocked位。    runtime_Semrelease(&m.sema, true, 1)  }}
unlockSlow()方法进入后首先检查状态,如果状态不一致,直接抛异常。然后饥饿模式直接唤醒队列首部的协程,如果没有等待协程,就不唤醒直接返回。等待协程数量-1,将唤醒位改成1,唤醒一个阻塞协程,唤醒的不一定是第一个等待协程。否则、饥饿模式下,将持有锁交给下一个等待协程,此时mutexLocked还为0,但是在饥饿模式下,新的协程不会更新mutexLocked位。

总结

99567938a7c662cc62a57b1050ffc9df.png
  • 原子性,把一个互斥量锁定为一个原子操作,保证如果一个协程锁定了一个互斥量,这时候其他协程同一时间不能成功锁定这个互斥量。
  • 唯一性:如果一个协程锁定了一个互斥量,在他解锁之前,其他协程无法锁定这个互斥量。
  • 互斥锁只能锁定一次,当在解锁之前再次进行加锁,便会无法加锁。如果在加锁前解锁,便会报错"panic: sync: unlock of unlocked mutex"。 
  • 互斥锁无冲突,有冲突时,首先自旋,经过短暂自旋后可以获得锁,如果自旋无结果时通过信号通知协程继续等待。

推荐阅读

  • Go 语言读写锁源码剖析(1)


喜欢本文的朋友,欢迎关注“Go语言中文网”:

7e04ea89bcdb4f06f395ec5cdea0e672.png

Go语言中文网启用微信学习交流群,欢迎加微信:274768166,投稿亦欢迎

最后

以上就是靓丽萝莉为你收集整理的kali锁屏后无法唤醒_Go语言 读写锁&互斥锁原理剖析(2)的全部内容,希望文章能够帮你解决kali锁屏后无法唤醒_Go语言 读写锁&互斥锁原理剖析(2)所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(44)

评论列表共有 0 条评论

立即
投稿
返回
顶部