On Sunday, 27 June 2021 at 19:33:40 UTC+1 ro...@campbell-lange.net wrote:
> Thank you for the pointers and the excellent video (actually by Bryan C.
> Mills, it seems).
>
>
Argh! My apologies to Bryan. I copied the link directly from my local
bookmarks/notes file, and I had misattributed it t
On 27/06/21, Brian Candler (b.cand...@pobox.com) wrote:
> On Sunday, 27 June 2021 at 10:32:22 UTC+1 ro...@campbell-lange.net wrote:
>
> > By the way, as a golang newbie, it isn't clear to me when it is advisable
> > to use a channel for locking as opposed to a mutex. Do people tend to use
> > the
On 27/06/21, Brian Candler (b.cand...@pobox.com) wrote:
> > Shouldn't that result in a panic, even without -race?
>
> It's not *guaranteed* to panic when you make concurrent accesses to the
> same map (hence the point of the race checker). And having two structs
> refer to the same map is no di
On Sunday, 27 June 2021 at 10:32:22 UTC+1 ro...@campbell-lange.net wrote:
> By the way, as a golang newbie, it isn't clear to me when it is advisable
> to
> use a channel for locking as opposed to a mutex. Do people tend to use the
> former?
>
>
There is an absolutely excellent video on this t
On 26/06/21, Ian Lance Taylor (i...@golang.org) wrote:
> On Sat, Jun 26, 2021 at 3:27 PM Rory Campbell-Lange wrote:
> >
> > I'm trying to work out why I have a data race problem (on go 1.15 and 1.16).
> >
> > *SearchResults.Set is called from several goroutines. I am trying to avoid
> > concurren
One way to be robust against this particular problem is to carry a pointer
to a mutex, rather than embedding a mutex.
https://play.golang.org/p/UPY7EBKSYl5
On Sunday, 27 June 2021 at 10:18:52 UTC+1 Brian Candler wrote:
> > Shouldn't that result in a panic, even without -race?
>
> It's not *guara
> Shouldn't that result in a panic, even without -race?
It's not *guaranteed* to panic when you make concurrent accesses to the
same map (hence the point of the race checker). And having two structs
refer to the same map is no different to having two variables refer to the
same map.
For the
On Sat, 2021-06-26 at 20:44 -0700, Ian Lance Taylor wrote:
> Looks like you have multiple SearchResults values that refer to the
> same map.
Shouldn't that result in a panic, even without -race?
Dan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" gr
On Sat, Jun 26, 2021 at 3:27 PM Rory Campbell-Lange wrote:
>
> I'm trying to work out why I have a data race problem (on go 1.15 and 1.16).
>
> *SearchResults.Set is called from several goroutines. I am trying to avoid
> concurrent access to its two maps using a mutex, but this isn't working.
>
>
You're going to need to provide more detail. Specifically, a minimal
reproducer. There is no obvious explanation for the race given what you've
already shown us so I suspect you've omitted an important fact.
On Sat, Jun 26, 2021 at 3:27 PM Rory Campbell-Lange
wrote:
> I'm trying to work out why
Try to use sync.RWMutex instead, you have more control when to read or
write.
Em sáb, 26 de jun de 2021 18:34, 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> escreveu:
> On Sat, 2021-06-26 at 23:26 +0100, Rory Campbell-Lange wrote:
> > I'm trying to work out why I have a data rac
On Sat, 2021-06-26 at 23:26 +0100, Rory Campbell-Lange wrote:
> I'm trying to work out why I have a data race problem (on go 1.15 and
> 1.16).
>
> *SearchResults.Set is called from several goroutines. I am trying to
> avoid concurrent access to its two maps using a mutex, but this isn't
> working.
I'm trying to work out why I have a data race problem (on go 1.15 and 1.16).
*SearchResults.Set is called from several goroutines. I am trying to avoid
concurrent access to its two maps using a mutex, but this isn't working.
108 type SearchResults struct {
109 Boxes map[string][]Box
110 s
13 matches
Mail list logo
