>From what i understand you propose to create a new object and switch out
the old one with the new one using the atomic package of go.
If that is the case i cannot use it since i don't control the field
directly.
I am using the SetString method of the Value struct in the reflect package.
// SetString sets v's underlying value to x.
// It panics if v's Kind is not String or if CanSet() is false.
func (v Value) SetString(x string) {
v.mustBeAssignable()
v.mustBe(String)
*(*string)(v.ptr) = x
}
On Sunday, May 26, 2019 at 8:51:59 PM UTC+3, 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 <smant...@gmail.com
> <javascript:>> 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 golan...@googlegroups.com <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9abf1f2b-00bf-4346-b429-e40617997237%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/9abf1f2b-00bf-4346-b429-e40617997237%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/7bf75b7a-322e-40c4-b78f-d2427fa275e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
