当runtime.GOMAXPROCS(1)时多个协程的执行顺序是怎样的

网上有一道关于多个协程的执行顺序的题目。 下面的代码会输出什么,并说明原因

runtime.GOMAXPROCS(1)
    wg := sync.WaitGroup{}
    wg.Add(20)
    for i := 0; i < 10; i++ {
        go func(i int) {
            fmt.Println("A: ", i)
            wg.Done()
        }(i)
    }
    for i := 0; i < 10; i++ {
        go func(i int) {
            fmt.Println("B: ", i)
            wg.Done()
        }(i)
    }
    wg.Wait()

这道题的参考答案是:“打印的顺序是随机的。 但是A:均为输出10,B:从0~9输出(顺序不定)。”
A的输出是10,B是0-9,这个是变量的作用域不同引起的,这个很好理解。但是输出顺序是不是随机的呢?经过验证,当runtime.GOMAXPROCS(1)时,即只有1个操作系统线程可供用户的Go代码使用时,多个协程的执行顺序是固定不变的,具体顺序跟不同的Go版本的具体实现有关。

为了方便说明问题,在wg.Wait()前后各加一句打印输出:

fmt.Printf("---main end loop---\n") 
wg.Wait() 
fmt.Printf("---  main exit  ---\n")

例如在Go1.13.8和Go1.14.6输出顺序固定为:

---main end loop---
B:  9
A:  10
A:  10
A:  10
A:  10
A:  10
A:  10
A:  10
A:  10
A:  10
A:  10
B:  0
B:  1
B:  2
B:  3
B:  4
B:  5
B:  6
B:  7
B:  8
---  main exit  ---

而在更早期的版本,如果Go1.4的输出顺序则固定为:

---main end loop---A:  10A:  10A:  10A:  10A:  10A:  10A:  10A:  10A:  10A:  10B:  0B:  1B:  2B:  3B:  4B:  5B:  6B:  7B:  8B:  9---  main exit  ---

可以看到“---main end loop---”总是最先输出,表明在1个操作系统线程的情况下,只有main协程执行到wg.Wait()阻塞等待时,其子协程才能被执行,而子协程的执行顺序正好对应于它们入队列的顺序。其中Go1.13.8和Go1.14.6,在实现上和早期版本有一点不同,每增加一个子协程就把其对应的函数地址存放到”p.runnext“,而把”p.runnext“原来的地址(即上一个子协程对应的函数地址)移动到队列”p.runq“里面,这样当执行到wg.Wait()时,”p.runnext“存放的就是最后一个子协程对应的函数地址(即输出B: 9的那个子协程)。当开始执行子协程对应的函数时,首先执行”p.runnext“对应的函数,然后按先进先出的顺序执行队列”p.runq“里的函数。所以这就解释了为什么总是B:9打在第一个,而后面打印的则是进入队列的顺序。

相关源码:$GOROOT/src/runtime/proc.go

入队列:

// runqput tries to put g on the local runnable queue.// If next is false, runqput adds g to the tail of the runnable queue.// If next is true, runqput puts g in the _p_.runnext slot.// If the run queue is full, runnext puts g on the global queue.// Executed only by the owner P.func runqput(_p_ *p, gp *g, next bool) {        if randomizeScheduler && next && fastrand()%2 == 0 {                next = false        }         if next {        retryNext:                oldnext := _p_.runnext                //把子协程gp对应的函数地址赋值给_p_.runnext                if !_p_.runnext.cas(oldnext, guintptr(unsafe.Pointer(gp))) {                        goto retryNext                }                if oldnext == 0 {                         return                }                // Kick the old runnext out to the regular run queue.                //从这句以下都是把_p_.runnext原来存放的上一个子协程的函数地址放入队列_p_.runq                gp = oldnext.ptr()        } retry:        h := atomic.LoadAcq(&_p_.runqhead) // load-acquire, synchronize with consumers        t := _p_.runqtail        if t-h < uint32(len(_p_.runq)) {                _p_.runq[t%uint32(len(_p_.runq))].set(gp)                atomic.StoreRel(&_p_.runqtail, t+1) // store-release, makes the item available for consumption                return        }        //print("runqput call runqputslow goid=", gp.goid, "\n")        if runqputslow(_p_, gp, h, t) {                return        }        // the queue is not full, now the put above must succeed        goto retry}

出队列:

// Get g from local runnable queue.// If inheritTime is true, gp should inherit the remaining time in the// current time slice. Otherwise, it should start a new time slice.// Executed only by the owner P.func runqget(_p_ *p) (gp *g, inheritTime bool) {        // If there's a runnext, it's the next G to run.        //第一个For循环是优先返回_p_.runnext对应的子协程函数地址, 返回之前会把_p_.runnext赋值为0,后续会break到下面第二个For循环        for {                next := _p_.runnext                if next == 0 {                        break                }                 if _p_.runnext.cas(next, 0) {                        return next.ptr(), true                }        }        //按先进先出顺序返回队列_p_.runq里面存储的子协程函数地址        for {                h := atomic.LoadAcq(&_p_.runqhead) // load-acquire, synchronize with other consumers                t := _p_.runqtail                if t == h {                        return nil, false                }                gp := _p_.runq[h%uint32(len(_p_.runq))].ptr()                if atomic.CasRel(&_p_.runqhead, h, h+1) { // cas-release, commits consume                        return gp, false                }        }}
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,366评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,521评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,689评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,925评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,942评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,727评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,447评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,349评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,820评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,990评论 3 337
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,127评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,812评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,471评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,017评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,142评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,388评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,066评论 2 355