c++ - boost::thread 导致小事件句柄泄漏？

Question

我正在调试这个数据库项目。它为更高级别的应用程序包装了对 SQLite 的访问。它被设计为异步运行，也就是说，它具有 ExecuteRequestAsync() 和 IsRequestReady() 等方法。当调用 ExecuteRequestAsync 时，它会生成一个 boost::thread 来完成工作并立即返回函数。当更高级别的应用程序决定它不再需要运行请求的结果时，它可能会调用 DumpRequest() 来取消它。由于很难优雅地取消数据库请求，DumpRequest 的实现只是维护一个等待“完成的请求”并将其删除的“清理监视器线程”。所有 boost::threads 都通过 boost::shared_ptr 进行管理，例如:

boost::shared_ptr<boost::thread> my_thread = new boost::thread(boost::bind(&DBCon::RunRequest, &this_dbcon));

当不再需要时(取消):

vector<boost::shared_ptr<boost::thread> > threads_tobe_removed;
// some iteration
threads_tobe_removed[i].get()->join();
threads_tobe_removed.erase(threads_tobe_removed.begin()+i);

我创建了这个单元测试项目来测试执行和转储请求的机制。它运行请求并随机取消正在运行的请求，并重复数千次。机制证明没问题。一切都按预期进行。

但是通过sysinternal的Process Explorer观察单元测试项目，发现存在handle leak问题。每通过 500 次左右，句柄计数就会增加 1，并且永远不会返回。增加的是“事件”类型句柄。文件和线程句柄没有增加(当然，随着线程的产生，句柄的数量在增加，但是每隔一百次就有一个 Sleep(10000) 调用等待它们被清理，以便可以观察到句柄计数)。

我自己没有管理过事件句柄。它们由 boost::thread 在创建线程时创建。我只保证优雅地关闭线程，我不知道这些事件有什么用。

不知道有没有人遇到过类似的问题？泄漏的原因可能是什么？ Process Explorer 中的这个数字是否足够可靠，可以称之为句柄泄漏？有什么办法可以追踪和修复吗？

我在 Windows Vista 和 Visual C++ 上使用静态链接的 boost 1.40。

Answer 1

threads_tobe_removed 的访问是线程安全的吗？如果不是，则可能存在竞争条件，当一个线程通过调用 DumpRequest 将线程添加到 vector，而清理监视器线程从 vector 中删除一个线程。因此，boost::thread-objects 可能会在没有首先加入线程的情况下被销毁，这将使线程在没有关联对象的情况下运行，这可能解释了泄漏。