当需要销毁该类的对象时，关闭由 C++ 类管理的 Boost 线程的最佳方法是什么？我有一个类，它在构造时创建并启动一个线程，并提供一个公共(public) Wake() 方法，该方法在需要做一些工作时唤醒线程。 Wake() 方法使用 Boost mutex 和 Boost 条件变量向线程发出信号；线程过程等待条件变量，然后完成工作并返回等待。

目前，我在类的析构函数中关闭了这个线程，使用 bool 成员变量作为“运行”标志；我清除标志，然后在条件变量上调用 notify_one()。然后线程过程唤醒，注意到“运行”为假，然后返回。代码如下:

class Worker
{
public:
    Worker();
    ~Worker();
    void Wake();
private:
    Worker(Worker const& rhs);             // prevent copying
    Worker& operator=(Worker const& rhs);  // prevent assignment
    void ThreadProc();
    bool m_Running;
    boost::mutex               m_Mutex;
    boost::condition_variable  m_Condition;
    boost::scoped_ptr<boost::thread> m_pThread;
};

Worker::Worker()
    : m_Running(true)
    , m_Mutex()
    , m_Condition()
    , m_pThread()
{
    m_pThread.reset(new boost::thread(boost::bind(&Worker::ThreadProc, this)));
}

Worker::~Worker()
{
    m_Running = false;
    m_Condition.notify_one();
    m_pThread->join();
}

void Worker::Wake()
{
    boost::lock_guard<boost::mutex> lock(m_Mutex);
    m_Condition.notify_one();
}

void Worker::ThreadProc()
{
    for (;;)
    {
        boost::unique_lock<boost::mutex> lock(m_Mutex);
        m_Condition.wait(lock);
        if (! m_Running) break;
        // do some work here
    }
}

像这样关闭类的析构函数中的线程是一个好主意，还是我应该提供一个公共(public)方法让用户在对象被销毁之前执行此操作，当有更多的错误处理和/或强制的可能性时如果线程过程未能干净或及时返回，则销毁线程？

在析构函数中清理我的对象的困惑很有吸引力，因为它不需要用户对细节的关注(抽象，欢呼!)但在我看来，如果我能保证采取完全负责成功彻底地清理事物，并且类外的代码可能有一天需要知道线程是否被干净地关闭。

另外，我使用的机制——写入一个线程堆栈上的对象中的成员变量并在另一个线程中读取该变量——是否安全且理智？

最佳答案

在类被销毁时释放类创建的资源是个好主意，即使其中一个资源是线程。如果资源是通过用户调用显式创建的，例如 Worker::Start() ，那么还应该有明确的方式释放它，比如Worker::Stop() .如果用户不调用 Worker::Stop()，在析构函数中执行清理也是一个好主意。和/或为用户提供实现 RAII 的作用域辅助类。 -成语，调用 Worker::Start()在它的构造函数和 Worker::Stop()在它的析构函数中。但是，如果资源分配是隐式完成的，例如在 Worker构造函数，那么资源的释放也应该是隐式的，而析构函数是该职责的主要候选者。

破坏

让我们看看Worker::~Worker() .一般规则是 not throw exceptions in destructors .如果一个 Worker对象位于从另一个异常中展开的堆栈上，并且 Worker::~Worker()抛出异常，然后 std::terminate()将被调用，杀死应用程序。而Worker::~Worker()没有显式抛出异常，重要的是要考虑到它正在调用的某些函数可能会抛出:

• m_Condition.notify_one() 不扔。
• m_pThread->join() 可以抛出boost::thread_interrupted .

如果 std::terminate()是期望的行为，则无需更改。但是，如果 std::terminate()不需要，然后捕获 boost::thread_interrupted并压制它。

Worker::~Worker()
{
  m_Running = false;
  m_Condition.notify_one();
  try
  {
    m_pThread->join();
  }
  catch ( const boost::thread_interrupted& )
  {
    /* suppressed */ 
  }
}

并发

管理线程可能很棘手。定义函数的确切期望行为很重要，例如 Worker::Wake()。 ，以及了解 boost 线程和同步的类型的行为。例如， boost::condition_variable::notify_one() 如果 boost::condition_variable::wait() 中没有线程被阻塞，则无效.让我们检查 Worker::Wake() 的可能并发路径.

下面是两种情况下并发的粗略尝试:

• 操作顺序从上到下发生。 (即顶部的操作发生在底部的操作之前。
• 并发操作写在同一行。
• <和 >用于突出显示一个线程何时唤醒或解除阻塞另一个线程。例如 A > B表示线程 A正在解除阻塞线程 B .

场景:Worker::Wake()在 Worker::ThreadProc() 时调用在 m_Condition 上被阻止.

Other Thread                       | Worker::ThreadProc
-----------------------------------+------------------------------------------
                                   | lock( m_Mutex )
                                   | `-- m_Mutex.lock()
                                   | m_Condition::wait( lock )
                                   | |-- m_Mutex.unlock()
                                   | |-- waits on notification
Worker::Wake()                     | |
|-- lock( m_Mutex )                | |
|   `-- m_Mutex.lock()             | |
|-- m_Condition::notify_one()      > |-- wakes up from notification
`-- ~lock()                        | `-- m_Mutex.lock() // blocks
    `-- m_Mutex.unlock()           >     `-- // acquires lock
                                   | // do some work here
                                   | ~lock() // end of for loop's scope
                                   | `-- m_Mutex.unlock()

Result: Worker::Wake() returns fairly quickly, and Worker::ThreadProc runs.

Scenario: Worker::Wake() invoked while Worker::ThreadProc() is not blocked on m_Condition.

Other Thread                       | Worker::ThreadProc
-----------------------------------+------------------------------------------
                                   | lock( m_Mutex )
                                   | `-- m_Mutex.lock()
                                   | m_Condition::wait( lock )
                                   | |-- m_Mutex.unlock()
Worker::Wake()                     > |-- wakes up
                                   | `-- m_Mutex.lock()
Worker::Wake()                     | // do some work here
|-- lock( m_Mutex )                | // still doing work...
|   |-- m_Mutex.lock() // block    | // hope we do not block on a system call
|   |                              | // and more work...
|   |                              | ~lock() // end of for loop's scope
|   |-- // still blocked           < `-- m_Mutex.unlock()
|   `-- // acquires lock           | lock( m_Mutex ) // next 'for' iteration.
|-- m_Condition::notify_one()      | `-- m_Mutex.lock() // blocked
`-- ~lock()                        |     |-- // still blocked
    `-- m_Mutex.unlock()           >     `-- // acquires lock
                                   | m_Condition::wait( lock )    
                                   | |-- m_Mutex.unlock()
                                   | `-- waits on notification
                                   |     `-- still waiting...

Result: Worker::Wake() blocked as Worker::ThreadProc did work, but was a no-op, as it sent a notification to m_Condition when no one was waiting on it.

This is not particularly dangerous for Worker::Wake(), but it can cause problems in Worker::~Worker(). If Worker::~Worker() runs while Worker::ThreadProc is doing work, then Worker::~Worker() may block indefinitely when joining the thread, as the thread may not be waiting on m_Condition at the point in which it is notified, and Worker::ThreadProc only checks m_Running after it is done waiting on m_Condition.

Working Towards a Solution

In this example, lets define the following requirements:

• Worker::~Worker() will not cause std::terminate() to be invoked.
• Worker::Wake() will not block while Worker::ThreadProc is doing work.
• If Worker::Wake() is called while Worker::ThreadProc is not doing work, then it will notify Worker::ThreadProc to do work.
• If Worker::Wake() is called while Worker::ThreadProc is doing work, then it will notify Worker::ThreadProc to perform another iteration of work.
• Multiple calls to Worker::Wake() while Worker::ThreadProc is doing work will result in Worker::ThreadProc performing a single additional iteration of work.

Code:

#include <boost/thread.hpp>
 
class Worker
{
public:
  Worker();
  ~Worker();
  void Wake();
private:
  Worker(Worker const& rhs);             // prevent copying
  Worker& operator=(Worker const& rhs);  // prevent assignment
  void ThreadProc();
 
  enum state { HAS_WORK, NO_WORK, SHUTDOWN };
  
  state                            m_State;
  boost::mutex                     m_Mutex;
  boost::condition_variable        m_Condition;
  boost::thread                    m_Thread;
};
 
Worker::Worker()
  : m_State(NO_WORK)
  , m_Mutex()
  , m_Condition()
  , m_Thread()
{
  m_Thread = boost::thread(&Worker::ThreadProc, this);
}
 
Worker::~Worker()
{
  // Create scope so that the mutex is only locked when changing state and
  // notifying the condition.  It would result in a deadlock if the lock was
  // still held by this function when trying to join the thread.
  {
    boost::lock_guard<boost::mutex> lock(m_Mutex);
    m_State = SHUTDOWN;
    m_Condition.notify_one();
  }
  try { m_Thread.join(); }
  catch ( const boost::thread_interrupted& ) { /* suppress */ };
}
 
void Worker::Wake()
{
  boost::lock_guard<boost::mutex> lock(m_Mutex);
  m_State = HAS_WORK;
  m_Condition.notify_one();
}
 
void Worker::ThreadProc()
{
  for (;;)
  {
    // Create scope to only lock the mutex when checking for the state.  Do
    // not continue to hold the mutex wile doing busy work.
    {
      boost::unique_lock<boost::mutex> lock(m_Mutex);
      // While there is no work (implies not shutting down), then wait on
      // the condition.
      while (NO_WORK == m_State)
      {
        m_Condition.wait(lock);
        // Will wake up from either Wake() or ~Worker() signaling the condition
        // variable.  At that point, m_State will either be HAS_WORK or
        // SHUTDOWN.
      }
      // On shutdown, break out of the for loop.
      if (SHUTDOWN == m_State) break;
      // Set state to indicate no work is queued.
      m_State = NO_WORK;
    }
 
    // do some work here
  }
}

注意:根据个人喜好，我选择不分配 boost::thread在堆上，因此，我不需要通过 boost::scoped_ptr 管理它. boost::thread有一个 default constructor这将引用 Not-a-Thread，它是 move-assignable .

关于c++ - 在类的析构函数中关闭类的线程成员是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11223119/