Go語言中鎖如何實現

今天小編給大家分享一下Go語言中鎖如何實現的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

Lock

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
func (m *Mutex) Lock() {
  // Fast path: grab unlocked mutex.
  // 上鎖,成功返回
  if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
    if race.Enabled {
      race.Acquire(unsafe.Pointer(m))
    }
    return
  }
  // Slow path (outlined so that the fast path can be inlined)
  //已經鎖上的寫成進入慢鎖流程
  m.lockSlow()
}

lockSlow

func (m *Mutex) lockSlow() {
  var waitStartTime int64 //執行時間
  starving := false //當前請求是否是饑餓模式
  awoke := false //當前請求是否是喚醒狀態
  iter := 0 //自旋次數
  old := m.state //舊state值
  for {
    // Don't spin in starvation mode, ownership is handed off to waiters
    // so we won't be able to acquire the mutex anyway.
    //舊state值已上鎖,并且未進入饑餓模式,且可以自旋,進入自旋邏輯
    if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
      // Active spinning makes sense. 
      // Try to set mutexWoken flag to inform Unlock
      // to not wake other blocked goroutines.
      // 當前協程未喚醒 
      //&& old.state 為未喚起狀態,就是說沒有其他被喚起的waiter
      //&& waiter數>0 
      //&& m.state標記為喚起狀態成功
      if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
        atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
        //標記當前協程為喚起狀態
        //r: 這是為了通知在解鎖Unlock()中不要再喚醒其他的waiter了
        awoke = true
      }
      //自旋
      runtime_doSpin()
      //自旋計數器
      iter++
      old = m.state
      continue
    }
    //r: old是鎖當前的狀態，new是期望的狀態，以期于在后面的CAS操作中更改鎖的狀態
    //new代表期望的state值
    new := old
    // Don't try to acquire starving mutex, new arriving goroutines must queue.
    //old不是饑餓狀態,new帶上上鎖標志位,也就是饑餓狀態不上鎖
    if old&mutexStarving == 0 {
      new |= mutexLocked
    }
    //舊state值是上鎖狀態或饑餓狀態,新state waiter數+1
    //r: 表示當前goroutine將被作為waiter置于等待隊列隊尾
    if old&(mutexLocked|mutexStarving) != 0 {
      new += 1 << mutexWaiterShift
    }
    // The current goroutine switches mutex to starvation mode.
    // But if the mutex is currently unlocked, don't do the switch.
    // Unlock expects that starving mutex has waiters, which will not
    // be true in this case.
    //當前協程為饑餓狀態&&舊state已上鎖,新state加饑餓標志位
    if starving && old&mutexLocked != 0 {
      new |= mutexStarving
    }
    //r:? 當awoke為true，則表明當前goroutine在自旋邏輯中，成功修改鎖的Woken狀態位為1
    if awoke {
      // The goroutine has been woken from sleep,
      // so we need to reset the flag in either case.
      if new&mutexWoken == 0 {
        throw("sync: inconsistent mutex state")
      }
      //新state關閉喚醒標志位
      //r: 因為在后續的邏輯中，當前goroutine要么是拿到鎖了，要么是被掛起。
      // 如果是掛起狀態，那就需要等待其他釋放鎖的goroutine來喚醒。
      // 假如其他goroutine在unlock的時候發現Woken的位置不是0，則就不會去喚醒，那該goroutine就無法再醒來加鎖。(見unlock邏輯)

      new &^= mutexWoken
    }
    //r: 嘗試將鎖的狀態更新為期望狀態
    if atomic.CompareAndSwapInt32(&m.state, old, new) {
      //舊state不是鎖或饑餓狀態,上鎖成功,返回
      if old&(mutexLocked|mutexStarving) == 0 {
        break // locked the mutex with CAS
      }
      // If we were already waiting before, queue at the front of the queue.
      //r: 如果走到這里，那就證明當前goroutine沒有獲取到鎖
      // 這里判斷waitStartTime != 0就證明當前goroutine之前已經等待過了，則需要將其放置在等待隊列隊頭
      //進入隊列是否排在最前
      queueLifo := waitStartTime != 0
      if waitStartTime == 0 {
        waitStartTime = runtime_nanotime()
      }
      //阻塞
      runtime_SemacquireMutex(&m.sema, queueLifo, 1)
      //r: 被信號量喚醒之后檢查當前goroutine是否應該表示為饑餓
      // （這里表示為饑餓之后，會在下一輪循環中嘗試將鎖的狀態更改為饑餓模式）
      // 1. 如果當前goroutine已經饑餓（在上一次循環中更改了starving為true）
      // 2. 如果當前goroutine已經等待了1ms以上
      
      //被信號量喚醒后當前協程是否進入饑餓狀態
      //1. 之前是饑餓狀態
      //2. 運行時間超過1ms
      starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
      // 再次獲取鎖狀態
      old = m.state
      if old&mutexStarving != 0 {
        // If this goroutine was woken and mutex is in starvation mode,
        // ownership was handed off to us but mutex is in somewhat
        // inconsistent state: mutexLocked is not set and we are still
        // accounted as waiter. Fix that.
        //饑餓模式協程是在Unlock()時handoff到當前協程的
        
        //r:? 如果當前鎖既不是被獲取也不是被喚醒狀態，或者等待隊列為空
        // 這代表鎖狀態產生了不一致的問題
        if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
          throw("sync: inconsistent mutex state")
        }
        //m.state 上鎖,waiter數-1
        delta := int32(mutexLocked - 1<<mutexWaiterShift)
        //當前協程不是饑餓狀態或舊state的waiter數=1,則m.state饑餓標志位置0
        if !starving || old>>mutexWaiterShift == 1 {
          // Exit starvation mode.
          // Critical to do it here and consider wait time.
          // Starvation mode is so inefficient, that two goroutines
          // can go lock-step infinitely once they switch mutex
          // to starvation mode.
          delta -= mutexStarving
        }
        atomic.AddInt32(&m.state, delta)
        //拿到鎖,退出.
        break
      }
      awoke = true
      iter = 0
    } else {
      //執行循環前的語句,恢復最新現場
      old = m.state
    }
  }

  if race.Enabled {
    race.Acquire(unsafe.Pointer(m))
  }
}

Unlock

// Unlock unlocks m.
// It is a run-time error if m is not locked on entry to Unlock.
//
// A locked Mutex is not associated with a particular goroutine.
// It is allowed for one goroutine to lock a Mutex and then
// arrange for another goroutine to unlock it.
func (m *Mutex) Unlock() {
  if race.Enabled {
    _ = m.state
    race.Release(unsafe.Pointer(m))
  }

  // Fast path: drop lock bit.
  //m.state取消鎖狀態,返回值new代表修改后的新值
  //如果為0代表沒有其他鎖了,退出;否則進入unlockSlow()
  //鎖空閑有兩種情況:
  //1. 所有位為0,代表沒有鎖了
  //2. 標志位為0, waiter數量>0,還有協程在等待解鎖
  new := atomic.AddInt32(&m.state, -mutexLocked)
  if new != 0 {
    // Outlined slow path to allow inlining the fast path.
    // To hide unlockSlow during tracing we skip one extra frame when tracing GoUnblock.
    m.unlockSlow(new)
  }
}

UnlockSlow

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 there are no waiters or a goroutine has already
      // been woken or grabbed the lock, no need to wake anyone.
      // In starvation mode ownership is directly handed off from unlocking
      // goroutine to the next waiter. We are not part of this chain,
      // since we did not observe mutexStarving when we unlocked the mutex above.
      // So get off the way.
      //解鎖,結束,退出
      //1. 沒有waiter了
      //2. 已上鎖
      //3. 鎖處于喚醒狀態,表示有協程被喚醒
      //4. 饑餓模式, 所有權交給了被解鎖饑餓模式的waiter
      if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
        return
      }
      // Grab the right to wake someone.
      // 如果能走到這，那就是上面的if判斷沒通過
      // 說明當前鎖是空閑狀態，但是等待隊列中有waiter，且沒有goroutine被喚醒
      // 所以，這里我們想要把鎖的狀態設置為被喚醒，等待隊列waiter數-1
      new = (old - 1<<mutexWaiterShift) | mutexWoken
      if atomic.CompareAndSwapInt32(&m.state, old, new) {
        //通過信號量喚醒某一個waiter,退出
        runtime_Semrelease(&m.sema, false, 1)
        return
      }
      //失敗的話,更新old信息,進入下個循環
      old = m.state
    }
  } else {
    // Starving mode: handoff mutex ownership to the next waiter, and yield
    // our time slice so that the next waiter can start to run immediately.
    // Note: mutexLocked is not set, the waiter will set it after wakeup.
    // But mutex is still considered locked if mutexStarving is set,
    // so new coming goroutines won't acquire it.
    //饑餓模式,喚醒等待隊列隊頭waiter
    runtime_Semrelease(&m.sema, true, 1)
  }
}

其他關鍵函數

runtime_canSpin

是否可自旋,不展開

runtime_doSpin

核心是匯編實現,循環執行三十次PAUSE指令

runtime_SemacquireMutex

信號量上鎖

sem來自單詞semaphore 信號量

runtime_Semrelease

信號量釋放

func runtime_Semrelease(s *uint32, handoff bool, skipframes int)

If handoff is true, pass count directly to the first waiter.

handoff 就是傳球的意思，handoff 為 false 時，僅僅喚醒等待隊列中第一個協程，但是不會立馬調度該協程；當 handoff 為 true 時，會立馬調度被喚醒的協程，此外，當 handoff = true 時，被喚醒的協程會繼承當前協程的時間片。具體例子，假設每個 goroutine 的時間片為 2ms，gorounte A 已經執行了 1ms，假設它通過 runtime_Semrelease(handoff = true) 喚醒了 goroutine B，則 goroutine B 剩余的時間片為 2 - 1 = 1ms。

golang 中 sync.Mutex 的實現

semrelease1(addr, handoff, skipframes) 參數handoff若為true，則讓被喚醒的g立刻繼承當前g的時間片繼續執行。若handoff為false，則把剛被喚醒的g放到當前p的runq中。

Golang sync.Mutex 源碼分析

RWMutex

很簡單,看源碼就行

[Go并發] - RWMutex源碼解析

type RWMutex struct {
  w           Mutex  // held if there are pending writers
  writerSem   uint32 // semaphore for writers to wait for completing readers
  readerSem   uint32 // semaphore for readers to wait for completing writers
  readerCount int32  // number of pending readers 當前讀鎖數量
  readerWait  int32  // number of departing readers 要離開的讀鎖數量,暨等待寫鎖解鎖,解鎖后可以釋放的讀鎖數量
}

Lock()

// Lock locks rw for writing.
// If the lock is already locked for reading or writing,
// Lock blocks until the lock is available.
func (rw *RWMutex) Lock() {
  if race.Enabled {
    _ = rw.w.state
    race.Disable()
  }
  // First, resolve competition with other writers.
  
  rw.w.Lock() //通過sync.Lock()限制多寫鎖進入下邊的邏輯
  // Announce to readers there is a pending writer.
  //r值不變, rwmutexMaxReaders值為1<<30
  //可以理解為只要讀鎖的數量小于1<<30位,rw.readerCount值<0表示有寫鎖.
  //也可以理解為加上一個負數,將31位以上都標記為1,代表有寫鎖, 剩余30位記錄讀鎖數量
  r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
  // Wait for active readers.
  //r!=0 有讀鎖,不能釋放寫鎖
  //將readerCount轉移到readerWait,readerWait的新值!=0 (以上可以翻譯為有讀鎖,將讀鎖數轉移到讀等待數,然后寫鎖阻塞,)
  // 滿足上面兩個條件,寫鎖阻塞, 等待喚醒,不返回
  if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
    runtime_SemacquireMutex(&rw.writerSem, false, 0)
  }
  if race.Enabled {
    race.Enable()
    race.Acquire(unsafe.Pointer(&rw.readerSem))
    race.Acquire(unsafe.Pointer(&rw.writerSem))
  }
}

UnLock()

// Unlock unlocks rw for writing. It is a run-time error if rw is
// not locked for writing on entry to Unlock.
//
// As with Mutexes, a locked RWMutex is not associated with a particular
// goroutine. One goroutine may RLock (Lock) a RWMutex and then
// arrange for another goroutine to RUnlock (Unlock) it.
func (rw *RWMutex) Unlock() {
  if race.Enabled {
    _ = rw.w.state
    race.Release(unsafe.Pointer(&rw.readerSem))
    race.Disable()
  }

  // Announce to readers there is no active writer.\
  //將Lock()方法減去的值加回來,變成正數
  r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
  if r >= rwmutexMaxReaders {
    race.Enable()
    throw("sync: Unlock of unlocked RWMutex")
  }
  // Unblock blocked readers, if any.
  //喚醒在RLock()方法阻塞的讀操作,數量為r
  for i := 0; i < int(r); i++ {
    runtime_Semrelease(&rw.readerSem, false, 0)
  }
  // Allow other writers to proceed.
  rw.w.Unlock()
  if race.Enabled {
    race.Enable()
  }
}

RLock()

// RLock locks rw for reading.
//
// It should not be used for recursive read locking; a blocked Lock
// call excludes new readers from acquiring the lock. See the
// documentation on the RWMutex type.
func (rw *RWMutex) RLock() {
  if race.Enabled {
    _ = rw.w.state
    race.Disable()
  }
  //<0表示已上寫鎖,阻塞
  if atomic.AddInt32(&rw.readerCount, 1) < 0 {
    // A writer is pending, wait for it.
    runtime_SemacquireMutex(&rw.readerSem, false, 0)
  }
  if race.Enabled {
    race.Enable()
    race.Acquire(unsafe.Pointer(&rw.readerSem))
  }
}

UnRLock()

// RUnlock undoes a single RLock call;
// it does not affect other simultaneous readers.
// It is a run-time error if rw is not locked for reading
// on entry to RUnlock.
func (rw *RWMutex) RUnlock() {
  if race.Enabled {
    _ = rw.w.state
    race.ReleaseMerge(unsafe.Pointer(&rw.writerSem))
    race.Disable()
  }
   //<0表示已上寫鎖,慢解鎖
  if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
    // Outlined slow-path to allow the fast-path to be inlined
    rw.rUnlockSlow(r)
  }
  if race.Enabled {
    race.Enable()
  }
}

// RUnlock undoes a single RLock call;
// it does not affect other simultaneous readers.
// It is a run-time error if rw is not locked for reading
// on entry to RUnlock.
func (rw *RWMutex) rUnlockSlow(r int32) {
  if r+1 == 0 || r+1 == -rwmutexMaxReaders {
    race.Enable()
    throw("sync: RUnlock of unlocked RWMutex")
  }
  // A writer is pending.
  //最后一個讀等待,喚醒寫鎖
  if atomic.AddInt32(&rw.readerWait, -1) == 0 {
    // The last reader unblocks the writer.
    runtime_Semrelease(&rw.writerSem, false, 1)
  }
}

以上就是“Go語言中鎖如何實現”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。