POSIX线程何时不立即取消? [英] When is POSIX thread cancellation not immediate?

问题描述

POSIX为线程取消类型指定两种类型: PTHREAD_CANCEL_ASYNCHRONOUS 和 PTHREAD_CANCEL_DEFERRED (由 pthread_setcanceltype(3)设置)确定何时 pthread_cancel(3)应该生效.就我的阅读而言，POSIX手册页对此没有多说，但是Linux手册页说了有关 PTHREAD_CANCEL_ASYNCHRONOUS 的以下内容:

The POSIX specifies two types for thread cancellation type: PTHREAD_CANCEL_ASYNCHRONOUS, and PTHREAD_CANCEL_DEFERRED (set by pthread_setcanceltype(3)) determining when pthread_cancel(3) should take effect. By my reading, the POSIX manual pages do not say much about these, but Linux manual page says the following about PTHREAD_CANCEL_ASYNCHRONOUS:

可以随时取消线程.(通常，它会在收到取消请求后立即被取消，但系统不对此予以保证.)

The thread can be canceled at any time. (Typically, it will be canceled immediately upon receiving a cancellation request, but the system doesn't guarantee this.)

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

I am curious about the meaning about the system doesn't guarantee this. I can easily imagine this happening in multicore/multi-CPU systems (before context switch). But what about single core systems:

1. 请求取消并启用取消( pthread_setcancelstate(3))并将取消类型设置为 PTHREAD_CANCEL_ASYNCHRONOUS 时，是否可以不立即取消线程?
2. 如果是，在什么情况下会发生这种情况?

1. Could we have a thread not cancelled immediately when cancellation is requested and cancellation is enabled (pthread_setcancelstate(3)) and cancel type set to PTHREAD_CANCEL_ASYNCHRONOUS?
2. If yes, under what conditions could this happen?

我主要是对Linux(LinuxThreads/NPTL)感到好奇，但更笼统地说，是关于POSIX标准的查看取消业务的方式.

I am mainly curious about Linux (LinuxThreads / NPTL), but also more generally about POSIX standard compliant way of viewing this cancellation business.

更新/澄清:这里真正的实际问题是调用 pthread_cancel()后立即销毁的资源的使用，其中目标线程已启用取消并设置为type PTHREAD_CANCEL_ASYNCHRONOUS ！！！因此，真正的重点是:在这种情况下，取消的线程在上下文切换后甚至即使很小的时间也能继续正常运行吗?

Update/Clarification: Here the real practical concern is usage of resources that are destroyed immediately after calling pthread_cancel() where the targeted thread have cancellation enabled and set to type PTHREAD_CANCEL_ASYNCHRONOUS!!! So the point really is: is there even a tiny possibility for the cancelled thread in this case to continue running normally after context switch (even for a very small time)?

感谢达蒙的回答，减少了与下一个上下文切换有关的信号传递和处理的问题.

Thanks for Damon's answer the question is reduced about signal delivery and handling in relation to the next context switch.

Update-2:我回答了我自己的问题，指出这是一个令人担忧的问题，并且应该在根本不同的概念级别上解决底层程序设计.我希望这个错误"的问题对其他想知道异步取消之谜的人有用.

Update-2: I answered my own question to point that this is bad concern and that the underlying program design should be addressed in fundamentally different conceptual level. I wish this "wrong" question is useful for others wondering about mysteries of asynchronous cancellation.

推荐答案

含义就是它所说的:它不能保证立即发生.这样做的原因是，实现细节需要一定的自由"，并在标准中加以考虑.

The meaning is just what it says: It's not guaranteed to happen instantly. The reason for this is that a certain "liberty" for implementation details is needed and accounted for in the standard.

例如在Linux/NPTL下，取消是通过发送信号nr来实现的.32.线程在收到信号时被取消，这通常发生在下一个内核到用户的切换，下一个中断或时间片的结尾(可能偶然地 )立即，但通常不是).但是，在线程不运行时，永远不会收到信号.因此，这里真正的收获是实际上不一定会立即收到信号.

For example under Linux/NPTL, cancellation is implemented by sending signal nr. 32. The thread is cancelled when the signal is received, which usually happens at the next kernel-to-user switch, or at the next interrupt, or at the end of the time slice (which may accidentially be immediately, but usually is not). A signal is never received while the thread isn't running, however. So the real catch here is actually that signals are not necessarily received immediately.

如果您考虑一下，也根本不可能做得太大不同.由于您可以 phtread_cleanup_push 操作系统必须执行的某些处理程序(它不能仅将线程炸毁而已！)，因此线程必须必须被取消.无法保证任何特定线程(包括您要取消的线程)在取消线程的确切时间都在运行，因此无法保证立即取消该线程.
当然，除了假设情况之外，如果操作系统以某种方式实现以阻塞调用线程并计划要取消的线程，以便其执行其处理程序，然后仅取消阻塞pthread_cancel.但是由于未将 pthread_cancel 指定为阻止，因此这绝对是令人讨厌的惊喜.由于会干扰执行时间限制和调度程序公平性，因此这在某种程度上也是不能接受的.

If you think about it, it isn't even possible to do it much different, either. Since you can phtread_cleanup_push some handlers which the operating system must execute (it cannot just blast the thread out of existence!), the thread must necessarily run to be cancelled. There is no guarantee that any particular thread (including the one you want to cancel) is running at the exact time you cancel a thread, so there can be no guarantee that it is cancelled immediately.
Except of course, hypothetically, if the OS was implemented in a way as to block the calling thread and schedule the to-be-cancelled thread so it executes its handlers, and only unblocks pthread_cancel afterwards. But since pthread_cancel isn't specified as blocking, this would be an utterly nasty surprise. It would also be somewhat inacceptable because of interfering wtih execution time limits and scheduler fairness.

因此，您的取消类型为禁用"，则什么也没有发生.或者，它是"enable"，取消类型是"deferred"，则当调用 pthreads(7)中列为取消点的函数时，线程会取消.
或者，它是异步的"，则如上所述，操作系统将在认为适当时立即执行某事"以取消线程-不是在精确的定义好的时间，而是很快".对于Linux，则通过发送信号来实现.

So, either your cancel type is "disable", then nothing happens. Or, it is "enable", and the cancel type is "deferred", then the thread cancels when calling a function that is listed as cancellation point in pthreads(7).
Or, it is "asynchronous", then as stated above, the OS will do "something" to cancel the thread as soon as it deems appropriate -- not at a precise, well-defined time, but "soon". In the case of Linux, by sending a signal.

这篇关于POSIX线程何时不立即取消?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！