什么时候POSIX线程取消不立即？

Question

POSIX为线程取消类型指定了两种类型:PTHREAD_CANCEL_ASYNCHRONOUS和PTHREAD_CANCEL_DEFERRED(设置pthread_setcanceltype(3))确定何时pthread_cancel(3)生效.通过我的阅读,POSIX手册页对这些内容并没有太多说明,但Linux手册页中有以下内容PTHREAD_CANCEL_ASYNCHRONOUS:

线程可以随时取消.(通常,它会在收到取消请求后立即取消,但系统不保证这一点.)

我很好奇系统的含义并不能保证这一点.我可以很容易地想象这种情况发生在多核/多CPU系统中(在上下文切换之前).但是单核系统呢:

1. 请求取消并启用取消(pthread_setcancelstate(3))并取消类型设置为PTHREAD_CANCEL_ASYNCHRONOUS？时,我们是否可以立即取消线程？
2. 如果是的话,在什么条件下会发生这种情况？

我主要对Linux(LinuxThreads/NPTL)感到好奇,但更普遍的是关于POSIX标准兼容的查看此取消业务的方式.

更新/澄清:这里真正的实际问题是在调用pthread_cancel()目标线程已启用取消并设置为键入的位置后立即销毁的资源的使用PTHREAD_CANCEL_ASYNCHRONOUS!所以关键在于:在这种情况下取​​消的线程是否有一个很小的可能性在上下文切换后继续正常运行(即使是很短的时间)？

感谢Damon的回答,减少了与下一个上下文切换相关的信号传递和处理问题.

更新2:我回答了我自己的问题,指出这是一个不好的问题,并且应该从根本上不同的概念层面解决基础程序设计.我希望这个"错误"的问题对于那些想知道异步取消的奥秘的人有用.

Answer 1

意思就是说它:它不能保证立即发生.其原因在于,标准中需要实现细节的某种"自由".

例如,在Linux/NPTL下,通过发送信号nr来实现取消.32.当接收到信号时线程被取消,这通常发生在下一个内核到用户交换机,或者下一个中断,或者在时间片结束时(可能意外地,但通常不是).但是,在线程未运行时,永远不会收到信号.因此,真正的问题实际上是信号不一定立即收到.

如果你考虑一下,它甚至不可能做到这一点.因为你可以phtread_cleanup_push使用操作系统必须执行的一些处理程序(它不能只是使线程不存在!),必须运行该线程才能被取消.无法保证任何特定线程(包括您要取消的线程)在您取消线程的确切时间运行,因此无法保证它会立即被取消.
当然,除了假设,如果OS的实现方式是阻塞调用线程并安排要取消的线程,以便它执行其处理程序,并且之后只解除阻塞pthread_cancel.但由于pthread_cancel未指定为阻止,这将是一个非常令人讨厌的惊喜.由于干扰执行时间限制和调度程序公平性,这也有些不可接受.

因此,要么取消类型是"禁用",那么没有任何反应.或者,它是"启用",并且取消类型是"延迟",然后线程在调用列为取消点的函数时取消pthreads(7).
或者,它是"异步的",然后如上所述,操作系统会在它认为合适时立即取消线程 - 不是在精确,明确定义的时间,而是"很快".在Linux的情况下,通过发送信号.