[asyncio随记一]asyncio的实现原理和关键源码分析

    最近在python3.7上用asyncio做项目,实现web的服务端,一边从GitHub和StackOverflow上抄代码,一边在看asyncio相关的源码,所学所思,姑且写在这里。

为什么会出现协程(coroutine)这种设计?

    多线程(thread)也是同时执行多个任务的一种设计,为什么有了多线程,我们还要设计协程,它有什么不同呢?

    首先,多线程的目的是什么?

    一种说法,利用多核的性能,让代码占用尽可能的计算资源,运行快一点。这算是个原因吧,我们简称为并行(parallelism)。在这里,我还不想抠字眼讨论并发(cocurrent)和并行。

    另一种说法,我们程序有些任务是cpu密集型(逻辑计算比较多),有些任务是IO密集型(读写文件或网络比较多),如果遇到IO密集型计算,比如从网站上下载一个大文件,这时候如果是阻塞下载,并且只有一个线程的话,程序的其他逻辑就无法执行,从这个程序的角度讲,他没能很好的占有cpu的资源,白白地等待下载的结束。如果开了另外一个线程的话,这个下载线程虽然阻塞掉了,但是别的线程依然可以跑别的逻辑,就可以更充分的占有cpu的资源。有人称同时执行不同的任务为并发。

(TODO? 图1 任务调度示意图)

    同样针对上面第二种问题,我们换个角度表述,我们有一个IO密集型任务,还有一个cpu密集型任务,我们想有效的运行这两个任务,不让IO密集型任务阻塞了cpu密集型任务,所以我们构造了一个任务调度器,当IO密集任务开始从网站上下载大文件的时候,我们把他从调度器上暂时移开,后面再去检查他,让调度器去执行cpu密集任务,在此期间我们可能会时不时的去检查IO任务有没有下载完毕(也可能是被动通知,如软件驱动的中断),如果发现完毕了,调度器可能会暂停当前的cpu密集任务,转而继续执行IO密集任务的后续工作。在多线程环境下,这个调度器就是操作系统,两个任务是两个线程。而协程,就是这个思路,只不过设计的更加极端一点,我们在多线程环境下,几乎不可能手动地控制先执行什么线程,再执行什么线程(只是操作系统的调度工作),而如果我们专门写了一个任务调度器,我们自己实现应用层面的调度算法,就可能实现先执行什么任务,再执行什么任务,什么时候暂停一个任务,什么时候恢复运行这个任务。这个可控的调度机制,就是协程。他的初始目的就是实现任务的并发,只不过想更加精细地控制任务的暂停和继续。协程是种设计思想,线程是计算机实现多任务的一种工程机制,线程可以用于实现协程。

asyncio的模样

    我们先杜撰一段代码应景。

图2 调度器和两个任务

    如图2所示,我们用async def定义了两个函数,一个下载大文件,一个做一些逻辑运算。然后我们实现了一个调度函数,在调度函数里,我们分别用两个任务函数创建了两个任务,加入到asyncio的event loop里面,接着,我们运行这个event loop,这样,两个任务就开始执行起来了。注意,async with和await的时候,都是执行一个异步函数的过程,这个时候,当前任务会主动让出event loop,去后台执行一些网络IO,event loop会选择自己等待队列的任务继续执行。等原来网络IO的任务结束网络IO,他会重新加入到event loop的等待队列,等待其他任务主动让出event loop,被动等待调度。比如self_play在执行await asyncio.sleep(3)的时候会主动让出event loop

    上面我特别强调了主动让出event loop,这是协程的核心思想,如果一个任务没有任何await或async with逻辑,那么它一旦执行,别的任务再也没有机会被调度到。比如,我们如果去掉self_play的await语句,整个event loop将永远被self_play所占用,其他任务再也没有机会执行,整个输出只有左右右手慢动作了。总之,爸爸不给,你不能抢。这一点和朴素的多线程很不一样。

asyncio实现原理推测

    从上面的介绍,我们可以大概猜出,asyncio主要有一个任务调度器(event loop),然后可以用async def定义异步函数作为任务逻辑,通过create_task接口把任务挂到event loop上。event loop的运行过程应该是个不停循环的过程,不停查看等待类别有没有可以执行的任务,如果有的话执行任务,直到碰到await之类的主动让出event loop的函数,如此反复。

(TODO? 图3 event loop调度示意图)

asyncio源码分析

    更进一步的问,evnet loop大致是怎么实现的呢?怎么进行调度的呢?

    我们顺藤摸瓜,在asyncio/base_events.py里面我们看到了create_task的源码实现,代码的关键是Task的构造,传了一个event loop(loop参数)进去,也就是在这个时候,task注册到了event loop上面。注册过程是c实现的(见文末附录1),但本质上都是通过event loop的call_soon()。

图4 create_task的实现

    图5,是run_forever的实现,基本上是不停的在循环,然后每一个循环执行一帧(_run_once)。

图5 run_forever()的实现

    图6是每一帧的代码实现,基本上是在调度队列里找到这一帧应该执行的任务(任务最终注册在event loop的结构是Handle,通过call_soon()实现),直接_run()。

图6 event loop每一帧的逻辑实现

    event loop的call_soon,是注册任务时使用的,字面意思是下一帧执行当前注册的任务。它的本质就是把当前任务封装成Handle,放到_ready里面,如图7所示。

图7 注册任务的最终实现

    调度队列是event驱动形成的,这也是为什么asyncio的核心叫做event loop。这部分代码同样也在_run_once()里面,见图7,这个select就是某种多路复用机制,比如select,epoll和iocp。

图8 event loop处理消息流程

    图8给出了select机制下的selector.select实现,看起来是不是有点熟悉啊。消息处理相关我们后续在常用接口里会再次提到。

图9 select模式下的消息归集

总结一下asyncio的实现思路

    有一个任务调度器event loop,我们可以把需要执行的coroutine打包成task加入到event loop的调度列表里面(以Handle形式)。

    在event loop的每个帧里面,它会检查需要执行那些task,然后运行这些task,可能拿到最终结果,也可能执行一半继续await别的任务,任务之间互相wait,通过回调来把任务串联起来(后面常用接口会继续深入介绍,实现细节见附录2)。

    任务可能会依赖别的IO消息,在每一帧,event loop都会用selector处理相应的消息,执行相应的callback函数。

    我们当前的介绍里,只有一个event loop,这个event loop跑在主线程里面。当然,event loop还可以开线程池处理别的任务,或者,多个线程里执行多个event loop,他们之间还有交互,我们这里不在介绍。   

    单个event loop跑在单个线程有个好处,只要自己不主动await,就会一直占有主线程,换句话说,同步函数一定没有数据冲突(data racing)。对比多线程方案,如果需要处理数据冲突,就需要加锁了,这在很多情况下会降低程序的性能。所以协程这种设计思路,非常适合有多个用户、但是每个用户之间没有共享数据的场景。如果需要实现并行,多开几个进程就行了。

    但是实际上在工程里面,我们很难单用一个线程处理问题,asyncio也不例外,特别在集成别的同步库的时候,可能需要用到别的线程,我们后续介绍。


后续笔记

asyncio常用接口及其意义(实用主义)

如何集成asyncio和同步库(介绍executor线程池对event loop的影响)

为什么异步编程容易犯错(数据冲突)


不适宜骚年的附录

1. Task的构造的c实现

    我们打开男性社交网站,这是event loop实现的核心代码。在这里我们找到了task的c实现_asyncio_Task___init___impl(L1933),它的核心代码执行ask_all_step_soon,间接调用脚本的event loop的call_soon,并且把自己加入到all_task这个全局list(通过register_task,主要是后面索引使用)。

图10 task构造函数实现

2. task执行细节

    task的执行,实现在task_step(L2878)和task_step_impl(L2540)  。其中task_step是asyncio任务执行的核心,对于一个coroutine,每次task_step得到一个结果,然后根据结果判断是否拿到了最终结果,或者需要继续计算等待别的结果,或者把结果扔给自己的waiter。

    python的await都是通过generator实现的,具体的计算在genobject,主要是通过PyEval_EvalFrameEx拿计算结果。

推荐阅读更多精彩内容