Please don't. Java is not relevant here and the advice given by other prior to this post in the thread is not incorrect. Using atomic operations (in this case it would be atomic.Value's Load and Store methods) invokes a write barrier, which is fundamentally just a memory synchronisation. In pkg sync there is good advice in the Overview of the package, though the best advice is in the MM https://golang.org/ref /mem#tmp_1:
> Programs that modify data being simultaneously accessed by multiple > goroutines must serialize such access. > > To serialize access, protect the data with channel operations or > other synchronization primitives such as those in the sync and > sync/atomic packages. > > If you must read the rest of this document to understand the behavior > of your program, you are being too clever. > > Don't be clever. On Sun, 2019-05-26 at 12:51 -0500, Robert Engels wrote: > Ignore the incorrect comments from the others. There are many valid > cases where relaxed concurrency rules apply and you don’t need > synchronization just atomic ops (and with certain platform this is > not needed - eg java volatile)That is why GC systems can outperform > non GC systems in concurrent scenarios. But you need to allocate new > objects not modify existing ones (a big reason GC platform strings > are usually immutable). You can do the same in Go. > > > > > On May 26, 2019, at 11:17 AM, Sotirios Mantziaris <smantziaris@gmai > > l.com> wrote: > > > > I understand, i have to synchronize access... > > Coming from another language i had some guarantees on some > > assignments mostly int. A string might be a issue here of course... > > I have to refactor my code in order to make is safe. > > > > thanks. > > > > > > > > On Sunday, May 26, 2019 at 6:13:56 PM UTC+3, Jan Mercl wrote: > > > On Sun, May 26, 2019 at 4:03 PM Sotirios Mantziaris > > > <smant...@gmail.com> wrote: > > > > > > > > > > > Let's assume that the string field Name has the value `Mr. > > > > Smith` and we change this to `Mr. Anderson` in the goroutine, > > > > what are the possible values that i could bet on a read? > > > > > > > > If these are either `Mr. Smith` or `Mr. Anderson` i am very ok > > > > with that because i want the value to be eventually > > > > consistent. > > > That would be the only possible outcomes iff a multi word value > > > is > > > updated atomically. > > > > > > > > > > > If there is another possible outcome then i need to synchronize > > > > the access and refactor a lot. > > > Any outcome is possible with a data race. One of those that are > > > often > > > seen in practices is, obviously, `Mr. Ander`. Another is that the > > > app > > > will segfault. Also, the Go memory model does not guarantee one > > > goroutine will _ever_ observe a change made by a different > > > goroutine > > > concurrently but without proper synchronization. The compiler if > > > free > > > to consider all values not explicitly mutated by a code path to > > > never > > > change without synchronization. > > > > > > tl;dr: There's no safe way to ignore a data race. > > -- > > 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/9abf1f2b-00bf-4346-b429- > > e40617997237%40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1558915152.21310.156.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
