On Tuesday, 14 April 2020 12:38:44 UTC+1, Slawomir Pryczek wrote: > > 1. If data that is accessed or changed - it needs to go into CPU cache > first, and AFAIK to caches whole memory block not just this single area of > memory on which we're operating. When we're doing writes without > synchronization to something which is tightly packed, how does it work that > cache isn't poisoned, and the result is still correct, even if each cpu > core is having its own L1 and L2 caches? >
That's dealt with by the CPU: see https://en.wikipedia.org/wiki/Cache_coherence > So im writing some code which will do hundreds of thousands of operations > per second and these operations need to read config (probably in some cases > at multiple places). You think using just atomic.Value (Store/Load) will > have impact when i run it on machine with eg. 96 cores? Maybe RW mutex > would be better? What you think? > If the config values are static, it should be safe for all threads to read unprotected the same shared area. If you need the config to change, you could create a new config object and then somehow signal to each goroutine that a new config is available (e.g. pass the pointer to the new config over a channel). The goroutine will need to check for the update message from time to time of course. If the config isn't too huge, you could just pass the whole config over the channel, and let each goroutine have its own local copy: "share by communicating". Just remember that some values in go contain hidden pointers - in particular slices and maps. There are suggested patterns for dealing with this shown in the examples under atomic.Value <https://golang.org/pkg/sync/atomic/#Value>. In general: I suggest avoiding premature optimisation. You expect that reading the config safely (with atomic/mutex protection) is going to take a sizeable proportion of the runtime - but even the most experienced programmers are often wrong about their gut feeling as to where the hot spots are. Build it in the clearest / most obvious way; then profile it; *then* decide where the important optimisations are. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/549a87f6-a3f5-4cb3-bfb5-36787c328be1%40googlegroups.com.
