4. 多线程

一般情况下，服务端开启一条线程做io_service::run()工作就足够了。但是，有些情况下可能会变得很糟糕。

从之前的分析，我们知道异步操作的一个关键步骤就是io_service回调我们注册的handler。现在假设客户端与服务端建立了四个socket连接，相应的I/O对象分别为socket1, socket2, socket3, socket4，并且假设io_service现在正在处理socket1注册的handler。如果这个handler处理的过程很长，那么在这期间socket2，socket3，socket4注册的handler会一直得不到执行，造成不良的使用体验。

针对这个问题，解决之道只有采用多线程的方法。多线程的用法很简单，我们只要把线程函数boost::asio::io_service::run和io_service指针绑定好传给boost::thread类就好了。如下所示：

boost::thread t(boost::bind(&boost::asio::io_service::run, &io));t.join();

但是，引入多线程又会引入多线程同步的问题，如果这个问题没解决好，死机就是家常便饭了。幸好，asio给我们提供了strand这个类（当然，也可以使用mutex，但是使用strand会使代码更加优雅）。下面，简单介绍下strand这个类。

1) 用法

用法很简单，首先定义下变量。

boost::asio::io_service::strand strand_(&io); //注意io_service对象地址作为他的参数。

然后在注册回调函数时，在外面套上一层strand_.wrap()就好了，如下所示：

timer1_.async_wait(strand_.wrap(boost::bind(&printer::print1, this)));
timer2_.async_wait(strand_.wrap(boost::bind(&printer::print2, this)));

这样的话，这两个异步操作的回调函数肯定是被顺序执行的。

2) 源码分析

在分析源码之前，我们看下一个完整的调用堆栈：

我们把不采用strand时的调用堆栈图拿来比对下

不知道有没有被吓一跳，采用strand方式竟然会多出这么多层调用，让回调的路途看上去如此漫长。

好了，废话不多说，我们strand的那张调用堆栈图中寻找strand的蛛丝马迹。回调的路上这个函数boost::asio::io_service::strand::dispatch，顿时眼前一亮，让我想起strand类中的dispatch函数。眼尖的朋友可能发现调用堆栈上出现了两次boost::asio::io_service::strand::dispatch，不要奇怪，这两次的handler是不一样的，如下图。

这是先被调用的

这是后被调用的

下面贴出io_service::strand类：

class io_service::strand
{
public:explicit strand(boost::asio::io_service& io_service): service_(boost::asio::use_service<boost::asio::detail::strand_service>(io_service)){service_.construct(impl_);}~strand(){}boost::asio::io_service& get_io_service(){return service_.get_io_service();}/* 这就是第一个出现在回调路上的函数。这个函数的作用是让strand执行给定的handler。还有一点要说的就是，如果当前线程调用了service::run，那么该线程可以直接调用handler。这也是和post的区别之一。我们可以假想下如果回调的路上不是strand::dispatch，而是strand::post，那么我们的线程栈上也不一定会这么长了。*/template <typename CompletionHandler>BOOST_ASIO_INITFN_RESULT_TYPE(CompletionHandler, void ())dispatch(BOOST_ASIO_MOVE_ARG(CompletionHandler) handler){// If you get an error on the following line it means that your handler does// not meet the documented type requirements for a CompletionHandler.BOOST_ASIO_COMPLETION_HANDLER_CHECK(CompletionHandler, handler) type_check;detail::async_result_init<CompletionHandler, void ()> init(BOOST_ASIO_MOVE_CAST(CompletionHandler)(handler));// 注意此处是service_是boost::asio::detail::strand_service类型的哦;
// strand_service里面才是真正控制多线程安全的地方。service_.dispatch(impl_, init.handler);return init.result.get();}// 和dispatch都有投递任务的作用。只是post会马上返回，handler会被某个调用service::run的线程执行。template <typename CompletionHandler>BOOST_ASIO_INITFN_RESULT_TYPE(CompletionHandler, void ())post(BOOST_ASIO_MOVE_ARG(CompletionHandler) handler){// If you get an error on the following line it means that your handler does// not meet the documented type requirements for a CompletionHandler.BOOST_ASIO_COMPLETION_HANDLER_CHECK(CompletionHandler, handler) type_check;detail::async_result_init<CompletionHandler, void ()> init(BOOST_ASIO_MOVE_CAST(CompletionHandler)(handler));service_.post(impl_, init.handler);return init.result.get();}// 这个wrap函数就是上面说起的那个打包函数。有了它，io_service会先调用strand然后再调用handler，相当于在回调的路上设置了一道关卡，通过strand保证线程安全性。template <typename Handler>
#if defined(GENERATING_DOCUMENTATION)unspecified
#elsedetail::wrapped_handler<strand, Handler, detail::is_continuation_if_running>
#endifwrap(Handler handler){return detail::wrapped_handler<io_service::strand, Handler,detail::is_continuation_if_running>(*this, handler);}bool running_in_this_thread() const{return service_.running_in_this_thread(impl_);}private:boost::asio::detail::strand_service& service_;boost::asio::detail::strand_service::implementation_type impl_;
};

光这个类是看不出具体实现细节的，相要了解更多实现细节需要分析strand_service这个类。

具体的多线程控制方面，我们可以看下strand_service::strand_impl这个嵌套类

// The underlying implementation of a strand.class strand_impl: public operation{public:strand_impl();private:// Only this service will have access to the internal values.friend class strand_service;friend struct on_do_complete_exit;friend struct on_dispatch_exit;// 这就是那个用来多线程控制的互斥锁// Mutex to protect access to internal data.boost::asio::detail::mutex mutex_;// 用来表示strand是否被某个handler“锁住”的变量// Indicates whether the strand is currently "locked" by a handler. This// means that there is a handler upcall in progress, or that the strand// itself has been scheduled in order to invoke some pending handlers.bool locked_;// 哦，等待处理的排队队列// The handlers that are waiting on the strand but should not be run until// after the next time the strand is scheduled. This queue must only be// modified while the mutex is locked.op_queue<operation> waiting_queue_;// 已经获取锁并准备运行的handler// The handlers that are ready to be run. Logically speaking, these are the// handlers that hold the strand's lock. The ready queue is only modified// from within the strand and so may be accessed without locking the mutex.op_queue<operation> ready_queue_;};

可以看出mutex_、locked_、waiting_queue_、ready_queue_这四个变量保证了线程安全性。具体实现方法，可以自己去调试下，这里就不细细分析了（其实是肚子饿了，要去吃饭了^^）。

PS： 异步调用+多线程肯定会大大增加你的调试复杂度，加上日志记录是势在必行的事情。这里向大家推荐下简单易用的glog：https://github.com/google/glog