Skip to content

Instantly share code, notes, and snippets.

@hallettj
Last active March 21, 2017 19:14
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save hallettj/8b876f19cf3b757bbc5b47671475c4d0 to your computer and use it in GitHub Desktop.
Experiment to see if saturating the goroutine worker pool with long-running tasks delays goroutines that are queued later
// This is a test to get a better understanding of Go's scheduling.
// The hypothesis is that if the goroutine worker pool is saturated with
// long-running tasks, then a goroutine that is queued later will not be
// scheduled until the long-running tasks complete.
//
// Tested in Go 1.7 using this command:
//
// go build -gcflags '-N -l' blocker.go && ./blocker
//
// The `gcflags` setting is my attempt to disable inlining, to give
// blocked goroutines a chance to be pre-empted on function entry.
//
package main
import (
"fmt"
"runtime"
"sync"
"time"
)
func blocker(wg *sync.WaitGroup) {
for {
doStuff()
}
fmt.Println("blocker done")
wg.Done()
}
func doStuff() int {
return 1
}
func outputter(wg *sync.WaitGroup) {
fmt.Println("done")
wg.Done()
}
func main() {
runtime.GOMAXPROCS(3)
var wg sync.WaitGroup
wg.Add(4)
for i := 0; i < 3; i++ {
go blocker(&wg)
}
time.Sleep(1 * time.Second)
go outputter(&wg)
wg.Wait()
fmt.Println("exit")
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment