主頁 > 知識庫 > golang 自旋鎖的實(shí)現(xiàn)

golang 自旋鎖的實(shí)現(xiàn)

熱門標(biāo)簽:南通如皋申請開通400電話 浙江高速公路地圖標(biāo)注 廣州呼叫中心外呼系統(tǒng) 地圖標(biāo)注的汽車標(biāo) 江西轉(zhuǎn)化率高的羿智云外呼系統(tǒng) 中國地圖標(biāo)注省會高清 學(xué)海導(dǎo)航地圖標(biāo)注 西部云谷一期地圖標(biāo)注 高德地圖標(biāo)注口訣

CAS算法(compare and swap)

CAS算法是一種有名的無鎖算法。無鎖編程,即不使用鎖的情況下實(shí)現(xiàn)多線程之間的變量同步,也就是在沒有線程被阻塞的情況下實(shí)現(xiàn)變量的同步,所以也叫非阻塞同步(Non-blocking Synchronization)。CAS算法涉及到三個操作數(shù)

  • 需要讀寫的內(nèi)存值V
  • 進(jìn)行比較的值A(chǔ)
  • 擬寫入的新值B

當(dāng)且僅當(dāng) V 的值等于 A時,CAS通過原子方式用新值B來更新V的值,否則不會執(zhí)行任何操作(比較和替換是一個原子操作)。一般情況下是一個自旋操作,即不斷的重試。

自旋鎖

自旋鎖是指當(dāng)一個線程在獲取鎖的時候,如果鎖已經(jīng)被其他線程獲取,那么該線程將循環(huán)等待,然后不斷地判斷是否能夠被成功獲取,知直到獲取到鎖才會退出循環(huán)。

獲取鎖的線程一直處于活躍狀態(tài),但是并沒有執(zhí)行任何有效的任務(wù),使用這種鎖會造成 busy-waiting 。

它是為實(shí)現(xiàn)保護(hù)共享資源而提出的一種鎖機(jī)制。其實(shí),自旋鎖與互斥鎖比較類似,它們都是為了解決某項(xiàng)資源的互斥使用。無論是互斥鎖,還是自旋鎖,在任何時刻,最多只能由一個保持者,也就說,在任何時刻最多只能有一個執(zhí)行單元獲得鎖。但是兩者在調(diào)度機(jī)制上略有不同。對于互斥鎖,如果資源已經(jīng)被占用,資源申請者只能進(jìn)入睡眠狀態(tài)。但是自旋鎖不會引起調(diào)用者睡眠,如果自旋鎖已經(jīng)被別的執(zhí)行單元保持,調(diào)用者就一直循環(huán)在那里看是否該自旋鎖的保持者已經(jīng)釋放了鎖,“自旋”一詞就是因此而得名。

golang實(shí)現(xiàn)自旋鎖

type spinLock uint32
func (sl *spinLock) Lock() {
  for !atomic.CompareAndSwapUint32((*uint32)(sl), 0, 1) {
    runtime.Gosched()
  }
}
func (sl *spinLock) Unlock() {
  atomic.StoreUint32((*uint32)(sl), 0)
}
func NewSpinLock() sync.Locker {
  var lock spinLock
  return lock
}

可重入的自旋鎖和不可重入的自旋鎖

文章開始的時候的那段代碼,仔細(xì)分析一下就可以看出,它是不支持重入的,即當(dāng)一個線程第一次已經(jīng)獲取到了該鎖,在鎖釋放之前又一次重新獲取該鎖,第二次就不能成功獲取到。由于不滿足CAS,所以第二次獲取會進(jìn)入while循環(huán)等待,而如果是可重入鎖,第二次也是應(yīng)該能夠成功獲取到的。

而且,即使第二次能夠成功獲取,那么當(dāng)?shù)谝淮吾尫沛i的時候,第二次獲取到的鎖也會被釋放,而這是不合理的。

為了實(shí)現(xiàn)可重入鎖,我們需要引入一個計(jì)數(shù)器,用來記錄獲取鎖的線程數(shù)

type spinLock struct {
   owner int
   count int
}

func (sl *spinLock) Lock() {
    me := GetGoroutineId()
    if spinLock .owner == me { // 如果當(dāng)前線程已經(jīng)獲取到了鎖,線程數(shù)增加一,然后返回
        sl.count++
        return
    }
    // 如果沒獲取到鎖,則通過CAS自旋
  for !atomic.CompareAndSwapUint32((*uint32)(sl), 0, 1) {
    runtime.Gosched()
  }
}
func (sl *spinLock) Unlock() {
   if rl.owner != GetGoroutineId() {
     panic("illegalMonitorStateError")
   }
   if sl.count >0 { // 如果大于0,表示當(dāng)前線程多次獲取了該鎖,釋放鎖通過count減一來模擬
      sl.count--
    }else { // 如果count==0,可以將鎖釋放,這樣就能保證獲取鎖的次數(shù)與釋放鎖的次數(shù)是一致的了。
      atomic.StoreUint32((*uint32)(sl), 0)
    }
}

func GetGoroutineId() int {
  defer func() {
    if err := recover(); err != nil {
      fmt.Println("panic recover:panic info:%v", err)   }
  }()

  var buf [64]byte
  n := runtime.Stack(buf[:], false)
  idField := strings.Fields(strings.TrimPrefix(string(buf[:n]), "goroutine "))[0]
  id, err := strconv.Atoi(idField)
  if err != nil {
    panic(fmt.Sprintf("cannot get goroutine id: %v", err))
  }
  return id
}


func NewSpinLock() sync.Locker {
  var lock spinLock
  return lock
}

自旋鎖的其他變種

1. TicketLock

TicketLock主要解決的是公平性的問題。

思路:每當(dāng)有線程獲取鎖的時候,就給該線程分配一個遞增的id,我們稱之為排隊(duì)號,同時,鎖對應(yīng)一個服務(wù)號,每當(dāng)有線程釋放鎖,服務(wù)號就會遞增,此時如果服務(wù)號與某個線程排隊(duì)號一致,那么該線程就獲得鎖,由于排隊(duì)號是遞增的,所以就保證了最先請求獲取鎖的線程可以最先獲取到鎖,就實(shí)現(xiàn)了公平性。

可以想象成銀行辦理業(yè)務(wù)排隊(duì),排隊(duì)的每一個顧客都代表一個需要請求鎖的線程,而銀行服務(wù)窗口表示鎖,每當(dāng)有窗口服務(wù)完成就把自己的服務(wù)號加一,此時在排隊(duì)的所有顧客中,只有自己的排隊(duì)號與服務(wù)號一致的才可以得到服務(wù)。

2. CLHLock

CLH鎖是一種基于鏈表的可擴(kuò)展、高性能、公平的自旋鎖,申請線程只在本地變量上自旋,它不斷輪詢前驅(qū)的狀態(tài),如果發(fā)現(xiàn)前驅(qū)釋放了鎖就結(jié)束自旋,獲得鎖。

3. MCSLock

MCSLock則是對本地變量的節(jié)點(diǎn)進(jìn)行循環(huán)。

4. CLHLock 和 MCSLock

都是基于鏈表,不同的是CLHLock是基于隱式鏈表,沒有真正的后續(xù)節(jié)點(diǎn)屬性,MCSLock是顯示鏈表,有一個指向后續(xù)節(jié)點(diǎn)的屬性。

將獲取鎖的線程狀態(tài)借助節(jié)點(diǎn)(node)保存,每個線程都有一份獨(dú)立的節(jié)點(diǎn),這樣就解決了TicketLock多處理器緩存同步的問題。

自旋鎖與互斥鎖

  • 自旋鎖與互斥鎖都是為了實(shí)現(xiàn)保護(hù)資源共享的機(jī)制。
  • 無論是自旋鎖還是互斥鎖,在任意時刻,都最多只能有一個保持者。
  • 獲取互斥鎖的線程,如果鎖已經(jīng)被占用,則該線程將進(jìn)入睡眠狀態(tài);獲取自旋鎖的線程則不會睡眠,而是一直循環(huán)等待鎖釋放。

總結(jié):

  • 自旋鎖:線程獲取鎖的時候,如果鎖被其他線程持有,則當(dāng)前線程將循環(huán)等待,直到獲取到鎖。
  • 自旋鎖等待期間,線程的狀態(tài)不會改變,線程一直是用戶態(tài)并且是活動的(active)。
  • 自旋鎖如果持有鎖的時間太長,則會導(dǎo)致其它等待獲取鎖的線程耗盡CPU。
  • 自旋鎖本身無法保證公平性,同時也無法保證可重入性。
  • 基于自旋鎖,可以實(shí)現(xiàn)具備公平性和可重入性質(zhì)的鎖。
  • TicketLock:采用類似銀行排號叫好的方式實(shí)現(xiàn)自旋鎖的公平性,但是由于不停的讀取serviceNum,每次讀寫操作都必須在多個處理器緩存之間進(jìn)行緩存同步,這會導(dǎo)致繁重的系統(tǒng)總線和內(nèi)存的流量,大大降低系統(tǒng)整體的性能。
  • CLHLock和MCSLock通過鏈表的方式避免了減少了處理器緩存同步,極大的提高了性能,區(qū)別在于CLHLock是通過輪詢其前驅(qū)節(jié)點(diǎn)的狀態(tài),而MCS則是查看當(dāng)前節(jié)點(diǎn)的鎖狀態(tài)。
  • CLHLock在NUMA架構(gòu)下使用會存在問題。在沒有cache的NUMA系統(tǒng)架構(gòu)中,由于CLHLock是在當(dāng)前節(jié)點(diǎn)的前一個節(jié)點(diǎn)上自旋,NUMA架構(gòu)中處理器訪問本地內(nèi)存的速度高于通過網(wǎng)絡(luò)訪問其他節(jié)點(diǎn)的內(nèi)存,所以CLHLock在NUMA架構(gòu)上不是最優(yōu)的自旋鎖。

以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。

您可能感興趣的文章:
  • 詳解golang RWMutex讀寫互斥鎖源碼分析
  • 詳解Golang互斥鎖內(nèi)部實(shí)現(xiàn)

標(biāo)簽:貴州 吐魯番 德宏 東營 保定 曲靖 常州 許昌

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《golang 自旋鎖的實(shí)現(xiàn)》,本文關(guān)鍵詞  golang,自旋,鎖,的,實(shí)現(xiàn),golang,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《golang 自旋鎖的實(shí)現(xiàn)》相關(guān)的同類信息!
  • 本頁收集關(guān)于golang 自旋鎖的實(shí)現(xiàn)的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章