> Within a single goroutine, the happens-before order is the order expressed by the program. If this is true, why is the order of 'a = 1; b = 2;' not ensured? I think you may be forgetting that "compilers and processors may reorder the reads and writes executed within a single goroutine"
> Inside a single goroutine the code proceeds in statement order. The code generated by the compiler, right? Of course, it is typically the processor who reorders. But what is the limit of the reorder? Is 'a = 1; b = 2;' so simple that we worry about this case, but is 'a = 1; x.Lock(); b = 2;' so complex that we assume that it will never be reordered? Now I see it is because we assume it is a memory barrier though it is undocumented. Thanks, Ian, I am sure now it is undocumented. > - a = "hello, world" happens-before l.Unlock() That is false unless l.Unlock() is memory barrier or some other restriction. It happens it is a barrier, so you can say it truly happens before. The spec or the memory model does not mention it, so technically we cannot state it because of the spec or the memory model. > If it didn't chaos would ensue, it would be as if statements in a function were executed in random order. In theory, the statements are allowed to run in any order but only "when the reordering does not change the behavior within that goroutine as defined by the language specification", that is "when reads and writes must behave as if they executed in the order specified by the program". But I agree with you, Dave, in practice the deviation is small. > I agree that this fact is not documented, but it is true nonetheless. Cool, thank you. I think it is quite important and really necessary to understand the memory model. Otherwise its examples do not make sense at all. Thank you all, I finally and completely understood the memory model. On Thursday, December 1, 2016 at 7:15:45 AM UTC+1, Ian Lance Taylor wrote: > > On Wed, Nov 30, 2016 at 5:44 PM, Daniel Fanjul > <daniel.fan...@gmail.com <javascript:>> wrote: > > I cannot tell if there is any memory barrier in the code of > > sync.RWMutex.Lock(), I don't understand it completely. I just think > there is > > not. > > https://golang.org/src/sync/mutex.go?s=1143:1165#L34 > > The sync/atomic routines provides memory barriers. > > I agree that this fact is not documented, but it is true nonetheless. > > Ian > -- 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. For more options, visit https://groups.google.com/d/optout.
