Remix.run Logo
kiitos 5 days ago

> To see what I mean by this, consider this program written in Go, which according to Wikipedia is memory-safe:

The Wikipedia definition of memory safety is not the Go definition of memory safety, and in Go programs it is the Go definition of memory safety that matters.

The program in the article is obviously racy according to the Go language spec and memory model. So this is all very much tilting at windmills.

ralfj 4 days ago | parent [-]

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. ;)

kiitos 2 days ago | parent | next [-]

For the purposes of this discussion, sure: 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.

4 days ago | parent | prev [-]
[deleted]