FAQ
This has come up before:

Should send/receive operations on channels be protected by a lock?

I couldn't find an answer to this question in the doc.

From the semantics of send, it is clear that sends should not be allowed
to race with closes.

From tutorials and common sense, it is pretty clear that sends and receives
can race. Although, interestingly, this is also not mentioned anywhere in
the doc
(as far as I could tell).


Can receives race? Yes, according to how it's used in the Go sources.
But, again, I didn't find it in the doc.

Can sends race? I don't know :)

P

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

  • Dmitry Vyukov at Jul 16, 2013 at 8:26 pm

    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and receives
    can race. Although, interestingly, this is also not mentioned anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Humm... do you need to protect concurrent mutex.lock/unlock with a mutex?..

    --
    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 Jul 16, 2013 at 8:27 pm

    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and receives
    can race. Although, interestingly, this is also not mentioned anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.

    --
    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.
  • Petar Maymounkov at Jul 17, 2013 at 10:24 pm
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and receives
    can race. Although, interestingly, this is also not mentioned anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.
  • Kyle Lemons at Jul 17, 2013 at 10:30 pm

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov wrote:

    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
      The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned anywhere
    in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.
  • Henrik Johansson at Jul 17, 2013 at 10:34 pm
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:
    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov wrote:

    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.

    --
    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.
  • Kyle Lemons at Jul 17, 2013 at 10:43 pm
    What do you mean the same channel instance?

    On Wed, Jul 17, 2013 at 3:34 PM, Henrik Johansson wrote:

    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:
    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov wrote:

    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.

    --
    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.
  • Henrik Johansson at Jul 17, 2013 at 10:47 pm
    I could get it wrong but i thought he meant sending on the same shared
    channel concurrently from different goroutines.
    On Jul 18, 2013 12:43 AM, "Kyle Lemons" wrote:

    What do you mean the same channel instance?

    On Wed, Jul 17, 2013 at 3:34 PM, Henrik Johansson wrote:

    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:
    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov wrote:

    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go
    sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.

    --
    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.
  • Kyle Lemons at Jul 17, 2013 at 11:05 pm
    That's what channels are for.

    On Wed, Jul 17, 2013 at 3:47 PM, Henrik Johansson wrote:

    I could get it wrong but i thought he meant sending on the same shared
    channel concurrently from different goroutines.
    On Jul 18, 2013 12:43 AM, "Kyle Lemons" wrote:

    What do you mean the same channel instance?

    On Wed, Jul 17, 2013 at 3:34 PM, Henrik Johansson wrote:

    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:
    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov wrote:

    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're
    not closing, what's the race? Channels don't require coordination on sends
    or coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <
    petarm@gmail.com> wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go
    sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.

    --
    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.
  • Henrik Johansson at Jul 17, 2013 at 11:07 pm
    If that was indeed Petars last consideration then its answered i guess.

    On Thu, Jul 18, 2013 at 1:05 AM, Kyle Lemons wrote:

    That's what channels are for.

    On Wed, Jul 17, 2013 at 3:47 PM, Henrik Johansson wrote:

    I could get it wrong but i thought he meant sending on the same shared
    channel concurrently from different goroutines.
    On Jul 18, 2013 12:43 AM, "Kyle Lemons" wrote:

    What do you mean the same channel instance?

    On Wed, Jul 17, 2013 at 3:34 PM, Henrik Johansson wrote:

    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:
    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov wrote:

    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're
    not closing, what's the race? Channels don't require coordination on sends
    or coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <
    petarm@gmail.com> wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends
    and receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go
    sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.

    --
    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 Jul 18, 2013 at 6:31 am

    On Thu, Jul 18, 2013 at 3:05 AM, Kyle Lemons wrote:
    That's what channels are for.
    Is it stated somewhere explicitly?

    On Wed, Jul 17, 2013 at 3:47 PM, Henrik Johansson wrote:

    I could get it wrong but i thought he meant sending on the same shared
    channel concurrently from different goroutines.
    On Jul 18, 2013 12:43 AM, "Kyle Lemons" wrote:

    What do you mean the same channel instance?


    On Wed, Jul 17, 2013 at 3:34 PM, Henrik Johansson <dahankzter@gmail.com>
    wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're
    not closing, what's the race? Channels don't require coordination on sends
    or coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go
    sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any
    separate
    protection.
    --
    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.
    --
    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.
  • Atomly at Jul 18, 2013 at 10:36 pm
    http://www.golang-book.com/10

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...

    On Thu, Jul 18, 2013 at 2:30 AM, Dmitry Vyukov wrote:
    On Thu, Jul 18, 2013 at 3:05 AM, Kyle Lemons wrote:
    That's what channels are for.
    Is it stated somewhere explicitly?

    On Wed, Jul 17, 2013 at 3:47 PM, Henrik Johansson <dahankzter@gmail.com>
    wrote:
    I could get it wrong but i thought he meant sending on the same shared
    channel concurrently from different goroutines.
    On Jul 18, 2013 12:43 AM, "Kyle Lemons" wrote:

    What do you mean the same channel instance?


    On Wed, Jul 17, 2013 at 3:34 PM, Henrik Johansson <
    dahankzter@gmail.com>
    wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the
    channel.
    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're
    not closing, what's the race? Channels don't require coordination
    on sends
    or coordination on receives. Any number of senders can be active
    and any
    number of receivers can be active, completely uncoordinated. In
    fact,
    channels are one primitive that you use in order to achieve
    coordination.
    The primary time you require coordination on top of a channel is
    when you
    want to close a channel; you are making a promise that no more
    values will
    be sent, and so you need to ensure that no more values will be sent
    before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <
    dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a
    lock?
    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends
    and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go
    sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close.
    But
    these are bugs anyway. Correct usages of chans do no need any
    separate
    protection.
    --
    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.
    --
    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.
  • Petar Maymounkov at Jul 18, 2013 at 10:52 am
    What I am asking is extremely elementary and it's probably confusing
    how simple my question is:

    I just meant, is this allowed:

    ch := make(chan int)

    for i := 0; i < 10; i++ {
         go func() {
             ch <- 1
         }()
    }

    This is "obviously" what channels should be able to do as they are
    "for synchronization"
    so you shouldn't have to protect the <- operation with a sync.Mutex.

    The reason I asked the question is somewhat inane:

    I never found this mentioned in the doc explicitly. As Jesse points out, this is
    addressed in the "Go Memory model", in the sentence:

    "Channel communication is the main method of synchronization between goroutines"

    However, my confusion arises from what Dmitry filed as an issue,
    namely that it is assumed in the godoc that if not stated otherwise,
    all primitive types are not safe to access concurrently. But this is
    not the case with channels and this is not
    stated explicitly enough, even though common sense thinking (combined with some
    common sense *assumptions*) would imply that. It seems best to state it clearly.

    P
    On 17 July 2013 18:34, Henrik Johansson wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.
    --
    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.
  • Petar Maymounkov at Jul 18, 2013 at 10:54 am
    To clarify: The issue that Dmitry filed is not confusing. The issue
    captures my reason
    for asking the question.
    On 18 July 2013 06:52, Petar Maymounkov wrote:
    What I am asking is extremely elementary and it's probably confusing
    how simple my question is:

    I just meant, is this allowed:

    ch := make(chan int)

    for i := 0; i < 10; i++ {
    go func() {
    ch <- 1
    }()
    }

    This is "obviously" what channels should be able to do as they are
    "for synchronization"
    so you shouldn't have to protect the <- operation with a sync.Mutex.

    The reason I asked the question is somewhat inane:

    I never found this mentioned in the doc explicitly. As Jesse points out, this is
    addressed in the "Go Memory model", in the sentence:

    "Channel communication is the main method of synchronization between goroutines"

    However, my confusion arises from what Dmitry filed as an issue,
    namely that it is assumed in the godoc that if not stated otherwise,
    all primitive types are not safe to access concurrently. But this is
    not the case with channels and this is not
    stated explicitly enough, even though common sense thinking (combined with some
    common sense *assumptions*) would imply that. It seems best to state it clearly.

    P
    On 17 July 2013 18:34, Henrik Johansson wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.
    --
    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 Jul 18, 2013 at 10:56 am

    On Thu, Jul 18, 2013 at 2:52 PM, Petar Maymounkov wrote:
    What I am asking is extremely elementary and it's probably confusing
    how simple my question is:

    I just meant, is this allowed:

    ch := make(chan int)

    for i := 0; i < 10; i++ {
    go func() {
    ch <- 1
    }()
    }

    This is "obviously" what channels should be able to do as they are
    "for synchronization"
    so you shouldn't have to protect the <- operation with a sync.Mutex.

    The reason I asked the question is somewhat inane:

    I never found this mentioned in the doc explicitly. As Jesse points out, this is
    addressed in the "Go Memory model", in the sentence:

    "Channel communication is the main method of synchronization between goroutines"
    This is still not enough.
    Is is a single-producer/single-consumer queue?
    Or maybe it is the main method of synchronization, but must be used
    with other synchronization primitives (just as goroutines are the
    method to achieve parallelism, but you can not do anything useful w/o
    chans).
    And what are guarantees for close() or len()?


    However, my confusion arises from what Dmitry filed as an issue,
    namely that it is assumed in the godoc that if not stated otherwise,
    all primitive types are not safe to access concurrently. But this is
    not the case with channels and this is not
    stated explicitly enough, even though common sense thinking (combined with some
    common sense *assumptions*) would imply that. It seems best to state it clearly.

    P
    On 17 July 2013 18:34, Henrik Johansson wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.
    --
    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.
  • Petar Maymounkov at Jul 18, 2013 at 10:01 pm
    Dmitry, are you asking me in this last response? I am a little confused.
    On 18 July 2013 06:56, Dmitry Vyukov wrote:
    On Thu, Jul 18, 2013 at 2:52 PM, Petar Maymounkov wrote:
    What I am asking is extremely elementary and it's probably confusing
    how simple my question is:

    I just meant, is this allowed:

    ch := make(chan int)

    for i := 0; i < 10; i++ {
    go func() {
    ch <- 1
    }()
    }

    This is "obviously" what channels should be able to do as they are
    "for synchronization"
    so you shouldn't have to protect the <- operation with a sync.Mutex.

    The reason I asked the question is somewhat inane:

    I never found this mentioned in the doc explicitly. As Jesse points out, this is
    addressed in the "Go Memory model", in the sentence:

    "Channel communication is the main method of synchronization between goroutines"
    This is still not enough.
    Is is a single-producer/single-consumer queue?
    Or maybe it is the main method of synchronization, but must be used
    with other synchronization primitives (just as goroutines are the
    method to achieve parallelism, but you can not do anything useful w/o
    chans).
    And what are guarantees for close() or len()?


    However, my confusion arises from what Dmitry filed as an issue,
    namely that it is assumed in the godoc that if not stated otherwise,
    all primitive types are not safe to access concurrently. But this is
    not the case with channels and this is not
    stated explicitly enough, even though common sense thinking (combined with some
    common sense *assumptions*) would imply that. It seems best to state it clearly.

    P
    On 17 July 2013 18:34, Henrik Johansson wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.
    --
    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.
  • Petar Maymounkov at Jul 18, 2013 at 10:02 pm
    My question was just this:

    Can two goroutine independently (without synchronization) send to the
    same channel.

    The answer is yes, and this is not made very clear in the doc. I think
    this is the whole story.
    On 18 July 2013 18:01, Petar Maymounkov wrote:
    Dmitry, are you asking me in this last response? I am a little confused.
    On 18 July 2013 06:56, Dmitry Vyukov wrote:
    On Thu, Jul 18, 2013 at 2:52 PM, Petar Maymounkov wrote:
    What I am asking is extremely elementary and it's probably confusing
    how simple my question is:

    I just meant, is this allowed:

    ch := make(chan int)

    for i := 0; i < 10; i++ {
    go func() {
    ch <- 1
    }()
    }

    This is "obviously" what channels should be able to do as they are
    "for synchronization"
    so you shouldn't have to protect the <- operation with a sync.Mutex.

    The reason I asked the question is somewhat inane:

    I never found this mentioned in the doc explicitly. As Jesse points out, this is
    addressed in the "Go Memory model", in the sentence:

    "Channel communication is the main method of synchronization between goroutines"
    This is still not enough.
    Is is a single-producer/single-consumer queue?
    Or maybe it is the main method of synchronization, but must be used
    with other synchronization primitives (just as goroutines are the
    method to achieve parallelism, but you can not do anything useful w/o
    chans).
    And what are guarantees for close() or len()?


    However, my confusion arises from what Dmitry filed as an issue,
    namely that it is assumed in the godoc that if not stated otherwise,
    all primitive types are not safe to access concurrently. But this is
    not the case with channels and this is not
    stated explicitly enough, even though common sense thinking (combined with some
    common sense *assumptions*) would imply that. It seems best to state it clearly.

    P
    On 17 July 2013 18:34, Henrik Johansson wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the channel.

    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're not
    closing, what's the race? Channels don't require coordination on sends or
    coordination on receives. Any number of senders can be active and any
    number of receivers can be active, completely uncoordinated. In fact,
    channels are one primitive that you use in order to achieve coordination.
    The primary time you require coordination on top of a channel is when you
    want to close a channel; you are making a promise that no more values will
    be sent, and so you need to ensure that no more values will be sent before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close. But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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.
    --
    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.
  • David DENG at Jul 18, 2013 at 10:45 pm
    As a basic element for concurrency in Go, channel is designed to be
    thread-safe for all actions.

    David
    On Friday, July 19, 2013 6:02:40 AM UTC+8, Petar Maymounkov wrote:

    My question was just this:

    Can two goroutine independently (without synchronization) send to the
    same channel.

    The answer is yes, and this is not made very clear in the doc. I think
    this is the whole story.

    On 18 July 2013 18:01, Petar Maymounkov <pet...@gmail.com <javascript:>>
    wrote:
    Dmitry, are you asking me in this last response? I am a little confused.

    On 18 July 2013 06:56, Dmitry Vyukov <dvy...@google.com <javascript:>>
    wrote:
    On Thu, Jul 18, 2013 at 2:52 PM, Petar Maymounkov wrote:
    What I am asking is extremely elementary and it's probably confusing
    how simple my question is:

    I just meant, is this allowed:

    ch := make(chan int)

    for i := 0; i < 10; i++ {
    go func() {
    ch <- 1
    }()
    }

    This is "obviously" what channels should be able to do as they are
    "for synchronization"
    so you shouldn't have to protect the <- operation with a sync.Mutex.

    The reason I asked the question is somewhat inane:

    I never found this mentioned in the doc explicitly. As Jesse points
    out, this is
    addressed in the "Go Memory model", in the sentence:

    "Channel communication is the main method of synchronization between
    goroutines"
    This is still not enough.
    Is is a single-producer/single-consumer queue?
    Or maybe it is the main method of synchronization, but must be used
    with other synchronization primitives (just as goroutines are the
    method to achieve parallelism, but you can not do anything useful w/o
    chans).
    And what are guarantees for close() or len()?


    However, my confusion arises from what Dmitry filed as an issue,
    namely that it is assumed in the godoc that if not stated otherwise,
    all primitive types are not safe to access concurrently. But this is
    not the case with channels and this is not
    stated explicitly enough, even though common sense thinking (combined
    with some
    common sense *assumptions*) would imply that. It seems best to state
    it clearly.
    P
    On 17 July 2013 18:34, Henrik Johansson wrote:
    I think he means concurrent sends on the same channel instance?
    On Jul 18, 2013 12:30 AM, "Kyle Lemons" wrote:

    On Wed, Jul 17, 2013 at 3:24 PM, Petar Maymounkov <pet...@gmail.com<javascript:>>
    wrote:
    Got it. Thanks.

    The question was motivated by the following considerations.

    You can imagine a design where a channel is never closed, and
    you'd like to have multiple uncoordinated agents send to the
    channel.
    So this highlights the question where racing sends are allowed.

    While I agree with you that a sensical usage will never have a send
    race with a close, having just sends race with each other seems
    like
    a valid/correct use of channels. But I needed to confirm that it is
    in fact allowed.

    I'm even more confused than I was with the original post. If you're
    not
    closing, what's the race? Channels don't require coordination on
    sends or
    coordination on receives. Any number of senders can be active and
    any
    number of receivers can be active, completely uncoordinated. In
    fact,
    channels are one primitive that you use in order to achieve
    coordination.
    The primary time you require coordination on top of a channel is
    when you
    want to close a channel; you are making a promise that no more
    values will
    be sent, and so you need to ensure that no more values will be sent
    before
    making that promise.
    On 16 July 2013 16:27, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov <
    dvy...@google.com <javascript:>>
    wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov <
    pet...@gmail.com <javascript:>>
    wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a
    lock?
    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not
    be
    allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends
    and
    receives
    can race. Although, interestingly, this is also not mentioned
    anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go
    sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close.
    But
    these are bugs anyway. Correct usages of chans do no need any
    separate
    protection.
    --
    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 <javascript:>.
    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...@googlegroups.com <javascript:>.
    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 Jul 18, 2013 at 6:32 am

    On Wed, Jul 17, 2013 at 12:27 AM, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:26 AM, Dmitry Vyukov wrote:
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and receives
    can race. Although, interestingly, this is also not mentioned anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    Sends and receives do not race with each other.

    A send can race with close, a close can race with another close.
    To make it clear, this is not a low-level race like a race on hashmap,
    it can *not* lead to memory corruption, etc.
    It is a high-level race that can lead to non-deterministic panic.

    But
    these are bugs anyway. Correct usages of chans do no need any separate
    protection.
    --
    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 Jul 18, 2013 at 8:33 am
    Filed https://code.google.com/p/go/issues/detail?id=5911
    On Wed, Jul 17, 2013 at 12:10 AM, Petar Maymounkov wrote:
    This has come up before:

    Should send/receive operations on channels be protected by a lock?

    I couldn't find an answer to this question in the doc.

    From the semantics of send, it is clear that sends should not be allowed
    to race with closes.

    From tutorials and common sense, it is pretty clear that sends and receives
    can race. Although, interestingly, this is also not mentioned anywhere in
    the doc
    (as far as I could tell).


    Can receives race? Yes, according to how it's used in the Go sources.
    But, again, I didn't find it in the doc.

    Can sends race? I don't know :)

    P

    --
    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
postedJul 16, '13 at 8:10p
activeJul 18, '13 at 10:45p
posts20
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase