4 ms·
You're correct that updating a map from multiple goroutines without synchronizing is unsafe. But the overhead of using a RWMutex (http://weekly.golang.org/pkg/
by jbarham 15y ago
You're correct that updating a map from multiple goroutines without synchronizing is unsafe. But the overhead of using a RWMutex (http://weekly.golang.org/pkg/sync/#RWMutex http://weekly.golang.org/pkg/sync/#RWMutex) in this case should be negligible compared to the I/O code.
The big win is that Go allows you to write straightforward concurrent code but under the hood uses high-performance system calls like epoll.
EDIT: Here's a thread-safe version: https://github.com/jbarham/Key-Value-Polyglot/blob/master/memg.go https://github.com/jbarham/Key-Value-Polyglot/blob/master/me.... Still plenty fast.
- teejae 15y agoFYI, In the Go version, the lock can be added more simply, without the rw: // Synchronize map access between multiple goroutines. type cache struct { m map[string]string sync.RWMutex } Then, you can just use: cache.Lock/Unlock/RLock/RUnlock directly. It's clearer. The beauty of Go's mixins.
- ootachi 15y agoSo much for CSP, if you're using threads and shared state.