gpt4 book ai didi

go - 如果写入从不在设计上相互竞争,那么使用 sync.RWMutex 的读取锁进行写入并使用其写入锁进行读取是否安全?

转载 作者:数据小太阳 更新时间:2023-10-29 03:39:22 26 4
gpt4 key购买 nike

来自 Go 文档:

A RWMutex is a reader/writer mutual exclusion lock. The lock can be held by an arbitrary number of readers or a single writer.

这个介绍性句子后面从来没有定义读者和作者可以做什么和不可以做什么。因此,我想知道某个定义的延伸是否可行。

假设我们有一组许多协程;我们称它为 SS 中的每个 goroutine 都有自己的资源,它经常读取和写入这些资源。假设我有一个额外的 goroutine R,它经常想要抓取 S 中的 goroutines 写入的资源的状态。让我们探索两个更明显的解决方案,看看我要去哪里。

  1. 我们可以使用一个互斥量。但是,S 中的 goroutine 将不必要地竞争锁,因为来自 S 的每个 goroutine 无论如何都只能访问自己的资源。
  2. S 中的每个 goroutine 使用一个互斥量。这消除了不必要的竞争,甚至让 R 可以选择是否需要立即锁定所有互斥锁,或者在某个时间点至少锁定每个互斥锁一次。但是需要一些额外的工作。

所以我的第三个想法是:让 S 中的 goroutines 在他们想要读取或写入时获取 sync.RWMutex 的读取锁(即通用 < em>inclusive lock) 并让 R 在需要读取时获取该互斥锁的写锁(即通用的 exclusive lock)。换句话说:

如果写入在设计上从不相互竞争,那么使用 sync.RWMutex 的读取锁进行写入并使用其写入锁进行读取是否安全?

最佳答案

你的问题的答案是肯定的,正如 Volker 所说。

我会给你一个更地道的 Go 解决方案:

every resources of goroutines in S take a sync.RWMutex
the goroutines in S read after sync.RWMutex.Rlock()
the goroutines in S write after sync.RWMutex.Lock()
extra goroutine R read after sync.RWMutex.Rlock()

我觉得你只是进错了区域,应该是个简单的问题。 :)

如果我误解了你,请告诉我。

关于go - 如果写入从不在设计上相互竞争,那么使用 sync.RWMutex 的读取锁进行写入并使用其写入锁进行读取是否安全?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57474513/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com