你这个理解错误。虽然你用了很久的协程。但是我觉得你太小看协程了。

协程应该是比进程、线程更高一级的抽象。和函数调用是同级别的，可以理解成异步的函数调用。

至于具体是使用线程、纤程还是进程来实现，或者根本就是混合实现那是另外的事情。在具体的调度和内存管理时，还分成 stackless, stackful 两种呢。

golang 和 java 就是典型的混合实现，纤程在线程间自动调度。

【 在 ylh1969 的大作中提到: 】
: 一般情况并不需要协程。
: 只有异步IO时，将它表达为同步，才需要。
: 简单点，在线程池网络编程中，长时间的同步IO，占用线程时间太长，影响别的任务。在等待IO期间，释放线程，由一个协程等待IO。
: ...................
--
修改:hgoldfish FROM 27.154.110.*
FROM 27.154.110.*

内核有用协程。我记得之前 bcache 的维护者有提到他们使用了内核态的纤程。

使用协程确实可以到内核的设计进行改造。比如那个 irq 的处理过程，就是典型的协程化场景。反正，凡是异步，多多少少都可以使用协程思维进行重新改造。

【 在 overcomeunic 的大作中提到: 】
: 有了协程，更象是有了一个确定性很强的状态机
: 但这个状态机又跟业务有关，好象不管是 内核｜编译器 ，都没有办法灵活地帮业务做一些定制
: 内核看着自己倒是可以用协程再提升一下性能，盲猜收益不会很大。
: ...................
--
FROM 27.154.110.*

多线程是可以利用多核性能的，单线程，再多的协程，也只用到一个核。
【 在 poocp 的大作中提到: 】
: 你说了半天，这些问题还是多线程带来的啊。
:
--
FROM 221.218.60.*

【 在 finlab 的大作中提到: 】
: 协程很多场合是为了节省线程切换的成本，提高cpu的利用率。
: 但是经常把一个事情劈成两半，绕了半天还是要再捏到一起。
: 既然协程这么流行，那就不如在cpu和操作系统、编译器层面进行优化，
: ...................

协程和进程线程是不同的东西，
协程最大的有点有二
首选， 协程节省切换开销， 这个是最明显的好处， 但不是最大的。
最主要的好处是， 它不像线程， 线程是抢占式的多任务， 而协程是协同多任务，
抢占多任务， 虽然简单粗暴， 但是增加了时间片的来回抢夺开销。
而协同多任务， 不仅没有时间片导致的， 抢夺切换， 就是协同切换也可以有具体的应用逻辑来控制，
所以， 可以有最好的性能。当然， 坏处就是会增加程序设计的难度和复杂度。
目前的协程模型， asyn await 方式，  确实设计的简洁， 但是不优美， 甚至有时给一部分程序员
带来理解困难。
--
FROM 115.171.244.*

错
协程允许有锁，你这个锁的本质让一块代码是原子的，可以非常轻易的实现。
剩下的是实现问题，协程设计上就不应该允许跨线程进程。
实现上的问题不要怪设计。

【 在 ylh1969 的大作中提到: 】
:
: 错。
: 协程缺乏锁机制会出很多问题。
: 有人给协程写锁。
: 见2楼，多线程协程，有一个线程锁不允许跨越IO的要求。

#发自zSMTH@CDU.MP
--
FROM 113.143.105.*