bthread的作用之一:将Reactor中的同步IO改异步IO。
理论上Reactor效率不如Proactor,具体表现在虽然Reactor模型避免了等待可读/可写事件就绪的时间,但是read/write调用本身的时间是不可避免的(即内核缓冲区和用户缓冲区之间的数据拷贝是占用当前线程CPU时间的),而Proactor却可以避免这个时间,所以效率更高。
那么为什么说Proactor效率更高呢?虽然Proactor不需要等待read/write本身,但只是把读写处理时间转交给了操作系统内核线程,总的处理时间并不会减少。
关键在于通过把read/write的时间转交给操作系统,当前线程可以继续去处理下一个连接,虽然总的吞吐量没有变化,但是每条请求的平均处理时延降低了。所以brpc中把IO操作交给新的bthread执行(https://github.com/apache/incubator-brpc/blob/master/docs/cn/io.md#%E6%94%B6%E6%B6%88%E6%81%AF)就相当于交给支持异步IO的操作系统去执行,它们都可以降低请求平均时延。
hook系统调用
有了异步IO和bthread的启示,我们会想到将所有会发生阻塞的系统调用都以这种方式改写,这就引出了hook。
简单来说hook库代码是对系统调用的包装,目的是当系统调用要阻塞时,不是直接阻塞当前线程,而是阻塞当前bthread,当前线程立即去执行另一个bthread,从而避免了线程阻塞。
这相当于把系统调用 + 线程的模型下放为hook后的系统调用 + 协程。(系统调用阻塞时发生线程切换,hook后的系统调用阻塞时发生协程切换,而协程切换开销小于线程,所以后者性能更好)。
但是brpc并没有hook系统调用,这是因为:
- bthread阻塞可能切换系统线程,依赖系统TLS的函数的行为未定义。
- 和阻塞pthread的函数混用时可能死锁。
- 这类hook函数本身的效率一般更差,因为往往还需要额外的系统调用,如epoll。