<p>Here is a code snippet from the <a href="https://tour.golang.org/concurrency/2" rel="nofollow">official tutorial</a></p>
<pre><code>package main
import "fmt"
func sum(s []int, c chan int) {
sum := 0
for _, v := range s {
sum += v
}
c <- sum // send sum to c
}
func main() {
s := []int{7, 2, 8, -9, 4, 0}
c := make(chan int)
go sum(s[:len(s)/2], c)
go sum(s[len(s)/2:], c)
x, y := <-c, <-c // receive from c
fmt.Println(x, y, x+y)
}
</code></pre>
<p>since we are doing the calculation in parallel, and each thread save its result into the same channel, doesn't this screw up the data?</p>
<hr/>**评论：**<br/><br/>barsonme: <pre><blockquote>
<p>since we are doing the calculation in parallel, and each thread save its result into the same channel, doesn't this screw up the data?</p>
</blockquote>
<p>Nope. Channels are essentially a thread-safe, FIFO queue.</p>
<p>Internally, channels use locks that prevent data races when they [the channels] are used concurrently.</p></pre>Malangelus: <pre><p>I'm a total novice in go, and my only experience has been writing a few packages to be used as the building blocks for making webapps comprised of distributed microservices, but my understanding of that code is that each go routine is summing half of the values, and returning that sum, and then each of those sums is assigned to a separate variable, X and Y. It's fine to do because the go routines are not touching the same values, and you don't care about which order the values are calculated and returned since you're just distributing the task of summing. I do not have a concrete understanding of go routines so if I'm wrong about that then I would be thrilled if someone would correct me.</p></pre>
