| +1 for the aggressive approach, mutexes are very fast in go. I got curious and wrote a quick little benchmark test: $ cat bench_test.go
package main
import (
"sync"
"testing"
)
func BenchmarkMutex(b *testing.B) {
var m sync.Mutex
for n := 0; n < b.N; n++ {
m.Lock()
m.Unlock()
}
}
$ go test -v -bench=. bench_test.go
BenchmarkMutex 50000000 24.0 ns/op
ok command-line-arguments 1.235s
A set of mutex.Lock() & .Unlock() calls takes only 24.0ns on average to complete.Thus it's possible to lock/unlock more than 41 million times per second on the puny 2011 MacBook Air I used for this. My .02c: The post seems like a case of premature optimization. Resource bottlenecks due to too much mutex locking in go does not seem like a case that will be commonly hit. With infinite potential bottlenecks, I don't like to spend my time worrying and fussing over things that are: A) Not yet a problem. B) Unlikely to ever be a problem or give me grief. Worrying about the overhead cost of locking falls squarely into just such a category. |