advance/async/getting-started

[giscus[bot]]

advance/async/getting-started

https://course.rs/advance/async/getting-started.html

[fengbianyun]

CPU 密集的任务很可能会一直霸着着【修改为：霸占着】 CPU。

[Jamesinit]

感觉同时载歌载舞这个例子并没用很好的体现出异步来。
他的执行结果还是顺序的啊。
我尝试在各个函数加打印，发现还是顺序执行的。
在sing_song之前加sleep，也并没有先执行dance，有点迷惑。
我理解是当sing这个sleep，另一个dance不应该先执行，这样才是同时载歌载舞吗？

[duanyuluo]

我的理解，async并不是多线程，而是在当前线程内切换任务（Future），所以，如果调用thread sleep就会挂起整个线程，这个和你声明async的机制是冲突的。

[duanyuluo]

async_std::sleep返回的也是一个Future，所以，这个函数并不是挂起当前线程，而是切换到其他Future执行了，比如这个例子中的dance。

[zhenxingliu]

结合了一下下面的打印线程ID例子,这些个Future是在同一个线程执行,就是一个M:N的模型.

[suningzh]

你好像少了一个Rap

[jockchou]

这里的异步是在单线程（Main线程）上做异步，你用Thread.sleep是整个Main线程都阻塞挂起了。
异步是指Main线程上有2个IO操作耗时，async异步函数会创建2个Futuer，这2个Futuer任何一个执行不会阻塞别一个。

[MrZLeo]

而且 Rust 也不允许你在特征中声明 async 函数(可以通过三方库实现)

[MrZLeo]

现在的Rust支持在特征中声明async函数了！

[kingwingfly]

曲婉婷的例子可以改一改，毕竟有争议（滑稽

[Rgoogle]

这个例子不好说明，应该异步要体现出顺序不一致

[sunface]

现在貌似是周杰伦 🤣

[lieren1922]

就是，这个例子加上一个sleep就比较好，参见上面的 QIN2DIM 例子。

[iscas-zac]

第一部分的

OS 线程

和

多线程

建议统一一下，用同一个术语来指代

[PPhoss]

菜鸟提问：block_on( ) 阻塞当前线程的意思是 会创建一个新的线程来运行future吗？

[kingwingfly]

不会，都是在同一个Runtime里面。

[bxb100]

我就是回来提醒你们 rust 即将支持 async trait 意味着将可以在堆中存放异步状态

[DAIMENGEN4]

个人理解如下：

首先，future并不是多线程。

Rust多线程编程的情况如下：

线程 （通过 thread::spawn 创建的） CUP
语言线程A -------------> OS线程1
语言线程B -------------> OS线程2
语言线程C -------------> OS线程3
语言线程D -------------> OS线程4

备注：一旦语言线程通过 thread::sleep 方法被阻塞，说明 OS 线程被阻塞。

anync await 编程

future_A -------> 语言线程A -------> OS线程1
future_B -------> 语言线程A -------> OS线程1
future_C -------> 语言线程A -------> OS线程1
future_D -------> 语言线程A -------> OS线程1

备注：调用 future_A 的 await 方法并不会阻塞语言线程A，此时的语言线程A还可以继续执行 future_B,C,D.。

猜测：如果，语言线程A里面的 所有 futrue 都处于 await 状态，语言线程A应该是处于了阻塞状态，也是会产生线程的上下文切换的。关于这个问题，还在研究中。

[guqihao-7]

你好，请问 future 是否就类似于协程？Rust 线程（您提到的语言线程）切换 future 是否就相当于协程切换，整个过程中无上下文切换？

[TsGanT]

我有一个例子，可能可以更简单的说明一个线程中运行多个future（task）的case：(交替打印结果，await阻塞当前task但不阻塞线程；)

[dependencies]
futures = "0.3"
[dependencies.async-std]
version = "1.7.0"
features = ["attributes"]

use core::time;
use std::time::Duration;

use async_std::task;
use futures::{executor::block_on, join};

async fn hello_world() {
    for j in 0..10 {
        task::sleep(time::Duration::from_secs(3)).await;
        println!("hello, world!: {:?}", j);
    }
}

async fn hello_cat() {
    for i in 0..10 {
        task::sleep(Duration::new(1, 0)).await;
        println!("hello, kitty! : {:?}", i);   
    }
}

async fn async_main() {
    let future1 = hello_world();
    let future2 = hello_cat();
    join!(future1, future2);
}

fn main() {
    let f = async_main();
    block_on(f);
}

[liushichuan]

[package]
name = "async_exp"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
async-std = "1.12.0"
futures = "0.3"

use std::time;

use futures::executor::block_on;

fn main() {
    block_on(test())
}

async fn sing() {
    async_std::task::sleep(time::Duration::from_secs(1)).await;
    println!("sing! {:?}", std::thread::current().id());
}

async fn dance() {
    println!("dance! {:?}", std::thread::current().id())
}

async fn test() {
    let sing = sing();
    let dance = dance();

    futures::join!(sing, dance);
}

可以打印一下线程id

[TsGanT]

这一章翻来覆去看了三遍，我怎么感觉最后真正实现并发的，是join啊！其他的什么async await其实就起到一个标记作用，更多的可能是给编译器看的，表示这部分代码 可以 被并发的执行；但是真正去实现并发的还是join！，因为他可以同时等待多个异步任务。其他那些等待单个异步任务完成的选手，那执行起来就还是有点像同步。。。

[TableBear]

join! 宏只是等待Future执行完成而已，并没有实现并发。async await 确实是一个标记作用，编译器会将对应函数和函数调用封装成Future，然后交给async 运行时去调度执行，这才是真正开始了并发。你说的其他等待单个异步任务的应该是block_on和await。block_on在文章中确实是会让Future同步，但是await则不同两个不同Future中的await 实际上还是可能异步执行的。以上是个人见解

[ADkun]

.await我理解是可以让出当前线程的使用权，让调度器可以进行调度。
调度器有可能执行当前的任务，也可能执行其它的任务，再回来执行当前的任务。

[tsingroo]

很像go里面的goroutine协程实现，底层跟线程也是M:N对应。并且在新版本对调度进行优化，不会产生让协程饿死的情况

[tsingroo]

从语法和使用上来看，几乎和javascript的async/await语法一样

[vince-1998]

因此.await对于实现异步编程至关重要，它允许我们在同一个线程内并发的运行多个任务。
这句话太关键了，有时候不注意看会走很多弯路。。。。。

[vince-1998]

https://blog.csdn.net/vince1998/article/details/138422536?spm=1001.2014.3001.5501 大家可以看看我写的博客，对作者代码进行了进一步的详细解释

[guqihao-7]

这么读下来，感觉 async 标记的代码块就是协程啊，多对一映射到一个 Rust 线程，Rust 线程和 OS 线程又是 1：1。同时因为 async 标记的语法块会被转换成实现了Future特征的状态机，async 代码块切换感觉就是协程切换而不是线程上下文切换，所以性能高点。
不知道上述理解是否有误，烦请指正。

[TableBear]

我觉得没毛病👍

[duanzihe]

我以前也这么觉得，就是为了减少阻塞切换线程的开销，在一个线程里分几个“任务”来切换；但是据说负责管理“任务”的是全局的异步进行时，它可能会把任务分配给线程池里的其他线程。在这里感觉可能不是单纯的多对一关系，涉及到线程池中负载均衡，可能要看具体的“异步运行时”是怎么实现的，我在这里就陷入疑惑了，然后再往里看又有点太深，暂时就止步于此了

[hamster0523]

就是

[YdayangY]

async为什么不会引起线程上下文切换？我理解的是，如果线程A的cpu时间片用完了，线程B开始执行就会导致线程切换。

[TableBear]

async 的task之间切换不是线程之间切换，它是用户线程主动切换task去执行，这样自然不会引起线程上下文切换。你可以理解为一个线程本来在执行A任务，A卡住了，然后去执行B任务。

[YdayangY]

明白了，谢谢。

[wzwmzm]

async, await, future 都是用来注册任务的, 只有join!(A, B, C,,,)标记过的任务间可以互相切换, 任务如何安排到线程由rust完成, 线程如何调度由OS完成

[duanzihe]

在learn_and_song这个任务因learn_song（虽然例子里的await其实跟没有差不多，因为只是learn_song只是返回一个对象，会立刻完成。但假设学歌是一个需要很长时间的异步操作）被await而挂起后，线程不会阻塞，而是去执行另一个异步任务dance，等到learn_song在后台完成了，才会继续进行learn_and_song。

[bellingham07]

我看很多地方，都在拿rust和go做比较，这是不是说明，go其实也可以

[Austin-Patrician]

使用.await 章节，futures = "0.3.31" ,并不会提示warning.

[KyonQi]

在async fn函数中使用.await可以等待另一个异步调用的完成。但是与block_on不同，.await并不会阻塞当前的线程，而是异步的等待Future A的完成，在等待的过程中，该线程还可以继续执行其它的Future B，最终实现了并发处理的效果。

这一段还是没看懂什么意思，在申明了async fn的函数内异步等待使用了.await的函数，我的理解是await相当于往调度器注册了这个函数并交给调度器做调度，那一个async fn内多个await函数是怎么保证顺序执行的呢？换句话说，我的疑问在于，既然是异步等待，怎么保证例子中是先learn_song再sing_song的呢？

[bxb100]

你仔细想想你如何启动多个 thread 的

[TableBear]

前面的.await先注册，等这个await的执行完再推进async fn里后面的.await语句，不会前面还没执行完就推进下面的。在await期间，线程可以放弃这个Future（或者说async fn），去执行其他Future

[KyonQi]

你仔细想想你如何启动多个 thread 的

意思是内部会有queue保证执行顺序吗，如果是这样那恍然大悟了

[KyonQi]

前面的.await先注册，等这个await的执行完再推进async fn里后面的.await语句，不会前面还没执行完就推进下面的。在await期间，线程可以放弃这个Future（或者说async fn），去执行其他Future

这样一说，思路理清了不少，感谢

[kraymond37]

文中提到async 代码的执行由社区的 async 运行时提供，例如 tokio 和 async-std，但是例子中并没有看到引用 tokio 或 async-std，实际上 block_on 就是一个最小化的运行时，看 block_on 的注释可以看到它是在当前线程运行，如果用 tokio，可以配置单线程或多线程。

[duanzihe]

忽然有点疑惑，如果一个线程里只剩了一个future,那这个future被await挂起了，线程又找不到其他的future,是不是只能空转？这样的话会不会比线程阻塞还糟糕啊？
这种情况是怎么解决的呢？线程会阻塞自己？还是说执行器会分配给他合适是future去执行呢？

[aakejiang]

若大家使用 tokio，那 CPU 密集的任务尤其需要用线程的方式去处理，例如使用 spawn_blocking 创建一个阻塞的线程去完成相应 CPU 密集任务。

至于具体的原因，不仅是上文说到的那些，还有一个是：tokio 是协作式的调度器，如果某个 CPU 密集的异步任务是通过 tokio 创建的，那理论上来说，该异步任务需要跟其它的异步任务交错执行，最终大家都得到了执行，皆大欢喜。但实际情况是，CPU 密集的任务很可能会一直霸占着 CPU，此时 tokio 的调度方式决定了该任务会一直被执行，这意味着，其它的异步任务无法得到执行的机会，最终这些任务都会因为得不到资源而饿死。

而使用 spawn_blocking 后，会创建一个单独的 OS 线程，该线程并不会被 tokio 所调度( 被 OS 所调度 )，因此它所执行的 CPU 密集任务也不会导致 tokio 调度的那些异步任务被饿死

这一段咋没看懂呢，spawn_blocking 不就是tokio创建的吗，到底是要用tokio创建线程还是不要？

[cctga]

这些个例子也就看看语法，async 看不出来有什么作用，因为这里的任务都是密集任务，没有阻塞等待休息时间，但是也不能使用 sleep 和 wait 来模拟，因为 sleep 和 wait 对线程的操作对于 async 来说是矛盾的，因为 async 的 await 并不是线程的 wait，sleep，wait 对于 async 平台来说也是需要做的任务，只是该任务不需要 CPU，但是 async 平台不知道，所以到底做没做任务，做了，只是做的是休息任务
要看到 async 真正的作用，还需在 io 中，在 io 才可以真正的休息，如网络 io，在等待后台回复的时候就可以休息，可以去做其他的任务，在磁盘 io 的时候，如果操作系统支持异步 id，就可以休息，去做其他任务