将muduo协程化之后发现吞吐量提升了接近一倍

[zhngs]

陈硕大大，我将muduo按照有栈非对称协程化之后，发现discard程序吞吐量提高了接近一倍，协程使用的boost-context，epoll使用的边沿触发，项目地址 https://github.com/zhngs/baize ，希望能听一听您的见解。ps：感谢您的muduo库和书籍以及网络编程视频，我学到了很多东西

[chenshuo]

我对协程的看法： https://groups.google.com/g/muduo-library/c/OIFG8uF6-Bg/m/I2uO-zcCAgAJ

长话短说：首先，我认为 Go 的并发模型非常好用，写起来比基于事件回调的风格思路要顺畅许多；但是，我目前认为在 C/C++ 里搞用纯户态的 coroutine 没有前途。

coroutine 的本质是对 OS thread 的复用，好处是比 thread 更轻量（10 倍以上），memory locality 也更好，一个程序可以有几百上千的线程 vs. 几万的 coroutine。
坏处是 OS / monitor / debugger 失去对程序的观察力，例如 /proc/pid/task 看不到 coroutine，而且 thread-local storage 和 gettid() 也都废掉了。
比如我通过 OS 看到某个某个 thread 死锁或者 busy-loop，其实很难知道具体是哪个 coroutine 出了问题。
一般的 debugger 能看到 OS threads，但看不到你自己实现的 coroutines，特别是当前没有运行的 coroutine。
profiler 也不容易正确找出热点，因为看不到正确的 call stack trace。

根据我这几年所学，我认为正确的做法是让内核做上下文切换，但同时可以把调度的任务放到用户态，这样两方面的好处都占住了。

具体说来，如果 Linux 内核接受了 Google 的 switchto() 系统调用，那么 C/C++ 服务端编程就可以采用 Go 一样的编程模型，大家都轻松很多。

ref.
https://news.ycombinator.com/item?id=24084348
https://news.ycombinator.com/item?id=24688225
https://lkml.org/lkml/2020/7/22/1202
https://www.youtube.com/watch?v=KXuZi9aeGTw
https://technodocbox.com/Unix/67839755-User-level-threads-with-threads-paul-turner.html

ps. Google 内部用 switchto() 已经很多年了。这也是我对 C++20 里的协程不感兴趣的原因。

[shaocongliang]

请教一下“纯户态”具体指？我理解实现协程必须有调度、创建、销毁三个功能。所谓的纯户态是指把这三者都放在用户态吗？

[yinghaoyu]

orz

[microcai]

reactor 就没法实现协程。

协程解决的是什么问题？协程解决的是回调地狱的问题。
reactor都没有回调地狱问题，何来协程呢？

至于所谓的协程性能高。其实并不是协程性能高。而是 proactor 模型带来的性能高。协程是用来解决 proactor 模型容易有回调地狱这个缺陷的。
既然 muduo 是 reactor 模型，那么就没有回调地狱。没有回调地狱，就没有使用协程的必要。

哪怕 linux 真的搞了个 switchto, muduo 也是没法实现协程的

[LunarStore]

测试标准是什么？，经过了上线的考验吗？

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2024年12月5日(周四) 下午3:30 收件人: ***@***.***>; 抄送: ***@***.***>; 主题: Re: [chenshuo/muduo] 将muduo协程化之后发现吞吐量提升了接近一倍 (Discussion #620) reactor 就没法实现协程。 协程解决的是什么问题？协程解决的是回调地狱的问题。 reactor都没有回调地狱问题，何来协程呢？ 至于所谓的协程性能高。其实并不是协程性能高。而是 proactor 模型带来的性能高。协程是用来解决 proactor 模型容易有回调地狱这个缺陷的。 既然 muduo 是 reactor 模型，那么就没有回调地狱。没有回调地狱，就没有使用协程的必要。 哪怕 linux 真的搞了个 switchto, muduo 也是没法实现协程的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>