Hi Guys, was wondering about some things related to multithread code. 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?
Are such patterns, when single thread is only operating on single cell(s) of memory, considered thread safe for slices and in general? https://play.golang.org/p/rF8jPEGDZzk 2. For lazy initialization double-check pattern. I found on several sources that it is safe, still race detector complains about data races (which is correct because there is race, which is done on purpose) - https://software.intel.com/en-us/node/506123 And of course this code seems to be working as expected https://play.golang.org/p/gUzWHr-1K9H 3. Now question is, can i disable these warnings somehow so race detector won't complain about safe code because i have ton of these and it's obfuscating usable output? 4. Im not sure about instruction ordering, will it always be the case that threads that see initialized=true will also see myconfig AFTER the update, because myconfig isn't synchronized. Would it be better to just use pointer instead and check for nil value or even atomic.Value? 5. How these patterns are working with other CPUs, are they considered unsafe on anything other than intel architecture? 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? I could just run some synthetic benchmarks but for these usually seem to not have much use in real life scenarios for multithreaded code. Thanks -- 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/eeadca01-1ad5-48e0-9ace-5afb19def2f3%40googlegroups.com.
