Short answer: Yes, it's safe. IMO it's always fun to try and find the answer in the docs though, so long answer:
According to the Go memory model <https://golang.org/ref/mem#tmp_0> The Go memory model specifies the conditions under which reads of a > variable in one goroutine can be guaranteed to observe values produced by > writes to the same variable in a different goroutine. Now, the only write you do to `A.id` is at creation time, so the question is, is that modification concurrent with other reads or does it "happen before" the reads? The answer is most likely, that it happens before - I assume you initialize the variable and only create goroutines reading it after that, so 1. the write happens-before the go statement, because of the rule <https://golang.org/ref/mem#tmp_2> "Within a single goroutine, the happens-before order is the order expressed by the program." and 2. that go statement happens-before any reads in that goroutine, because of the rule about goroutine creation <https://golang.org/ref/mem#tmp_5>. So, because happens-before is transitive, the write happens-before the reads. And because it's the only write, it's safe. There is a small caveat though: The Memory model speaks about "reads/writes of a variable". Maybe this still isn't safe, because you write to a variable holding an A concurrently (even though you access different fields)? Well, let's see what the spec has to say about variables <https://golang.org/ref/spec#Variables>: Structured variables of array, slice, and struct types have elements and > fields that may be addressed individually. Each such element acts like a > variable. Okay, so every field can be treated as its own variable. Thus, applying the rules of the memory model to individual fields is correct. On Sun, Jan 10, 2021 at 10:30 AM 김용빈 <kyb...@gmail.com> wrote: > I have a struct that will be used concurrently. > > type A struct { > sync.Mutex > id string > // other members > ... > } > > The other members of A will be concurrently read or written. So I think I > have to hold lock of A for those. > > But A.id will be written once at creation time of A (when it was not > handled concurrently, yet) and will only be read after then. > > Should I lock A to read A.id, or is it safe to read concurrently without > it? > > Thanks in advance. > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/1e7df2af-b26e-403f-a8a4-41170b2d2aeen%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/1e7df2af-b26e-403f-a8a4-41170b2d2aeen%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFKXWK9TASg4mhOQRoggMqPNeRvD49LnHmUPhfHsu1gCg%40mail.gmail.com.
