FAQ
Could someone please explain how the code in slide19<http://talks.golang.org/2012/chat.slide#19>works with non-buffered channel.

It is clear to me how it would work with a channel of size 1. But with
non-buffered channel there seems to be a chicken-and-egg problem, neither
routine would decide which path to take until the other one decided. If
select was fully random there would be a chance that 2 routines both try to
write to channel and would need a routine which randomly picks the read
path to get unblocked.

Clearly I'm missing something either about channels or the select statement.

Here's a toy example:
http://play.golang.org/p/EB17CLO0OZ

thanks!

--

Search Discussions

  • Jesse McNelis at Oct 28, 2012 at 10:34 pm

    On Mon, Oct 29, 2012 at 7:47 AM, dr wrote:
    if select was fully random there would be a chance that 2 routines both try to
    write to channel and would need a routine which randomly picks the read path
    to get unblocked.
    Here is your answer.
    select will choose from the operations which can proceed it doesn't
    act on one until it can actually proceed. If one goroutine is writing
    then the other can't be writing too because that would block. The only
    other operation that could proceed is to receive.
    Clearly I'm missing something either about channels or the select statement.

    Here's a toy example:
    http://play.golang.org/p/EB17CLO0OZ

    thanks!

    --


    --
    =====================
    http://jessta.id.au

    --
  • Jonathan Pittman at Oct 28, 2012 at 10:39 pm
    I believe the output is as expected.

    agent 1 started...
    agent 2 started...
    agent 2 : read id 1.
    agent 1 : written it's own id.

    1. agent 1 starts
    2. agent 2 starts
    3. agent 1 gets to the select statement and select determines that comm
    does not have a value that can be received, but comm is ready to be written
    to...
    4. since the channel is non-buffered, it sits and waits at line 11
    5. agent 2 comes along and select sees that not only is comm not ready
    to be written to (because agent 1 is trying to do so), but comm has a value
    that can be received
    6. agent 2 pulls the value off the channel, and runs the fmt.Printf
    function
    7. agent 1 can now move on as well since the value it was putting on the
    channel has been pulled off the channel and so runs the fmt.Printf function

    There isn't really a chicken and egg problem. Given a choice (a.k.a.
    select statement), if a non-buffered channel has nothing on it or nothing
    being put on it, then it is ready for writing. Once a value is placed on
    the channel, the select operation that can proceed would be the
    read/receive.

    At least, that's how I understand it.
    On Sun, Oct 28, 2012 at 3:47 PM, dr wrote:

    Could someone please explain how the code in slide19<http://talks.golang.org/2012/chat.slide#19>works with non-buffered channel.

    It is clear to me how it would work with a channel of size 1. But with
    non-buffered channel there seems to be a chicken-and-egg problem, neither
    routine would decide which path to take until the other one decided. If
    select was fully random there would be a chance that 2 routines both try to
    write to channel and would need a routine which randomly picks the read
    path to get unblocked.

    Clearly I'm missing something either about channels or the select
    statement.

    Here's a toy example:
    http://play.golang.org/p/EB17CLO0OZ

    thanks!

    --

    --
  • Jonathan Pittman at Oct 28, 2012 at 10:40 pm
    What Jesse said made more sense.
    On Sun, Oct 28, 2012 at 5:39 PM, Jonathan Pittman wrote:

    I believe the output is as expected.

    agent 1 started...
    agent 2 started...
    agent 2 : read id 1.
    agent 1 : written it's own id.

    1. agent 1 starts
    2. agent 2 starts
    3. agent 1 gets to the select statement and select determines that
    comm does not have a value that can be received, but comm is ready to be
    written to...
    4. since the channel is non-buffered, it sits and waits at line 11
    5. agent 2 comes along and select sees that not only is comm not ready
    to be written to (because agent 1 is trying to do so), but comm has a value
    that can be received
    6. agent 2 pulls the value off the channel, and runs the fmt.Printf
    function
    7. agent 1 can now move on as well since the value it was putting on
    the channel has been pulled off the channel and so runs the fmt.Printf
    function

    There isn't really a chicken and egg problem. Given a choice (a.k.a.
    select statement), if a non-buffered channel has nothing on it or nothing
    being put on it, then it is ready for writing. Once a value is placed on
    the channel, the select operation that can proceed would be the
    read/receive.

    At least, that's how I understand it.
    On Sun, Oct 28, 2012 at 3:47 PM, dr wrote:

    Could someone please explain how the code in slide19<http://talks.golang.org/2012/chat.slide#19>works with non-buffered channel.

    It is clear to me how it would work with a channel of size 1. But with
    non-buffered channel there seems to be a chicken-and-egg problem, neither
    routine would decide which path to take until the other one decided. If
    select was fully random there would be a chance that 2 routines both try to
    write to channel and would need a routine which randomly picks the read
    path to get unblocked.

    Clearly I'm missing something either about channels or the select
    statement.

    Here's a toy example:
    http://play.golang.org/p/EB17CLO0OZ

    thanks!

    --

    --
  • Andrew Gerrand at Oct 29, 2012 at 4:32 am

    On 29 October 2012 07:47, dr wrote:
    Could someone please explain how the code in slide19 works with non-buffered
    channel.

    It is clear to me how it would work with a channel of size 1. But with
    non-buffered channel there seems to be a chicken-and-egg problem, neither
    routine would decide which path to take until the other one decided. If
    select was fully random there would be a chance that 2 routines both try to
    write to channel and would need a routine which randomly picks the read path
    to get unblocked.
    The scheduler chooses, not the goroutines. The scheduler knows about
    all waiting operations, and matches send operations with receive
    operations. There cannot be a send without a corresponding receive, so
    the situation you describe (where both goroutines choose to send
    simultaneously) cannot happen.

    Andrew

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 28, '12 at 9:48p
activeOct 29, '12 at 4:32a
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase