Is replacing the map variable with a new map object thread safe?

I don't think it thread-safe because map object is larger than a machine word, and Golang has no guarantee it's thead-safe. But when I run the demo code with go run -race main.go, it never reports errors. It might be the reason that ThreadSanitizer depends on runtime checking and assigning operation is hard to meet the thread unsafe condition.

Here is the sample code:

package main

import (
	"fmt"
)

var m = make(map[int]bool)

func Read() {
	for {
		for k := range m {
			fmt.Println(k)
		}
	}
}

func Replace() {
	for {
		newM := make(map[int]bool, 10)
		for i := 0; i < 10; i++ {
			newM[i] = false
		}
		m = newM
	}
}

func main() {
	c := make(chan struct{})

	go Read()
	go Replace()

	<-c
}

So how could I modify the code to trigger the concurrent error? Or maybe I am wrong and the code is thread-safe?

There are several things to note here:

        for k := range m {

Range expression is evaluated once at the beginning of the for loop. So this operation will read m once (note that this means if the code in the loop reassigns m, the loop will continue to iterate through the original m, but if new elements are added or elements are removed from m, those will be detected by the loop), and the loop itself will call fmt.Println, which consumes most of the execution time in that goroutine. If you want to catch the race, remove that.

Second, you don't really need to initialize the second map.

And when you do these things and run the race detector, it may catch the data race. In my case, it did.

The race detector complains about a race when it detects one. Because of that, if it reports a race, then there is a race. If it doesn't report one, that doesn't mean there isn't a race.

In my platform, a map variable itself is actually the same size as a machine word: it is simply a pointer to the map structure. So, the write to a map variable is actually atomic, that is, you would not see a partially-assigned map in this platform. However, that doesn't prevent the race, because there are no guarantees on when the other goroutine will see that memory write.

In short, there is a race. It is not because of the size of the map variable. To fix, use a mutex.

> Is replacing the map variable with a new map object thread-safe?

No, It's unsafe.

What can you do to make it safe?

1. add some lock control in sync (like sync.RWMutex), here is a rough implementation from your code:

package main

import (
	"fmt"
	"sync"
)

type safeMap struct {
	rwLock sync.RWMutex
	m      map[int]bool
}

var safem = safeMap{
	m: make(map[int]bool),
}

func Read() {
	for {
		safem.rwLock.RLock()
		for k := range safem.m {
			fmt.Println(k)
		}
		safem.rwLock.RUnlock()
	}
}

func Replace() {
	for {
		newM := make(map[int]bool, 10)
		for i := 0; i < 10; i++ {
			newM[i] = false
		}
		safem.rwLock.Lock()
		safem.m = newM
		safem.rwLock.Unlock()
	}
}

func main() {
	c := make(chan struct{})

	go Read()
	go Replace()

	<-c
}

2. use sync.Map

> Map is like a Go map[interface{}]interface{} but is safe for concurrent use by multiple goroutines without additional locking or coordination. Loads, stores, and deletes run in amortized constant time.

I was able to trigger a warning, modifying the Replace function a bit.

package main

import (
	"fmt"
)

var m = make(map[int]bool)

func Read() {
	for {
		for k, v := range m {
			fmt.Println(k, v)
		}
	}
}

func Replace(flag bool) {
	for {
		newM := make(map[int]bool, 10)
		for i := 0; i < 10; i++ {
			newM[i] = flag
		}
		m = newM
	}
}

func main() {
	c := make(chan struct{})

	go Read()
	go Replace(false)
	go Replace(true)

	<-c
}

As pointed out by @Burak Serdar, the reason for not detecting race might be due to fmt.Println() taking most of the execution time.