Boost. asio series -- io_service

IO Model

The io_service object is the scheduler in the asio framework, and all asynchronous io events are distributed and processed through it (an io_service object must be input in the constructor of the io object ).

Asio: io_service;
Asio: ip: tcp: socket (io_service );

In the asio framework, the main io synchronization process is as follows:

1. Applications call IO object member functions to perform IO operations
2. The IO object sends a request to io_service.
3. Io_service calls the function of the operating system to perform the connection operation.
4. The operating system returns the execution result to io_service.
5. Io_service translates the incorrect operation result into boost: system: error_code type, and passes it to the IO object.
6. If the operation fails, the IO object throws an exception of the boost: system: system_error type.

The asynchronous IO processing process is somewhat different:

1. Applications call IO object member functions to perform IO operations
2. IO Object Request io_service Service
3. Io_service notifies the operating system that an asynchronous connection is required.
4. The operating system indicates that the connection operation is completed, and io_service obtains the operation result from the queue.
5. The application must call io_service: run () to receive results.
6. After io_service: run () is called, io_service returns an operation result and translates it into error_code, which is passed to the Event Callback Function.

Io_service object

Io_service objects mainly have two methods: post and run:

1. Post is used to publish io events, such as timer and socket read/write. It is generally called by the corresponding object of the asio framework without explicit calling.
2. Run is used to listen for io event responses and execute response callback. asynchronous io operations need to be explicitly called in the code, and synchronous io operations are implicitly called by the io object (not the run function, but it is also waiting for io events ).

It can be seen that io_service provides a producer and consumer model. In asynchronous io operations, we need to manually control the consumer and call the run function. Its basic working mode is as follows:

1. Wait for io Event Response. Exit if all io event response is complete.
2. Wait for the io Event Response and execute the corresponding callback.
3. Continue to wait for the next io event, repeat 1-2

Io_service is a working queue model. Note the following points during use:

1. The run function will exit after the io event is completed, causing subsequent asynchronous io tasks based on this object to fail to be executed.

Because io_service does not take the initiative to frequently run scheduling threads, We need to manually allocate them. The common way is to assign them a thread and then execute the run function. However, the run function exits after the io event is completed, and the thread terminates. Subsequent asynchronous io tasks based on the object cannot be scheduled.

To solve this problem, you can use an asio: io_service: work object to protect io_service. In this way, even if all io tasks are completed, they will not exit and continue waiting for new io tasks.

Boost: asio: io_service io;
Boost: asio: io_service: work (io );
Io. run ();

2. The callback is synchronously executed in the thread of the run function. When the callback processing time is long, the subsequent io response is blocked.

There are two ways to solve this problem: 1. start multiple threads to execute the run function (the run function is thread-safe), 2. start a new thread (or use the thread pool) to execute the callback function. Generally, if the callback Processing Event is not very short, the callback method should be used in the thread pool.

3. The callback is synchronously executed in the run function thread. When there are many io events, the callback will not be responded in a timely manner.

This is actually a performance problem. On a multi-core cpu, You can execute the run function in multiple threads to solve this problem. This method can only make full use of the cpu performance. The performance issue is not solved by software alone.

Asynchronous io Scheduling in. net

Compared with the io_service manual control method,. net is purely automatic. IO scheduling is managed by CLR without manual control. The callback is also executed in the thread pool, so there is no need to worry about affecting subsequent IO responses.

It is precisely because of CLR hosting that no scheduling object similar to io_service exists in the asynchronous IO framework of. net, which also conforms to the consistent and concise approach of. net.