Go 的sync包有一个Mutex. 不幸的是它不是递归的。在 Go 中实现递归锁的最佳方法是什么？
问问题
16059 次
3 回答
41
很抱歉没有直接回答你的问题：
恕我直言，如何在 Go 中实现递归锁的最佳方法是不实现它们，而是重新设计你的代码以首先不需要它们。我认为，对他们的渴望很可能表明正在使用错误的方法来解决某些（此处未知）问题。
作为上述主张的间接“证明”：对于涉及互斥锁的/某些常见情况，递归锁是否是一种常见/正确的方法，它迟早会包含在标准库中。
最后，最后但并非最不重要的是：Go 开发团队的 Russ Cox 在这里写的https://groups.google.com/d/msg/golang-nuts/XqW1qcuZgKg/Ui3nQkeLV80J：
递归（又名可重入）互斥锁是个坏主意。使用互斥体的根本原因是互斥体保护不变量，可能是内部不变量，例如“p.Prev.Next == p for all elements of the ring”，或者可能是外部不变量，例如“我的局部变量 x 等于 p.Prev 。”
锁定互斥锁会断言“我需要保留这些不变量”，也许“我会暂时破坏这些不变量”。释放互斥体断言“我不再依赖那些不变量”和“如果我破坏了它们，我已经恢复了它们。”
了解互斥锁保护不变量对于确定需要互斥锁的位置和不需要互斥锁的位置至关重要。例如，使用原子递增和递减指令更新的共享计数器是否需要互斥锁？这取决于不变量。如果唯一不变量是计数器在 i 递增和 d 递减后具有值 i - d，则指令的原子性确保了不变量；不需要互斥锁。但是如果计数器必须与其他一些数据结构同步（也许它计算列表中元素的数量），那么单个操作的原子性是不够的。其他东西，通常是互斥体，必须保护更高级别的不变量。这就是 Go 中的 map 操作不能保证是原子的原因：在典型情况下它会增加开销而没有好处。
让我们看一下递归互斥锁。假设我们有这样的代码：
func F() {
mu.Lock()
... do some stuff ...
G()
... do some more stuff ...
mu.Unlock()
}
func G() {
mu.Lock()
... do some stuff ...
mu.Unlock()
}
通常，当对 mu.Lock 的调用返回时，调用代码现在可以假定受保护的不变量保持不变，直到它调用 mu.Unlock。
当从 F 或当前线程已经拥有 mu 的任何其他上下文中调用时，递归互斥锁实现将使 G 的 mu.Lock 和 mu.Unlock 调用成为无操作。如果 mu 使用了这样的实现，那么当 mu.Lock 在 G 内部返回时，不变量可能成立，也可能不成立。这取决于 F 在调用 G 之前做了什么。也许 F 甚至没有意识到 G 需要这些不变量并且已经破坏了它们（完全有可能，尤其是在复杂代码中）。
递归互斥锁不保护不变量。互斥锁只有一项工作，而递归互斥锁不做。
他们有更简单的问题，比如你写的
func F() {
mu.Lock()
... do some stuff
}
您永远不会在单线程测试中找到错误。但这只是更大问题的一个特例，即它们根本不保证互斥体旨在保护的不变量。
如果您需要实现可以在有或没有持有互斥锁的情况下调用的功能，最明确的做法是编写两个版本。例如，代替上面的 G，你可以写：
// To be called with mu already held.
// Caller must be careful to ensure that ...
func g() {
... do some stuff ...
}
func G() {
mu.Lock()
g()
mu.Unlock()
}
或者如果它们都未导出，则 g 和 gLocked。
我确信我们最终会需要 TryLock；请随时为此向我们发送 CL。超时锁定似乎不太重要，但如果有一个干净的实现（我不知道有一个），那么它可能会没问题。请不要发送实现递归互斥锁的 CL。
递归互斥锁只是一个错误，只不过是 bug 的舒适之家。
拉斯
于 2013-02-03T10:21:28.403 回答
3
您可以很容易地从sync.Mutex和sync.Cond中进行递归锁定。有关一些想法，请参见此处的附录 A。
除了Go 运行时没有公开任何 goroutine Id 的概念之外。这是为了阻止人们用 goroutine 本地存储做愚蠢的事情，并且可能表明设计者认为如果你需要一个 goroutine Id，那么你做错了。
如果你真的想的话，你当然可以用一点 C 从运行时中挖掘出 goroutine Id 。您可能想阅读该主题以了解为什么 Go 的设计者认为这是一个坏主意。
于 2013-02-03T14:28:38.077 回答
-10
正如已经确定的那样，从并发的角度来看，这是一个悲惨、可怕、可怕和可怕的想法。
无论如何，由于您的问题实际上是关于 Go 的类型系统，因此您将如何使用递归方法定义类型。
type Foo struct{}
func (f Foo) Bar() { fmt.Println("bar") }
type FooChain struct {
Foo
child *FooChain
}
func (f FooChain) Bar() {
if f.child != nil {
f.child.Bar()
}
f.Foo.Bar()
}
func main() {
fmt.Println("no children")
f := new(FooChain)
f.Bar()
for i := 0; i < 10; i++ {
f = &FooChain{Foo{}, f}
}
fmt.Println("with children")
f.Bar()
}
于 2013-02-03T17:08:41.077 回答