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/EB17CLO0OZthanks!
--
--