On Tue, Jul 28, 2026 at 7:50 PM robert engels <[email protected]> wrote: > > 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.
What I mean is that it is OK to write this: https://go.dev/play/p/Mw7lP7ElPQ_a package main import ( "fmt" "sync" ) func main() { m := map[string]*int{ "a": new(1), "b": new(2), } var wg sync.WaitGroup for k := range m { wg.Go(func() { (*m[k])++ }) } wg.Wait() for k, v := range m { fmt.Println(k, *v) } } Ian > > 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/CAOyqgcVWNed7_7gnGCRtT6kN0ZKsz%3D3j01Vd%2BkkR2YTHeiqZ_Q%40mail.gmail.com.
