Implementation analysis of Boost::asio Io_service

implementation Analysis of Boost::asio Io_service the role of Io_service

Io_servie implements a task queue, where the task is a function of void (void). Io_servie the two most commonly used interfaces are post and run,post to the task queue, run is the task in the queue until all is finished, and run can be called by n threads. Io_service is a fully thread-safe queue. Interface for Io_servie

The interfaces provided are run, Run_one, poll, Poll_one, stop, Reset, dispatch, post, and the most commonly used is the basic class structure of the run, post, stop Io_servie implementation code:

<!--[if!supportlists]-->l <!--[Endif]-->io_servie is the interface class, for the implementation of Cross-platform, the policy model is adopted, all interfaces have Impl_type implementation. According to the platform different impl_type divided into

<!--[if!supportlists]-->n <!--[Endif]-->win_iocp_io_service win version of the implementation, where the main analysis of the Linux version.

<!--[if!supportlists]-->n <!--[Endif]-->task_io_service is implemented under the non-win platform with the following code structure:

<!--[if!supportlists]-->u <!--[endif]-->detail/task_io_service_fwd.hpp Simple declaration Task_io_service name

<!--[if!supportlists]-->u <!--[Endif]-->detail/task_io_service.hpp declares Task_io_service methods and properties

<!--[if!supportlists]-->u <!--[Endif]-->detail/impl/task_io_service.ipp specific implementation files

<!--[if!supportlists]-->u <!--[endif]--> The task type in the queue is Opertioan, the prototype is actually a typedef task_io_service_operation operation, its implementation file in DETAIL/TASK_IO_SERVICE_OPERATION.HPP, when the task in the queue is executed, is task_io_service_operation:: Complete is called. Io_servie: Implementation of:P OST method

Post the task to the queue, and then activate the idle thread to perform the task. The implementation process is as follows:

<!--[if!supportlists]-->l <!--[Endif]-->post receive Handler as an argument, is actually an imitation function that constructs a Completion_handler object through this functor, Completion_handler inherits from Operation. Then call Post_immediate_completion.

<!--[if!supportlists]-->l <!--[Endif]-->post_immediate_completion will first add Outstanding_work_, and then call Post_ Deferred_completion.

<!--[if!supportlists]-->l <!--[Endif]-->post_deferred_completion first lock the task row, and then call Wake_one_thread_and_ Unlock

<!--[if!supportlists]-->l <!--[Endif]-->wake_one_thread_and_unlock tries to wake up the currently idle thread, and its implementation is special in that, if there are no idle threads, However, when the thread is executing Task->run, that is, blocking on the epoll_wait, the epoll_wait execution of the task queue is completed before the epoll_wait is executed.

<!--[if!supportlists]-->l <!--[Endif]-->first_idle_thread_ maintains all current idle threads, actually using Leader/follower mode, Wakes only the first of the idle threads each time it wakes up. the realization of Io_servie::run method

The Run method executes all the tasks in the queue until the task has finished executing.

<!--[if!supportlists]-->l <!--[Endif]-->run method first constructs a idle_thread_info, which is the same as the First_idle_thread_ type. That is, the concatenation of all threads through First_idle_thread_, which is not immediately concatenated, when the thread does not have a task to do is to join the First_idle_thread_ header, there is a task to execute, from the First_idle_thread_ break open. This is normal, because the FIRST_IDLE_THREAD_ maintains the current idle thread.

<!--[if!supportlists]-->l <!--[endif]--> lock, loop execution Do_one method until Do_one returns false

<!--[if!supportlists]-->l <!--[Endif]-->do_one performs one task at a time. First check to see if the queue is empty, append the thread to the header of the First_idle_thread_, and then block on the condition variable until it is awakened.

<!--[if!supportlists]-->l <!--[endif]--> when awakened or first executed, if Stopped_ is true (that is, when the Stop method is invoked), return 0

<!--[if!supportlists]-->l <!--[endif]--> queue is not empty, pop out a task, check queue no task so simple unlock, if still, call Wake_one_thread_and_ Unlock try to wake up other idle threads to execute. Then perform the task and return 1.

<!--[if!supportlists]-->l <!--[endif]--> actually has a special judgment when performing a queue task if (o = = &task_operation_), it will perform task_- >run,task_ variable type is reactor, implemented as Epoll_reactor on Linux platform, implementing code file as Detail/impl/epoll_reactor.ipp,run method actually executes epoll_wait , run blocking waits for an event on the epoll_wait, and after processing the event the function that needs to be recalled is pushed into the Io_servie task queue, although the epoll_wait is blocked, but it provides the interrupt function, How the interrupt is implemented, it adds a file descriptor to epoll_wait that has 8 bytes to read, a file descriptor that is dedicated to interrupting epoll_wait, and is encapsulated into Select_interrupter, Select_interrupter is actually eventfd_select_interrupter, creating two file descriptors through pipe system calls at construction time, and then writing 8 bytes in advance through WRITE_FD, which are reserved for 8 bytes. The Epollet level is triggered in addition to epoll_wait, so that the epoll_wait is immediately interrupted as long as the Select_interrupter read file descriptor is added to the epoll_wait. It's very ingenious .... In fact, because of this reactor, it is called Io_servie, otherwise it is a pure task queue.

<!--[if!supportlists]-->l <!--the principles of the Endif]-->run method are:

<!--[if!supportlists]-->n <!--[endif]--> has a task to perform tasks immediately, as much as possible to make all threads work together

<!--[if!supportlists]-->n <!--[endif]--> If there is no task, blocking on epoll_wait waiting IO event

<!--[if!supportlists]-->n <!--[endif]--> If a new task arrives and there is no idle thread, break epoll_wait first and perform the task first

<!--[if!supportlists]-->n <!--[endif]--> If there are tasks in the queue, and Epoll_wait listener events are required, then non-blocking calls Epoll_ Wait (the timeout field is set to 0) to be blocked on epoll_wait after the task has finished executing.

<!--[if!supportlists]-->n <!--[endif]--> is almost as extreme as the use of threads.

<!--[if!supportlists]-->n <!--[endif]--> can know from this function that when using ASIO, Io_servie should be as much as possible, so that its epoll_wait occupies the most time slices , which can respond to IO events to the maximum extent and reduce the response delay. However, each io_servie::run occupies one thread, so the best io_servie should be the same as the CPU's kernel number. the realization of Io_servie::stop

<!--[if!supportlists]-->l <!--[endif]--> Add locks, call Stop_all_threads

<!--[if!supportlists]-->l <!--[endif]--> Set the stopped_ variable to true, iterate through all the idle threads and wake up in turn

<!--[if!supportlists]-->l <!--[Endif]-->task_interrupted_ set to True, call Task_ interrupt method

<!--[if!supportlists]-->l <!--[Endif]-->task_ type is reactor, analysis has been done in the Run method

<!--[if!supportlists]-->l <!--[endif]-->