Golang concurrent access map/array with fixed size

Question

I was exploring the possibility of concurrently accessing a map with fixed keys without a lock for performance improvement. I've explored the similar with slice before and seems it works:

func TestConcurrentSlice(t *testing.T) {
    fixed := []int{1, 2, 3}
    wg := &sync.WaitGroup{}
    for i := 0; i < len(fixed); i++ {
        idx := i
        wg.Add(1)
        go func() {
            defer wg.Done()
            fixed[idx]++
        }()
    }
    wg.Wait()
    fmt.Printf("%v\n", fixed)
}

The above code will pass the -race test.

That gave me the confidence of achieving the same thing with map with fixed size (fixed number of keys) because I assume if the number of keys doesn't change, so the underline array (in map) does not need to expand, so it will be safe for us to access different key (different memory location) in different go-routine. So I wrote this test:

type simpleStruct struct {
    val int
}

func TestConcurrentAccessMap(t *testing.T) {
    fixed := map[string]*simpleStruct{
        "a": {0},
        "b": {0},
    }
    wg := &sync.WaitGroup{}
    // here I use array instead of iterating the map to avoid read access
    keys := []string{"a", "b"}
    for _, k := range keys {
        kcopy := k
        wg.Add(1)
        go func() {
            defer wg.Done()
            // this failed the race test
            fixed[kcopy] = &simpleStruct{}

            // this actually can pass the race test!
            //fixed[kcopy].val++
        }()
    }
    wg.Wait()
}

however, the test failed the race test with error message concurrent write by runtime.mapassign_faststr() function.

And one more interesting I found is the code I've commented out "fixed[kcopy].val++" actually passed the race test (I assume it's because of the writings are at different memory location). But I'm wondering since the go-routines are accessing different keys of the map, why it will fail the race test?

Answer 1

Accessing different slice elements without synchronization from multiple goroutines is OK, because each slice element acts as an individual variable. For details, see Can I concurrently write different slice elements.

However, this is not the case with maps. A value for a specific key does not act as a variable, and it is not addressable (because the actual memory space the value is stored at may be internally changed–at the sole discretion of the implementation).

So with maps, the general rule applies: if the map is accessed from multiple goroutines where at least one of them is a write (assign a value to a key), explicit synchronization is needed.