On Sun, Jan 10, 2021 at 12:57 PM 김용빈 <kyb...@gmail.com> wrote: > Thank you Wagner, as always! > > Yes, I asked because it is a field of a struct. With your answer, now I > can sure what I wrote is correct or not. > > And also thanks for your guide to official documents. I will check them > first next time. >
No worries, I wasn't trying to call you out or anything, it's a lot of material :) I just genuinely find it fun to do > > > 2021년 1월 10일 일요일 오후 6시 53분 29초 UTC+9에 axel.wa...@googlemail.com님이 작성: > >> 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...@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/fffc1d95-e6c5-4cf1-87bc-1c64742172aan%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/fffc1d95-e6c5-4cf1-87bc-1c64742172aan%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/CAEkBMfEM9vUEUhzcBrxONzKLBXVsGNdr6Oc%2BimQFn-cv1zZFDQ%40mail.gmail.com.
