打印本文 打印本文  关闭窗口 关闭窗口  
C++技巧(多线程下的返回值优化陷阱)
作者:佚名  文章来源:不详  点击数  更新时间:2008/10/22 21:33:42  文章录入:杜斌  责任编辑:杜斌

  “函数的返回值优化”是我们对程序的一个常见优化手段。只要可能,我们都应该返回对象的有效引用,而不是重新生成一个临时对象。但是,也许这种想法在多线程里需要更仔细的斟酌一下。
  Examda从一个简单例子讲起:
  template<T>
  class FdMap
  {
  std::vector<T> vec_;
  public:
  void Set(int fd,const T & v){
  if(fd >= 0){
  if(fd < vec_.size()){
  vec_[fd] = v;
  }else{
  vec_.resize(fd + 1);
  vec_[fd] = v;
  }
  }
  }
  T Get(int fd) const{
  if(fd >= 0 && fd < vec_.size())
  return vec_[fd];
  return T();
  }
  };
  这里FdMap是一个把int映射到T对象的类型,考试大采用std::vector作为底层容器。它所做的工作很简单:在需要的时候扩充容器vec_;如果访问超过了范围,返回T的默认值。
  如果FdMap要在多线程下工作,考试大那么我们需要加一点代码,进行必要的同步:
  template<T>
  class FdMap
  {
  std::vector<T> vec_;
  Mutex mutex_; //锁同步对象
  public:
  void Set(int fd,const T & v){
  if(fd >= 0){
  Guard g(mutex_) //加锁
  if(fd < vec_.size()){
  vec_[fd] = v;
  }else{
  vec_.resize(fd + 1);
  vec_[fd] = v;
  }
  }
  }
  T Get(int fd) const{
  if(fd >= 0){
  Guard g(mutex_) //加锁
  if(fd < vec_.size()){
  return vec_[fd];
  }
  return T();
  }
  };
  其中Mutex是任意线程同步类型;Guard是对应的范围保卫类型,在构造的时候锁住mutex_,析构的时候解锁。到目前为止,FdMap类非常完美,没有任何问题。
  在实际应用中,我们可能把FdMap用于关联socket fd和对应的客户端连接对象(例如ClientData),于是可能的实例化是FdMap<ClientData *>。
  不过有经验的程序员马上会看出,直接在FdMap里存储ClientData指针是不行的。如果某个线程Get到了一个fd的ClientData指针,而另一个线程却试图关闭这个fd连接,那么ClientData对象是释放掉,还是继续有效?如果释放了ClientData对象,那么前一个线程随后的访问就会失效;如果继续保留ClientData对象,那么谁也不知道该在何时释放它了,就会内存泄漏。
  正确的做法是,在FdMap里存储ClientData的智能指针,那么哪个线程都不需要特意释放ClientData对象,智能指针会在适当的时候处理。为了保险,我们决定使用boost::shared_ptr,因为大家都认为它是正确的。
  OK,我们有了一个设计完美,运行正确的FdMap,完整的实例化是:
  FdMap<boost::shared_ptr<ClientData> >
  终于有一天,我们需要优化代码,于是我们重新审视上面的代码。Get函数!是的,它的返回值是否可以优化?因为对于智能指针,即使是拷贝构造函数都是昂贵的,能够减少一个临时对象的构造,对于我们的确太诱人了。
  但是有一个明显的问题:当fd不在范围内的时候,返回谁的引用?且看下面的实现。
  下面是我们的“优化”:
  const T & Get(int fd) const{
  static const T DEF = T();
  if(fd >= 0){
  Guard g(mutex_) //加锁
  if(fd < vec_.size()){
  return vec_[fd];
  }
  return DEF;
  }
  通过增加一个局部静态常量DEF,解决了返回默认引用的问题。如果fd在范围内,那么返回vec_里的对象引用,是没有问题的。
  但是当我再次运行这个“优化版”的时候,不幸的是,一天之后程序崩溃了!怎么回事?我检查了所有用到Get函数的地方:
  boost::shared_ptr<ClientData> pClient = fdMap.Get(fd);
  这样的代码实在看不出有什么问题,而检查Get函数的实现,也没有发现任何问题!
  事实上,问题是这样的:
  仔细分析Get函数的操作,可以发现,在“return vec_[fd];”之后,FdMap内部的锁已经解开了,而此时调用线程得到的还是FdMap::vec_[fd]对象的引用,于是接下来给pClient赋值的操作就是一个没有任何保护的过程。如果在把这个引用赋值给pClient的过程中,FdMap::vec_[fd]没有被任何其他线程更改,那么一切正常;否则,程序就可能崩溃!
  明白了这个例子,相信大家在以后的优化过程中,会更谨慎的处理多线程下的代码。来源:考试大网
打印本文 打印本文  关闭窗口 关闭窗口