Re:Updating the Go Memory Model
by throwaway34241 on Monday July 12, 2021 @08:43PM
(#27816663)
Sure, I was imagining implementing better race semantics the way Java/C# do, by referencing certain multi-word data by pointer to avoid partial update problems. As it is now slices are 192-bit values (on 64 bit systems) embedded directly in objects that can be shared across threads, I don't know how you would efficiently update that atomically.
Just in theory: pointer/capacity pair is atomic, then you read len non-atomically and check it's less than cap before using it. Slice header today puts len before cap, but, like, if we're dreaming.
You'd probably hit other walls. I'm def. not trying to say it's straightforward!
Is Java really memory safe in the face of races? The case I'm thinking about is this:
Shared state:
ArrayList A with intial buffer B and length L
Thread 1:
Grows A and replaces B with buffer C, length with M
Thread 2:
(Earlier loaded B into a register)
Code says write to A[M-1]. JVM checks M-1 against M but uses B as it was already stored in a register. Now you have a buffer overflow.
Except, people on this thread seem to think this is impossible. How does Java prevent this?
The buffer itself, being a Java array, is checked. You'll get an exception but you won't get undefined behaviour.
It's obviously, uh, quite an Exercise for the Reader(tm) to figure out the best path to avoid memory unsafety given races in line with other Go priorities (as a starting point, imagine a ton of expensive atomics accessing certain pairs on the heap, downgraded to regular loads/stores if the compiler can prove it's safe). But I was trying to say it seems harder to get there now that certain things are set in stone and regressing perf of anything is going to be bad for some user out there.