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 
    
       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 
     
        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 
      
       #if defined(GENERATING_DOCUMENTATION)  unspecified#else  detail::wrapped_handler
       
        #endif  wrap(Handler handler)  {    return detail::wrapped_handler
        
         (*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
    
      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
     
       ready_queue_;  };
     
    

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

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