Is Concurrent Access to Go Maps Safe During `range` Iteration?

Concurrent Access to Maps with 'range' in Go

The Go blog entry on "Maps in action" emphasizes the importance of synchronization when accessing maps concurrently. However, it remains unclear whether iterating over maps using the range keyword constitutes a "read" or a "turnover" phase, and whether concurrent access is permissible during this process.

The range expression in a for loop is evaluated once before the loop begins. This means that the map value is accessed only once, and any subsequent modifications made to the map will not be reflected in the iteration. As such, concurrent access is safe as long as the map itself is not modified while iterating over it.

To ensure thread safety, the map should be read-locked before entering the loop and unlocked after each iteration. This prevents concurrent goroutines from modifying the map during this time. The code below demonstrates this technique:

func IterateMapKeys(iteratorChannel chan int) error {
    testMapLock.RLock()
    defer testMapLock.RUnlock()
    for k, v := range testMap {
        testMapLock.RUnlock()
        someFunc()
        testMapLock.RLock()
        if someCond {
            return someErr
        }
    }
    return nil
}

Modifying the map in a different goroutine while holding a write lock ensures the safe modification and subsequent observation of the changes by the loop iterator.

However, it's crucial to note that this locking mechanism only prevents concurrent access, not concurrent modification. Concurrent modifications can still occur, but they will not affect the current iteration.

The above is the detailed content of Is Concurrent Access to Go Maps Safe During `range` Iteration?. For more information, please follow other related articles on the PHP Chinese website!