4 ms·
When should one use sync.Map vs a plain old map with a RWMutex?
by helper 9y ago
When should one use sync.Map vs a plain old map with a RWMutex?
- tejasmanohar 9y agoWhen one does not care about type safety ;) Only sorta kidding... Personally, I think sync.Map is a dangerous addition to the standard library, and hope that the Go team does not encourage using the empty interface{}'s like this. I can only imagine how bad it'll feel when someone reads an int64 as an int.
- TheSwordsman 9y agoI'd go further and say when one cares less about performance. There's overhead for type assertions that could be avoided by implementing your own synchronized map with the types you desire. Admittedly, the overhead is probably negligible for most users.
- helper 9y agoIts not really any different context.WithValue where the strongly encouraged idiom is to have all access go through typed get/set methods that handle the type casting for you.
- pjmlp 9y agoUntil they introduce some kind of type safe genericity language level support, interface{} and go generate are the only options available for generic data structures. Personally I would already be happy with what CLU allowed for in 1975, no need for anything more expressive.
- kasey_junk 9y agoThere is a third option which is to add specific data structures to the existing list of generic data structures with out making user defined generics.
- pjmlp 9y agoWhich leads to the question when would they stop adding special case structures?
- kasey_junk 9y ago(shrug) they clearly are ok with some generics. In my mind if they argued that they'd rather support more widely used data structures at the language level instead of user defined generics thats a logically consistent position. In fact, if I could get a) a type safe concurrent map b) a promise/future construct and c) a fast concurrent queue for single writer multi-reader, I'd probably be ok with the set of generic data structures provided in the language. If they fixed their variance rules along the way as well, I'd probably lose any actual arguments against the type system when it comes to the systems I build. The question is of course, are those the only ones that fall into that category? Who knows but those are the ones I run into the most pain for.
- dullgiulio 9y agoAlthough I agree with you about encouraging interface{} (there is even a "proverb" against its usage), you cannot read an empty interface as a type it is not. Unlike C void-pointer, interface{} is the tuple (type, value) and you need a type assertion for the right tipe to get the value.
- the8472 9y agoProbably the same with any other locked data structure vs. structure using atomic ops. If you have read-heavy workload, especially one that does batching then grabbing a read-lock once and executing your batches before releasing it can be faster than lots of reads on a current map. Especially on weakly ordered architectures where the ordered reads may cost you performance.
- helper 9y agoThat makes sense. I was hoping someone would have some concrete benchmarks for different access patterns but I don't see any in the github issue[1]. [1]: https://github.com/golang/go/issues/18177 https://github.com/golang/go/issues/18177
- deleted 9y ago[deleted]
- bigdubs 9y agogenerally don't want to use RWMutex unless you can help it; the performance is much worse than the regular sync.Mutex