使用pthread_cancel取消线程:良好做法或不好

我在Linux(CentOS 5.3)上有一个C++程序,它产生多个线程,这些线程处于无限循环中以执行作业并在某些时间内休眠.现在我必须取消正在运行的线程以防新的配置通知进入并重新启动新的线程集,我已经使用了pthread_cancel.我观察到的是,即使在接收到取消指示后,线程也没有停止,甚至在睡眠完成后一些睡眠线程也会出现.

由于不需要这种行为,在上述场景中使用pthread_cancel会引发关于好坏练习的问题.

请评论上述场景中的pthread_cancel用法.

1> David Rodríg..：

---

一般来说,线程取消并不是一个好主意.只要有可能,最好有一个共享标志,线程使用该标志来突破循环.这样,您将让线程执行在实际退出之前可能需要执行的任何清理.

在没有实际取消的线程问题上,POSIX规范确定了一组取消点(man 7 pthreads).线程只能在这些点取消.如果您的无限循环不包含取消点,您可以通过调用添加一个取消点pthread_testcancel.如果pthread_cancel被调用,那么此时它将被采取行动.

---

不能同意.`pthread_cancel()`可能更容易使用.如果调用`pthread_cleanup_push()`和`pthread_cleanup_pop()`来设置清理处理程序,则可以避免资源泄漏.

---

+1用于避免取消,这是内存泄漏的最快方式,更糟糕的是.礼貌地问问:)

---

似乎我必须使用共享标志来更改线程终止的逻辑。但是，另一方面，我的程序有取消状态设置为ASYNCHRONOUS的线程，我认为这与在调用相应的清理处理程序后立即终止线程有关。

2> Maxim Egorus..：

---

如果您正在编写异常安全的C++代码(请参阅http://www.boost.org/community/exception_safety.html),那么您的代码自然可以用于线程取消.glibs在线程取消时引发C++异常,因此你的析构函数可以进行适当的清理.

---

如果OP知道他们永远不需要在另一个pthreads实现上运行,那没关系,但我建议不要依赖于通过异常实现的线程取消.使用标志将线程退出"隐藏的东西"并进入您可以看到的代码,使后来的维护者更容易.多年来我一直有这个特殊问题的经验,我得出的结论是,最好的办法是避免取消,因为当你取消混合时,总会有一些东西让你沮丧.

---

这篇博客文章描述了为什么RAII不能与取消完全组合：https://skaark.wordpress.com/2010/08/26/pthread_cancel-considered-harmful/