>
> I'm not saying that m["foo"] is a
> variable (it's not, because it's not addressable). I'm saying that m
> is a variable and m["foo"] is a read of that variable m, just as if p
> is a variable of pointer type then *p is a read of that variable p.
>
Ah, ok, this framing makes sense to me!
On Mon, Apr 13, 2020 at 1:59 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Mon, Apr 13, 2020 at 10:17 AM <alecben...@gmail.com> wrote:
> >
> > Very old thread I know, but:
> >
> > > a map is a variable
> >
> > This seems clear enough, but what doesn't seem obvious to me is that an
> expression like m["foo"] can be treated as "just a variable". Does the spec
> also make that clear?
> >
> > E.g., if I roll my own map type, there's no reason to assume
> m.Get("foo") is safe for concurrent reads. Naively, I'd assume m["foo"] is
> analogous to something like m.Get("foo"). Does the spec make it clear that
> that's not the case, as far as memory semantics go?
>
> My opinion from more than six years ago is unchanged.
>
> A map m is a variable. An expression like m["foo"] is a read of that
> variable. A statement like m["foo"] = "bar" is a write of that
> variable. Yes, m["foo"] is safe for concurrent reads. I don't see
> any way to insert a distinction between m and m["foo"] with regard to
> whether a map is a variable. I'm not saying that m["foo"] is a
> variable (it's not, because it's not addressable). I'm saying that m
> is a variable and m["foo"] is a read of that variable m, just as if p
> is a variable of pointer type then *p is a read of that variable p.
>
> I agree that if you roll your own map type then m.Get("foo") might not
> necessarily be safe for concurrent calls, but I'm asserting that since
> in Go a map is variable, m["foo"] must be safe for concurrent
> execution. (And, for what it's worth, in the current implementations
> that is true.)
>
> Ian
>
> > On Friday, November 15, 2013 at 1:12:53 PM UTC-5, Ian Lance Taylor wrote:
> >>
> >> On Thu, Nov 14, 2013 at 9:58 PM, Dominik Honnef <domi...@fork-bomb.org>
> wrote:
> >> > Ian Lance Taylor <ia...@golang.org> writes:
> >> >
> >> >>> It's not specified.
> >> >>
> >> >> A read from a map is like any other read from a variable. Thus it's
> >> >> fine if multiple goroutines read from a map simultaneously. But if
> >> >> one goroutine reads from a map while another writes to a map, or if
> >> >> two goroutines write to a map, then the program must synchronize
> those
> >> >> goroutines in some way.
> >> >
> >> > Does the existing specification actually guarantee this? Because there
> >> > are certainly ways to implement it that don't have that guarantee.
> >> > https://code.google.com/p/go/source/detail?r=af469280a34b comes to
> mind
> >> > in particular.
> >> >
> >> > I know that this implementation of Go seems to guarantee it, but could
> >> > there be an alternate implementation that implements maps that aren't
> >> > safe for concurrent reads and still implement the specification?
> >>
> >> The relevant document is here is the memory model
> >> (http://golang.org/ref/mem). The memory model is written in terms of
> >> reads and writes to a variable. You are essentially saying "a map is
> >> not a variable, so we need a separate specification for the behaviour
> >> of a map." I am simply saying: a map is a variable.
> >>
> >> I'm not opposed to adding a sentence about maps to the memory model.
> >> I'm just not sure it's required.
> >>
> >> You are of course correct that maps can be implemented such that they
> >> do not meet the requirements of the Go memory model. It's possible to
> >> implement non-map variables that way too, e.g., by caching reads and
> >> writes across synchronization boundaries. Either way it would be a
> >> case where the implementation fails to meet the spec, or, in other
> >> words, it would be a bug.
> >>
> >> Ian
> >
> > --
> > 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/75e5430c-855e-479b-b1fa-d8ea196db3b9%40googlegroups.com
> .
>
--
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/CA%2Bz56Y6-tGdTaOs7yJihvQbU0%3D0H_K21E%2BnZYbHYF6ovw%3Db02Q%40mail.gmail.com.
