Why does order and way of calling goroutines matter?


I am trying to understand goroutines.
In the following example, why do 1)–4) behave differently?
See https://play.golang.org/p/_XXZe47W53v

package main
import (

func send(x int, ch chan int) {ch<-x}
func read(ch chan int) {fmt.Println(<-ch)}

func main() {
    ch := make(chan int)

    go read(ch)              // 1) works
    go send(1,ch)            // -> 1

    // go fmt.Println(<-ch)  // 2) fatal error: all goroutines are asleep - deadlock!
    // go send(1,ch)         // isn't this the same as the above ?

    // go send(1,ch)         // 3) works
    // go fmt.Println(<-ch)  // -> 1

    // go fmt.Println(<-ch)  // 4) fatal error: all goroutines are asleep - deadlock!
    // go send(1,ch)         // why does the order of the go routine calls matter?



You are seeing the errors because the read is not happening inside of the goroutine, but in the main thread.

The line:

go fmt.Println(<-ch)

is evaluating the parameter in the main thread, and once it succeeds it will run the Println in the goroutine with the already resolved parameter. Since the code can never write to the ch in this state, it deadlocks.

You can observe this by changing it to:

go func() { fmt.Println(<-ch) }()

Then it will create a closure around the ch, and then the anonymous routine will be blocked, not the main thread, which can continue on to the send().

Answered By – Travis Hegner

Answer Checked By – Jay B. (GoLangFix Admin)

Leave a Reply

Your email address will not be published.