Or to be perhaps more precise: This view can be useful to understand the
observed behaviour: A string is two words which are updated non-atomically,
hence one read might observe the write of the length separately from the
write of the data.
But to determine the *correctness* of the program, any co
On Mon, Mar 25, 2024 at 3:47 PM 'Brian Candler' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> And as Axel's own reproducer shows, even having two threads reading and
> writing the same *variable* which points to a string can result in
> indeterminate behaviour, since a string is really
And as Axel's own reproducer shows, even having two threads reading and
writing the same *variable* which points to a string can result in
indeterminate behaviour, since a string is really a struct containing two
parts (a pointer and a len). You're not mutating the string itself, but
you are u
TBQH the word "mutable" doesn't make a lot of sense in Go (even though the
spec also calls strings "immutable").
Arguably, *all* values in Go are immutable. It's just that all *pointers*
in Go allow to modify the referenced variables - and some types allow you
to get a pointer to a shared variable,
Wow, i am from other language and i thought `string` is immutable or
something like that, so thread-safe for this operation. learned something
new!!! Thanks
On Thursday, March 21, 2024 at 11:42:24 PM UTC+8 Ethan Reesor wrote:
> I hadn't used the race detector before. I do see a race warning for
I hadn't used the race detector before. I do see a race warning for
(*URL).String() among an embarrassing number of other results. I'm going to
update (*URL).String() to use atomic.Pointer to remove the race.
Thanks,
Ethan
On Thu, Mar 21, 2024 at 8:59 AM 'Axel Wagner' via golang-nuts <
golang-nut
On Thu, Mar 21, 2024 at 2:48 PM 王李荣 wrote:
> hi Axel,
>
> is not modifying `u.memoize.str` thread-safe? the len and the data point
> should become visible at same time?
>
What makes you think that? To be clear, there are no benign data races.
Even a data-race on a variable smaller than a word i
hi Axel,
is not modifying `u.memoize.str` thread-safe? the len and the data point
should become visible at same time?
在2024年3月16日星期六 UTC+8 06:29:06 写道：
> Have you tried running the code with the race detector enabled? I suspect
> that you are concurrently modifying `u.memoize.str` by calling
Have you tried running the code with the race detector enabled? I suspect
that you are concurrently modifying `u.memoize.str` by calling `u.String()`
from multiple goroutines. And the non-zero length of the string header
written by one goroutine becomes visible to the other one, before the
modifica
