Concurrent Access to Map Values?

[jlfo...@berkeley.edu]

(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?

Cordially,

Jon Forrest

[robert engels]

You are assigning to elements, so no, not allowed. If you have a system where you know all of the keys ahead of time there are much better data structures to use for something like this - simple atomic read and write of the values. 

On Jul 28, 2026, at 11:15 AM, 'jlfo...@berkeley.edu' via golang-nuts <golan...@googlegroups.com> wrote:



--
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 golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/873345e3-4dc6-4578-a408-b356f3ab04abn%40googlegroups.com.

[Ian Lance Taylor]

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

[robert engels]

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 <ia...@golang.org> wrote:
>
> On Tue, Jul 28, 2026 at 9:15 AM 'jlfo...@berkeley.edu' via golang-nuts

> --
> 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 golang-nuts...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXoVnqDhF2n5rYMPACpLZmwWROt%3DQCAkVXRqucnj4D%3D4w%40mail.gmail.com.

[Ian Lance Taylor]

On Tue, Jul 28, 2026 at 7:50 PM robert engels <rob...@me.com> 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

[robert engels]

That code is correct, and matches the OPs scenario, but it goes beyond your original constraints which was that they “are not concurrently written to”. With that code, you are also synchronizing any reads with the mutators - which is what I was trying to clarify.

> On Jul 28, 2026, at 11:19 PM, Ian Lance Taylor <ia...@golang.org> wrote:

[Touring Tim]

I'm sure you should put a lock if changing v, I have similar maps and always lock when writing to it and rlock when reading.

For me a completely static map initialised and k,v set, is one that needs no lock to read concurrently.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/533BF668-A19F-47E7-BDA0-4898A7DBBA03%40me.com.

[Haddock]

Java has a segmented concurrent hash map, see  java - In ConcurrentHashMap how the segments are defined - Stack Overflow where each segment is thread safe. So you when values of keys in different segments are accessed access can happen concurrently which improves throughput.

[Haddock]

Forgot to mention: The current implementation of ConcurrentHashMap in the more recent JDKs is quite optimized and it is meanwhile hard to see what it does. If you take an older JDK (JDK8 or upwards, not sure  ConcurrentHashMap already exists in JDK8) you see an older implementation with an array of 16 segments and some algorithm that from the key derives a number between 0 and 15. That approach is easy to implement in some other language.

[robert engels]

This may be of interest to some. Shows some specific implementations of some concurrent structures. https://github.com/robaho/go-concurrency-test

On Jul 29, 2026, at 5:00 AM, Haddock <bienle...@gmail.com> wrote:

Forgot to mention: The current implementation of ConcurrentHashMap in the more recent JDKs is quite optimized and it is meanwhile hard to see what it does. If you take an older JDK (JDK8 or upwards, not sure  ConcurrentHashMap already exists in JDK8) you see an older implementation with an array of 16 segments and some algorithm that from the key derives a number between 0 and 15. That approach is easy to implement in some other language.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/499f95fa-a71f-4333-a32b-5cc91b4f4975n%40googlegroups.com.