FAQ
Hello GoNuts,

This is more of a theoretical question:

I read and re-read through Rob Pike's 2012 talk on concurrency patterns. One statement that struck me was that he said: "Buffering removes synchronization"

So, I haven't used buffered channels much but in wondering if this statement means what I think it does.

Suppose I build an app that is concurrent and technically sound or correct from racy conditions an implemented using non-buffered channels only. Let's assume the app is written for true correctness in the sense of proper communication and synchronization.

Now let's say I go into my app and tweak some channels to be buffered for the sake of performance or whatever reason. If buffering removes synchronization does this not mean my program may not be technically correct anymore? Because I can no longer guarantee that certain areas of code are ruining in synchronization?

If guess if this true then does that mean buffered channels are dangerous? I thought they were still synchronized but what changed was that they allow u to send asynchronously? In this scenario, a message going into a channel is queued into the buffer, requiring more memory but at least the receiver will still block waiting for a message? Is my understanding of this correct?

Anybody want to take a stab?

I appreciate the answers as usual and am having more fun with this language than any language before.

-Ralph Caraveo


--
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 Nov 29, 2013 at 7:39 pm

    On Fri, Nov 29, 2013 at 9:28 AM, wrote:
    This is more of a theoretical question:

    I read and re-read through Rob Pike's 2012 talk on concurrency patterns. One statement that struck me was that he said: "Buffering removes synchronization"

    So, I haven't used buffered channels much but in wondering if this statement means what I think it does.

    Suppose I build an app that is concurrent and technically sound or correct from racy conditions an implemented using non-buffered channels only. Let's assume the app is written for true correctness in the sense of proper communication and synchronization.

    Now let's say I go into my app and tweak some channels to be buffered for the sake of performance or whatever reason. If buffering removes synchronization does this not mean my program may not be technically correct anymore? Because I can no longer guarantee that certain areas of code are ruining in synchronization?
    Yes, it is possible to write a program that is correct when using
    unbuffered channels but is incorrect when using buffered channels.

    If guess if this true then does that mean buffered channels are dangerous?
    I'm not sure that follows. You do have to understand when it is
    appropriate to use buffered channels. For better or for worse, Go
    does permit race conditions, so in that sense Go is dangerous in
    general. You have to be aware of that possibility, and you have to be
    aware of how you can use channels, whether buffered or not, to avoid
    them.

    I thought they were still synchronized but what changed was that they allow u to send asynchronously? In this scenario, a message going into a channel is queued into the buffer, requiring more memory but at least the receiver will still block waiting for a message? Is my understanding of this correct?
    I'm not sure exactly what you are asking. It is true that if a
    goroutine tries to receive a value from a channel, and no values have
    been sent to the channel, that the goroutine will block until some
    value has been sent.

    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.
  • Deckarep at Nov 30, 2013 at 12:33 am
    Thank you Ian,

    I think i've fallen into the trap of thinking that just because one may use
    channels (buffered or not) for sharing data there still is no guarantee
    that you aren't writing racy code.

    I need to continue to ponder these scenarios and practice. Some of the
    material I've read about buffered channels just simply mentions that
    channels can be buffered....but
    obviously like you said I need to better understand in what cases I would
    want buffered/non-buffered channels.

    P.s. my last question wasn't very clear but you did answer it...i just
    wanted to confirm the behavior.

    -Ralph

    On Friday, November 29, 2013 11:39:47 AM UTC-8, Ian Lance Taylor wrote:

    On Fri, Nov 29, 2013 at 9:28 AM, <deck...@gmail.com <javascript:>>
    wrote:
    This is more of a theoretical question:

    I read and re-read through Rob Pike's 2012 talk on concurrency patterns.
    One statement that struck me was that he said: "Buffering removes
    synchronization"
    So, I haven't used buffered channels much but in wondering if this
    statement means what I think it does.
    Suppose I build an app that is concurrent and technically sound or
    correct from racy conditions an implemented using non-buffered channels
    only. Let's assume the app is written for true correctness in the sense of
    proper communication and synchronization.
    Now let's say I go into my app and tweak some channels to be buffered
    for the sake of performance or whatever reason. If buffering removes
    synchronization does this not mean my program may not be technically
    correct anymore? Because I can no longer guarantee that certain areas of
    code are ruining in synchronization?

    Yes, it is possible to write a program that is correct when using
    unbuffered channels but is incorrect when using buffered channels.

    If guess if this true then does that mean buffered channels are
    dangerous?

    I'm not sure that follows. You do have to understand when it is
    appropriate to use buffered channels. For better or for worse, Go
    does permit race conditions, so in that sense Go is dangerous in
    general. You have to be aware of that possibility, and you have to be
    aware of how you can use channels, whether buffered or not, to avoid
    them.

    I thought they were still synchronized but what changed was that they
    allow u to send asynchronously? In this scenario, a message going into a
    channel is queued into the buffer, requiring more memory but at least the
    receiver will still block waiting for a message? Is my understanding of
    this correct?

    I'm not sure exactly what you are asking. It is true that if a
    goroutine tries to receive a value from a channel, and no values have
    been sent to the channel, that the goroutine will block until some
    value has been sent.

    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.
  • John Nagle at Dec 3, 2013 at 2:46 am

    On 11/29/2013 11:39 AM, Ian Lance Taylor wrote:
    On Fri, Nov 29, 2013 at 9:28 AM, wrote:

    This is more of a theoretical question:

    I read and re-read through Rob Pike's 2012 talk on concurrency patterns. One statement that struck me was that he said: "Buffering removes synchronization"
        Another way to say this is "buffering allows concurrency".
    Unbuffered channels, for the main use cases, make goroutines
    behave like coroutines - sender and receiver goroutines take
    turns executing, but don't execute simultaneously.

        John Nagle

    --
    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.
  • Rob Pike at Dec 3, 2013 at 3:25 am
    The right way to think of it is that unbuffered channels synchronize
    the two sides. Buffered channels do not. That's why I meant by
    "buffering removes synchronization".

    If the code depends on that synchronization, buffering the channels
    will break the code. If it does not, buffering enables parallelism
    (it's already concurrent by some definitions) if there are multiple
    CPUs.

    -rob

    On Mon, Dec 2, 2013 at 6:45 PM, John Nagle wrote:
    On 11/29/2013 11:39 AM, Ian Lance Taylor wrote:
    On Fri, Nov 29, 2013 at 9:28 AM, wrote:

    This is more of a theoretical question:

    I read and re-read through Rob Pike's 2012 talk on concurrency patterns. One statement that struck me was that he said: "Buffering removes synchronization"
    Another way to say this is "buffering allows concurrency".
    Unbuffered channels, for the main use cases, make goroutines
    behave like coroutines - sender and receiver goroutines take
    turns executing, but don't execute simultaneously.

    John Nagle

    --
    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.
  • Andrew Francis at Dec 3, 2013 at 9:50 pm
    Hi:

    From previous experience, I found that poorly written programmes with
    unbuffered channels caused deadlock (as opposed to race conditions which I
    think the original poster mentioned). Changing to buffered, papered over
    the problem.

    Cheers,
    Andrew

    P.S - Maybe this is slightly off topic but I recall John Reppy in
    "Concurrent ML" using deadlock avoidance as an argument for buffered
    synchronous channels.....

    On Monday, December 2, 2013 10:24:46 PM UTC-5, Rob Pike wrote:


    If the code depends on that synchronization, buffering the channels
    will break the code. If it does not, buffering enables parallelism
    (it's already concurrent by some definitions) if there are multiple
    CPUs.

    -rob

    On Mon, Dec 2, 2013 at 6:45 PM, John Nagle wrote:
    On 11/29/2013 11:39 AM, Ian Lance Taylor wrote:
    On Fri, Nov 29, 2013 at 9:28 AM, <deck...@gmail.com <javascript:>>
    wrote:
    This is more of a theoretical question:

    I read and re-read through Rob Pike's 2012 talk on concurrency
    patterns. One statement that struck me was that he said: "Buffering
    removes synchronization"
    Another way to say this is "buffering allows concurrency".
    Unbuffered channels, for the main use cases, make goroutines
    behave like coroutines - sender and receiver goroutines take
    turns executing, but don't execute simultaneously.

    John Nagle

    --
    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.
  • Lars Seipel at Dec 3, 2013 at 11:49 pm

    On Tue, Dec 03, 2013 at 01:23:30PM -0800, Andrew Francis wrote:
    From previous experience, I found that poorly written programmes with
    unbuffered channels caused deadlock (as opposed to race conditions which I
    think the original poster mentioned). Changing to buffered, papered over
    the problem.
    Yes, it's true the other way around, too: you can't just switch a
    buffered channel to an unbuffered one in general and expect the
    resulting program to still work.

    That program doesn't have to be poorly written, though. If your
    algorithm depends on the channel being buffered for a certain number of
    send operations then that's just the way it is. There's nothing
    inherently wrong about it.

    Lars

    --
    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 Dec 3, 2013 at 6:54 am

    On Tue, Dec 3, 2013 at 6:45 AM, John Nagle wrote:
    On 11/29/2013 11:39 AM, Ian Lance Taylor wrote:
    On Fri, Nov 29, 2013 at 9:28 AM, wrote:

    This is more of a theoretical question:

    I read and re-read through Rob Pike's 2012 talk on concurrency patterns. One statement that struck me was that he said: "Buffering removes synchronization"
    Another way to say this is "buffering allows concurrency".
    Unbuffered channels, for the main use cases, make goroutines
    behave like coroutines - sender and receiver goroutines take
    turns executing, but don't execute simultaneously.
    This is not true. Both goroutines execute concurrently between chan operations.

    --
    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.
  • Felix Zilla at Dec 3, 2013 at 7:57 am

    according to Rob's 2012 IO talk, he said buffered chan is like erlang
    mailbox, and in erlang you drop a message in a mailbox and you don't wait
    for it to be read, so with this in Go with buffered and unbuffered chan it
    means unbuffered chan(the goroutine with this chan) wait for the chan to be
    read from the other end and buffered chan will not wait for the chan to be
    read, buffered chan will keep adding to the chan(ie the goroutine will
    continue it's execution) until the buffer is full and it will wait to.
    --
    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 29, '13 at 5:29p
activeDec 3, '13 at 11:49p
posts9
users8
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase