Hi Here are two examples how to achieve it: https://play.golang.org/p/wAtyGMSw6g or https://play.golang.org/p/EZWZUOpuwb
First example: In best cases it executes the creator function once and returns always the stored item, in bad cases it executes the creator function multiple times but returns always the first stored item. Second example uses a lock to create and store the item. If the creator function is expensive, then I would use the latter example otherwise the first. Cheers snmed Am Freitag, 1. September 2017 00:18:35 UTC+2 schrieb bep: > > sync.Map in Go 1.9 is a little low on examples/doc in the wild, so I > thought I should ask here. > > The new type is promoted as a replacement for RWMutex in mostly read use > cases with stable keys. I assume that a typical in memory cache would fit > that description. > > With RWMutex, if the cost of creating the cache item is high, I would > maybe do something ala: > > mu.RLock() > // Check cache > mu.RUnclock() > > // Return if found > > // If Not found: > mu.Lock() > defer mu.Unlock() > // Double check cache, return if found > // Create item and put in cache > > > > > I don't see how the above can be written with a sync.Map without adding a > mutex. > > bep > -- 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.
