> > > > Is there a better way? > > Is fn allowed to mutate the map? If not then the locking/unlocking is not > necessary at all. If yes then there's a race between acquiring the k,v pair > from the map under a lock and calling fn with those, now possibly obsolete > values. >
Even if fn does not mutate the map, some other goroutine could and that's not safe without holding any locks. From the Go 1.6 release notes <https://golang.org/doc/go1.6>: > The runtime has added lightweight, best-effort detection of concurrent > misuse of maps. As always, if one goroutine is writing to a map, no other > goroutine should be reading or writing the map concurrently. If the runtime > detects this condition, it prints a diagnosis and crashes the program. The > best way to find out more about the problem is to run the program under the > race > detector <https://blog.golang.org/race-detector>, which will more > reliably identify the race and give more detail. Perhaps a sync.RWMutex would work better, just hold the RLock while iterating which will allow other goroutines to also read from the map (but not change the map). Dragos -- 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.
