- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
本文将介绍 Go 语言中的 sync.Cond 并发原语,包括 sync.Cond 的基本使用方法、实现原理、使用注意事项以及常见的使用使用场景。能够更好地理解和应用 Cond 来实现 goroutine 之间的同步.
sync.Cond 是Go语言标准库中的一个类型,代表条件变量。条件变量是用于多个goroutine之间进行同步和互斥的一种机制。 sync.Cond 可以用于等待和通知goroutine,以便它们可以在特定条件下等待或继续执行.
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
方法: 提供创建 Cond
实例的方法 Wait
方法: 使当前线程进入阻塞状态,等待其他协程唤醒 Singal
方法: 唤醒一个等待该条件变量的线程,如果没有线程在等待,则该方法会立即返回。 Broadcast
方法: 唤醒所有等待该条件变量的线程,如果没有线程在等待,则该方法会立即返回。 当使用 sync.Cond 时,通常需要以下几个步骤:
sync.Cond
对象,关联这个互斥锁; Wait
方法等待条件变量被通知; Signal
或 Broadcast
方法通知等待的协程。 下面是一个简单的代码的示例,展示了大概的代码结构
var (
// 1. 定义一个互斥锁
mu sync.Mutex
cond *sync.Cond
count int
)
func init() {
// 2.将互斥锁和sync.Cond进行关联
cond = sync.NewCond(&mu)
}
go func(){
// 3. 在需要等待的地方,获取互斥锁,调用Wait方法等待被通知
mu.Lock()
// 这里会不断循环判断 是否满足条件
for !condition() {
cond.Wait() // 等待任务
}
mu.Unlock()
}
go func(){
// 执行业务逻辑
// 4. 满足条件,此时调用Broadcast唤醒处于等待状态的协程
cond.Broadcast()
}
下面通过描述 net/http 中的 connReader ,来展示使用 sync.Cond 实现阻塞等待通知的机制。这里我们不需要理解太多,只需要知道 connReader 下面两个方法
func (cr *connReader) Read(p []byte) (n int, err error) {}
func (cr *connReader) abortPendingRead() {}
Read 方法则是用于从 HTTP 连接中读取数据,不允许并发访问的。而 abortPendingRead 则是用于终止正在读取的连接.
从 abortPendingRead 方法的语意来看,是需要成功终止其他协程进行数据的读取之后,才能正常返回,也就是此时没有协程再继续读取数据了,才可以返回.
那abortPendingRead 如何得知是否还有协程在读取数据呢,其实是可以通过定时轮训 connReader 的状态,从而判断当前Read方法是否仍在读取数据。但是定时轮训效率太低,可能会造成cpu的大量空转。更好的方式,应该是让协程进入阻塞状态,然后等条件满足了,其他协程再来唤醒当前协程,然后再继续运行下去.
这个其实就是 sync.Cond 设计的用途,当不满足运行条件时,先进入阻塞状态,等待条件满足时,再由其他协程来唤醒,然后再继续运行下去,能够提高程序的执行效率。其中 Wait 方法便是让协程进入阻塞状态,而 Singal 和 Boardcast 便是唤醒处于阻塞状态的协程,告知其条件满足了,可以继续向下执行了.
回到我们 connReader 的例子,我们使用 sync.Cond 实现阻塞等待通知的效果.
type connReader struct {
// 是否正在读取数据
inRead bool
mu sync.Mutex // guards following
cond *sync.Cond
}
func (cr *connReader) abortPendingRead() {
if !cr.inRead{
return
}
//1. 通过一定手段,让Read方法中断
cr.mu.Lock()
// 判断Read方法是否仍然在读取数据
for cr.inRead {
//2. 此时Read方法仍然在读取数据, 不满足条件,等待通知
cr.cond.Wait()
}
cr.mu.Unlock()
}
func (cr *connReader) Read(p []byte) (n int, err error) {
cr.mu.Lock()
cr.inRead = true
// 1. 读取数据
// 2. abortPendingRead通过某种手段,让Read方法中断
cr.inRead = false
cr.mu.Unlock()
// 3. 现在已经满足abortPendingRead继续执行下去的条件了,可以唤醒abortPendingRead协程了
cond.Boardcast()
}
这里 abortPendingRead 方法首先判断是否还在读取数据,是的话,调用 Wait 方法进入阻塞状态,等待条件满足后继续执行.
对于 Read 方法,因为其不运行并发访问,当其将退出时,说明此时已经没有协程在读取数据了,满足 abortPendingRead 继续执行下去的条件了,此时可以调用 Boardcast 来唤醒等待条件满足的协程。之后调用 abortPendingRead 方法的协程此时能够接收到通知,便能够顺利被唤醒,从而正确返回.
这里便展示了一个简单的,使用 sync.Cond 实现阻塞等待通知的例子.
在 Sync.Cond 存在一个通知队列,保存了所有处于等待状态的协程。通知队列定义如下
type notifyList struct {
wait uint32
notify uint32
lock uintptr // key field of the mutex
head unsafe.Pointer
tail unsafe.Pointer
}
当调用 Wait 方法时,此时 Wait 方法会释放所持有的锁,然后将自己放到 notifyList 等待队列中等待。此时会将当前协程加入到等待队列的尾部,然后进入阻塞状态.
当调用 Signal 时,此时会唤醒等待队列中的第一个协程,其他继续等待。如果此时没有处于等待状态的协程,调用 Signal 不会有其他作用,直接返回。当调用 BoradCast 方法时,则会唤醒 notfiyList 中所有处于等待状态的协程.
sync.Cond 的代码实现比较简单,协程的唤醒和阻塞已经由运行时包实现了, sync.Cond 的实现直接调用了运行时包提供的API.
Wait 方法首先调用 runtime_notifyListAd 方法,将自己加入到等待队列中,然后释放锁,等待其他协程的唤醒.
func (c *Cond) Wait() {
// 将自己放到等待队列中
t := runtime_notifyListAdd(&c.notify)
// 释放锁
c.L.Unlock()
// 等待唤醒
runtime_notifyListWait(&c.notify, t)
// 重新获取锁
c.L.Lock()
}
Singal 方法调用 runtime_notifyListNotifyOne 唤醒等待队列中的一个协程.
func (c *Cond) Signal() {
// 唤醒等待队列中的一个协程
runtime_notifyListNotifyOne(&c.notify)
}
Broadcast 方法调用 runtime_notifyListNotifyAll 唤醒所有处于等待状态的协程.
func (c *Cond) Broadcast() {
// 唤醒等待队列中所有的协程
runtime_notifyListNotifyAll(&c.notify)
}
如果在调用 Wait 方法前未加锁,此时会直接 panic ,下面是一个简单例子的说明
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()
}
上面代码中,协程一每隔1s,将count字段的值自增1,然后唤醒所有处于等待状态的协程。协程二执行的条件为count的值为10的倍数,此时满足执行条件,唤醒后将会继续往下执行.
但是这里在调用 sync.Wait 方法前,没有先获取锁,下面是其执行结果,会抛出 fatal error: sync: unlock of unlocked mutex 错误,结果如下
count = 0
fatal error: sync: unlock of unlocked mutex
因此,在调用 Wait 方法前,需要先获取到与 sync.Cond 关联的锁,否则会直接抛出异常.
强制调用Wait方法前需要先获取该锁。这里的原因在于调用 Wait 方法如果不加锁,有可能会出现竞态条件.
这里假设多个协程都处于等待状态,然后一个协程调用了Broadcast唤醒了其中一个或多个协程,此时这些协程都会被唤醒.
如下,假设调用 Wait 方法前没有加锁的话,那么所有协程都会去调用 condition 方法去判断是否满足条件,然后都通过验证,执行后续操作.
for !condition() {
c.Wait()
}
c.L.Lock()
// 满足条件情况下,执行的逻辑
c.L.Unlock()
此时会出现的情况为,本来是需要在满足 condition 方法的前提下,才能执行的操作。现在有可能的效果,为前面一部分协程执行时,还是满足 condition 条件的;但是后面的协程,尽管不满足 condition 条件,还是执行了后续操作,可能导致程序出错.
正常的用法应该是,在调用 Wait 方法前便加锁,只会有一个协程判断是否满足 condition 条件,然后执行后续操作。这样子就不会出现即使不满足条件,也会执行后续操作的情况出现.
c.L.Lock()
for !condition() {
c.Wait()
}
// 满足条件情况下,执行的逻辑
c.L.Unlock()
调用 sync.Wait 方法,协程进入阻塞状态后被唤醒,没有重新检查条件变量,此时有可能仍然处于不满足条件变量的场景下。然后直接执行后续操作,有可能会导致程序出错。下面举一个简单的例子
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 设置为true
flag = true
// 唤醒所有处于等待状态的协程
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()
// 不满足条件,此时进入等待状态
if !flag {
cond.Wait()
}
// 被唤醒后,此时可能仍然不满足条件
fmt.Printf("协程 %d flag = %t", i, flag)
flag = false
cond.L.Unlock()
}
}(i)
}
wg.Wait()
}
在这个例子,我们启动了一个协程,定时将 flag 设置为true,相当于每隔一段时间,便满足执行条件,然后唤醒所有处于等待状态的协程.
然后又启动了两个协程,在满足条件的前提下,开始执行后续操作,但是这里协程被唤醒后,没有重新检查条件变量,具体看第39行。这里会出现的场景是,第一个协程被唤醒后,此时执行后续操作,然后将 flag 重新设置为false,此时已经不满足条件了。之后第二个协程唤醒后,获取到锁,没有重新检查此时是否满足执行条件,直接向下执行,这个就和我们预期不符,可能会导致程序出错,代码执行效果如下
协程 1 flag = true
协程 0 flag = false
协程 1 flag = true
协程 0 flag = false
可以看到,此时协程0执行时, flag 的值均为 false ,说明此时其实并不符合执行条件,可能会导致程序出错。因此正确用法应该像下面这样子,被唤醒后,需要重新检查条件变量,满足条件之后才能继续向下执行.
c.L.Lock()
// 唤醒后,重新检查条件变量是否满足条件
for !condition() {
c.Wait()
}
// 满足条件情况下,执行的逻辑
c.L.Unlock()
本文介绍了 Go 语言中的 sync.Cond 并发原语,它是用于实现 goroutine 之间的同步的重要工具。我们首先学习了 sync.Cond 的基本使用方法,包括创建和使用条件变量、使用 Wait 和 Signal / Broadcast 方法等.
在接下来的部分中,我们介绍了 sync.Cond 的实现原理,主要是对等待队列的使用,从而 sync.Cond 有更好的理解,能够更好得使用它。同时,我们也讲述了使用 sync.Cond 的注意事项,如调用 Wait 方法前需要加锁等.
基于以上内容,本文完成了对 sync.Cond 的介绍,希望能够帮助大家更好地理解和使用Go语言中的并发原语.
最后此篇关于深入理解Go语言中的sync.Cond的文章就讲到这里了,如果你想了解更多关于深入理解Go语言中的sync.Cond的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我正在使用 go 图表库 https://github.com/wcharczuk/go-chart制作条形图。我面临的问题是标签值很长,我想将文本旋转 45 度以显示完整文本 我喜欢显示的日期格式是
我在构建一个非常简单的通过 cgo 调用 c 代码的 go 程序时遇到了问题。我的设置: $: echo $GOPATH /go $: pwd /go/src/main $: ls ctest.c
没有 C 的背景,只有 Go 的“初学者”经验,我正在尝试弄清楚 main.go 是实际需要的还是只是一个约定。 我想创建一个简单的网络 API,但有人可以为我澄清一下吗? 最佳答案 main.go
我read从 Go 1.4 开始,Go 运行时是用 Go 本身编写的(而不是用 C)。 这怎么可能?如果 Go 程序在运行时之上运行,并且运行时是 Go 程序,那么运行时是否在自身之上运行? 最佳答案
这是“Go 之旅”中的代码示例 Range and Close : package main import ( "fmt" ) func fibonacci(n int, c chan int
给定以下 go.mod 文件: module foo go 1.12 require ( github.com/bar/baz v1.0.0 github.com/rat/cat v1
我有一个 CI/CD 管道,它需要跨平台并与几个不同的管理程序一起工作。为了不必更改 Windows 和 Linux 的构建任务,我认为 Go 将是编写一次代码并在任何地方运行的好方法。然而,考虑到
我有一个 Dockerfile,用于使用 go build 编译 Go 应用程序。我进行了研究,确实建议将 go build 用于生产。 但是我找不到正确的答案来解释为什么。 我了解 go run 创
我尝试在命令提示符#Go lang 中运行该程序-但是当我键入运行“go run hello.go”命令时,我开始了 CreateFile hello.go:The system cannot fin
我正在使用“Go 编程语言”一书学习 Go。第一章介绍os.Open用于读取文件的模块。我尝试打开如下所示的 go 文件。 f, err = os.Open("helloworld.go") 我收
关闭。这个问题需要details or clarity .它目前不接受答案。 想改进这个问题?通过 editing this post 添加详细信息并澄清问题. 2年前关闭。 Improve this
为了解决我对 goroutine 的一些误解,我去了 Go 操场跑了 this code : package main import ( "fmt" ) func other(done cha
这个问题在这里已经有了答案: Evaluate/Execute Golang code/expressions like js' eval() (5 个回答) 1年前关闭。 对于任何 go 程序,我想
这是我基本上试图从路径打印基准的代码。 这意味着,如果用户输入“/some/random/path.java”,则输出将为“path”。同样,如果用户arg为“/another/myapp.c”,则输
$ go version 1.13.3 我的文件夹结构如下: GOPATH +---src +--- my-api-server +--- my-auth-server
这个问题在这里已经有了答案: How to embed file for later parsing execution use (4 个答案) What's the best way to bun
我觉得这有点奇怪,为什么这段代码不起作用? package main import "fmt" func main() { var i, j int = 1, 2 k
go编译器执行完如下命令后的可执行文件存放在哪里? $> go run file.go 最佳答案 在 /tmp 文件夹中,如果您使用的是 unix 机器。 如果您使用的是 Windows,则在 \Us
我目前正在开始使用 Go,并且已经深入研究了有关包命名和工作区文件夹结构的注意事项。 不过,我不太确定如何根据 Go 范式正确组织我的代码。 这是我当前的结构示例,它位于 $GOPATH/src 中:
假设我有一个接受用户输入的 Lua 程序,而该输入恰好是有效的 Lua 源代码。这是在程序仍在运行时进行清理、编译和执行的。 Go 是否(或将)实现这样的事情? 最佳答案 我认为以下两个项目之间有足够
我是一名优秀的程序员,十分优秀!