On Fri, Dec 29, 2017 at 2:16 PM, Caleb Spare <cesp...@gmail.com> wrote: > I'm quite certain that code is correct. There's no data race here > since the write and the non-atomic read are both inside the mutex.
I don't believe so, I think this is currently safe because of the way the compiler does not maintain any live registers across function call boundaries, however this probably isn't a strong enough guarantee. > The memory model rules about mutexes formalize how they serialize the > code inside them. Because the unlock happens-before the next lock, and > because sequential code in a single goroutine has the happens-before > order that the source code expresses, this read: > > if o.done == 0 then o.done could be loaded into a register, and on some architectures it must be loaded into a register, after this point. > > and this write: > > atomic.StoreUint32(&o.done, 1) Taking the address of the done field in the o object will have no impact on the value of o.done potentially cached in a register. If this code is inlined into its caller then the registerised copy of o.done may be consulted again without respect to the atomic load earlier in the function. This is probably not happening today because this function is not a leaf function and is not eligible for inlining at the default settings. The correctness of the function is relying on unspecified compiler behaviour. > are not concurrent. (This is just a slightly more precise way of > stating the natural, intuitive behavior of a mutex.) Therefore, that > read *must* observe the previously written value. I don't agree, the intermixing of atomic and non atomic accesses to this value create an ambiguity, we've had cases of this reported into the past with other intermixing of atomic and non atomic loads. > > On Thu, Dec 28, 2017 at 7:11 PM, Dave Cheney <d...@cheney.net> wrote: >> I think you are right, all access to that field should go via atomic >> load/store operations. I don’t think it’s safe to mix those operations wth >> normal loads and stores even within the same goroutine. >> >> -- >> 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.
