您好,登錄后才能下訂單哦!
本文小編為大家詳細(xì)介紹“Golang中的sync.Cond怎么使用”,內(nèi)容詳細(xì),步驟清晰,細(xì)節(jié)處理妥當(dāng),希望這篇“Golang中的sync.Cond怎么使用”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來(lái)學(xué)習(xí)新知識(shí)吧。
sync.Cond
是Go語(yǔ)言標(biāo)準(zhǔn)庫(kù)中的一個(gè)類型,代表?xiàng)l件變量。條件變量是用于多個(gè)goroutine之間進(jìn)行同步和互斥的一種機(jī)制。sync.Cond
可以用于等待和通知goroutine,以便它們可以在特定條件下等待或繼續(xù)執(zhí)行。
sync.Cond
的定義如下,提供了Wait
,Singal
,Broadcast
以及NewCond
方法
type Cond struct {
noCopy noCopy
// L is held while observing or changing the condition
L Locker
notify notifyList
checker copyChecker
}
func NewCond(l Locker) *Cond {}
func (c *Cond) Wait() {}
func (c *Cond) Signal() {}
func (c *Cond) Broadcast() {}
NewCond
方法: 提供創(chuàng)建Cond
實(shí)例的方法
Wait
方法: 使當(dāng)前線程進(jìn)入阻塞狀態(tài),等待其他協(xié)程喚醒
Singal
方法: 喚醒一個(gè)等待該條件變量的線程,如果沒有線程在等待,則該方法會(huì)立即返回。
Broadcast
方法: 喚醒所有等待該條件變量的線程,如果沒有線程在等待,則該方法會(huì)立即返回。
當(dāng)使用sync.Cond
時(shí),通常需要以下幾個(gè)步驟:
定義一個(gè)互斥鎖,用于保護(hù)共享數(shù)據(jù);
創(chuàng)建一個(gè)sync.Cond
對(duì)象,關(guān)聯(lián)這個(gè)互斥鎖;
在需要等待條件變量的地方,獲取這個(gè)互斥鎖,并使用Wait
方法等待條件變量被通知;
在需要通知等待的協(xié)程時(shí),使用Signal
或Broadcast
方法通知等待的協(xié)程。
最后,釋放這個(gè)互斥鎖。
下面是一個(gè)使用sync.Cond的簡(jiǎn)單示例,實(shí)現(xiàn)了一個(gè)生產(chǎn)者-消費(fèi)者模型:
var (
// 1. 定義一個(gè)互斥鎖
mu sync.Mutex
cond *sync.Cond
count int
)
func init() {
// 2.將互斥鎖和sync.Cond進(jìn)行關(guān)聯(lián)
cond = sync.NewCond(&mu)
}
func worker(id int) {
// 消費(fèi)者
for {
// 3. 在需要等待的地方,獲取互斥鎖,調(diào)用Wait方法等待被通知
mu.Lock()
// 這里會(huì)不斷循環(huán)判斷 是否有待消費(fèi)的任務(wù)
for count == 0 {
cond.Wait() // 等待任務(wù)
}
count--
fmt.Printf("worker %d: 處理了一個(gè)任務(wù)\n", id)
// 5. 最后釋放鎖
mu.Unlock()
}
}
func main() {
// 啟動(dòng)5個(gè)消費(fèi)者
for i := 1; i <= 5; i++ {
go worker(i)
}
for {
// 生產(chǎn)者
time.Sleep(1 * time.Second)
mu.Lock()
count++
// 4. 在需要等待的地方,獲取互斥鎖,調(diào)用BroadCast/Singal方法進(jìn)行通知
cond.Broadcast()
mu.Unlock()
}
}
在這個(gè)示例中,創(chuàng)建一個(gè)生產(chǎn)者在生產(chǎn)任務(wù),同時(shí)創(chuàng)建五個(gè)消費(fèi)者來(lái)消費(fèi)任務(wù)。當(dāng)任務(wù)數(shù)為0時(shí),此時(shí)消費(fèi)者會(huì)調(diào)用Wait
方法進(jìn)入阻塞狀態(tài),等待生產(chǎn)者的通知。
當(dāng)生產(chǎn)者產(chǎn)生任務(wù)后,使用Broadcast
方法通知所有的消費(fèi)者,喚醒處于阻塞狀態(tài)的消費(fèi)者,開始消費(fèi)任務(wù)。這里使用sync.Cond
實(shí)現(xiàn)多個(gè)協(xié)程之間的通信和同步。
這里的原因在于調(diào)用Wait
方法前如果不加鎖,有可能會(huì)出現(xiàn)競(jìng)態(tài)條件。
這里假設(shè)多個(gè)協(xié)程都處于等待狀態(tài),然后一個(gè)協(xié)程調(diào)用了Broadcast喚醒了其中一個(gè)或多個(gè)協(xié)程,此時(shí)這些協(xié)程都會(huì)被喚醒。
如下,假設(shè)調(diào)用Wait
方法前沒有加鎖的話,那么所有協(xié)程都會(huì)去調(diào)用condition
方法去判斷是否滿足條件,然后都通過(guò)驗(yàn)證,執(zhí)行后續(xù)操作。
for !condition() {
c.Wait()
}
c.L.Lock()
// 滿足條件情況下,執(zhí)行的邏輯
c.L.Unlock()
此時(shí)會(huì)出現(xiàn)的情況為,本來(lái)是需要在滿足condition
方法的前提下,才能執(zhí)行的操作?,F(xiàn)在有可能的效果,為前面一部分協(xié)程執(zhí)行時(shí),還是滿足condition
條件的;但是后面的協(xié)程,盡管不滿足condition
條件,還是執(zhí)行了后續(xù)操作,可能導(dǎo)致程序出錯(cuò)。
正確的用法應(yīng)該是,在調(diào)用Wait
方法前便加鎖,那么即使多個(gè)協(xié)程被喚醒,一次也只會(huì)有一個(gè)協(xié)程判斷是否滿足condition
條件,然后執(zhí)行后續(xù)操作。這樣子就不會(huì)出現(xiàn)多個(gè)協(xié)程同時(shí)判斷,導(dǎo)致不滿足條件,也執(zhí)行后續(xù)操作的情況出現(xiàn)。
c.L.Lock()
for !condition() {
c.Wait()
}
// 滿足條件情況下,執(zhí)行的邏輯
c.L.Unlock()
sync.Cond
是為了協(xié)調(diào)多個(gè)協(xié)程之間對(duì)共享數(shù)據(jù)的訪問而設(shè)計(jì)的。使用sync.Cond
的場(chǎng)景通常都涉及到對(duì)共享數(shù)據(jù)的操作,如果沒有共享數(shù)據(jù)的操作,那么沒有太大必要使用sync.Cond
來(lái)進(jìn)行協(xié)調(diào)。當(dāng)然,如果存在重復(fù)喚醒的場(chǎng)景,即使沒有對(duì)共享數(shù)據(jù)的操作,也是可以使用sync.Cond
來(lái)進(jìn)行協(xié)調(diào)的。
通常情況下,使用sync.Cond
的場(chǎng)景為:多個(gè)協(xié)程需要訪問同一份共享數(shù)據(jù),需要等待某個(gè)條件滿足后才能訪問或修改這份共享數(shù)據(jù)。
在這些場(chǎng)景下,使用sync.Cond
可以方便地實(shí)現(xiàn)對(duì)共享數(shù)據(jù)的協(xié)調(diào),避免了多個(gè)協(xié)程之間的競(jìng)爭(zhēng)和沖突,保證了共享數(shù)據(jù)的正確性和一致性。因此,如果沒有涉及到共享數(shù)據(jù)的操作,就沒有必要使用sync.Cond
來(lái)進(jìn)行協(xié)調(diào)。
下面舉一個(gè)使用 sync.Cond
的例子,用它來(lái)實(shí)現(xiàn)生產(chǎn)者-消費(fèi)者模型。生產(chǎn)者往items
放置元素,當(dāng)items
滿了之后,便進(jìn)入等待狀態(tài),等待消費(fèi)者喚醒。消費(fèi)者從items
中取數(shù)據(jù),當(dāng)items
空了之后,便進(jìn)入等待狀態(tài),等待生產(chǎn)者喚醒。
這里多個(gè)協(xié)程對(duì)同一份數(shù)據(jù)進(jìn)行操作,且需要基于該數(shù)據(jù)判斷是否喚醒其他協(xié)程或進(jìn)入阻塞狀態(tài),來(lái)實(shí)現(xiàn)多個(gè)協(xié)程的同步和協(xié)調(diào)。sync.Cond
就適合在這種場(chǎng)景下使用,其正是為這種場(chǎng)景設(shè)計(jì)的。
package main
import (
"fmt"
"sync"
"time"
)
type Queue struct {
items []int
cap int
lock sync.Mutex
cond *sync.Cond
}
func NewQueue(cap int) *Queue {
q := &Queue{
items: make([]int, 0),
cap: cap,
}
q.cond = sync.NewCond(&q.lock)
return q
}
func (q *Queue) Put(item int) {
q.lock.Lock()
defer q.lock.Unlock()
for len(q.items) == q.cap {
q.cond.Wait()
}
q.items = append(q.items, item)
q.cond.Broadcast()
}
func (q *Queue) Get() int {
q.lock.Lock()
defer q.lock.Unlock()
for len(q.items) == 0 {
q.cond.Wait()
}
item := q.items[0]
q.items = q.items[1:]
q.cond.Broadcast()
return item
}
func main() {
q := NewQueue(10)
// Producer
go func() {
for {
q.Put(i)
fmt.Printf("Producer: Put %d\n", i)
time.Sleep(100 * time.Millisecond)
}
}()
// Consumer
go func() {
for {
item := q.Get()
fmt.Printf("Consumer: Get %d\n", item)
time.Sleep(200 * time.Millisecond)
}
}()
wg.Wait()
}
在某些場(chǎng)景中,由于不滿足某種條件,此時(shí)協(xié)程進(jìn)入阻塞狀態(tài),等待條件滿足后,由其他協(xié)程喚醒,再繼續(xù)執(zhí)行。在整個(gè)流程中,可能會(huì)多次進(jìn)入阻塞狀態(tài),多次被喚醒的情況。
比如上面生產(chǎn)者和消費(fèi)者模型的例子,生產(chǎn)者可能會(huì)產(chǎn)生一批任務(wù),然后喚醒消費(fèi)者,消費(fèi)者消費(fèi)完之后,會(huì)進(jìn)入阻塞狀態(tài),等待下一批任務(wù)的到來(lái)。所以這個(gè)流程中,協(xié)程可能多次進(jìn)入阻塞狀態(tài),然后再多次被喚醒。
sync.Cond
能夠?qū)崿F(xiàn)即使協(xié)程多次進(jìn)入阻塞狀態(tài),也能重復(fù)喚醒該協(xié)程。所以,當(dāng)出現(xiàn)需要實(shí)現(xiàn)重復(fù)喚醒的場(chǎng)景時(shí),使用sync.Cond
也是非常合適的。
在Sync.Cond
存在一個(gè)通知隊(duì)列,保存了所有處于等待狀態(tài)的協(xié)程。通知隊(duì)列定義如下:
type notifyList struct {
wait uint32
notify uint32
lock uintptr // key field of the mutex
head unsafe.Pointer
tail unsafe.Pointer
}
當(dāng)調(diào)用Wait
方法時(shí),此時(shí)Wait
方法會(huì)釋放所持有的鎖,然后將自己放到notifyList
等待隊(duì)列中等待。此時(shí)會(huì)將當(dāng)前協(xié)程加入到等待隊(duì)列的尾部,然后進(jìn)入阻塞狀態(tài)。
當(dāng)調(diào)用Signal
時(shí),此時(shí)會(huì)喚醒等待隊(duì)列中的第一個(gè)協(xié)程,其他繼續(xù)等待。如果此時(shí)沒有處于等待狀態(tài)的協(xié)程,調(diào)用Signal
不會(huì)有其他作用,直接返回。當(dāng)調(diào)用BoradCast
方法時(shí),則會(huì)喚醒notfiyList
中所有處于等待狀態(tài)的協(xié)程。
sync.Cond
的代碼實(shí)現(xiàn)比較簡(jiǎn)單,協(xié)程的喚醒和阻塞已經(jīng)由運(yùn)行時(shí)包實(shí)現(xiàn)了,sync.Cond
的實(shí)現(xiàn)直接調(diào)用了運(yùn)行時(shí)包提供的API。
Wait
方法首先調(diào)用runtime_notifyListAd
方法,將自己加入到等待隊(duì)列中,然后釋放鎖,等待其他協(xié)程的喚醒。
func (c *Cond) Wait() {
// 將自己放到等待隊(duì)列中
t := runtime_notifyListAdd(&c.notify)
// 釋放鎖
c.L.Unlock()
// 等待喚醒
runtime_notifyListWait(&c.notify, t)
// 重新獲取鎖
c.L.Lock()
}
Singal
方法調(diào)用runtime_notifyListNotifyOne
喚醒等待隊(duì)列中的一個(gè)協(xié)程。
func (c *Cond) Signal() {
// 喚醒等待隊(duì)列中的一個(gè)協(xié)程
runtime_notifyListNotifyOne(&c.notify)
}
Broadcast
方法調(diào)用runtime_notifyListNotifyAll
喚醒所有處于等待狀態(tài)的協(xié)程。
func (c *Cond) Broadcast() {
// 喚醒等待隊(duì)列中所有的協(xié)程
runtime_notifyListNotifyAll(&c.notify)
}
在上面2.5已經(jīng)說(shuō)明了,調(diào)用Sync.Cond
方法前需要加鎖,否則有可能出現(xiàn)競(jìng)態(tài)條件。而且,現(xiàn)有的sync.Cond
的實(shí)現(xiàn),如果在調(diào)用Wait
方法前未加鎖,此時(shí)會(huì)直接panic
,下面是一個(gè)簡(jiǎn)單例子的說(shuō)明:
package main
import (
"fmt"
"sync"
"time"
)
var (
count int
cond *sync.Cond
lk sync.Mutex
)
func main() {
cond = sync.NewCond(&lk)
wg := sync.WaitGroup{}
wg.Add(2)
go func() {
defer wg.Done()
for {
time.Sleep(time.Second)
count++
cond.Broadcast()
}
}()
go func() {
defer wg.Done()
for {
time.Sleep(time.Millisecond * 500)
//cond.L.Lock()
for count%10 != 0 {
cond.Wait()
}
t.Logf("count = %d", count)
//cond.L.Unlock()
}
}()
wg.Wait()
}
上面代碼中,協(xié)程一每隔1s,將count字段的值自增1,然后喚醒所有處于等待狀態(tài)的協(xié)程。協(xié)程二執(zhí)行的條件為count的值為10的倍數(shù),此時(shí)滿足執(zhí)行條件,喚醒后將會(huì)繼續(xù)往下執(zhí)行。
但是這里在調(diào)用sync.Wait
方法前,沒有先獲取鎖,下面是其執(zhí)行結(jié)果,會(huì)拋出 fatal error: sync: unlock of unlocked mutex 錯(cuò)誤,結(jié)果如下:
count = 0
fatal error: sync: unlock of unlocked mutex
因此,在調(diào)用Wait
方法前,需要先獲取到與sync.Cond
關(guān)聯(lián)的鎖,否則會(huì)直接拋出異常。
調(diào)用sync.Wait
方法,協(xié)程進(jìn)入阻塞狀態(tài)后被喚醒,沒有重新檢查條件變量,此時(shí)有可能仍然處于不滿足條件變量的場(chǎng)景下。然后直接執(zhí)行后續(xù)操作,有可能會(huì)導(dǎo)致程序出錯(cuò)。下面舉一個(gè)簡(jiǎn)單的例子:
package main
import (
"fmt"
"sync"
"time"
)
var (
count int
cond *sync.Cond
lk sync.Mutex
)
func main() {
cond = sync.NewCond(&lk)
wg := sync.WaitGroup{}
wg.Add(3)
go func() {
defer wg.Done()
for {
time.Sleep(time.Second)
cond.L.Lock()
// 將flag 設(shè)置為true
flag = true
// 喚醒所有處于等待狀態(tài)的協(xié)程
cond.Broadcast()
cond.L.Unlock()
}
}()
for i := 0; i < 2; i++ {
go func(i int) {
defer wg.Done()
for {
time.Sleep(time.Millisecond * 500)
cond.L.Lock()
// 不滿足條件,此時(shí)進(jìn)入等待狀態(tài)
if !flag {
cond.Wait()
}
// 被喚醒后,此時(shí)可能仍然不滿足條件
fmt.Printf("協(xié)程 %d flag = %t", i, flag)
flag = false
cond.L.Unlock()
}
}(i)
}
wg.Wait()
}
在這個(gè)例子,我們啟動(dòng)了一個(gè)協(xié)程,定時(shí)將flag
設(shè)置為true,相當(dāng)于每隔一段時(shí)間,便滿足執(zhí)行條件,然后喚醒所有處于等待狀態(tài)的協(xié)程。
然后又啟動(dòng)了兩個(gè)協(xié)程,在滿足條件的前提下,開始執(zhí)行后續(xù)操作,但是這里協(xié)程被喚醒后,沒有重新檢查條件變量,具體看第39行。這里會(huì)出現(xiàn)的場(chǎng)景是,第一個(gè)協(xié)程被喚醒后,此時(shí)執(zhí)行后續(xù)操作,然后將flag
重新設(shè)置為false,此時(shí)已經(jīng)不滿足條件了。之后第二個(gè)協(xié)程喚醒后,獲取到鎖,沒有重新檢查此時(shí)是否滿足執(zhí)行條件,直接向下執(zhí)行,這個(gè)就和我們預(yù)期不符,可能會(huì)導(dǎo)致程序出錯(cuò),代碼執(zhí)行效果如下:
協(xié)程 1 flag = true
協(xié)程 0 flag = false
協(xié)程 1 flag = true
協(xié)程 0 flag = false
可以看到,此時(shí)協(xié)程0執(zhí)行時(shí),flag
的值均為false
,說(shuō)明此時(shí)其實(shí)并不符合執(zhí)行條件,可能會(huì)導(dǎo)致程序出錯(cuò)。因此正確用法應(yīng)該像下面這樣子,被喚醒后,需要重新檢查條件變量,滿足條件之后才能繼續(xù)向下執(zhí)行。
c.L.Lock()
// 喚醒后,重新檢查條件變量是否滿足條件
for !condition() {
c.Wait()
}
// 滿足條件情況下,執(zhí)行的邏輯
c.L.Unlock()
讀到這里,這篇“Golang中的sync.Cond怎么使用”文章已經(jīng)介紹完畢,想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過(guò)才能領(lǐng)會(huì),如果想了解更多相關(guān)內(nèi)容的文章,歡迎關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。