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?
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
> <javascript:>> wrote:
> > Ian Lance Taylor <ia...@golang.org <javascript:>> 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.
