Kotlin coroutines are a concurrency design pattern used to simplify asynchronous code, but not native threads.
两个tasks是怎么在同一个thread上提供并行的?
版主: hci
Kotlin coroutines are a concurrency design pattern used to simplify asynchronous code, but not native threads.
两个tasks是怎么在同一个thread上提供并行的?
noid2 写了: 2025年 9月 25日 21:00Kotlin coroutines are a concurrency design pattern used to simplify asynchronous code, but not native threads.
两个tasks是怎么在同一个thread上提供并行的?
There are two types of routines:
call and then return
call, yield, send, yield, send, ..., return
coroutine operates like a synchronized thread coordinated by its caller.
You can use coroutine to implement concurrent programs to avoid delays due to blocking IO operations.
That is, when you need to make a blocking IO call, you yield to your caller until the IO call returns.
async/await primitives make it easy to use coroutine for asynchronous computation.
我的问题不是怎么用,而是
两个tasks是怎么在同一个thread上提供并行的?
Attach the tasks to a thread? 那又怎么提供tasks之间的并行呢?虚拟机上有tasks的调度算法?
or other ways?
对
noid2 写了: 2025年 9月 26日 17:08Attach the tasks to a thread? 那又怎么提供tasks之间的并行呢?虚拟机上有tasks的调度算法?
or other ways?
noid2 写了: 2025年 9月 26日 17:08Attach the tasks to a thread? 那又怎么提供tasks之间的并行呢?虚拟机上有tasks的调度算法?
or other ways?
这个和虚拟机没没关系。
这也不是并行运算。
并行运算时两个线。
这个是一根线,不过是主动的交换控制权。是一种合作式的concurrency.
Concurrency != parallelism
All parallel programs are concurrent but not all concurrent programs are parallel.
wildthing 写了: 2025年 9月 26日 18:44这个和虚拟机没没关系。
这也不是并行运算。
并行运算时两个线。
这个是一根线,不过是主动的交换控制权。是一种合作式的concurrency.Concurrency != parallelism
All parallel programs are concurrent but not all concurrent programs are parallel.
主动的交换控制权,哪个机构控制这个主动?
合作式的交换控制。
coroutine yields control to caller, caller restarts coroutine until it reaches the next yield point.
This does not require a central scheduler. It is entirely based on the execution semantics of coroutine and its caller.
This is not threading, which does require a scheduler to wake up sleeping thread, preempting running thread, putting blocking threads to sleep, etc.
You can think of coroutine as manual threading if you will.
wildthing 写了: 2025年 9月 26日 20:47合作式的交换控制。
coroutine yields control to caller, caller restarts coroutine until it reaches the next yield point.
This does not require a central scheduler. It is entirely based on the execution semantics of coroutine and its caller.
This is not threading, which does require a scheduler to wake up sleeping thread, preempting running thread, putting blocking threads to sleep, etc.
You can think of coroutine as manual threading if you will.
caller控制交换?yield point是哪里,end of suspend function? 还是要插入一些语句,什么语句?
如果不插入这些语句,那就一直运行到task结束,或者thread被换出?
noid2 写了: 2025年 9月 26日 21:08caller控制交换?yield point是哪里,end of suspend function? 还是要插入一些语句,什么语句?
如果不插入这些语句,那就一直运行到task结束,或者thread被换出?
Consider the Fibonacci function below. f is a coroutine (or more accurately, a generator since it only emits values).
'yield a' is the yield point of the coroutine.
f will run to the yield point, each time 'next(f)' is called. There is no thread here. The control of execution switches between the for loop and the body of fib() until the loop completes and stop calling 'f'.
The main program will continue after the loop completes but 'f' will remain in suspended mode until it is garbage collected.
def fib():
-- a, b = 0, 1
-- while True:
----- yield a
----- a, b = b, a + b
f = fib()
for _ in range(0,10):
-- print(next(f))
就是引擎或者类似的东西控制的
属于语言的一部分
不是os threading
就是把code block和变量存起来存在一个一个地方
然后运行别的
有个callback
Callback 运行完了就跳到那个存起来的code block

我的理解无论是多线程还是多进程,尤其是线程涉及系统调用--读写文件socket etc。都依赖于进程协调的信号或中断机制。传统大型机无论是软件架构和硬件架构都能保证协调的信号或中断机制的可靠性。
把这一机制移植到PC架构(特指硬件架构),我从来没有看到过任何文章验证评测协调的信号或中断机制的可靠性。
所以,在PC架构上的并行prallel or concurrency 就是一个伪科学。
同时,也可以解释,你使用传统系统软件或网络编程教科书上的C代码例题,完全没有预期的输出。

heteroclinic 写了: 2025年 9月 28日 17:22我的理解无论是多线程还是多进程,尤其是线程涉及系统调用--读写文件socket etc。都依赖于进程协调的信号或中断机制。传统大型机无论是软件架构和硬件架构都能保证协调的信号或中断机制的可靠性。
把这一机制移植到PC架构(特指硬件架构),我从来没有看到过任何文章验证评测协调的信号或中断机制的可靠性。
所以,在PC架构上的并行prallel or concurrency 就是一个伪科学。
同时,也可以解释,你使用传统系统软件或网络编程教科书上的C代码例题,完全没有预期的输出。
当然不是说PC架构就不能协调同步了,就是本来操作系统该干的事情,把复杂度转嫁给了应用,比如一个复杂多种条件的大循环。
我也在想,如果coroutine有这么多优点,为啥不在OS那层去实现?

那就不是技术问题而是fitness了,当你刚刚大蒜较真的时候,你就应该立刻开始分发简历。
书就是在 网上白话白话。不负担任何责任。
当年书把这些都跟"zhuzhi”浇过心,组织上认为书是大放厥词。
希望"zhuzhi”不是针对我个人而是对于技术问题,拿出自己的校训,认证校正一下。
我和deepseek通了气,一会吃完饭,整理贴上来。本版往来五百定,不懂的话,回学校CS101走起。
希望大家互相吹捧提携,不要拆书的台。
所有系统设计都有两个目标,整体的资源利用率和方便的用户借口。侧重度不同,就有了这两三级的概念,进程,线程,goroutine
coroutine自己主动。比如等待io的时候,当前任务在得到结果之前做不了任何事,干脆主动把线程让出给其它coroutine运行。如果写个死循环之类的计算密集型任务,强行抢占线程不放,这套机制就失效了。所以协程一般用于网站后端之类并发高,计算量小的场景。
系统调度进程和线程需要考虑到公平性,不管线程里运行什么都有可能被系统强行踢出,释放资源给其它任务。古早的OS让一个线程永远占住CPU会导致整个系统锁死,DOS好像就是这样吧。
协程是轻量级、灵活、主动共享资源,线程消耗资源较大、被动接受OS管理,适用于不同的场景。
noid2 写了: 2025年 9月 25日 21:00Kotlin coroutines are a concurrency design pattern used to simplify asynchronous code, but not native threads.
两个tasks是怎么在同一个thread上提供并行的?
不写kotlin。不过原理好像是线程栈存在栈区,协程栈是放在堆区。