Is Go's `range` Keyword Safe for Concurrent Map Access?

Concurrent Access to Maps with 'range' in Go

In the "Go maps in action" blog entry, the documentation states that maps are not safe for concurrent use without synchronization mechanisms like sync.RWMutex. However, it's not clear whether access via range iteration constitutes a "read" or if the range keyword has specific locking requirements.

Concurrency of range

The range expression is evaluated once before the loop begins. For maps, this means that the map variable (e.g., testMap) is only evaluated once, even though new key-value pairs may be added or removed during the iteration. This separation between the initial evaluation and the iteration itself implies that the map is not accessed by the for statement while executing an iteration.

Safe Iteration

Therefore, the following iteration is safe for concurrent access:

func IterateMapKeys(iteratorChannel chan int) error {
    testMapLock.RLock()
    defer testMapLock.RUnlock()
    mySeq := testMapSequence
    for k, _ := range testMap {
        ....
    }
    return nil
}

This design ensures that the map is locked only when necessary, while allowing for concurrent access to other goroutines.

Concurrent Modification

However, this type of locking only prevents concurrent access, not concurrent modification. It's possible for another goroutine to acquire the write lock and modify the map even while the iteration is ongoing. To prevent this, the map should remain locked throughout the iteration.

Example

This example demonstrates the difference between unlocking and locking within the for block:

func IterateMapKeys(iteratorChannel chan int) error {
    testMapLock.RLock()
    defer testMapLock.RUnlock()
    mySeq := testMapSequence
    for k, _ := range testMap {
        testMapLock.RUnlock()
        ....
        testMapLock.RLock()
        ....
    }
    return nil
}

In this example, releasing the read lock within the for block allows for concurrent modification and potential errors.

Conclusion

The range keyword itself does not provide synchronization for concurrent access to maps. Using proper synchronization mechanisms (e.g., sync.RWMutex) is crucial to ensure the safety of concurrent iterations and modifications.

The above is the detailed content of Is Go's `range` Keyword Safe for Concurrent Map Access?. For more information, please follow other related articles on the PHP Chinese website!