Tamás's suggestion of using [4]string as the key is a good one. You could use any struct you want as well, if you want to name the parts of the key.
How are you using the map? If you're only reading the map, then concurrent access is allowed. Concurrent access is only forbidden if one of the accesses is a write. If you have only occasional writes, a sync.RWMutex might be appropriate. Yes, locking around the map accesses does serialize the goroutines. But the shorter the critical section, the faster your app will run. In your traffic analogy, the more cars/sec can fit though a merge point, the more traffic flows. And if other parts of the road have a lower speed limit, it may still pay to make those sections of road wider (parallel). On Monday, September 12, 2016 at 1:13:10 PM UTC-7, Tamás Gulácsi wrote: > > TL;DR > I know what concurrency is. > For a map access, if you hold the lock for as few instructions as > possible, it shouldn't hurt much. > If you're after an idea of the best solution, that will be harser - maybe > not a map is the best answer for your specific use case, but a slice. Or a > slice of maps with hashed access. > Or just copy the map before read it, and swap the whole map after a change. > > > If you can write down the access to the innermost element of your > multidimensional map as m[a][b][c][d], then you know that you won't have > more than four levels, so you can use a map[[4]string]string. > > If you want an unbounded level, then first please define the equality on > them, to be able to use them as map keys! > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
