Concurrency is achieved in Go when setting to single core with blocking operations

I was testing how a blocking operation works on Go, and how it deprives other go-routines from having processor share, so I did that test:

package main
    
import (
    "fmt"
    "runtime"
    "time"
)
    
func test2() {
    for i := 1; ; i++ {
        fmt.Println(i, time.Now())
    }
}
    
func test() {
    a := 100
    for i := 1; i < 1000; i++ {
        a = i*100/i + a
        fmt.Println("value: " , a )
    }
}
    
func main() {
    runtime.GOMAXPROCS(1)
    go test2()
    for {
        test()
    }
}

As you can see in the example, first line of main() I'm setting Go to use a single core and a never ending task runs on, so that it blocks any other process, though I see results I didn't expect, I found out that both test and test2 are running, each having it's time share (a larger time share per process that's longer than if I set the GOMAXPROCS to higher values). This is the output:

https://gist.github.com/anonymous/b3634be74d30fd36f552

How can I explain this?

P.S. I'm using Go version 1.5.3

Update

I made a little change by setting GOMAXPROCS to 2, removed fmt.Println("value: " , a ) from test function, now, the program runs test2 for some time and, the test function takes over and nothing else run!

An important distinction is that GOMAXPROCS=1 doesn't limit the runtime to 1 core, it limits the number of OS threads actively running user code to 1. All (gc derived) Go programs are multithreaded.

In most cases a busy loop will interfere with the scheduler and/or garbage collection, sometimes even if GOMAXPROCS > 1. In your example though, the calls to the test() and fmt.Println functions are scheduling points, and those allow the runtime scheduler to execute other goroutines.

As you pointed out, if the call to fmt.Println is removed from test, the progress on test2() eventually stops (apparently the call to test() alone isn't sufficient to let the scheduler proceed. Maybe it's to fast, inlined, blocked by the internal for loop, so on).

In this case it is because the busy-loop calls to test() are preventing the GC from doing it's stop-the-world phase of garbage collection, and blocking the scheduler. You can verify this by running the program with GOGC=off.

The details of scheduling, cpu-bound tasks, garbage collection, etc. can change from release to release, but since goroutines are cooperatively scheduled, a busy-loop is always a mistake. If you have an actual need for a long running, cpu-bound loop, you can cooperate with the scheduler by ocasionally inserting a call to runtime.Gosched() to yield to other goroutines.