* burak serdar <bser...@computer.org> [191112 12:45]: > Is there a guarantee that the compiler will not reorganize > instructions around an atomic read/write? That is: > > i++ > k:=atomic.AddInt32(&j,1) > > Is there a guarantee that the compiler won't rewrite this as: > > k:=atomic.AddInt32(&j,1) > i++
First, from one of the issues to which Robert Engels pointed, it appears that the language designers are in agreement that if atomics are not covered by the Go Memory Model, they should be. From this, it seems safe to me to treat them as if they provide a does-not-happen-concurrently promise. >From that (and, independently, from the fact that atomics would otherwise lose all their documented usefulness) it follows that you have the same guarantee about reordering that you would have if you replaced the atomic access with a mutex or channel operation. Everybody seems to agree that the compiler can only reorder if such reordering not only does not affect the behavior of the goroutine being reordered, but also does not affect the behavior observed by other goroutines _where a happens-before relationship between those goroutines_ promises such behavior. Unfortunately, I cannot find any wording in the GMM that prevents reordering one goroutine when such reordering breaks a transitive happens-before relationship with an operation in another goroutine. The permission to reorder one goroutine is given before the term "happens before" is defined. The GMM makes specific guarantees about the non-transitive happens-before relationships between goroutines, and gives examples that clearly demonstrate transitive intent, but that transitive property is never explicitly stated. In other words, the permission to reorder within one goroutine is never limited to reordering happens-before operations that do not involve other goroutines. I believe this is a much more egregious omission in the GMM than not mentioning atomics. It is clearly intended, otherwise the whole GMM is completely useless. ...Marvin -- 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/20191113162815.pjh4mrgvaae64xhq%40basil.wdw.
