* Robert Engels [231115 12:29]:
> What I’m suggesting is that imagine a dev changes that code and has
> version() access the request property…
Okay, that makes sense.
> This is why if you are sharing data in a concurrent way you need to be
> very careful of all usages.
Absolutely.
> The
On Tuesday, 14 November 2023 at 03:38:04 UTC Mike Schinkel wrote:
1. A value variable and multiple value receivers <--- compiles
2. A pointer variable and multiple value receivers <--- compiles
3. A pointer variable and multiple pointer receivers. <--- compiles
4. A value variable and multiple
What I’m suggesting is that imagine a dev changes that code and has version()
access the request property…
This is why if you are sharing data in a concurrent way you need to be very
careful of all usages.
The safest solution is to use immutable objects - of which the non pointer are.
So
* Robert Engels [231114 21:55]:
>Switching to pointer receivers everywhere actually makes this worse. Any
>access is potentially a data race.
>It stills seems like this is a compiler issue. There needs to be a way to
>synchronize the pointer to value copy in conjunction with
* burak serdar [231114 19:09]:
> I do not agree that this is because how the compiler works. A value
> receiver is equivalent to pass-by-value argument, that is:
>
> rcp.version()
>
> is equivalent to:
>
> RPC.version(rpc)
>
> thus, creating the copy of the rpc variable. So, the compiler may
Switching to pointer receivers everywhere actually makes this worse. Any access is potentially a data race. It stills seems like this is a compiler issue. There needs to be a way to synchronize the pointer to value copy in conjunction with other synchronization. The only way to do this would be to
On Tuesday, November 14, 2023 at 6:16:58 PM UTC-5 burak serdar wrote:
It is a data race because calling rpc.version() makes a copy of rpc,
which causes reading the field rpc.result concurrently while it is
being written by the goroutine.
Thank you for explaining. I think I am starting to see
I do not agree that this is because how the compiler works. A value
receiver is equivalent to pass-by-value argument, that is:
rcp.version()
is equivalent to:
RPC.version(rpc)
thus, creating the copy of the rpc variable. So, the compiler may
choose to avoid the race by not copying it, or by
It is a data race because calling rpc.version() makes a copy of rpc,
which causes reading the field rpc.result concurrently while it is
being written by the goroutine.
On Tue, Nov 14, 2023 at 3:59 PM Mike Schinkel wrote:
>
> On Monday, November 13, 2023 at 11:28:00 PM UTC-5 Dan Kortschak wrote:
On Monday, November 13, 2023 at 11:28:00 PM UTC-5 Dan Kortschak wrote:
https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race
Thanks for that link.
However, after studying it for well more than an hour I cannot figure out
why it is a data race, and unfortunately Dave Cheney
Lastly, the only reason that changing to a pointer receiver “solves” the race
is because the field in the object isn’t accessed - something the compiler
could detect in the other version as well.
> On Nov 13, 2023, at 10:50 PM, Robert Engels wrote:
>
> Similarly, even in a single threaded
Similarly, even in a single threaded Java program objects are copied/moved
behind the scenes - these don’t generate race conditions as the runtime ensures
there isn’t one.
> On Nov 13, 2023, at 10:47 PM, Robert Engels wrote:
>
> To me this is a limitation of the compiler. If a passed
To me this is a limitation of the compiler. If a passed argument is unused it
doesn’t even need to be created. Similarly if only a few fields are used in a
called function a sparse data object can be sent. It only becomes a race if the
data being copied is actually used - then the race is also
On Mon, 2023-11-13 at 19:38 -0800, Mike Schinkel wrote:
> I have been wondering for a while why the advice against mixing
> pointer and value receivers, which GoLang so often flags me for
> doing.
https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race
--
You received this message
That's a really good question, IMO.
I have been wondering for a while why the advice against mixing pointer and
value receivers, which GoLang so often flags me for doing.
Ideally I think that I would like to be able use value receivers most of
the time when I want the method to leave the
15 matches
Mail list logo
