gpt4 book ai didi

c++ - 为什么这种线程管理模式会导致死锁?

转载 作者:塔克拉玛干 更新时间:2023-11-03 01:47:57 25 4
gpt4 key购买 nike

我正在使用一个公共(public)基类 has_threads 来管理应该允许实例化 boost::thread 的任何类型。

has_threads 的实例各自拥有一个 setthread(以支持 waitAllinterruptAll 函数,我不在下面包括),并且应该在线程终止时自动调用 removeThread 以维护此 set 的完整性。

在我的程序中,我只有其中一个。每隔 10 秒创建一个线程,每个线程执行一次数据库查找。查找完成后,线程运行完成,应该调用 removeThread;使用互斥锁集,线程对象从内部跟踪中删除。我可以看到这与输出 ABC 一起正常工作。

不过,这些机制偶尔会发生冲突。 removeThread 可能同时执行两次。我不明白为什么这会导致死锁。从这一点开始的所有线程调用都不会输出 A 以外的任何内容。 [值得注意的是,我使用的是线程安全的标准库,当不使用 IOStreams 时问题仍然存在。] 堆栈跟踪表明互斥体正在锁定这些线程,但为什么不锁定最终由第一个线程释放第二个线程,然后第二个线程释放第三个线程,依此类推?

我是否遗漏了有关 scoped_lock 工作原理的一些基本知识?尽管(或什至由于?)使用了互斥锁,但这里有什么我遗漏的明显可能导致死锁的地方吗?

很抱歉这个糟糕的问题,但我相信您已经知道,几乎不可能为这样的错误提供真实的测试用例。

class has_threads {
protected:
template <typename Callable>
void createThread(Callable f, bool allowSignals)
{
boost::mutex::scoped_lock l(threads_lock);

// Create and run thread
boost::shared_ptr<boost::thread> t(new boost::thread());

// Track thread
threads.insert(t);

// Run thread (do this after inserting the thread for tracking so that we're ready for the on-exit handler)
*t = boost::thread(&has_threads::runThread<Callable>, this, f, allowSignals);
}

private:

/**
* Entrypoint function for a thread.
* Sets up the on-end handler then invokes the user-provided worker function.
*/
template <typename Callable>
void runThread(Callable f, bool allowSignals)
{
boost::this_thread::at_thread_exit(
boost::bind(
&has_threads::releaseThread,
this,
boost::this_thread::get_id()
)
);

if (!allowSignals)
blockSignalsInThisThread();


try {
f();
}
catch (boost::thread_interrupted& e) {

// Yes, we should catch this exception!
// Letting it bubble over is _potentially_ dangerous:
// http://stackoverflow.com/questions/6375121

std::cout << "Thread " << boost::this_thread::get_id() << " interrupted (and ended)." << std::endl;
}
catch (std::exception& e) {
std::cout << "Exception caught from thread " << boost::this_thread::get_id() << ": " << e.what() << std::endl;
}
catch (...) {
std::cout << "Unknown exception caught from thread " << boost::this_thread::get_id() << std::endl;
}
}

void has_threads::releaseThread(boost::thread::id thread_id)
{
std::cout << "A";
boost::mutex::scoped_lock l(threads_lock);

std::cout << "B";
for (threads_t::iterator it = threads.begin(), end = threads.end(); it != end; ++it) {

if ((*it)->get_id() != thread_id)
continue;

threads.erase(it);
break;
}
std::cout << "C";
}

void blockSignalsInThisThread()
{
sigset_t signal_set;
sigemptyset(&signal_set);
sigaddset(&signal_set, SIGINT);
sigaddset(&signal_set, SIGTERM);
sigaddset(&signal_set, SIGHUP);
sigaddset(&signal_set, SIGPIPE); // http://www.unixguide.net/network/socketfaq/2.19.shtml
pthread_sigmask(SIG_BLOCK, &signal_set, NULL);
}


typedef std::set<boost::shared_ptr<boost::thread> > threads_t;
threads_t threads;

boost::mutex threads_lock;
};

struct some_component : has_threads {
some_component() {
// set a scheduler to invoke createThread(bind(&some_work, this)) every 10s
}

void some_work() {
// usually pretty quick, but I guess sometimes it could take >= 10s
}
};

最佳答案

好吧,如果同一个线程锁定它已经锁定的互斥量(除非您使用递归互斥量),则可能会发生死锁。

如果释放部分被同一个线程第二次调用,就像它似乎发生在您的代码中,那么您就会遇到死锁。

我没有详细研究你的代码,但你可能必须重新设计你的代码(简化?)以确保同一线程不能两次获取锁。您或许可以对锁的所有权使用安全检查 ...

编辑:正如我在评论和 IronMensan 回答中所说,一种可能的情况是线程在创建期间停止,在释放锁定在代码创建部分的互斥锁之前调用 at_exit。

编辑2:

嗯,有了mutex和scoped lock,我只能想象一个递归锁,或者一个不释放的锁。例如,如果循环由于内存损坏而进入无限循环,就会发生这种情况。

我建议添加更多带有线程 ID 的日志,以检查是否存在递归锁或其他奇怪的东西。然后我会检查我的循环是否正确。我还将检查每个线程只调用一次 at_exit ...

还有一件事,检查在 at_exit 函数中删除(从而调用析构函数)线程的效果...

我的 2 美分

关于c++ - 为什么这种线程管理模式会导致死锁?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8434762/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com