在派生类中管理线程生命周期

时间:2013-01-08 15:44:59

标签: c++ multithreading boost boost-thread

我有一个 Base 类,它充当多个同步事件处理策略的接口。我现在想要策略以异步方式处理事件。为了最小化代码重构,每个策略都有自己的内部线程用于异步事件处理。我主要关心的是如何管理这个线程的生命周期。 派生策略类是在代码库周围构建和销毁的,因此很难管理策略类之外的线程生命周期(启动/停止)。

我最终得到了以下代码:

#include <iostream>
#include <cassert>

#include <boost/shared_ptr.hpp>
#include <boost/thread.hpp>

struct Base
{
    virtual ~Base()
    {
        std::cout << "In ~Base()" << std::endl;

        // For testing purpose: spend some time in Base dtor
        boost::this_thread::sleep(boost::posix_time::milliseconds(1000));
    }

    virtual void processEvents() = 0;

    void startThread()
    {
        if(_thread)
        {
            stopThread();
        }
        _thread.reset(new boost::thread(&Base::processEvents, this));
        assert(_thread);
    }

    void stopThread()
    {
        if(_thread)
        {
            std::cout << "Interrupting and joining thread" << std::endl;
            _thread->interrupt();
            _thread->join();
            _thread.reset();
        }
    }

    boost::shared_ptr<boost::thread> _thread;
};

struct Derived : public Base
{
    Derived()
    {
        startThread();
    }

    virtual ~Derived()
    {

        std::cout << "In ~Derived()" << std::endl;

        // For testing purpose: make sure the virtual method is called while in dtor
        boost::this_thread::sleep(boost::posix_time::milliseconds(1000));

        stopThread();

    }

    virtual void processEvents()
    {
        try
        {
            // Process events in Derived specific way
            while(true)
            {
                // Emulated interruption point for testing purpose
                boost::this_thread::sleep(boost::posix_time::milliseconds(100));
                std::cout << "Processing events..." << std::endl;
            }
        }
        catch (boost::thread_interrupted& e)
        {
            std::cout << "Thread interrupted" << std::endl;
        }
    }
};

int main(int argc, char** argv)
{
    Base* b = new Derived;
    delete b;
    return 0;
}

如您所见,线程被中断并在 Derived 类析构函数中连接。 Stackoverflow上的许多评论都认为在析构函数中加入一个线程是个坏主意。但是,考虑到必须通过构建/销毁 Derived 类来管理线程生命周期的约束,我找不到更好的主意。有人有更好的主张吗?

1 个答案:

答案 0 :(得分:0)

当类被销毁时,释放类创建的资源是个好主意,即使其中一个资源是一个线程。但是,当在析构函数中执行任何非平凡的任务时,通常需要花时间来全面检查其含义。


析构

一般规则是not throw exceptions in destructors。如果Derived对象位于正在从另一个异常展开的堆栈上,并且Derived::~Derived()抛出异常,则将调用std::terminate(),从而终止该应用程序。虽然Derived::~Derived()没有显式抛出异常,但重要的是要考虑它调用的某些函数可能会抛出,例如_thread->join()

如果std::terminate()是所需行为,则无需进行任何更改。但是,如果不需要std::terminate(),请抓住boost::thread_interrupted并禁止它。

try
{
  _thread->join();
}
catch (const boost::thread_interrupted&)
{
  /* suppressed */ 
}

继承

看起来似乎继承用于代码重用,并通过将异步行为隔离到Base层次结构的内部来最小化代码重构。但是,一些样板逻辑也在Dervied中。由于已经必须更改从Base派生的类,我建议考虑聚合或CRTP以最小化这些类中的样板逻辑和代码的数量。

例如,可以引入辅助类型来封装线程逻辑:

class AsyncJob
{
public:
  typedef boost::function<void()> fn_type;

  // Start running a job asynchronously.
  template <typename Fn>
  AsyncJob(const Fn& fn)
    : thread_(&AsyncJob::run, fn_type(fn))
  {}

  // Stop the job.
  ~AsyncJob()
  {
    thread_.interrupt();

    // Join may throw, so catch and suppress.
    try { thread_.join(); }
    catch (const boost::thread_interrupted&) {}
  }

private: 

  //  into the run function so that the loop logic does not
  // need to be duplicated.
  static void run(fn_type fn)
  {
    // Continuously call the provided function until an interrupt occurs.
    try
    {
      while (true)
      {
        fn();

        // Force an interruption point into the loop, as the user provided
        // function may never call a Boost.Thread interruption point.
        boost::this_thread::interruption_point();
      }
    }
    catch (const boost::thread_interrupted&) {}
  }

  boost::thread thread_;
};

可以在Derived的构造函数中聚合和初始化此帮助程序类。它消除了对大部分样板代码的需求,并且可以在其他地方重复使用:

struct Derived : public Base
{
    Derived()
      : job_(boost::bind(&Base::processEvents, this))
    {}

    virtual void processEvents()
    {
      // Process events in Derived specific way
    }

private:

  AsyncJob job_;
};

另一个关键点是AsyncJob强制Boost.Thread interruption point进入循环逻辑。作业关闭逻辑是根据中断点实现的。因此,在迭代期间达到中断点是至关重要的。否则,如果用户代码永远不会到达中断点,则可能最终陷入死锁。


寿命

检查线程的生命周期是否必须与对象的生命周期相关联,或者是否需要与对象的生命周期相关联的异步事件处理。如果是后者,则可能值得考虑使用线程池。线程池可以对线程资源提供更精细的控制,例如施加最大限制,以及最大限度地减少浪费的线程数量,例如线程无效或创建/销毁短期线程所花费的时间。

例如,考虑用户创建500 Dervied个类的数组的情况。需要500个线程来处理500个策略吗?或者25个线程可以处理500个策略?请记住,在某些系统上,线程创建/销毁可能很昂贵,甚至可能存在最大的线程限制。


总之,检查权衡,并确定哪些行为是可接受的。最小化代码重构可能很困难,特别是在更改对代码库的各个区域有影响的线程模型时。很难获得完美的解决方案,因此找出涵盖大多数情况的解决方案。一旦明确定义了受支持的行为,就可以修改现有代码,使其处于受支持的行为范围内。