goroutines, threads, and full memory barrier

[Peter Kleiweg]

I have written a package with Go bindings for ZeroMQ.

http://github.com/pebbe/zmq3

There may be a potential problem, which I haven't encountered
yet, but may exist anyway.

The thing is, a ZeroMQ socket, the main object type that is used
in most operations, is not thread safe. The FAQ says:

a socket may be shared if and only if each thread executes a
full memory barrier before accessing the socket

http://www.zeromq.org/area:faq#toc5

What is this "full memory barrier", and does Go execute it, and
at what moments?

Before switching to another goroutine?

Before switching to another thread?

Before moving a goroutine from one thread to another?

Before calling a C function?

Is there a way to force the execution of a full memory barrier?


--
Peter Kleiweg
my Go programming cookbook: http://www.let.rug.nl/~kleiweg/go/

[Ian Lance Taylor]

On Wed, May 29, 2013 at 1:31 PM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>
> I have written a package with Go bindings for ZeroMQ.
>
> http://github.com/pebbe/zmq3
>
> There may be a potential problem, which I haven't encountered
> yet, but may exist anyway.
>
> The thing is, a ZeroMQ socket, the main object type that is used
> in most operations, is not thread safe. The FAQ says:
>
> a socket may be shared if and only if each thread executes a
> full memory barrier before accessing the socket
>
> http://www.zeromq.org/area:faq#toc5
>
> What is this "full memory barrier", and does Go execute it, and
> at what moments?

The Go memory model is at http://golang.org/ref/mem . I think it is
safe to assume that whenever two different goroutines are connected by
a happens-before event, e.g., a send/receive on an unbuffered channel,
both goroutines execute a full memory barrier.

Ian

[Maxim Khitrov]

I think you're right, but there was some disagreement about that in
the "Friday coding challenge" discussion:

http://groups.google.com/d/msg/golang-nuts/H5EekTspSVg/V-lwCiw0HKcJ

[Ian Lance Taylor]

I think that is technically correct. It's a happens-before
relationship, so it could be a release and an acquire barrier rather
than a full memory barrier. Nevertheless I think "it is safe to
assume...."

Ian

[Dmitry Vyukov]

On Thu, May 30, 2013 at 12:31 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:

I have written a package with Go bindings for ZeroMQ.

    http://github.com/pebbe/zmq3

There may be a potential problem, which I haven't encountered
yet, but may exist anyway.

The thing is, a ZeroMQ socket, the main object type that is used
in most operations, is not thread safe. The FAQ says:

    a socket may be shared if and only if each thread executes a
    full memory barrier before accessing the socket

    http://www.zeromq.org/area:faq#toc5

What is this "full memory barrier", and does Go execute it, and
at what moments?

http://en.wikipedia.org/wiki/Memory_barrier

 

Before switching to another goroutine?

No

 

Before switching to another thread?

What is this?

 

Before moving a goroutine from one thread to another?

Yes

 

Before calling a C function?

No

 

Is there a way to force the execution of a full memory barrier?

Yes, by synchronizing goroutines with channels and mutexes.

It is also safe to access the socket from a single goroutine (even if it moves from thread to thread).