1. DELL 2723QX 4K 全面屏
2. DELL S3221QS 4K 带鱼屏

都是 3000 左右，美术选 1 ，非美术选 2

@CRVV @EchoGroot #109

> for flag print sleep 的那个循环一直占用着 CPU ，sleep 的实现是忙等，而后面的 for 循环从来都没有执行到，这是一种符合 spec 的行为

sleep 的实现是忙等，这个不对吧？它可不是纯 cpu spin 那种吧？ print 也是有 io 的，也不是导致后面的 for 循环从来没有执行到的原因吧？
所以虽然后面的 for 被优化掉了，但我并不清楚具体什么原因导致的优化

> 两个 goroutine 同时对一个变量做读写操作，这个叫 data race ，当然是 undefined behavier
> 两个线程不能同时读写同一个变量，这个算基础知识吧

这个说法片面了吧~
data race 可能会造成不一致、undefined behavior ，但如果正确使用、并不会造成 ub 。
我代码里一些 flag 就是 data race 的，为了性能，一些简单的地方没必要都加锁，atomic 也是多余

OP 不用被气到，而且这跟煤矿辛苦没有关系：同样是煤矿，其他非编内人员，同样辛苦但待遇更差、仍然是不公平的。
我相信多数抱怨的人是觉得分配方案不够 average 和 balance ，并不是仇视你家人拿的多。
大家都心平气和些

用谷歌登录是不是也有同样的问题？这跟账号大一统没关系吧，相当于用于身份信息的那个中心 id 的故障问题，跟国内国外没关系。

@codehz #100

其实就是语言定位、取舍问题。c/cpp 这些是要把底层能力尽量留给开发者、开发者可以“肆意”掌控和进行性能优化，编译器自己优化性能的效率比肉眼要高得多。golang 的定位本来也不是像 c/cpp 那样极致性能与控制力，而是尽量在工程上让开发者能够舒服地做业务逻辑，所以写 go 也不需要考虑那么多。

@rockyliang #96

汇编在这里，去掉了 fmt 换成了 println 免得太长影响视线：
https://gist.github.com/lesismal/3673322106d032abc10a2a06ee138f9b

@rockyliang #96

看了下汇编，for 循环里不断设置 flag 的语句这块生成的汇编只有一条 NOPL （空指令）汇编、应该是被编译器优化掉了。
随便在 for 循环里加个 print 之类的，都可以让 flag=false 生效。

OP 的疑问其实是 CPU 指令自己的事情，并不算是编程语言相关的，所以我再提一下这个帖子，建议 OP 先看下：
https://www.51cto.com/article/716546.html
还有例如这个帖子：
https://xiaolincoding.com/os/1_hardware/cpu_mesi.html#mesi-%E5%8D%8F%E8%AE%AE

CPU 多核缓存一致性由 CPU 保证。一些人举例子的 i++是属于多个并发各自执行一组指令时各组指令自己的原子性问题、和 cache 一致性其实应该是无关的。

很多认为的可见性的不一致问题，应该是编译器优化导致的，例如：
#96
c++ const 变量通过指针强改内容但其他用到 const 变量的地方仍然是旧值、因为编译器认为常量直接类似宏替换了，需要 volatile 指定每次读内存主要也是为了告诉编译器不要优化这里的内容

@rockyliang
如果只是并行 cpu cache 的问题，相当于跟 golang 语言无关、跟 chan 也无关，直接看这种吧：
https://www.51cto.com/article/716546.html

@Frankcox #68 嗯嗯

@guanhui07 除了 #82 里说的，其他还有很多，go 并发编程里随便弄些协程做常驻任务运行，还可以方便结合 chan 、mutex 之类的实现各种功能，我搜的 swoole 例子里主要是 http handler 处理 http 请求这种，更广泛的业务场景怕是差距更大，不只是简单的无状态接口这个地方的协程的便利性

@Frankcox #56

我也没有说是协程执行先后顺序的问题呀。。
可能我给那几个步骤排序，造成了你的误解、误以为我在说协程执行的先后顺序。
请仔细看下，我说的是不同协程里，golang 对 chan 的操作时序保证，这与 go f()是否被先调度执行是无关的

> OP 的疑问是如何确保如果两个协程在不同的 core 上执行，修改的值在不同的 core cache 上同步

不管你是单核心并发、还是多核心并发或并行，chan 都在语言层面通过锁、调度器做了这个对并发操作 chan 行为的顺序保证，就是官网里这句：A receive from an unbuffered channel is synchronized before the completion of the corresponding send on that channel.

所以 OP 把问题本身就搞混了

官网里这个例子前面那句写的很清楚了：
> A receive from an unbuffered channel is synchronized before the completion of the corresponding send on that channel.
> 无缓冲的 chan 的接收在该 chan 上相应的发送完成之前进行同步。

如果没有这个保证，c <- 0 可能先于 f()协程完成、所以很可能 a 还没被设置。
但有了这个保证，则例子中：
<-c 先于 c <- 0 完成;
a = "hello, world" 先于 <-c ，所以也先于 c <- 0;
print(a) 在 c <- 0 之后，所以 a = "hello, world" 先于 print(a)，所以肯定打印了 hello world 。


本质上 OP 是迷惑为什么“无缓冲的 chan 的接收在该 chan 上相应的发送完成之前进行同步”。
这个可以自己啃下 runtime/chan.go 源码

完全没毛病，人家出钱了啊

@guanhui07 #81

看了下，看样子 swoole 确实是框架内置了一些驱动已经与协程结合起来了，例如 mysql 、redis ，确实很不错。
但这毕竟仍然是框架级的，也就是说，必须得 swoole 框架支持慢 IO 操作才能真正实现同步代码底层非阻塞+自动调度。三方的东西很多，如果需要依赖一些 swoole 尚未支持的，则仍然是可能阻塞的。
golang 是语言级支持了这些，三方的 golang 驱动实现基于 golang 标准库即可获得同步代码底层非阻塞+自动调度。

所以也不能完全说“没什么不同”