Goroutines, Deferred Function Calls and Panic/Recover

Modern CPUs often have multiple cores, and some CPU cores support hyper-threading. In other words, modern CPUs can process multiple instruction pipelines simultaneously. To fully use the power of modern CPUs, we need to do concurrent programming in coding our programs.

Concurrent computing is a form of computing in which several computations are executed during overlapping time periods. The following picture depicts two concurrent computing cases. In the picture, A and B represent two separate computations. The second case is also called parallel computing, which is special concurrent computing. In the first case, A and B are only in parallel during a small piece of time.

Concurrent computing may happen in a program, a computer, or a network. In Go 101, we only talk about program-scope concurrent computing. Goroutine is the Go way to create concurrent computations in Go programming.

Goroutines are also often called green threads. Green threads are maintained and scheduled by the language runtime instead of the operating systems. The cost of memory consumption and context switching, of a goroutine is much lesser than an OS thread. So, it is not a problem for a Go program to maintain tens of thousands goroutines at the same time, as long as the system memory is sufficient.

Go doesn't support the creation of system threads in user code. So, using goroutines is the only way to do (program scope) concurrent programming in Go.

Each Go program starts with only one goroutine, we call it the main goroutine. A goroutine can create new goroutines. It is super easy to create a new goroutine in Go, just use the keyword go followed by a function call. The function call will then be executed in a newly created goroutine. The newly created goroutine will exit alongside the exit of the called function.

All the result values of a goroutine function call (if the called function returns values) must be discarded in the function call statement. The following is an example which creates two new goroutines in the main goroutine. In the example, time.Duration is a custom type defined in the time standard package. Its underlying type is the built-in type int64. Underlying types will be explained in the next article.

package main

import (
	"log"
	"math/rand"
	"time"
)

func SayGreetings(greeting string, times int) {
	for i := 0; i < times; i++ {
		log.Println(greeting)
		d := time.Second * time.Duration(rand.Intn(5)) / 2
		time.Sleep(d) // sleep for 0 to 2.5 seconds
	}
}

func main() {
	rand.Seed(time.Now().UnixNano()) // needed before Go 1.20
	log.SetFlags(0)
	go SayGreetings("hi!", 10)
	go SayGreetings("hello!", 10)
	time.Sleep(2 * time.Second)
}

Quite easy. Right? We do concurrent programming now! The above program may have three user-created goroutines running simultaneously at its peak during run time. Let's run it. One possible output result:

hi!
hello!
hello!
hello!
hello!
hi!

When the main goroutine exits, the whole program also exits, even if there are still some other goroutines which have not exited yet.

Unlike previous articles, this program uses the Println function in the log standard package instead of the corresponding function in the fmt standard package. The reason is the print functions in the log standard package are synchronized (the next section will explain what synchronizations are), so the texts printed by the two goroutines will not be messed up in one line (though the chance of the printed texts being messed up by using the print functions in the fmt standard package is very small for this specific program).

Concurrent computations may share resources, generally memory resource. The following are some circumstances that may occur during concurrent computing:

• In the same period that one computation is writing data to a memory segment, another computation is reading data from the same memory segment. Then the integrity of the data read by the other computation might be not preserved.
• In the same period that one computation is writing data to a memory segment, another computation is also writing data to the same memory segment. Then the integrity of the data stored at the memory segment might be not preserved.

These circumstances are called data races. One of the duties in concurrent programming is to control resource sharing among concurrent computations, so that data races will never happen. The ways to implement this duty are called concurrency synchronizations, or data synchronizations, which will be introduced one by one in later Go 101 articles.

Other duties in concurrent programming include

• determine how many computations are needed.
• determine when to start, block, unblock and end a computation.
• determine how to distribute workload among concurrent computations.

The program shown in the last section is not perfect. The two new goroutines are intended to print ten greetings each. However, the main goroutine will exit in two seconds, so many greetings don't have a chance to get printed. How to let the main goroutine know when the two new goroutines have both finished their tasks? We must use something called concurrency synchronization techniques.

Go supports several concurrency synchronization techniques. Among them, the channel technique is the most unique and popularly used one. However, for simplicity, here we will use another technique, the WaitGroup type in the sync standard package, to synchronize the executions between the two new goroutines and the main goroutine.

The WaitGroup type has three methods (special functions, will be explained later): Add, Done and Wait. This type will be explained in detail later in another article. Here we can simply think

• the Add method is used to register the number of new tasks.
• the Done method is used to notify that a task is finished.
• and the Wait method makes the caller goroutine become blocking until all registered tasks are finished.

Example:

package main

import (
	"log"
	"math/rand"
	"time"
	"sync"
)

var wg sync.WaitGroup

func SayGreetings(greeting string, times int) {
	for i := 0; i < times; i++ {
		log.Println(greeting)
		d := time.Second * time.Duration(rand.Intn(5)) / 2
		time.Sleep(d)
	}
	// Notify a task is finished.
	wg.Done() // <=> wg.Add(-1)
}

func main() {
	rand.Seed(time.Now().UnixNano()) // needed before Go 1.20
	log.SetFlags(0)
	wg.Add(2) // register two tasks.
	go SayGreetings("hi!", 10)
	go SayGreetings("hello!", 10)
	wg.Wait() // block until all tasks are finished.
}

Run it, we can find that, before the program exits, each of the two new goroutines prints ten greetings.

The last example shows that a live goroutine may stay in (and switch between) two states, running and blocking. In that example, the main goroutine enters the blocking state when the wg.Wait method is called, and enter running state again when the other two goroutines both finish their respective tasks.

The following picture depicts a possible lifecycle of a goroutine.

Note, a goroutine is still considered to be 'running' if it is asleep (after calling time.Sleep function) or awaiting the response of a system call or a network connection.

When a new goroutine is created, it will enter the 'running' state automatically. Goroutines can only exit from running state, and never from blocking state. If, for any reason, a goroutine stays in blocking state forever, then it will never exit. Such cases, except some rare ones, should be avoided in concurrent programming.

A blocking goroutine can only be unblocked by an operation made in another goroutine. If all goroutines in a Go program are in blocking state, then all of them will stay in blocking state forever. This can be viewed as an overall deadlock. When this happens in a program, the standard Go runtime will try to crash the program.

The following program will crash, after two seconds:

package main

import (
	"sync"
	"time"
)

var wg sync.WaitGroup

func main() {
	wg.Add(1)
	go func() {
		time.Sleep(time.Second * 2)
		wg.Wait()
	}()
	wg.Wait()
}

The output:

fatal error: all goroutines are asleep - deadlock!

...

Later, we will learn more operations which will make goroutines enter blocking state.

A deferred function call is a function call which follows a defer keyword. The defer keyword and the deferred function call together form a defer statement. Like goroutine function calls, all the results of the function call (if the called function has return results) must be discarded in the function call statement.

When a defer statement is executed, the deferred function call is not executed immediately. Instead, it is pushed into a deferred call queue maintained by its caller goroutine. After a function call fc(...) returns (but has not fully existed yet) and enters its exiting phase, all the deferred function calls pushed into the deferred call queue during executing the function call will be removed from the deferred call queue and executed, in first-in, last-out order, that is, the reverse of the order in which they were pushed into the deferred call queue. Once all these deferred calls are executed, the function call fc(...) fully exits.

Here is a simple example to show how to use deferred function calls.

package main

import "fmt"

func main() {
	defer fmt.Println("The third line.")
	defer fmt.Println("The second line.")
	fmt.Println("The first line.")
}

The output:

The first line.
The second line.
The third line.

Here is another example which is a little more complex. The example will print 0 to 9, each per line, by their natural order.

package main

import "fmt"

func main() {
	defer fmt.Println("9")
	fmt.Println("0")
	defer fmt.Println("8")
	fmt.Println("1")
	if false {
		defer fmt.Println("not reachable")
	}
	defer func() {
		defer fmt.Println("7")
		fmt.Println("3")
		defer func() {
			fmt.Println("5")
			fmt.Println("6")
		}()
		fmt.Println("4")
	}()
	fmt.Println("2")
	return
	defer fmt.Println("not reachable")
}

For example,

package main

import "fmt"

func Triple(n int) (r int) {
	defer func() {
		r += n // modify the return value
	}()

	return n + n // <=> r = n + n; return
}

func main() {
	fmt.Println(Triple(5)) // 15
}

The arguments of a deferred function call are all evaluated at the moment when the corresponding defer statement is executed (a.k.a. when the deferred call is pushed into the deferred call queue). The evaluation results are used when the deferred call is executed later during the existing phase of the surrounding call (the caller of the deferred call).

The expressions within the body of an anonymous function call, whether the call is a general call or a deferred/goroutine call, are evaluated during the anonymous function call is executed.

Here is an example.

package main

import "fmt"

func main() {
	func() {
		for i := 0; i < 3; i++ {
			defer fmt.Println("a:", i)
		}
	}()
	fmt.Println()
	func() {
		for i := 0; i < 3; i++ {
			defer func() {
				fmt.Println("b:", i)
			}()
		}
	}()
}

Run it. The output:

a: 2
a: 1
a: 0

b: 3
b: 3
b: 3

The first loop prints i as 2, 1 and 0 as a sequence. The second loop always prints i as 3, because when the three fmt.Println calls within the anonymous function are invoked, the value of the loop variable i has changed to 3.

To make the second loop print the same result as the first one, we can modify the second loop as

		for i := 0; i < 3; i++ {
			defer func(i int) {
				// The "i" is the input parameter.
				fmt.Println("b:", i)
			}(i)
		}

or

		for i := 0; i < 3; i++ {
			i := i // <=> var i = i
			defer func() {
				// The "i" is not the loop variable.
				fmt.Println("b:", i)
			}()
		}

The same argument valuation moment rules also apply to goroutine function calls. The following program will output 123 789.

package main

import "fmt"
import "time"

func main() {
	var a = 123
	go func(x int) {
		time.Sleep(time.Second)
		fmt.Println(x, a) // 123 789
	}(a)

	a = 789

	time.Sleep(2 * time.Second)
}

By the way, it is not a good idea to do synchronizations by using time.Sleep calls in formal projects. If the program runs on a computer which CPUs are occupied by many other programs running on the computer, the newly created goroutine may never get a chance to execute before the program exits. We should use the concurrency synchronization techniques introduced in the article concurrency synchronization overview to do synchronizations in formal projects.

func panic(v interface{})
func recover() interface{}

package main

import "fmt"

func main() {
	defer func() {
		fmt.Println("exit normally.")
	}()
	fmt.Println("hi!")
	defer func() {
		v := recover()
		fmt.Println("recovered:", v)
	}()
	panic("bye!")
	fmt.Println("unreachable")
}

hi!
recovered: bye!
exit normally.

package main

import (
	"fmt"
	"time"
)

func main() {
	fmt.Println("hi!")

	go func() {
		time.Sleep(time.Second)
		panic(123)
	}()

	for {
		time.Sleep(time.Second)
	}
}

hi!
panic: 123

goroutine 5 [running]:
...

package main

func main() {
	a, b := 1, 0
	_ = a/b
}

panic: runtime error: integer divide by zero

goroutine 1 [running]:
...

• Go 101에 대해 - 이 책이 쓰여진 이유
• 감사의 말

• Go 소개 - Go를 배우는 가치
• Go 툴체인 - Go 프로그램을 컴파일하고 실행하는 방법

• Go 코드에 익숙해지기
  • 소스 코드 요소 소개
  • 키워드와 식별자
  • 기본 자료형과 기본 값 리터럴
  • 상수와 변수 - 무형성(untyped) 값과 자료형 추론 소개를 포함
  • 일반 연산자 - 더 많은 자료형 추론 규칙 소개를 포함
  • 함수 선언과 호출
  • 코드 패키지와 패키지 들여오기
  • 표현식, 구문과 단순 구문
  • 기본 흐름 제어
  • 고루틴, 지연된 함수 호출과 패닉/복구

• Go 자료형 체계
  • Go 자료형 체계 개요 - Go 프로그래밍 숙달을 위해 반드시 읽어봐야 하는
  • 포인터
  • 구조체
  • 변수 - Go 변수에 대한 더 깊은 이해
  • 배열, 슬라이스와 맵 - 1급 객체 컨테이너 자료형
  • 문자열
  • 함수 - 함수 자료형과 값, 가변 인자 함수
  • 채널 - Go에서 동시성 동기화를 하는 방법
  • 메서드
  • 인터페이스 - 리플렉션과 다형성을 하는 값 상자
  • 자료형 임베딩 - 자료형을 확장하는 방법
  • 자료형에 안전하지 않는 포인터
  • 제네릭 - 합성 자료형의 사용과 읽는 법
  • 리플렉션 - reflect 표준 패키지

• 특별 주제
  • 개행 규칙
  • 지연된 함수 호출 더 알아보기
  • 패닉/복구 사용 사례
  • 패닉/복구 메커니즘에 대한 고찰 - 함수 호출 종료 단계를 포함
  • 코드 블록과 식별자 스코프
  • 표현식 평가 순서
  • Go의 값 복사 비용
  • 경계 검사 제거(BCE)

• 동시성 프로그래밍
  • 동시성 동기화 개요
  • 채널 사용 사례
  • 채널을 깔끔하게 닫는 방법
  • 기타 동시성 동기화 기술 - sync 표준 패키지
  • 원자적 연산 - sync/atomic 표준 패키지
  • Go의 메모리 순서 보장
  • 흔히들 저지르는 동시성 프로그래밍 실수들

• 메모리 관련
  • 메모리 블록
  • 메모리 레이아웃
  • 메모리 누수 시나리오

• 일부 요약
  • 몇 가지 간단한 요약
  • Go의 nil
  • 값 변환, 할당과 비교 규칙
  • 구문/의미 예외
  • Go Details 101
  • Go FAQ 101
  • Go Tips 101

• 더 많은 토픽