Jan's comments about possible outcomes other than those outlined in Sotirios' second post are correct. Using atomic.Value would synchronise the values due to the introduction of a write barrier. I'm not omitting much of the argument, you're just missing it.
Sorry, I'm done. On Mon, 2019-05-27 at 19:22 -0500, Robert Engels wrote: > 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 <dan@kortschak.i > > > > > > o> > > > > > > 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/1559004035.21310.189.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
