You have conveniently omitted much of the argument, for example, like reading Ander from a string containing Anderson due to improper synchronization - which is clearly incorrect and what I was pointing out. The java refs are important to this discussion since when everything is ref and under GC, the ABA problem does not occur. Since Go has value structures and arrays of them the issue is dependent upon the detailed data structures as to what concurrency techniques are suitable.
The op specifically asked about valid values that could be seen. It had nothing to do with being clever or over optimizing. As in the slides I included, just saying use a lock or mutex is not correct, as locks have other issues (deadlocks, priority inversion, others ). Lastly, if you are going to argue against the points, feel free to do so, but incorrectly changing the argument or my position is not very welcome. > On May 27, 2019, at 6:51 PM, Dan Kortschak <d...@kortschak.io> wrote: > > In the post that I was replying to you told the OP to ignore incorrect > comments and then brought in the java world and stated that > synchronisation was not needed, only atomic operations. The comments by > previous posters were not incorrect and how things work in java is only > barely relevant here given the way that that language handles objects > and how that that differs from how Go handles values. The claim that > synchronisation is not required is arguably correct; the use of atomics > in Go imposes a write barrier, which is a form of synchronisation. > > On the being clever issue, the benefits that are gained from using > lower level synchronisation constructs and building from there rather > than using the language-idiomatic constructs depend on context. In > cases they are definitely warranted, in others not so much. Given that > the OP was asking about issues that indicated that there was some > misunderstanding about how race conditions affect Go, using lower level > constructs seems like something that should not be happening now (maybe > later if warranted by performance needs). Given that the aspect of the > project that is being asked about is in re-configuration, it is likely > not to be on a hot path and so probably (I have not looked at the code > in depth) will never need to have that level of performance > optimisation. From the OP, the sensible approach looks like a > sync.RWLock-protected struct with getters and setters. > >> On Mon, 2019-05-27 at 14:58 -0500, robert engels wrote: >> I’m sorry if you think I put words in your mouth, I did not mean to. >> >> Can you please explain what "Please don’t” means then? I took it at >> face value, and that it was a affirmative response to “Don’t be >> clever." >> >>> >>> On May 27, 2019, at 7:33 AM, Dan Kortschak <d...@kortschak.io> >>> wrote: >>> >>> Please don't say I've said things I didn't. I did not dissuade >>> someone >>> from understanding or using something. I quoted the memory model, >>> and I >>> pointed out that the advice given by previous posters was not >>> incorrect >>> as you claim. What you are reading them as saying may be wrong, but >>> not >>> what they are actually saying. >>> >>>> On Mon, 2019-05-27 at 07:10 -0500, robert engels wrote: >>>> >>>> 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/617354D7-74B6-4504-902F-9502989B6522%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
