ThreadLoop实践学习笔记
背景在一样平常工作和学习源码过程中，经常可以看到ThreadLoop的运用，发现ThreadLoop作为一个基础工具，在具体项目中有差异而又十分相似的实现，虽然焦点的机制万变不离其宗（IO多路复用），但面向的业务场景差异导致了差异的实践结果，现在见过有几种ThreadLoop的实践，本文做一个分析记录和知识点的总结
基础TaskLoop：
面向Task：
Task类型包裹回调函数和必要数据，如have_run,is_run，task_tag等，TaskLoop负责实行Task，实质是处理Task类型包裹的回调函数
[*]焦点接口：PostTask(Task)、PostDelayTask(Task)、PostRepeatTask(Task)
[*]功能：用户将Task交给线程进行异步处理，同时实现简单的Timer机制，对任务触发的时间进行延迟或重复
[*]面向场景：工作线程实行Task
[*]缺点：仅能对Task进行处理，无法充分使用多路复用机制监听Socket或其他fd
[*]代码：TaskLoop-Task
面向Event：
Event类型和Task相比，拥有了变乱的语义，Event变乱=需要监听的触发源+变乱处理回调，一样平常来说触发源设计为Event Fd可以完善适配IO多路复用机制，同时仅监听Event fd可以给上层组件充足的灵活性，可以认为这是面向变乱ThreadLoop很优雅的设计方法了
[*]焦点接口：在面向Task的基础上，增加对变乱的监听AddWatch(Event)
[*]功能：提供文件形貌符监听的功能
[*]面向场景：变乱驱动，需要监听文件形貌符，例如Socket、Timer，上层仅需设计自己需要的Event即可实现定制化需求，例如进阶TaskLoop中的Timer就是很好的例子
[*]具体实践：
epoll+Event，基于epoll_data.ptr的指针完成监听变乱的处理，在Event中设定各类变乱（或指定变乱）的回调，muduo的channel就是基于这种机制设计的
[*]代码：TaskLoop-Event
注意：
Event类可以设计为基类，事件处理回调OnEventCallback可以通过识别Event的不同类型做事件的分发，完成Event内信息的传递，后续也可以通过基类->子类的转换，实现更多的任务处理和信息传递能力
讨论1：
除了poll多路复用+wakeupFd可以用于实现任务/事件队列，相似的也可以使用条件变量的方式做事件的同步，但条件变量有唤醒丢失和虚假唤醒等问题
相较而言FD的多路复用监听机制更加稳定，同时基于文件描述符监听的方式，可以增加基于Timer FD的功能
讨论2：
在具体的实践中，只要能完成实际的业务需求也可以不用解耦，可直接将业务逻辑回调写到secket fd触发后的逻辑中，设计Event来提供监听的统一接口是为了通用性，提供可复用接口给其他模块进阶TaskLoop
MsgQueue：TaskLoop+queue
基于TaskLoop，增加队列queue可实现一个异步的消息队列，提供PostMsg(msg)接口，MsgQueue初始化时绑定消息处理函数init(callback)，
[*]焦点原理：MsgQueue内部有一个变乱触发的Event，绑定到TaskLoop中进行监听，当用户调用PostMsg(msg)向内部的queue压入消息时，自动叫醒Event FD来wakeup TaskLoop监听中的文件形貌符，在Event叫醒的回调内取出queue积压的msg，调用提前绑定好的callback，完成消息的异步处理
[*]焦点接口：PostMsg(msg)
[*]面向场景：异步消息处理队列
[*]代码：MsgQueue
Timer：TaskLoop+Timer Fd
基于面向Event的TaskLoop，在Timer的场景下，AddWatch(Event)实质上是AddWatch(TimerEventFd)，因此只需要在AddWatch(Event)的基础上做TimerFd创建的封装即可
[*]焦点接口：AddTimer(Task)
[*]面向场景：定时器任务处理
[*]代码：TimerMng
ThreadLoopMng
线程池，维护多个ThreadLoop的生命周期，派发任务
[*]焦点接口：TaskLoop* GetTaskLoop()；
[*]面向场景：线程池管理工作线程，维护线程生命周期
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]