Are slices thread-safe for reading?

[jonathan....@gmail.com]

I'm sorry if this has been answered before, but a quick Googling only turned up some stuff on slices not being thread-safe for writing. Is it thread-safe to have multiple goroutines reading from the same slice (with none writing to it)? I don't see any reason why it wouldn't be, I just wanted to make sure. Also, am I correct that it's not thread-safe to have multiple goroutines reading from the same map?

[Jan Mercl]

AFAIK, you can safely read (memory of) any thing from multiple
goroutines as long as updating/creation of that thing HB the reads and
all the reads HB any possible later mutation of thing. It doesn't
matter if thing is a slice or map or anything else except for channels
which are concurrent access safe by their very nature.

-j

[Dmitry Vyukov]

yes, it's safe

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[jonathan....@gmail.com]

Great, thanks for clarifying.

[roger peppe]

The case that I'm always slightly concerned about is this:

http://play.golang.org/p/7fnQgF_wWc

It's race free, I don't know how it could work efficiently on architectures
that don't support byte-sized reads and writes.

[Dmitry Vyukov]

it also must work
a programmer must be able to reason in terms of 'variables', otherwise
it becomes unmanageable
in either case, C/C++/Java do this, so I think we are quite safe in
terms of potential architectures not supporting byte-sized
reads/writes

[nicolas...@gmail.com]

For your question about map being read by multiple goroutines, the answer is in this thread :

https://groups.google.com/forum/#!topic/golang-nuts/3FVAs9dPR8k

[Ian Lance Taylor]

On Tue, Feb 25, 2014 at 5:53 AM, roger peppe <rogp...@gmail.com> wrote:
> The case that I'm always slightly concerned about is this:
>
> http://play.golang.org/p/7fnQgF_wWc
>
> It's race free, I don't know how it could work efficiently on architectures
> that don't support byte-sized reads and writes.

The C++11 memory model requires that the equivalent code in C++ work
correctly. It follows that on architectures that do not support
byte-level access C++ requires that char arrays be laid out in memory
such that each element takes up two bytes (or whatever is required).
Go will have to do the same thing.

Or to put it another way, it is essentially no longer possible to
create an architecture that does not offer byte-level access and is
programmable in standard high-level languages.

Ian

[minux]

Does the standard require CHARBITS to be 8?
i think for non-byte-addressable architectures, making CHARBITS greater than 8 is permitted under the standard.

(although if Go requires atomic byte access, Go won't be possible on those systems. e.g. some older DSPs)

[Ian Lance Taylor]

On Tue, Feb 25, 2014 at 3:50 PM, minux <minu...@gmail.com> wrote:
>
> On Feb 25, 2014 9:53 AM, "Ian Lance Taylor" <ia...@golang.org> wrote:
>> On Tue, Feb 25, 2014 at 5:53 AM, roger peppe <rogp...@gmail.com> wrote:
>> > The case that I'm always slightly concerned about is this:
>> >
>> > http://play.golang.org/p/7fnQgF_wWc
>> >
>> > It's race free, I don't know how it could work efficiently on
>> > architectures
>> > that don't support byte-sized reads and writes.
>>
>> The C++11 memory model requires that the equivalent code in C++ work
>> correctly. It follows that on architectures that do not support
>> byte-level access C++ requires that char arrays be laid out in memory
>> such that each element takes up two bytes (or whatever is required).
>> Go will have to do the same thing.
>>
>> Or to put it another way, it is essentially no longer possible to
>> create an architecture that does not offer byte-level access and is
>> programmable in standard high-level languages.
> Does the standard require CHARBITS to be 8?

No.

> i think for non-byte-addressable architectures, making CHARBITS greater than
> 8 is permitted under the standard.

Yes, but programmers find that baffling in a different way. It means
that strings take up double the space they expect.

Ian

[Dave Cheney]

> i think for non-byte-addressable architectures, making CHARBITS greater than
> 8 is permitted under the standard.

Yes, but programmers find that baffling in a different way.  It means
that strings take up double the space they expect.

*cough* Java *cough* 

[roger peppe]

On 26 February 2014 00:09, Ian Lance Taylor <ia...@golang.org> wrote:
>> i think for non-byte-addressable architectures, making CHARBITS greater than
>> 8 is permitted under the standard.
>
> Yes, but programmers find that baffling in a different way. It means
> that strings take up double the space they expect.

But also, surely the language defines that "\xff"[0]+1 == 0 ?

(and that byte is an alias for uint8).

So CHARBITS (sic) would still be 8, but unsafe address calculations
may differ.

Aside: I remember using a C compiler (for some TI DSP chip?) where
sizeof(int) == sizeof(char) == 1, and char had 32 bits.