协程压根就不是os调度的单位。
协程本质上就是个高级一点的goto的语法糖而已。

【 在 leadu 的大作中提到: 】
: 100次同步是100个协程，，各个核上的线程随机得到到这些协程，就没有太多的大小核调度问题了
:
--
FROM 180.111.50.*

很多人刚开始接触协程确实会有“goto的语法糖”这种解读，特别是有些语言对这个支持的实在差，比如c、go。目前对协程支持最好的是c#，完全把协程first class化。
协程虽然不是os调度的单位，但是它可以被线程池中的线程peek。在随机peek的过程中完成了负载均衡
【 在 lvsoft 的大作中提到: 】
: 协程压根就不是os调度的单位。
: 协程本质上就是个高级一点的goto的语法糖而已。
:
--
FROM 123.116.196.*

行

【 在 leadu (leadu) 的大作中提到: 】
: 不懂就别参与讨论了
--
FROM 119.132.56.*

协程可以作为(用户空间多核)调度的单位。但是是有代价的。

我说你对协程的理解不到位，不是说你对协程的优点没理解到位，而是说你对协程的缺点理解没到位。

不信你讲一下协程有什么缺点。

【 在 leadu (leadu) 的大作中提到: 】
: 很多人刚开始接触协程确实会有“goto的语法糖”这种解读，特别是有些语言对这个支持的实在差，比如c、go。目前对协程支持最好的是c#，完全把协程first class化。
: 协程虽然不是os调度的单位，但是它可以被线程池中的线程peek。在随机peek的过程中完成了负载均衡
--
修改:hgoldfish FROM 140.224.35.*
FROM 140.224.35.*

说协程是goto的语法糖只是一种比较土鳖的说法。比较雅一点的说法是continuation，只不过这么说没几个人听的懂就是了。

进程线程协程本身只是一个用来定义上下文实现资源隔离的概念。调度是在实际环境中为了解决资源不足和冲突才引入的，额外的，另一个维度的东西。而且现在来说进程线程之类的概念都太老了，满足不了实际需要了，现在大家都玩sandbox+bare metal，有人连os kernel，ring0都想消灭掉了。实现层面早就玩出花了，who care c#是不是在什么犄角旮旯的地方做的比c、go更好啊，这些都是细枝末节的无聊话题，都不在一个维度上。

协程这东西，最有价值的地方是内核无感。这点与线程相反，线程是用户态的程序无感。所以协程的价值就是当成高级goto来用，给你一套机制让你可以方便的安排好context switch的位置、时间、节奏。因为你都安排好了，自然不需要竞争，不产生调度负担，所以才能提高规模。

非要在实现层面整个协程的调度当然是可以的，早在WIN3.x时代，连进程和线程都没有的时候，当时的线程就是协程。如果你一定要把协程整得又能抢占调度，又能以协程为单位在cpu core上迁移甚至并发，xx队列xx池xx锁等等之类的东西一个不拉啥也都整上，那这就是线程。线程遇到的问题也会一个不拉都遇到。又不是取个名字叫协程就能自然免疫问题的。


【 在 leadu 的大作中提到: 】
: 很多人刚开始接触协程确实会有“goto的语法糖”这种解读，特别是有些语言对这个支持的实在差，比如c、go。目前对协程支持最好的是c#，完全把协程first class化。
: 协程虽然不是os调度的单位，但是它可以被线程池中的线程peek。在随机peek的过程中完成了负载均衡
--
FROM 180.111.50.*