AsyncOS开发记录文档
本文最后更新于 2026年6月14日 凌晨
各阶段任务仓库
- 阶段一：爬虫 （已完成爬虫下载部分的初步实现，还需要补充性能分析）
Week1
这周的的会议主要交流了一下个人参加此次项目阶段的主要目的和想法。
由于时差，本人未能及时参会，故在此记录一下参加训练营的想法。
我是萨尔大学的本科大一学生，国内高考上了北京邮电大学的海南分校，对操作系统以及底层硬件相关很感兴趣，故报名参加此次训练营活动。现在主要还是在一个兴趣探索的阶段。这次在三个项目中，感觉异步 OS 的整体学习路径更为明确，也更符合我的兴趣，所以报名参加。
近期规划就是先按照要求，完成异步编程的相关实验，增强对 Rust 异步机制的理解与相关的代码开发经验。
5.20
完成了 Rust 爬虫的线程并发部分，使用了标准库的 std::thread::spawn 实现。
完成了 Rust 爬虫的进程并发部分，使用 curl 做为下载进程。std::process::Command 作为并发的实现。
5.21
完成了 Rust 爬虫的协程部分，使用了 tokio 作为 async 的运行时，达成协程并发的效果。
Week2
爬虫小结
最后的结果表：
| Model | Runs | Completed Avg | Failed Avg | Elapsed Avg (ms) | Throughput Avg (tasks/s) | Latency p50 (ms) | Latency p99 (ms) | Peak RSS Max (MiB) | RSS p99 (MiB) |
|---|---|---|---|---|---|---|---|---|---|
| process | 100 | 25.54 | 2.46 | 34.047 | 754.90 | 24.164 | 34.802 | 99.31 | 85.67 |
| thread | 100 | 25.63 | 2.37 | 11.683 | 2225.32 | 6.970 | 13.687 | 31.75 | 31.70 |
| async | 100 | 23.51 | 4.49 | 10.604 | 2228.50 | 5.641 | 10.616 | 30.38 | 30.28 |
评测机配置为 Macbook Air 13， M4， 16G内存。
一些问题和解决方法：
Process 反而最快
一开始在 WSL 上跑时，出现了 Process 的完成时间优于线程和协程版，推测原因为涉及大量的文件 IO，同时 curl 的实现可能会更好以及 WSL 本身 ext4 虚拟磁盘的原因。
因此，我再 Mac 上再次测试，得到了与预期相符的结果。
此外，为了防止 curl 的实现对实验结果的影响，将 process download 的实现改为了自己实现下载。
网络 IO 对结果的影响
学习刘卫同学的思路，先将所有请求 Cache 到本地，再将任务 URL 改为指向本地 HTTP 服务器的 URL，保证所有的任务的 IO 部分不会有太大的差别。
初探任务二
这周主要先看了《200行讲透 Rust Future》，学习了一下主要实现思路以及和如今 Rust 实现的对比。
就绿色线程来看，它基本就是 OS 的 Thread 在 User level 的实现。而 Rust 的 Async 模型则是采用了状态机作为最后的实现。相比而言，状态机更符合 Rust 的设计思想，即：
- 零成本抽象（编译器解决状态机编译）
- 无 GC / 精确控制内存与生命周期
- 适合系统编程
因此现在 Rust 采用了如今的 Async 实现。
Week3
优先级扩展
在 《200行实现Future中》 扩展了优先级支持，采用了分优先级队列并按等待时间提高优先级的策略。测出本实现在高优先级任务上强于 Tokio，平均运行时则是 Tokio 更强，符合预期。相关代码位置在这里
数据为 100 次运行的平均值，采用了任务一中的预缓存优化。
| Priority | Avg successful tasks (SF/Tokio) | SimpleFuture avg finish | SimpleFuture p50 finish | Tokio avg finish | Tokio p50 finish |
|---|---|---|---|---|---|
| High | 9.03 / 9.00 | 0.002 s | 0.002 s | 0.004 s | 0.002 s |
| Normal | 10.00 / 10.00 | 0.005 s | 0.005 s | 0.005 s | 0.004 s |
| Low | 13.00 / 13.00 | 0.008 s | 0.008 s | 0.005 s | 0.005 s |
| Overall | 32.03 / 32.00 | 0.006 s | 0.006 s | 0.005 s | 0.005 s |
初探 Embassy
Embassy 感觉可以理解为一个为嵌入式设备的设计的 “Tokio”。
传统 MCU 开发一般都需要 RTOS，手写状态机，但如果我们用了 Rust 的 async/await 的话，状态机是生成好的。
这样我们就能得到一个很契合 MCU 的一个操作流程，因为它：
- 不需要线程栈，减少浪费
- 内存大小编译期已知
- …
Week4
IPC 优化的历史研究
梳理了 IPC 的发展流程，尝试获取 IPC 优化的灵感。
StarryOS 的 IPC 部分研究
在阅读源码后发现，StarryOS 的 SysV IPC Message Queue 在用户态 ABI 上保持与 Linux 一致的同步系统调用语义，但其内核阻塞等待路径已接入基于 Future/Waker 的异步调度框架。
当 msgsnd 或 msgrcv 的执行条件暂不满足时，系统通过 WaitQueue::wait_if 构造 WaitIfFuture；若 Future 返回 Pending，当前任务被注册到等待队列并让出 CPU。待消息队列状态发生变化后，相应事件通过 Waker 将任务重新加入就绪队列，由调度器再次运行该任务并重新检查等待条件。
因此这部分能做的的工作可能还有：
- 优化锁颗粒度
- 精准唤醒
- 类似 L4 的 Lazy Scheduling 减少入队次数
- …
但总体实现本身已经是异步的了。
Tokio爬虫程序的动态分析
使用 Rust-gdb 对之前写的爬虫程序进行了动态分析。整体过程验证了我对 Rust 这套状态机异步的理解。具体总结在这里。