Boost::asio io_service 实现分析

io_service的作用

io_servie 实现了一个任务队列,这里的任务就是void(void)的函数。Io_servie最常用的两个接口是post和run,post向任务队列中投递任务,run是执行队列中的任务,直到全部执行完毕,并且run可以被N个线程调用。Io_service是完全线程安全的队列。

Io_servie的接口

提供的接口有run、run_one、poll、poll_one、stop、reset、dispatch、post,最常用的是run、post、stop

Io_servie 实现代码的基本类结构:

l  Io_servie是接口类,为实现跨平台,采用了策略模式,所有接口均有impl_type实现。根据平台不同impl_type分为

n  win_iocp_io_service Win版本的实现,这里主要分析Linux版本。

n  task_io_service 非win平台下的实现,其代码结构为:

u  detail/task_io_service_fwd.hpp 简单声明task_io_service名称

u  detail/task_io_service.hpp 声明task_io_service的方法和属性

u  detail/impl/task_io_service.ipp 具体实现文件

u  队列中的任务类型为opertioan,原型其实是typedef task_io_service_operation operation,其实现文件在detail/task_io_service_operation.hpp中,当队列中的任务被执行时,就是task_io_service_operation:: complete被调用的时候。

Io_servie::Post方法的实现

Post向队列中投递任务,然后激活空闲线程执行任务。其实现流程如下:

l  Post接收handler作为参数,实际上是个仿函数,通过此仿函数构造出completion_handler对象,completion_handler继承自operation。然后调用post_immediate_completion。

l  post_immediate_completion首先将outstanding_work_增加,然后调用post_deferred_completion。

l  post_deferred_completion首先加锁将任务入列,然后调用wake_one_thread_and_unlock

l  wake_one_thread_and_unlock尝试唤醒当前空闲的线程,其实现中特别之处在于,若没有空闲线程,但是有线程在执行task->run,即阻塞在epoll_wait上,那么先中断epoll_wait执行任务队列完成后再执行epoll_wait。

l  first_idle_thread_维护了所有当前空闲线程,实际上使用了Leader/Follower模式,每次唤醒时只唤醒空闲线程的第一个。

Io_servie::run方法的实现

Run方法执行队列中的所有任务,直到任务执行完毕。

l  run方法首先构造一个idle_thread_info,和first_idle_thread_类型相同,即通过first_idle_thread_将所有线程串联起来,它这个串联不是立即串联的,当该线程无任务可做是加入到first_idle_thread_的首部,有任务执行时,从first_idle_thread_中断开。这很正常,因为first_idle_thread_维护的是当前空闲线程。

l  加锁,循环执行do_one方法,直到do_one返回false

l  do_one每次执行一个任务。首先检查队列是否为空,若空将此线程追加到first_idle_thread_的首部,然后阻塞在条件变量上,直到被唤醒。

l  当被唤醒或是首次执行,若stopped_为true(即此时stop方法被调用了),返回0

l  队列非空,pop出一个任务,检查队列无任务那么简单的解锁,若仍有,调用wake_one_thread_and_unlock尝试唤醒其他空闲线程执行。然后执行该任务,返回1.

l  实际上在执行队列任务时有一个特别的判断if (o == &task_operation_),那么将会执行task_->run,task_变量类型为reactor,在linux平台实现为epoll_reactor,实现代码文件为detail/impl/epoll_reactor.ipp,run方法实际上执行的是epoll_wait,run阻塞在epoll_wait上等待事件到来,并且处理完事件后将需要回调的函数push到io_servie的任务队列中,虽然epoll_wait是阻塞的,但是它提供了interrupt函数,该interrupt是如何实现的呢,它向epoll_wait添加一个文件描述符,该文件描述符中有8个字节可读,这个文件描述符是专用于中断epoll_wait的,他被封装到select_interrupter中,select_interrupter实际上实现是eventfd_select_interrupter,在构造的时候通过pipe系统调用创建两个文件描述符,然后预先通过write_fd写8个字节,这8个字节一直保留。在添加到epoll_wait中采用EPOLLET水平触发,这样,只要select_interrupter的读文件描述符添加到epoll_wait中,立即中断epoll_wait。很是巧妙。!!!实际上就是因为有了这个reactor,它才叫io_servie,否则就是一个纯的任务队列了。

l  Run方法的原则是:

n  有任务立即执行任务,尽量使所有的线程一起执行任务

n  若没有任务,阻塞在epoll_wait上等待io事件

n  若有新任务到来,并且没有空闲线程,那么先中断epoll_wait,先执行任务

n  若队列中有任务,并且也需要epoll_wait监听事件,那么非阻塞调用epoll_wait(timeout字段设置为0),待任务执行完毕在阻塞在epoll_wait上。

n  几乎对线程的使用上达到了极致。

n  从这个函数中可以知道,在使用ASIO时,io_servie应该尽量多,这样可以使其epoll_wait占用的时间片最多,这样可以最大限度的响应IO事件,降低响应时延。但是每个io_servie::run占用一个线程,所以io_servie最佳应该和CPU的核数相同。

Io_servie::stop的实现

l  加锁,调用stop_all_threads

l  设置stopped_变量为true,遍历所有的空闲线程,依次唤醒

l  task_interrupted_设置为true,调用task_的interrupt方法

l  task_的类型为reactor,在run方法中已经做了分析

l

Boost::asio io_service 实现分析,布布扣,bubuko.com

时间: 2024-10-14 12:46:13

Boost::asio io_service 实现分析的相关文章

boost::asio::io_service(之一)

boost::asio::io_service /// Provides core I/O functionality. /** * The io_service class provides the core I/O functionality for users of the * asynchronous I/O objects, including: * io_service类为下面的异步对象提供了核心的I/O操作函数 * * @li boost::asio::ip::tcp::socke

网络库crash以及boost asio strand dispath分析

最近在做服务器的稳定性的相关测试,服务器的网络底层使用的是boost asio,然后自己做的二次封装以更好的满足需求. 服务器昨天晚上发现crash了一次,之前测试了将近半个多月,有一次是莫名的退出了,不过由于是新的测试服,忘记将ulimit -c进行修改了,所以没有coredump,这次又发生了. coredump如下: #0 0x0000000000000091 in ?? () #1 0x0000000000459729 in ClientHandler::HandleConnect(cp

boost asio io_service学习笔记

构造函数 构造函数的主要动作就是调用CreateIoCompletionPort创建了一个初始iocp. Dispatch和post的区别 Post一定是PostQueuedCompletionStatus并且在GetQueuedCompletionStatus 之后执行. Dispatch会首先检查当前thread是不是io_service.run/runonce/poll/poll_once线程,如果是,则直接运行. poll和run的区别 两者代码几乎一样,都是首先检查是否有outstan

boost::asio::io_service 超时设置

class client{public:  /*client(const udp::endpoint& listen_endpoint)    : socket_(io_service_, listen_endpoint),      deadline_(io_service_)  {    deadline_.expires_at(boost::posix_time::pos_infin);    check_deadline();  } std::size_t receive(const b

Boost.ASIO简要分析-5 多io_service

5. 多io_service 前面那篇讲到了多线程的用法.这篇讲一下多io_service的用法,大家可参考下官方提供的HTTP Server 2(an io_service-per-CPU)这个例子. 官方提供的例子中,使用方法很简单,建立一个io_service_pool,然后对每一个io_service开一个线程去让它跑起来(毕竟,io_service::run这个函数在有任务的时候会一直工作的,只有开多个线程才做到不影响别的io_service).当然,我们也可以为每个io_servic

boost::asio的io_service处理过程

1.主线程定义回调对象 2.调用io object的操作 3.io object会另开线程,定义opertion op来执行操作,同时将回调对象加到op的do_complete上.进行操作 4.完成操作加入完成队列 5.io_service线程循环从完成队列取事件,调用其事件对应的回调函数 Operation 还记得前面我们在分析resolver的实现的时候,挖了一个关于operation的坑?为了不让自己陷进去,现在来填吧:接下来我们就来看看asio中的各种operation. 和前面提到过的

boost.asio源码剖析(三) ---- 流程分析

* 常见流程分析之一(Tcp异步连接) 我们用一个简单的demo分析Tcp异步连接的流程: 1 #include <iostream> 2 #include <boost/asio.hpp> 3 4 // 异步连接回调函数 5 void on_connect(boost::system::error_code ec) 6 { 7 if (ec) // 连接失败, 输出错误码 8 std::cout << "async connect error:"

Boost.ASIO简要分析-4 多线程

4. 多线程 一般情况下,服务端开启一条线程做io_service::run()工作就足够了.但是,有些情况下可能会变得很糟糕. 从之前的分析,我们知道异步操作的一个关键步骤就是io_service回调我们注册的handler.现在假设客户端与服务端建立了四个socket连接,相应的I/O对象分别为socket1, socket2, socket3, socket4,并且假设io_service现在正在处理socket1注册的handler.如果这个handler处理的过程很长,那么在这期间so

boost.asio系列——io_service

IO模型 io_service对象是asio框架中的调度器,所有异步io事件都是通过它来分发处理的(io对象的构造函数中都需要传入一个io_service对象). asio::io_service io_service;    asio::ip::tcp::socket socket(io_service); 在asio框架中,同步的io主要流程如下: 应用程序调用IO对象成员函数执行IO操作 IO对象向io_service 提出请求. io_service 调用操作系统的功能执行连接操作. 操