* Jeff Learman <jeff.lear...@gmail.com> [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 volatile does
in C. Volatile ensures that the variable is not register-optimized,
that reads and writes to it are not optimized away when local code can
be proven to not observe those actions, and that reads and writes of
properly aligned values whose size is the machine word size happen
atomically (it also ensures proper alignment). sync/atomic does just
that.
For Microsoft C/C++, for architectures other than arm, volatile, by
default, also prevents reordering of reads and writes to non-volatile
variables around a read or write to a volatile variable. The ISO
definition of volatile explicitly does not require this, favoring the
std::atomic<T> as the mechanism to effect this.
There was discussion a number of years back (8 or more?) about whether
the Go Memory Model explicitly specified, implicitly specified, or did
not specify that sync/atomic provided a guarantee about not reordering
non-atomic reads and writes around atomic operations. The current
version of the memory models says under "Advice" near the beginning of
the document:
To serialize access, protect the data with channel operations or
other synchronization primitives such as those in the sync and
sync/atomic packages.
This sounds to me like an explicit declaration.
> Issues like this aren't
> really data races, but they are caught by the race detector.
Yes, they are. While amd64 and arm64 architectures will ensure, at the
CPU level, that a single instruction read or write to properly aligned
memory will always read or write the whole value atomically, not all
architectures do (especially many RISC architectures). Also, without
explicit memory barrier instructions, the amd64 (and I think arm64)
instructions will not guarantee observability to other cores.
You really should read the link Nigel gave below.
The OP said "I do not want to use atomic operations or locking to remove
this race condition for performance reasons." I believe the OP should
try sync/atomic. It should not give any statistically significant
performance difference from using the volatile keyword in C, as I would
expect C to use a memory barrier for volatile accesses so that other
cores and other hardware on the bus can observe them.
...Marvin
> On Wednesday, June 7, 2017 at 8:47:02 AM UTC-4 Fuxin Hao 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?
> >
> >
> > 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 <dgr...@gmail.com> wrote:
> >> > On Monday, February 22, 2016 at 8:29:59 PM UTC+1, mikew...@gmail.com
> >> > wrote:
> >> >> I've been trying to find a way to ignore errors from the golang
> >> >> race detector. In particular I have a stats loop that does stale
> >> >> reads from for a variable that is updated constantly. In this
> >> >> case I do not care if the value of the read is stale and I do
> >> >> not want to use atomic operations or locking to remove this race
> >> >> condition for performance reasons. Does anyone know if there is
> >> >> a way to add something to the lines of code that read this value
> >> >> to tell the race detector to ignore errors coming from a
> >> >> specific line of code?
> >> >
> >> > You might be interested in
> >> >
> >> https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
> >>
> >>
> >> See also the "an aggressive compiler might delete the entire go
> >> statement" and "there is no guarantee that the write to done will ever
> >> be observed by main" examples at https://golang.org/ref/mem
> >>
--
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/YqTL5qnxLnGvNVzO%40basil.wdw.
