GopherCon 2017: Understanding Channels - Kavya Joshi
Why Stack Overflow recommends it
Stack Overflow users link it when explaining how Go channels behave under the hood, such as direct sender-to-receiver handoff, blocking behavior, and why channels can scale better than mutexes.
Recommended by 4 people across 3 different months, 2018 to 2019.
What it is
A GopherCon 2017 conference talk by Kavya Joshi on how Go channels work internally, including the runtime scheduler and memory management behind channel operations. It covers how sends and receives interact with goroutines, locking, and buffers.
What people said
Recommends Abdullah Al Maruf - Tuhin · 2018-04 · Stack Overflow · on “Go tutorial: Channels, Buffered Channels tutorial”
The chnnael c , in your 1st example of unbuffered channel, is not acting as LIFO. Actually it is happening because of go routines . The go routines executes concurrently. If you tweak your code to debug, add one extra line in sum to print the sum before sending to channel. package main import "fmt" func sum(s []int, c chan int) { sum := 0 for _, v := range s { sum += v } fmt.Println("slice:", s) fmt.Println(sum) c <- sum // send sum to c } func main() { s := []int{7, 2, 8, -9, 4, 0} c := make(chan int) go sum(s[:2], c) go sum(s[2:4], c) go sum(s[4:6], c) x, y, z := <-c, <-c, <-c // receive from c fmt.Println(x, y, z, x+y+z) } The output is: slice: [4 0] 4 slice: [7 2] 9 slice: [8 -9] -1 4 9
Recommends Sergio Tulentsev · 2019-01 · Stack Overflow · on “How time.sleep changes result of this program that uses channels”
I think this talk should shed some light on what happens here: [this video] Interesting things happen on a blocked channel: data may flow directly from senders to receivers, bypassing the channel :)
Recommends 8n8 · 2019-08 · Stack Overflow · on “Why does sync.Mutex largely drop performance when goroutine contention is more than 3400?”
After watching this talk [this video] , it seems reasonable that a channel can cope better with a lot of goroutines than a mutex. My understanding is that a channel contains a lock to protect its buffer. In principle a goroutine has to acquire and free the lock on the channel whenever it uses it, but that the locking is optimised away in these two cases: The receiver is waiting for an empty channel to have something put in it. In this case the incoming data is dumped straight into the sleeping receiver's memory space, bypassing the channel memory and lock altogether. The sender is waiting for a full channel to have something taken out of it. In this case the current receiver takes the message fro
Recommends user11856505 · 2019-08 · Stack Overflow · on “Buffered channels in Go”
After reading the comments and some online resources the following approach seems to work fine so far. The first 8 minutes in this video [this video] was quite helpful to understand the concept. The defer close(ch) is something I'm uncertain, though. package main import "strings" func SendFile(ch chan string) { for filePath := range ch { //upload file here } } func SaveToFile(uartData []string) filePath string { return filePath } func main() { ch := make(chan string, 1000) defer close(ch) go SendFile(<-ch) uart := uartInit() for { data := uart.Read(buf) uartData = strings.Split(string(buf), " ") ch <- SaveToFile(uartData) } }