在多个goroutine之间共享的Golang结构中，非共享成员是否需要互斥保护？

Question

I have one Golang struct shared among multiple goroutines. For concurrent access to struct members, there is the mutex sync.RWMutex. For struct member that is accessed by one single goroutine, is there need of mutex protection?

For example, in the code below, one single writer goroutine accesses the member shared.exclusiveCounter, without any lock protection. Is this correct/safe? Or is there need of mutex because the whole struct is accessed by multiple goroutines thru a shared pointer?

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    s := &shared{mutex: &sync.RWMutex{}}

    readerDone := make(chan int)
    writerDone := make(chan int)

    go reader(s, readerDone)
    go writer(s, writerDone)

    <-readerDone
    <-writerDone
}

type shared struct {
    mutex            *sync.RWMutex
    sharedCounter    int // member shared between multiple goroutines, protected by mutex
    exclusiveCounter int // member exclusive of one goroutine -- is mutex needed?
}

func (s *shared) readCounter() int {
    defer s.mutex.RUnlock()
    s.mutex.RLock()
    return s.sharedCounter
}

func (s *shared) setCounter(i int) {
    defer s.mutex.Unlock()
    s.mutex.Lock()
    s.sharedCounter = i
}

func reader(s *shared, done chan<- int) {
    for {
        time.Sleep(2 * time.Second)
        counter := s.readCounter()
        fmt.Printf("reader: read counter=%d
", counter)
        if counter > 5 {
            break
        }
    }
    fmt.Printf("reader: exiting
")
    done <- 1
}

func writer(s *shared, done chan<- int) {
    s.exclusiveCounter = 0
    for {
        time.Sleep(1 * time.Second)
        s.exclusiveCounter++
        fmt.Printf("writer: writing counter=%d
", s.exclusiveCounter)
        s.setCounter(s.exclusiveCounter)
        if s.exclusiveCounter > 5 {
            break
        }
    }
    fmt.Printf("writer: exiting
")
    done <- 1
}

Run it on playground

Answer 1

If only a single goroutine accesses the struct member, you don't need to have a mutex to control access. I would, probably, use one anyway (either re-use the existing mutex in the struct, or another one), on the basis that while there may only be one goroutine accessing that struct member today, there's nothing enforce that.