FAQ
Hi GoNuts,

I asked a question a few days ago about the intricacies of concurrency in
Go when GOMAXPROCS was set to 1.

I got some very good answers in response:
https://groups.google.com/forum/#!searchin/golang-nuts/Ralph$20/golang-nuts/kpHbzQaf6z0/FJLWHobLGU8J

To quote Lars:

No. The Go Memory Model is defined in terms of goroutines, not threads.
Unsynchronized concurrent access to shared data from multiple goroutines
is not safe as soon as one of them is a writer. The implementation is
free to make use of that.

If Go defines everything in terms of goroutine safety and not threads why
does the documentation for a Map (as an example) refer to a map as not
being "thread-safe"? Is this just inconsistency within the docs? Or is
it proper to say that a Map is not thread-safe? Here is the docs i'm
referring to: http://golang.org/doc/faq#atomic_maps and also here:

I guess I'm getting confused if these terms are interchangeable or not. If
they are not interchangeable perhaps the docs should be updated to reflect
this? I personally feel that having a distinction is important because
although it's possible to think of Goroutines as light-weight threads, to
call them threads is still wrong.

Anyone care to shed some light?

Thanks in advance,

-Ralph

P.S. Not trying to nitpick, just really trying to have an intuitive
understanding on 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

  • Dominik Honnef at Nov 8, 2013 at 9:54 pm
    You can freely substitute "thread-safe" with "goroutine-safe" in Go
    documentation, where it occurs.

    Unless documentation very explicitly refers to actual threads (such as
    the fact that using OpenGL with cgo requires pinning a goroutine to a
    specific thread), it means goroutines when it says "thread-safe".

    It might be noted that most of the documentation will avoid the term, in
    favour of "(not) safe for concurrent access". Maybe the FAQ entry should
    be updated. Especially because it refers to "access from multiple
    threads", which is quite inaccurate.

    --
    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 Nov 9, 2013 at 8:06 am

    On Nov 8, 2013 11:54 PM, "Dominik Honnef" wrote:
    You can freely substitute "thread-safe" with "goroutine-safe" in Go
    documentation, where it occurs.

    Unless documentation very explicitly refers to actual threads (such as
    the fact that using OpenGL with cgo requires pinning a goroutine to a
    specific thread), it means goroutines when it says "thread-safe".

    It might be noted that most of the documentation will avoid the term, in
    favour of "(not) safe for concurrent access". Maybe the FAQ entry should
    be updated. Especially because it refers to "access from multiple
    threads", which is quite inaccurate. +1
    --
    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.
    --
    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 Nov 9, 2013 at 8:05 am
    Goroutine-safe is not well-established term. While thread-safe is, and it
    means safe for concurrent access.

    sent from phone
    On Nov 8, 2013 11:43 PM, wrote:

    Hi GoNuts,

    I asked a question a few days ago about the intricacies of concurrency in
    Go when GOMAXPROCS was set to 1.

    I got some very good answers in response:
    https://groups.google.com/forum/#!searchin/golang-nuts/Ralph$20/golang-nuts/kpHbzQaf6z0/FJLWHobLGU8J

    To quote Lars:

    No. The Go Memory Model is defined in terms of goroutines, not threads.
    Unsynchronized concurrent access to shared data from multiple goroutines
    is not safe as soon as one of them is a writer. The implementation is
    free to make use of that.

    If Go defines everything in terms of goroutine safety and not threads why
    does the documentation for a Map (as an example) refer to a map as not
    being "thread-safe"? Is this just inconsistency within the docs? Or is
    it proper to say that a Map is not thread-safe? Here is the docs i'm
    referring to: http://golang.org/doc/faq#atomic_maps and also here:

    I guess I'm getting confused if these terms are interchangeable or not.
    If they are not interchangeable perhaps the docs should be updated to
    reflect this? I personally feel that having a distinction is important
    because although it's possible to think of Goroutines as light-weight
    threads, to call them threads is still wrong.

    Anyone care to shed some light?

    Thanks in advance,

    -Ralph

    P.S. Not trying to nitpick, just really trying to have an intuitive
    understanding on 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.
    --
    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
postedNov 8, '13 at 9:43p
activeNov 9, '13 at 8:06a
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase