<p>Learning go by gobyexample.com and im' confused what's the point of channels. When you use it? and why? </p>
<hr/>**评论：**<br/><br/>mwholt: <pre><p>Channels are primarily valuable synchronization primitives. See <a href="https://golang.org/doc/effective_go.html#channels" rel="nofollow">https://golang.org/doc/effective_go.html#channels</a> and <a href="https://tour.golang.org/concurrency/2" rel="nofollow">https://tour.golang.org/concurrency/2</a></p>
<p>(in other words, they coordinate work and timing of goroutines)</p></pre>Franke123: <pre><p>They're awesome for coordinating concurrency, like this: <a href="https://play.golang.org/p/TFxkEK6PG_" rel="nofollow">https://play.golang.org/p/TFxkEK6PG_</a></p></pre>likcoras: <pre><p>They're useful for passing values between goroutines, something that might need mutexes in other languages to do safely.</p>
<p>Here's a useful talk by Rob Pike about concurrency in go, he covers channels as well: <a href="https://youtu.be/f6kdp27TYZs" rel="nofollow">Go Concurrency Patterns</a>. He talks about channels around <a href="https://youtu.be/f6kdp27TYZs?t=617" rel="nofollow">10:17</a>.</p></pre>video_descriptionbot: <pre><table><thead>
<tr>
<th align="left">SECTION</th>
<th align="left">CONTENT</th>
</tr>
</thead><tbody>
<tr>
<td align="left">Title</td>
<td align="left">Google I/O 2012 - Go Concurrency Patterns</td>
</tr>
<tr>
<td align="left">Description</td>
<td align="left">Rob Pike Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code. For all I/O 2012 sessions, go to <a href="https://developers.google.com/io/" rel="nofollow">https://developers.google.com/io/</a></td>
</tr>
<tr>
<td align="left">Length</td>
<td align="left">0:51:27</td>
</tr>
</tbody></table>
<table><thead>
<tr>
<th align="left">SECTION</th>
<th align="left">CONTENT</th>
</tr>
</thead><tbody>
<tr>
<td align="left">Title</td>
<td align="left">Google I/O 2012 - Go Concurrency Patterns</td>
</tr>
<tr>
<td align="left">Description</td>
<td align="left">Rob Pike Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code. For all I/O 2012 sessions, go to <a href="https://developers.google.com/io/" rel="nofollow">https://developers.google.com/io/</a></td>
</tr>
<tr>
<td align="left">Length</td>
<td align="left">0:51:27</td>
</tr>
</tbody></table>
<hr/>
<p><sup>I am a bot, this is an auto-generated reply | </sup><sup><a href="https://www.reddit.com/u/video_descriptionbot" rel="nofollow">Info</a></sup> <sup>|</sup> <sup><a href="https://www.reddit.com/message/compose/?to=video_descriptionbot&subject=Feedback" rel="nofollow">Feedback</a></sup> <sup>|</sup> <sup>Reply STOP to opt out permanently</sup></p></pre>Yojihito: <pre><p>Channels are just syntax sugar for mutexes, they use mutexes under the hood and are slower than a simple mtx.Lock() mtx.Unlock().</p></pre>cdoxsey: <pre><p>They are not syntactic sugar. Channels let you use select. You can't do that with mutexes.</p></pre>Yojihito: <pre><blockquote>
<p>passing values between goroutines, something that might need mutexes in other languages to do safely.</p>
</blockquote>
<p>I meant this.</p></pre>Sythe2o0: <pre><p>On top of the select statement which is very useful, channels can be buffered to only act as a mutex in some scenarios. They are slower than mutexes but they offer more utility.</p></pre>Yojihito: <pre><p>Does a buffered channel not use mutexes if he's not full?</p></pre>stone_henge: <pre><p>Buffering means that in scenarios where the consumer is sometimes much slower than the producer in the short term, the producer needn't wait for the consumer to accept the value to continue. Instead, it continues queuing the data in the buffer, and the consumer gets to it when whatever condition is slowing it down disappears.</p>
<p>You can of course implement this using mutexes and some sort of queue/buffer, but the point is that channels already solve that (very common) problem, and that the solution is less trivial than "syntax sugar"</p></pre>Yojihito: <pre><p>The buffer is not flexible, that's a big disadvantage for my use case.</p></pre>stone_henge: <pre><p>Then I agree that rolling your own queue using a growable and shrinkable array and mutexes might be a good option.</p>
<p>Personally I like the definite bounds and I think that a good, performant growing/shrinking strategy is a very hard problem, even impossible for the general case. Especially knowing when to shrink is very dependent on traffic patterns.</p></pre>faiface: <pre><p>Yeah, channels are a 731 lines of code (<a href="https://golang.org/src/runtime/chan.go" rel="nofollow">https://golang.org/src/runtime/chan.go</a>) syntactic sugar for mutexes. Also, Go is a syntactic sugar for machine instructions and it's slower than typing the machine instructions manually.</p></pre>stone_henge: <pre><p>Channels are used for a very common scenario where you not only need to guarantee that only one thread writes to or reads from a resource at once, but a producer-consumer relationship where the producer can produce without knowing anything about the state of the consumer. If all you need is a mutex, by all means use that, but if you need a synchronized FIFO queue or a guarantee that you aren't overwriting a value before the consumer has a chance to touch it, channels are a good general implementation.</p></pre>Yojihito: <pre><blockquote>
<p>where the producer can produce without knowing anything about the state of the consumer</p>
</blockquote>
<p>But it's a full stop-the-world for the producer if the buffer is full, unfortunately there does not exist a flexible buffer for channels.</p></pre>dmikalova: <pre><p>"Don't communicate by sharing memory, share memory by communicating."</p>
<p>Channels let you control when two or more pieces of code run in relation to each other. For example in an unbuffered channel the sender is blocked until a receiver picks up the message, and a receiver is blocked until a sender sends a message.</p></pre>
