I don’t think that is true. You still need to use atomics or locks to modify the values even with a single writer, or there’s no guarantee a reader will see the updated value ever.
> On Jul 28, 2026, at 3:04 PM, Ian Lance Taylor <[email protected]> wrote: > > On Tue, Jul 28, 2026 at 9:15 AM '[email protected]' via golang-nuts > <[email protected]> wrote: >> >> (I posted this to r/golang but I didn't get what I consider a definitive >> answer). >> >> I know that maps aren't safe for concurrent access, but I've always thought >> this meant only that you can't add or delete keys concurrently. >> >> Let's say I already have a map[string]int that has been filled with keys >> that are file names. I won't be adding any more keys. I want to add an int >> value for each existing key to contain the file size. Could I do this by >> running a bunch of go routines, one per file name key? (Let's ignore for now >> whether doing this would be any faster than not using go routines.) >> >> The Go Language spec doesn't directly define the rules for concurrent memory >> safety. Instead, those rules are explicitly defined in the Go Memory Model >> (https://go.dev/ref/mem). I looked there but I wasn't able to find what I >> was looking for. The Go FAQ has a section on Atomic Maps >> (https://go.dev/doc/faq#atomic_maps) says >> >> "As long as all goroutines are only reading—looking up elements in the map, >> including iterating through it using a for range loop—and not changing the >> map by assigning to elements or doing deletions, it is safe for them to >> access the map concurrently without synchronization." >> >> The question here is what is meant by "assigning to elements". >> >> My thinking is that this should be allowed because adding a file name to the >> map should have also added space for an int value. So, I'd just be modifying >> this int, and not changing the hash table data structure. Is this correct? > > The Go memory model prohibits concurrent reads and writes, or > concurrent writes, to variables. A map is a variable. You can't > concurrently modify either the key or the value of a map. > > What you can do is store a pointer in the map. Then you can modify the > fields to which that pointer points as you wish. Of course you have to > avoid concurrent modifications of those memory locations, but that > doesn't matter if each element is only modified by a single goroutine. > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXoVnqDhF2n5rYMPACpLZmwWROt%3DQCAkVXRqucnj4D%3D4w%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/D581C8DE-1234-4DB8-94FC-6C3A4C72D894%40me.com.
