runtime.GOMAXPROCS()的意义到底是什么 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
dawniii
V2EX    Go 编程语言

runtime.GOMAXPROCS()的意义到底是什么

  •  
  •   dawniii 2017-05-04 21:04:49 +08:00 2312 次点击
    这是一个创建于 3090 天前的主题,其中的信息可能已经有所发展或是发生改变。
    func main() { num := runtime.GOMAXPROCS(1) fmt.Println(num) c := make(map[int]int) for i := 0; i < 100; i++ { go func() { for j := 0; j < 1000000; j++ { c[j] = j } }() } time.Sleep(10000*time.Second) } 

    我搜索到的文档,都是说 runtime.GOMAXPROCS() 是设置实际并发执行的个数,我设置为 1 后,这段代码还是会报致命错误 fatal error: concurrent map writes 所以这个设置是失效了吗? mac 下 golang1.8

    15 条回复    2017-05-05 10:08:44 +08:00
    kappa
        1
    kappa  
       2017-05-04 21:07:36 +08:00
    错误信息不是写的很清楚么,你的代码在起 goroutine 并发写 map
    popu111
        2
    popu111  
       2017-05-04 21:12:11 +08:00 via Android
    golang 中 map 不允许并行操作而已,百度一下报错你就知道_(:з」∠)_连谷歌都用不到
    kohnv
        3
    kohnv  
       2017-05-04 21:15:53 +08:00
    @kappa 楼主的意思是只设置了一个 cpu 来跑 goroutine, 照理来说应该就没有并发的问题了
    timothyye
        4
    timothyye  
       2017-05-04 21:22:35 +08:00 via Android
    这个并发错误,只是跟开启了多协程并发写 map 有关,跟你设一个 cpu 无关啊。一个 cpu 也可以跑很多个并发协程的啊。。。你可以把协程理解为跟线程类似,但是比线程更轻量级的东西,一个 cpu 也可以跑多线程的吧。。。
    kxjhlele
        5
    kxjhlele  
       2017-05-04 21:23:52 +08:00 via Android
    @kohnv 1 个 cpu 还是多个 cpu,map 都不行,并发和并行的区别
    timothyye
        6
    timothyye  
       2017-05-04 21:24:34 +08:00 via Android
    runtime.GOMAXPROCS()是设 cpu 数量,不是控制协程数量

    要想不报错,你得控制同一时刻只能有一个协程写 map,比如加锁什么的
    wangxn
        7
    wangxn  
       2017-05-04 21:27:14 +08:00
    对 map 进行修改的操作不是原子的,所以可能某个协程在修改中途被抢占。
    dawniii
        8
    dawniii  
    OP
       2017-05-04 21:38:51 +08:00
    @timothyye 我查的资料,这个设置的不是 cpu 数量(和理解为 CPU 数量差不多),其实是 MPG 模型中 P 的数量(即有多少个 goroutine 可以同时运行)。所以我说设置为 1,应该就是同时只有一个 goroutine 在执行,怎么会有这种冲突呢。就算是理解为 1 个 cpu 多线程的情况,同一时刻也只有一个线程在跑啊。
    popu111
        9
    popu111  
       2017-05-04 21:47:06 +08:00 via Android
    @dawniii 但是 P 到 G 仍然是一对多的,Goroutine 只是协程而不是线程
    dawniii
        10
    dawniii  
    OP
       2017-05-04 21:49:09 +08:00
    @popu111 P 到 G 是一对多,而且是顺序切换的,同一时刻只有一个 G 在 P 上跑
    kohnv
        11
    kohnv  
       2017-05-04 21:51:06 +08:00
    @dawniii 同一个线程再跑 但是可能跑了一半就跑别的 goroutine 了, 也有可能出现 data race.

    比如内存数据保存到了临时变量, 然后切到另一个 goroutine 修改了这个内存, 过了一会就切回了把临时变量里的数据写到内存, 于是就覆盖了另一个 goroutine 写的数据.
    wangxn
        12
    wangxn  
       2017-05-04 21:51:45 +08:00
    @dawniii 即使同一时刻只有一个协程在跑,那这个协程也有可能在修改 map 的途中被切换出去了。
    dawniii
        13
    dawniii  
    OP
       2017-05-04 22:10:50 +08:00
    @kohnv
    @wangxn
    感谢,明白了。再请教下另外一个问题,我查的资料上说,goroutine 遇到 io 阻塞操作,会扔到 eventpoll 中。那整个 golang 程序中有多少个 eventpoll ?一个 P 一个 还是全局就一个呢?非常感谢
    dawniii
        14
    dawniii  
    OP
       2017-05-05 08:49:48 +08:00
    @popu111
    @kohnv
    @wangxn
    又搜了搜资料可算是明白怎么回事了,在比较老的 go 版本里,goroutine 的调度还不是抢占式的。runtime.GOMAXPROCS(1)设置后,goroutine 中只要不存在跨越调度点或者 IO 调度点的操作,都可以是无锁的。后来改成了抢占式调度,就必须要加锁同步了。
    PhilC
        15
    PhilC  
       2017-05-05 10:08:44 +08:00
    map 操作不是原子的,可能一个 goroutine 执行了一半,被调度了
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     5423 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 23ms UTC 05:48 PVG 13:48 LAX 22:48 JFK 01:48
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86