I think the bit you're missing is this: > Within a single goroutine, the happens-before order is the order expressed by > the program.
That is, there is an implicit happens-before between each successive statement *within a single goroutine*. So in the example: - the first l.Lock() happens-before go f() - by the memory model rules for goroutine creation; go f() happens-before f executes - a = "hello, world" happens-before l.Unlock() - by the memory model rules for locks, the first (only) l.Unlock() happens-before the second l.Lock() - the second l.Lock() happens-before print(a) - therefore, transitively, a = "hello-world" happens-before print(a) -Caleb On Wed, Nov 30, 2016 at 5:40 PM, Daniel Fanjul <daniel.fanjul.alcu...@gmail.com> wrote: > I think the current implementations of the methods of sync.RWMutex happen to > be actual memory barriers and this is why everything works just fine. > > But I don't think the spec or the memory model or the doc of sync mentions > this. > > If this is not described, the example in the memory model for the locks is > wrong: > > // https://play.golang.org/p/pmhbeyn_wZ > > var l sync.Mutex > var a string > > func f() { > a = "hello, world" > l.Unlock() > } > > func main() { > l.Lock() > go f() > l.Lock() > print(a) > } > > > The statements in f() might be reordered to run l.Unlock() first and then > the assignment. The code would not guarantee to print "hello, world" at the > end. > > -- > 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. -- 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.
