They are not clever. They are foundational in high performance lock-free structures and other techniques commonly found in HPC and HFT - and even the linux kernel (RCU). This is a decent overview https://www.cs.cmu.edu/~410-s05/lectures/L31_LockFree.pdf but a bit hard to follow since it is slides.
You can review github.com/robaho/go-concurrency-test to see the performance difference lock-free techniques can offer in certain applications. For certain, most programs do not need these techniques but dissuading someone from understanding and/or using them because they are “being clever” is not appropriate. > On May 26, 2019, at 6:59 PM, Dan Kortschak <d...@kortschak.io> wrote: > > 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/D0D2FF18-2665-43B4-A250-82FCF4B7516D%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
