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 <[email protected]> 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 <[email protected]> >>> 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 >>>>>> <[email protected]> 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 [email protected]. >>>>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/84ac843e670e7781198d231193cd45908d8b58b1.camel%40kortschak.io. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/088292D5-ABB8-45DD-8A51-ABB134B3E81E%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
