boost::io_service interpretation

io_servie implements a task queue, where the task is the void(void) function. The two most commonly used interfaces of Io_servie are post and run. Post delivers tasks to the task queue. Run executes the tasks in the queue until all are executed, and run can be called by N threads. Io_service is a fully thread-safe queue.

boost::io_service interpretation

asio is a c asynchronous programming model library provided by boost. Its core class io_service provides task queue and task distribution functions in multi-thread programming. In socket , mainly used as an event driver in io programming (completion port, select, poll, epoll, etc.).

Queue model

Each io_service has a public task queue and multiple private task queues. The public queue is shared by each thread, and the private queue is exclusive to each thread. .

The task execution process of io_service is roughly as follows:

1. Call the run method and enter the main loop;

2. Determine whether the public queue is empty. If it is not empty, take out the task and execute it. When the number of tasks is greater than 1, wake up other idle threads at the same time;

3. The task execution is completed and the The tasks in the private queue of each thread are moved to the public task queue;

4. triggers the reactor, which is usually epoll under Linux. When there is an event, the task of the corresponding event is placed in the private queue. In the queue.

5. When the queue is empty, add the current thread to the idle thread queue, enter the wait state, and wait for other threads to wake up (task_operation).

6. When the user calls post, the task is directly delivered to the public queue op_queue.

Thread pool model

There are two commonly used thread pool models:

One is that multiple threads share a task queue, and the user puts the task Posted to the task queue, other threads compete to obtain task execution from the queue. Combined with boost::thread, the thread pool can be realized by calling the run method in multiple threads:

using namespace boost;
using namespace boost::asio;
io_service ios;
int thread_num = 10;
thread *t[thread_num] = {0};
// 创建线程池
for(int i = 0; i < thread_num; ++i)
{
    t[i] = new thread(bind(&io_service::run, &ios));
}

// 向任务队列中投递任务，该任务将随机由一个调用run方法的线程执行
ios.post(func);

// 等待线程退出
for(int i = 0; i < thread_num; ++i)
{
    t[i]->join();
}

It is easy to see that the bottleneck of this kind of thread pool is a task queue, and multiple threads compete for access. Tasks can easily lead to performance degradation in large concurrent programs.

The other is that each thread maintains a task queue. The user can choose to deliver tasks to one of the task queues randomly or in rotation. The tasks in the task queue can only be consumed by the thread in which it is located. This kind of thread pool also has a corresponding implementation (io_service_pool) in the boost example. The basic method is to create multiple io_service objects, each corresponding to a thread. The code is as follows:

using namespace boost;
using namespace boost::asio;
int thread_num = 10;
io_service ios[thread_num];
thread *t[thread_num] = {0};
// 创建线程池
for(int i = 0; i < thread_num; ++i)
{
    t[i] = new thread(bind(&io_service::run, &ios[i]));
}

// 轮训投递任务
for(int i = 0; i < thread_num; ++i)
{
    ios[i].post(func);
}   

// 等待线程退出
for(int i = 0; i < thread_num; ++i)
{
    t[i]->join();
}

The following is Class diagram based on Linux environment, because some classes have different definitions on Windows.

#io_service defines the main interface, and the implementation under Linux is task_io_service.

task_io_service mainly defines three things:

1. A reactor, reactor is an event driver such as completion port, select, poll, epoll;

2. A public task queue op_queue is used to store tasks posted by users and tasks returned by reactor;

3. Thread related variables. io_service itself will not create any threads, but it will save some thread call information, such as thread private queues, etc.

In addition, task_io_service also maintains a list of idle threads and wakes up one of the idle threads when extra tasks arrive. In the common Linux single task queue thread pool, a condition variable is used to wake up the thread. In a multi-core system, a pthread_cond_signal call will wake up one or more threads in the wait state (refer to https://linux.die. net/man/3/pthread_cond_signal), although there is only one task, if the idle thread method is used, only one idle thread is awakened when there is a task, which can reduce many unnecessary wake-ups.

The thread_info_base class maintains a simple memory pool with only one piece of memory. It can reduce the memory allocation overhead only when continuously applying for memory release.

The role of io_service::work: io_service::run will return immediately when the task is completed. This is not what you want when writing a resident service program. The solution given by boost is to define a work variable , it’s amazing at first glance. This variable that seems to have nothing to do with io_server can actually control the behavior of run. When you open the source code, you can see that the implementation of work is surprisingly simple. It just calls the worked_started() method of io_service in the constructor, so that The number of pending tasks (outstanding_work_) is greater than 0. In this case, io_service::run considers that there are always tasks to be processed and does not return.

Related recommendations:

Angular updates directive_AngularJS

based on the status of service

Introduction to the methods of using factory and service in AngularJS_AngularJS

The above is the detailed content of boost::io_service interpretation. For more information, please follow other related articles on the PHP Chinese website!