3 ms·
Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior.
by pcwalton 7y ago
Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior.
I haven't heard of this causing a problem in practice, though.
- Thaxll 7y agoI never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption. Please give us a code example.
- skybrian 7y agoSlice values are normally copied so it's not an issue. The slice would need to be stored in a global or a struct's field and then changed while some other goroutine is reading it. (I haven't seen this happen, though.)
- pcwalton 7y agoYes, not synchronizing a slice can lead to memory corruption in Go.
- staticassertion 7y agoHere you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.
- psanford 7y agoHere's a blog post from Russ Cox (Go core team) explaining it: https://research.swtch.com/gorace https://research.swtch.com/gorace
- deleted 7y ago[deleted]
- cwzwarich 7y agoAre all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.
- pcwalton 7y agoUnfortunately slices are 3 words. (Besides, AArch64 isn't a common target for Go. On x86 you'd need cmpxchg16b or something.)