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/CAOyqgcW-LphZV6%2BXQizEURnZpfkxogASoT1qAhioRJow_BD96g%40mail.gmail.com.
