3 ms·

Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any. (But also, it'd be kind of silly for every la

by ralfj 1y ago

Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any. (But also, it'd be kind of silly for every language to make up their own definition of memory safety. Then even C is memory safe, they just have to define it the right way. ;)

deleted 1y ago
[deleted]
kiitos 1y ago
For the purposes of this discussion, sure: https://go.dev/ref/mem https://go.dev/ref/mem Relevant bit for the OP is probably: A data race is defined as a write to a memory location happening concurrently with another read or write to that same location, unless all the accesses involved are atomic data accesses as provided by the sync/atomic package. Which describes exactly what is happening in the OP's program: func repeat_get() { for { x := globalVar // <-- unsynchronized read of globalVar x.get() // <-- unsynchronized call to Thing.get() } } By itself this isn't a problem, these are just reads, and you don't need synchronization for concurrent reads by themself. The problem is introduced here: func repeat_swap() { var myval = 0 for { globalVar = &Ptr { val: &myval } // <-- unsynchronized write to globalVar globalVar = &Int { val: 42 } // <-- unsynchronized write to globalVar } } func main() { go repeat_get() // <-- one goroutine is doing unsynchronized reads repeat_swap() // <-- another goroutine is doing unsynchronized writes } Just a (chef's kiss) textbook example of a data race, and a clearly unsound Go program. I don't know how or why the OP believes "this program ... [is] according to Wikipedia memory-safe" -- it very clearly is not. But, you know, I think everyone here is basically talking past each other.

by ralfj 1y ago

deleted 1y ago

[deleted]

kiitos 1y ago

For the purposes of this discussion, sure: https://go.dev/ref/mem https://go.dev/ref/mem Relevant bit for the OP is probably: A data race is defined as a write to a memory location happening concurrently with another read or write to that same location, unless all the accesses involved are atomic data accesses as provided by the sync/atomic package. Which describes exactly what is happening in the OP's program: func repeat_get() { for { x := globalVar // <-- unsynchronized read of globalVar x.get() // <-- unsynchronized call to Thing.get() } } By itself this isn't a problem, these are just reads, and you don't need synchronization for concurrent reads by themself. The problem is introduced here: func repeat_swap() { var myval = 0 for { globalVar = &Ptr { val: &myval } // <-- unsynchronized write to globalVar globalVar = &Int { val: 42 } // <-- unsynchronized write to globalVar } } func main() { go repeat_get() // <-- one goroutine is doing unsynchronized reads repeat_swap() // <-- another goroutine is doing unsynchronized writes } Just a (chef's kiss) textbook example of a data race, and a clearly unsound Go program. I don't know how or why the OP believes "this program ... [is] according to Wikipedia memory-safe" -- it very clearly is not. But, you know, I think everyone here is basically talking past each other.