Re: [go-nuts] Re: Ignore stale read errors from the race detector

* Jeff Learman [220610 13:23]: > Unlike C, Go has no `volatile` keyword. Therefore, the compiler is allowed > to cache a value that is never updated in the scope that it sees, and > there's no way for us to tell it not to do that. Actually, sync/atomic does essentially the same thing that

[go-nuts] Re: Ignore stale read errors from the race detector

Consider skipping specific tests when the race detector is active. Alternatively (and dangerously, unless you understand the consequences), provide two implementations; one that is safe and is used when race detection is enabled, and another that is unsafe, and use build flags to control it:

Re: [go-nuts] Re: Ignore stale read errors from the race detector

Unlike C, Go has no `volatile` keyword. Therefore, the compiler is allowed to cache a value that is never updated in the scope that it sees, and there's no way for us to tell it not to do that. Issues like this aren't really data races, but they are caught by the race detector. On Wednesday,

Re: [go-nuts] Re: Ignore stale read errors from the race detector

On Tue, Jun 6, 2017 at 7:48 PM, wrote: > > "there is no guarantee that the write to done will ever > be observed by main", i am wondering why the write to done will ever > be observed by main in detail? I'm sorry, I don't understand the question. The program in question,

Re: [go-nuts] Re: Ignore stale read errors from the race detector

"there is no guarantee that the write to done will ever be observed by main", i am wondering why the write to done will ever be observed by main in detail? On Thursday, February 25, 2016 at 8:07:29 AM UTC+8, Nigel Tao wrote: > > On Tue, Feb 23, 2016 at 7:46 AM, Damian Gryski