golang的深入理解

https://tiancaiamao.gitbooks.io/go-internals/content/zh/02.3.html
golang中goroutine的来世今生：
/*
可以看到，这里在代码区中故意的用Go语言中的G，M，甚至包括GOMAXPROCS等取名字。
其实本质上，GO语言的调度层无非就是这样一个工作模式的：几条物理线程，不停的取goroutine运行
*/

package main

import (
"fmt"
"sync"
)

type G interface {
Run()
}

type Sched struct {
allg []G
lock *sync.Mutex
}

var sched Sched

func M() {
for {
sched.lock.Lock()
if len(allg) > 0 {
g := sched.allg[0]
sched.allg = sched.allg[1:]
g.Run()
}
sched.lock.UnLock()
}
}

func main() {
for i := 0; i < GOMAXPROCS; i++ {
go M()
}
}

/*
上面的情形太简单了，就是工作线程不停的取goroutine运行，这个还不能称之为调度。
调度有一些复杂的控制机制，比如哪个goroutine应该被运行，
它应该运行多久，什么时候将它换出来。
对于上面的代码，如果Run函数一直执行，比如I/O阻塞，那么在他结束之前不会
返回到调用器层面。那么假设上面的任务中Run进入到一个阻塞的系统调用了，
这样M也就跟着一起阻塞了，这样实际工作的线程就少了一个，无法充分利用cpu多核的优点。
**/

/*
一个简单的解决办法是在进入系统调用之前再制造一个M出来干活，
这样就填补了这个进入系统调用的M的空缺，始终保证有GOMAXPROCS个工作线程在干活了。
那当这个M结束了系统调用后归来，新的M又没退出的时候，总的M数不是变多了？？？
**/

func entersyscall(){
go M() //通过这种简陋的方式来模拟新加一个M，作者理解的很优雅。。。
}

/*
M出系统调用的时候，怎么办呢，如果让M接着干活，岂不是超过了GOMAXPROCS个线程了？
这个问题上面已经提过，所以在exitsyscall的时候要让这个出来的M不能再干活了，
要限制干活的M的个数为GOMAXPROCS个，多了则让它们闲置
物理线程比cpu多
**/