boost.asio系列——io_service
IO模型
io_service對象是asio框架中的調(diào)度器,所有異步io事件都是通過它來分發(fā)處理的(io對象的構(gòu)造函數(shù)中都需要傳入一個io_service對象)。
????asio::io_service?io_service;
????asio::ip::tcp::socket?socket(io_service);
在asio框架中,同步的io主要流程如下:
????
而異步IO的處理流程則有些不同:
????
io_service對象
io_service對象主要有兩個方法——post和run:
可見,io_service提供的是一個生產(chǎn)者消費者模型。在異步io操作中需要我們手動控制消費者,調(diào)用run函數(shù),它的基本工作模式如下:
從中可以看出,io_service是一個工作隊列的模型。在使用過程中一般有如下幾個需要注意的地方:
1. run函數(shù)在io事件完成后會退出,導(dǎo)致后續(xù)基于該對象的異步io任務(wù)無法執(zhí)行
由于io_service并不會主動常見調(diào)度線程,需要我們手動分配,常見的方式是給其分配一個線程,然后執(zhí)行run函數(shù)。但run函數(shù)在io事件完成后會退出,線程會終止,后續(xù)基于該對象的異步io任務(wù)無法得到調(diào)度。
解決這個問題的方法是通過一個asio::io_service::work對象來守護io_service。這樣,即使所有io任務(wù)都執(zhí)行完成,也不會退出,繼續(xù)等待新的io任務(wù)。
????boost::asio::io_service?io;
????boost::asio::io_service::work?work(io);
????io.run();
2. 回調(diào)在run函數(shù)的線程中同步執(zhí)行,當回調(diào)處理時間較長時阻塞后續(xù)io響應(yīng)
解決這個問題的方法有兩種:1. 啟動多線程執(zhí)行run函數(shù)(run函數(shù)是線程安全的),2. 新啟動一個線程(或通過線程池)來執(zhí)行回調(diào)函數(shù)。一般來講,如果回調(diào)處理事件不是特別短,應(yīng)該使用在線程池中處理回調(diào)的方式。
3. 回調(diào)在run函數(shù)的線程中同步執(zhí)行,io事件較多的時候得不到及時響應(yīng)
這個其實是性能問題了,在多核cpu上可以通過在多個線程中執(zhí)行run函數(shù)來解決這一問題。這種方式也只能充分利用cpu性能,本身性能問題就不是光靠軟件就能解決的。
.net中的異步io調(diào)度方式
和io_service這種手動控制的方式比起來,.net則是純粹的自動檔了。IO調(diào)度由CLR托管了,無需手動控制?;卣{(diào)也是在線程池中執(zhí)行,無需擔心影響后續(xù)IO響應(yīng)。
正是由于CLR的托管,在.net 的異步IO框架中,就沒有類似io_service的調(diào)度對象存在,這也符合.net的一貫簡潔做法。
超強干貨來襲 云風專訪:近40年碼齡,通宵達旦的技術(shù)人生總結(jié)
以上是生活随笔為你收集整理的boost.asio系列——io_service的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 内存管理:_CrtDumpMemoryL
- 下一篇: 详细解析Raid0、Raid0+1、Ra