关于goroutine无限循环和memory分配的问题

Question

So i have a program which need to allocate a very big chunk of memory and hold it forever. As a test, i also run a goroutine which runs an infinite loop, in my main thread, i allocate the memory, however the program stuck forever in the goroutine's infinite loop even i set GOMAXPROCS to more then 1.

func main() {
    runtime.GOMAXPROCS(2)
    go func() {
        for {
            //fmt.Printf("goroutine1\n")
        }
    }()
    fmt.Println("main thread1")
    x := [1145][1145]int{}
    for i := 0; i < 1144; i++ {
        fmt.Println(i)
        x[i][i] = i
    }
    fmt.Println("main thread2")

}

if i don't do anything in the infinite loop, my main thread1 will never be able to successfully allocate the memory and print "main thread2", even i set GOMAXPROCS to 2, if i print something inside the infinite loop, everythings works fine(which is expected, as the goroutine print something in the infinite loop, it invoke the system call and yield the cpu, so my main thread can allocate the memory.

i am wondering why is that?

Answer 1

Your underlying computer system has some number of thread-executors. The Go runtime finds out how many on its own, and creates the appropriate number of runtime executors to use all of the system's. Changing GOMAXPROCS changes how many executors the runtime will try to allocate, but has no effect on the underlying system. In this case, it appears that the underlying system itself has only one executor.

If your underlying system had two or more, Go would already have created two executors by this point and would be running the infinite loop goroutine on one of them, and your main goroutine on the other, at the same time. But since your system has only one, just one gets to run. Regardless of how many runtime-level executors the Go runtime might create, only one of them can be bound to a hardware CPU to actually run .

Note that goroutines are mapped many-to-N. For instance, suppose you spin off 1000 goroutines, and have ten CPUs. The runtime will allocate ten executors and use the ten CPUs to run ten of the 1000 goroutines at once. The remaining 990 goroutines wait until one of the executors reaches a point where it voluntarily stops running that goroutine and picks up one of the remaining 990.

You can call runtime.Gosched yourself, from any goroutine, to say: I voluntarily suspend myself to let other goroutines that would like to run, run, until an executor can pick me up to run again. Many other systems call this function yield or some variation. (And be careful with the word "suspend": I used it here for effect, but the goroutine that caled runtime.Gosched is not technically suspended in that it's still marked as "would like to run", while other goroutines may be technically suspended in that they're marked "cannot run now, waiting for ____" (fill in the blank).)

See also How do goroutines work? (or: goroutines and OS threads relation) .