On Fri, Jan 12, 2018 at 2:03 AM, Chris Hopkins <cbehopk...@gmail.com> wrote: > > Does anyone know of an architecture that go runs on that has non-coherent > data caches? If so, is there a mechanism in the language/tool chain to > protect against the issues of this? > > Background: > I was watching a video on the go trace tool > (https://www.youtube.com/watch?v=ySy3sR1LFCQ) in this video he uses a > technique I would never have thought safe. i.e. he declares an array of > items and then uses a separate go routine on each item in the array. The > logic making it safe being that each routine operates on a different element > of the array, therefore no concurrent access. > Then it occurred to me it might not be safe after all. If you have > Non-Coherent data caches for multiple cores then one cache could load a > cache line and modify it. At a similar time a different cache does the same > thing, but to a different address within that cache line. One of them evicts > the line first, and its modification is overwritten by the last cache to > have the line modified. > > Some digging shows that all the CPU architectures I can find that I can run > go on have coherent L1 data caches. > > However I set out to prove this was safe: > https://play.golang.org/p/igfpqrX8Jc- > > Playing with the trace tool implies that this might be because I can't get > the scheduler to launch multiple routines running at the same time (hence > adding in the heavyCpu function). Or at least sufficiently concurrent to > agress this issue. > So it's fine, but it got me wondering if it were fine by accident or design. > I'm sure there must be architectures out there where global coherency across > all cores is not maintained, and if there is, I guess the scheduler would > have to be aware of this - but I don't know how you could mitigate this if > the example code is legal. If it is not legal, it doesn't seem to be > detected by the tools.
An incoherent cache would affect far more than the case you describe. For example, it is straightforward and indeed common for multiple different global variables to share a single cache line. This is even possible if the global variables are defined in different packages. Yet it is clearly valid for different goroutines to set different global variables simultaneously. As far as I know no common processor architecture provides multiple cores with an incoherent cache, as the programming model for such an architecture is complex. If Go is ever ported to such an architecture, it will have to arrange for every global variable, and every slice/array element, and every struct field, to live in a different cache line. That can be done easily enough by simply setting the required alignment high enough for each data type. Of course this will make the cache somewhat less effective, but, so it goes. Ian -- 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.
