Since len() for slice and map are O(1), why len() is not thread-safe?

Question

I read some post(Are len(string) and len(slice)s O(1) operation in Go?, How to check if a map is empty in Golang?) and found that len() for slice and map are O(1), the implementation is get a member(e.g. size, length) of the structure. But the test(Is len() thread safe in golang?) show len() is not thread-safe, why?

Answer 1

What you're referring to is called a benign data race. The map size is just an int, so one could assume that reading and writing a single int is atomic, right? Well, no.

The Go memory model is derived from the C memory model, in which accessing the same memory from two or more threads, at least one of which is writing, without synchronization is a data race - a form of undefined behavior. It does not matter if you're accessing a single int or a more complex structure.

There are two reasons why a benign data race does not actually exist:

1. Hardware. There are two types of CPU cache architectures: one with strong cache coherency (e.g. x86) and another with weak cache coherency (e.g. ARM). Regular writes to memory may not become "visible" on other cores immediately, depending on the hardware. Special "atomic" instructions are required to make data visible between cores.

2. Software. According to the memory model, each thread is assumed to execute in isolation (until a synchronization event with happens-before semantics occurs). The compiler is allowed to assume that reading the same memory location will provide the same result, and for example, hoist these reads of the loop (thus breaking your program). This is why synchronization must be explicit in the code, even when targeting hardware with strong cache coherency.

---

The following program may or may not ever finish, depending on the CPU and compiler optimization flags:

func main() {
    x := 0
    go func() {
        x = 1
    }()
    for x == 0 {  // DATA RACE! also, the compiler is allowed to simplify "x == 0" to "true" here
        // wait ...
    }
}

To make it correct, use synchronization to let the compiler know there is concurrency involved:

func main() {
    var mtx sync.Mutex
    x := 0
    go func() {
        mtx.Lock()
        x = 1 // protect writes by a mutex
        mtx.Unlock()
    }()
    for {
        mtx.Lock()
        x_copy := x // yes, also reads must be protected
        mtx.Unlock()
        if x_copy != 0 {
            break
        }
        // wait ...
    }
}

The locking and unlocking of the same mutex creates an acquire-release fence such that all memory writes done before unlocking the mutex are "released" and become visible to the thread that subsequently locks the mutex and "acquires" them.