Can you detect how many threads a given number of goroutines will create?

I understand that goroutines are multiplexed onto multiple OS threads, so if one should block, such as while waiting for I/O, others continue to run. But is there any way to know ahead of time how many threads I would spawn if I was to create n go开发者_C百科routines?

For example, if we call the function below would we know how many (or the maximum number of) system threads would be created for n goroutines:

type Vector []float64

// Apply the operation to n elements of v starting at i.
func (v Vector) DoSome(i, n int, u Vector, c chan int) {
    for ; i < n; i++ {
        v[i] += u.Op(v[i])
    }
    c <- 1;    // signal that this piece is done
}

Each goroutine can use a maximum of one thread at a time. Whether it uses a thread or not depends on what it's doing. The value of GOMAXPROCS determines the number of threads that can be used by freely running Go code - in other words, the maximum level of parallelism.

However more threads can be used, even with GOMAXPROCS=1, when goroutines block directly on system calls or calls into C.

The following operations do not cause the goroutine to use a thread when they block:

• channel operations
• network operations
• sleeping
• all primitives in the sync package

This means, for example, that if you have many goroutines that open /dev/ttyxx and block on read, you'll be using a thread for each one. Same goes if you're execing a load of processes and waiting for them to exit.

According to Pike's Go Course PDF slides (Day 3):

...if you want user-level parallelism you must set $GOMAXPROCS or call runtime.GOMAXPROCS(n). GOMAXPROCS tells the runtime scheduler how many non-syscall-blocked goroutines to run at once.

Based on this blog post, too, it would seem setting the environment variable GOMAXPROCS lets you fix the number of threads. I'm not sure how to get the default number of threads the runtime will manage if you do not specify this value, however.

This blog post seems to imply that if you do not set the environment variable the runtime will only utilize one core (presumably because it is only using one process.)

Currently, gccgo will create one thread per goroutine.

I don't know about 6g.