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 <smantzia...@gmail.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/BC55E282-8BA4-4727-850E-7DAFA76EB576%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
