> Given the above, is it guaranteed that A's stores to X, Y and Z are synchronized-before B's loads from X, Y and Z?
Yes. The writes of X, Y, and Z are sequenced before the atomic write to M, the atomic write to M is synchronized before the atomic read of M (assuming the read returns the result of that write), and the atomic read of M is sequenced before the reads of X,Y, and Z. Thus the writes of X, Y, and Z happen before the reads of X, Y, and Z in your example. On Sunday, October 30, 2022 at 10:34:42 AM UTC-7 Konstantin Khomoutov wrote: > On Sun, Oct 30, 2022 at 08:47:41AM -0700, jake...@gmail.com wrote: > > > I would like to give you a definitive answer, but the same question > comes > > up in https://groups.google.com/g/golang-nuts/c/Gze1TRtdLdc/ and there > is > > much disagreement and no clear resolution. (The initial question is not > > exactly yours, but if I understand correctly, the discussion quickly > gets > > simplified to exactly yours.) So unless *someone from the go team is > > willing to clarify,* all you are getting are varying options. Of course, > > read the thread yourself and maybe you will believe one side was > correct. > > Thank you! > Somehow I missed that thread, and it is indeed very close to my situation. > An very interesting read - though not quite satisfying, alas ;-) > > > Reading your description, I am also concerned that you could have a > logical > > race. Its possible you already account for this, but if you are setting > the > > 'array pointer' atomically and separately setting the 'count' > atomically, > > the there could be cases where readers read a count not matching the > > current array. There are many simple fixes, and you hopefully have > already > > taken this into account, but I just wanted to mention it. > > Again, thanks! > Yes, there is a logical race, but in the real code the variable holding the > address of an array is written only once: the writer goroutine actually > grows > a linked list, and the "active" array is the list's tail - in the same > compound variable with its length. So I _thought_ that any reader who > managed > to get to the list's tail had no way reading the length from a different > array. (Trying to explain the whole construction I'm dealing with would > supposedly made it impenetrable for the readers so I've tried to simplify > the > things as much as possible.) > > -- 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/5a5a8754-7f1d-4ead-b35e-e65829204e26n%40googlegroups.com.
