FAQ
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/

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

Search Discussions

  • Ian Lance Taylor at May 29, 2013 at 8:43 pm

    On Wed, May 29, 2013 at 1:31 PM, Peter Kleiweg 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Maxim Khitrov at May 29, 2013 at 8:50 pm

    On Wed, May 29, 2013 at 4:43 PM, Ian Lance Taylor wrote:
    On Wed, May 29, 2013 at 1:31 PM, Peter Kleiweg 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.
    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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at May 29, 2013 at 8:57 pm

    On Wed, May 29, 2013 at 1:49 PM, Maxim Khitrov wrote:
    On Wed, May 29, 2013 at 4:43 PM, Ian Lance Taylor wrote:
    On Wed, May 29, 2013 at 1:31 PM, Peter Kleiweg 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.
    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
    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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dgrijalva at May 29, 2013 at 8:48 pm
    I'll bet you can get away with just always accessing the socket from the
    same goroutine. That FAQ uses lots of words, but I'm pretty sure they just
    mean to use a mutex around accessing your socket.
    On Wednesday, May 29, 2013 1:31:17 PM UTC-7, Peter Kleiweg 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?

    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/
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at May 30, 2013 at 4:30 am

    On Thu, May 30, 2013 at 12:31 AM, Peter Kleiweg 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).

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 29, '13 at 8:31p
activeMay 30, '13 at 4:30a
posts6
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase