何时使用pthread_cancel而不是pthread_kill?

Sas*_*shi 25 pthreads

什么时候使用pthread_cancel而不是pthread_kill

pax*_*blo 32

我不会同时使用这两种,但这只是个人偏好.

在这两个中,pthread_cancel最安全的是终止线程,因为线程只有在将其可取消性状态设置为true时才会受到影响pthread_setcancelstate().

换句话说,在以可能导致死锁的方式保存资源时,它不应该消失.该pthread_kill()调用向特定线程发送信号,这是一种异常影响线程的方法,除了取消它之外的其他原因.

我的大多数线程都倾向于在循环中进行工作并定期检查标志以查看它们是否应该退出.这主要是因为我在一个pthread_kill()危险pthread_cancel()且不存在的世界中长大.

我赞同这样的理论,即每个线程应该完全控制自己的资源,包括它的执行生命周期.我总是发现这是避免死锁的最佳方法.为此,我只使用互斥锁进行线程之间的通信(我很少发现需要真正的异步通信)和一个用于终止的标志变量.

  • 我大多同意,除非线程的工作是部分或完全IO.在这种情况下,可能会陷入阻止永远不会返回的系统调用,并且取消和中断信号是唯一可以解除卡住的方法.此外,为此目的使用中断信号总是具有竞争条件,除非你只是用信号轰击目标线程直到它退出,留下取消作为最实用的选择.IMO很遗憾,取消被指定为可怕的异常 - 就像展开而不是让系统调用返回"ECANCELLED"...... (2认同)

小智 7

你不能“杀死”一个线程pthread_kill()。如果您尝试使用 发送SIGTERMSIGKILL到一个线程pthread_kill(),它将终止整个过程。

我赞同这样一种理论,即程序员而不是线程(也不是 API 设计者)应该在各个方面完全控制自己的软件,包括哪些线程取消哪些。

我曾经在一家公司工作,在那里我们开发了一个服务器,该服务器使用一个工作线程池和一个特殊的主线程,该主线程负责随时创建、挂起、恢复和终止工作线程。当然,线程使用了某种同步,但这是我们的设计,而不是一些 API 强制的教条。该系统运行良好且高效!

这是在 Windows 下。然后我尝试将它移植到 Linux,我偶然发现了 pthread 的愚蠢“理论”,关于挂起另一个线程等是多么错误。所以我不得不放弃 pthreads 并直接使用本机 Linux 系统调用 ( clone()) 来实现线程对于我们的服务器。