手撸一款简单高效的线程池(五)

原创
2021/09/06 09:29
阅读数 155


在之前的内容中,我们给大家介绍了 C++实现线程池过程中的一些常用线优化方案,并分析了不同机制使用时的利弊。这一篇,是线程池系列的最后一章。我们会介绍一下 CGraph 中的 threadpool 如何使用,给出性能对比,并对接下来的工作做一些展望。让我们在线程池性能优化和功能提升的道路上,越走越远。

大家好,我是不会写代码的纯序员——Chunel Feng。各位绅士们,很高兴又在这里跟大家见面了。

在之前的几篇文章里,我们先是讨论了原生 C++对多线程编程支持的匮乏,然后又分别从线程调度层面和工程实现层面,给介绍了一些线程池优化的实用思路,主要包括:local-thread 机制、lock-free 机制、work-stealing 机制、自动扩缩容机制、批量处理机制、负载均衡机制、避免 busy-waiting、分支预测优化和减少无用 copy。真心希望以上内容,会对大家有所帮助。

本章内容,是这个线程池系列的最后一章。我们会先介绍一下 CGraph 中 threadpool 的使用 demo,并提供出来实测的一些数据,来佐证我们之前的各种努力,的确达到了优化的效果。同时也会畅想一下今后可能的优化方向和扩展点,算是从起因、经过、结果和展望这几个大的方面,形成一个完整的“闭环”吧。

首先,还是照例,先上源码链接:CGraph 源码链接[1] 其中,线程池的实现在 /src/UtilsCtrl/ThreadPool/ 文件夹中

使用 Demo

首先,来看一个简单的使用 demo 吧。

我们在线程池优化第一章中,立 flag 的时候说过,threadpool 要可以支持任意入参和返回值的任务执行,并且简单好上手。下面这段代码,分别定义了 4 种不同类型的函数:普通函数,静态函数,类成员函数,类成员静态函数

int add(int i, int j) {    return i + j;}static float minusBy5(float i) {    return i - 5.0f;}class myFunction {public:    std::string pow2(std::string& str) const {        int result = 1;        int pow = power_;        while (pow--) {            result *= (int)atoi(str.c_str());        }        return "pow2 result is : " + std::to_string(result);    }    static int divide(int i, int j) {        if (0 == j) {            return 0;        }        return i / j;    }    int power_ = 2;};


下面一段代码,主要展示了如何通过 CGraph 中的 threadpool 来执行以上几种函数,并且说明了如何做阻塞等待。

void tutorial_threadpool() {    UThreadPoolPtr tp = UThreadPoolSingleton::get();    // 通过单例方式获取    int i = 6, j = 3;    std::string str = "5";    myFunction mf;    /**     * 可以通过lambda表达式传递函数     * 也可以传入任意多个参数     * 方法返回值也可以是任意类型     */    auto r1 = tp->commit([i, j] { return add(i, j); });    auto r2 = tp->commit(std::bind(minusBy5, 8.5f));    auto r3 = tp->commit(std::bind(&myFunction::pow2, mf, str));    std::future<int> r4 = tp->commit(std::bind(&myFunction::divide, i, j));    // commit()返回值,实际上是一个std::future<T>类型    /**     * 返回值可以是intstring等各种类型     * 调用get()方法,表示阻塞等待该函数执行完毕     * 不调用get()方法,表示不阻塞等待     */    std::cout << r1.get() << std::endl;    // std::cout << r2.get() << std::endl;    // 不阻塞等待该函数执行完毕    std::cout << r3.get() << std::endl;    std::cout << r4.get() << std::endl;}

代码行数不多哈,整体也比较 easy,也没啥好说的。从我实际做(B)开(U)发(G)的经验来说,支持以上这几种函数,就可以完成基本所有方法的调度了。

需要强调的一点就是,针对 threadpool 这一块,我进行过亿次以上的任务写入测试,功能也都是稳定可靠的。

性能对比

一波骚操作之后,我们终于还是要出一下性能测试报告的。在这里捏,我最后说一遍,多线程实际执行的情况复杂,实际性能数据需要带入实际环境大量实测。

我们接下来的测试数据,主要就是跟最常见的one input, one output的 threadpool 写法进行对比,具体链接我就不上了,大家 github 或者*乎上直接搜索一下就好。

测试的方法呢,主要就是高并发大批量空跑return 0;的任务,从而考察线程池的调度能力。还有要说明的,就是实验结果并非单纯测试线程池本身,而是通过在 CGraph 框架中,并发跑 并发数 个任务,然后等待批量任务执行完毕后再跑下一轮,一共跑 执行次数 轮。

void cgraph_threadpool_test() {    CGRAPH_ECHO("cur thread size is [%d], and max thread size is [%d].", CGRAPH_DEFAULT_THREAD_SIZE,CGRAPH_MAX_THREAD_SIZE);    GPipelinePtr pipeline = GPipelineFactory::create();    int thd = 2;    int times = 5000000;    for (int i = 0; i < thd; i++) {        GElementPtr ptr = nullptr;        // 其中,HelloWorldNode执行内容为:return 0;        pipeline->registerGElement<HelloWorldNode>(&ptr);    }    time_t start = time(nullptr);    pipeline->process(times); // 运⾏pipeline    time_t end = time(nullptr);    CGRAPH_ECHO("[%d] node for one time, run [%d] times, ts is [%d].", thd, times, end-start);    GPipelineFactory::destroy(pipeline); }

由于常规线程池并不包含自动扩缩容机制,在测试过程中,也是保证 CGraph 中的线程数量 max 和 default 值也设置为相同的。

测试的结果,更多是在比较 CGraph 在使用传统线程池和优化后的线程池时,空跑调度任务的性能差距。旨在说明以上提出的优化方案切实有效。以上所有结果,均验证 2 次以上,不同配置的机器上可能略有差别。

在这里,也给大家推荐其他几个 C++常用的并行库:openmptbb等,还有很多国内互联网巨头公司提供出来的相关开源组件,使用起来都很简单,大家也可以去尝试看看。

void myPrint(int x) {    std::cout << x << std::endl;}void openmp_version() {    /* openmp版本,并发打印0~99 */    #pragma omp parallel for num_threads(4)    for(int i = 0; i < 100; i++) {        myPrint(i);    }}void tbb_version(){    /* tbb版本,并发打印0~99 */    tbb::parallel_for(0, 100, 1, myPrint);}void cgraph_version() {    /* CGraph版本,并发打印0~99 */    UThreadPoolPtr tp = UThreadPoolSingleton::get();    for (int i = 0; i < 100; i++) {        tp->commit([i] { myPrint(i); });    }}

并发编程是一个很常见的话题。通用的方法很多,也各有优劣,建议大家在选择和使用的时候多思考,多比较。在成长的过程中,不是很建议陷入那种“这个项目之前就是用的 xx 方法,所以我也就用了”的怪圈。当然,如果在现实工作中,考虑到功能稳定性、一致性、快速迭代和可维护性的话,那就是另外的话题了。

TODO

以上说了这么多,都是在说好的地方:做了哪些优化,加了哪些功能。在快要结束的时候,也要总结一下,CGraph 中的 threadpool 中还有哪些功能的缺失和不足

任务优先级

我们之前提过,local-thread 机制和批量执行机制,会使得 threadpool 中的任务执行顺序,和实际写入顺序变的不一致。关于这一点,我们提供了CGRAPH_FAIR_LOCK_ENABLE参数(默认为false),如果设置为true则任务执行顺序和任务写入顺序保持一致。

不过,还有一个很实际的问题:有些情况下,不同任务的优先级就是不同的,优先级高的任务,理应优先被执行。这个时候,线程池中任务的存储方式就应该从queue改为priority_queue了,当然肯定还会牵扯到一些其他的改动,有兴趣的话可以尝试去实现一下。

拒绝策略

任务写入 threadpool 中,是瞬间的动作,但是有些任务执行起来就需要很长的时间,比如:sleep(100);。当线程池中源源不断的写入大量任务,却无法及时消费的时候,是可能引发各种意想不到的问题,甚至程序崩溃的。所以,一个优秀的线程池中还应该有拒绝策略,比如:内部未执行任务超过 1 爽(约 208w)之后,就外部任务就无法继续写入了。

拒绝策略,又可以区分为严格的拒绝策略和宽松的拒绝策略。严格,主要体现在写入任务的瞬间,如果 pool 中的任务数量正好是 1 爽的时候,就拒绝;宽松,就可以是 pool 中的任务数量超过 1 爽之后的若干秒后,pool 开始拒绝外部写入,直到其中任务被消费到小于 1 爽之后的若干秒后,又恢复正常。

严格和宽松,没有绝对的优劣之分,只有各自适合和不适合的场景。如果有时间,可以尝试去实现一下。

加入 cas 机制

我们之前也提过,cas 属于无锁编程技术的一种。再次申明,并不是通过无锁编程的实现方式,性能就一定高于有锁编程。不过,这也是一个很值得尝试的优化点,而且理论上有相对更优的性能。等排期哦哦哦,哈哈。

线程绑定运行

我们之前聊过一些线程亲和性的问题。没提到的一点是,一个线程是可以绑定在特定 cpu 核上运行的,这样做也可以一定程度上提升亲和性。这个功能在 Linux 上实现相对简单,但是我并没有找到什么跨平台的方法来实现这个功能。有兴趣的朋友也可以自己试试看。

本章小结

本章节是我们关于线程池优化的最后一篇了,我把个人对线程池的理解,基本上都写在了这几篇文章里了。并发编程本身博大精深,而个人水平和时间都有限,有些地方没能讲解的非常深入。在写文章的过程中,也竭尽全力对自己的每一处内容做了验证,力求正确无误,却仍可能存在一些认知的盲区和错误的描述,希望大家不吝指教。

虽然还存在诸多的不完美,但还是非常开心能从一而终的把代码和文章写完,并在 github 上和这里跟大家分享。C++ 线程池我之前在工作中用到过,但是并没有做过什么优化和改进。通过这一个月自己闲暇时间的摸索和学习吧,我个人是有了一些自己的积累和进步,也希望可以通过分享,对大家有一丝的帮助和启发。

在这个过程中,也有幸得到了阿里云、搜狗和旷视等一流公司资深大佬的一些指导,在这里再次深表感谢。  如果说自己的既有行动是“99%的努力”的话,那高人的点拨更像是“1%的灵感”,让我受益匪浅,足以提升一个层次,今后还请多多指教。

也要感谢我们产品的童鞋,你并没有什么超前的意识,所以也提不出来什么过分的需求,让我在日常工作之余还有一些自己的时间,来做相关的事情。还要感谢我身边的一位同事,在间歇性架构升级和持续性相互撕逼的常规操作中,默默的帮我挡掉了一些小小的需求。今后的日子里,两位多多保重,去你们的(更广阔的舞台)吧,哈哈。最后,更要感谢我的女神,在这期间一直不回我微信,也约不出来,好让我有了足够多的时间来撸代码和写文章。

最近,也通过写博客和公众号,认识了不少新朋友。很高兴认识大家,很感谢大家的关注和一键三连。同样感谢几位朋友的打赏,就像一杯午后的咖啡,不贵,但很暖心。

最后的最后,下面是我的微信二维码,欢迎大家加我微信,随时交流聊天,多多指教。添加的时候,请加上简单个人备注信息,不然的话,一律标注为“大姨妈介绍的第 N 个相亲对象” ——我会时不时去撩你的哦,嘿嘿。

推荐阅读

如何实现一个图化框架?代码已开源!一文看懂开源图化框架中的循环设计逻辑!手撸一款简单高效的线程池(一)手撸一款简单高效的线程池(二)手撸一款简单高效的线程池(三)手撸一款简单高效的线程池(四)

引用链接

[1] CGraph 源码链接: https://github.com/ChunelFeng/CGraph



长按识别下图二维码,关注公众号「Doocs 开源社区」,第一时间跟你们分享好玩、实用的技术文章与业内最新资讯。



本文分享自微信公众号 - Doocs开源社区(idoocs)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部