Когда отмена потока POSIX не является немедленной?

Смысл именно в том, что он говорит: это не гарантированно произойдет мгновенно. Причина этого в том, что необходима определенная «свобода» в отношении деталей реализации, которая учитывается в стандарте.

Например, в Linux/NPTL отмена осуществляется путем отправки сигнала nr. 32. Поток отменяется при получении сигнала, что обычно происходит при следующем переключении ядра на пользователя, или при следующем прерывании, или в конце кванта времени (что может случайно быть немедленно, но обычно это не так). Однако сигнал никогда не принимается, пока поток не запущен. Итак, настоящая загвоздка здесь в том, что сигналы не обязательно принимаются немедленно.

Если подумать, то и по-другому сделать тоже невозможно. Поскольку вы можете phtread_cleanup_push некоторые обработчики, которые должна выполнять операционная система (она не может просто уничтожить поток!), поток должен обязательно запуститься для отмены. Нет никакой гарантии, что какой-либо конкретный поток (включая тот, который вы хотите отменить) запущен в точное время, когда вы отменяете поток, поэтому нет гарантии, что он будет отменен немедленно.
За исключением, конечно, гипотетического случая, если ОС была реализована таким образом, чтобы блокировать вызывающий поток и планировать подлежащий отмене поток, чтобы он выполнял свои обработчики и только после этого разблокировал pthread_cancel. Но поскольку pthread_cancel не указано как блокирующее, это было бы совершенно неприятным сюрпризом. Это также было бы несколько неприемлемо из-за вмешательства в ограничения времени выполнения и справедливости планировщика.

Итак, либо ваш тип отмены «отключить», тогда ничего не происходит. Или это «включить», а тип отмены «отложен», тогда поток отменяется при вызове функции, которая указана как точка отмены в pthreads(7).
Или это «асинхронно», тогда, как указано выше, ОС сделает «что-то», чтобы отменить поток, как только сочтет это целесообразным — не в точное, четко определенное время, а «скоро». В случае Linux, отправив сигнал.

Если вам нужно задаться вопросом, когда произойдет асинхронная отмена, вы делаете что-то ужасно неправильное.

1. Следование стандартам. Вы грызете землю под ногами, преднамеренно создавая или позволяя существовать коду, правильность которого зависит от предположений о платформе (одно ядро, конкретная реализация и т. д.). Почти всегда лучше, если это возможно, следовать стандартам (и четко документировать, когда это невозможно). Само название PTHREAD_CANCEL_ASYNCHROUNOUS предполагает значение асинхронный, которое отличается от немедленного или даже почти немедленного. В оригинальном плакате конкретно указано одно ядро, но почему вы должны допускать существование кода, который будет ломаться недетерминированным образом, когда ваш код запускается на действительно параллельных машинах (многоядерных или ЦП), где практически невозможно иметь гарантию немедленности (для этого потребуется остановить работу других ядер или дождаться переключения контекста или какого-либо другого ужасного взлома, который ваша ОС / ЦП не будет поддерживать для поддержки ваших нетрадиционных желаний). Режим асинхронной отмены потока не предназначен для гарантированной немедленной отмены потока. Следовательно, использовать их таким образом ужасно запутанно, даже если это сработает.

2. Асинхронная безопасность. Если вас беспокоит механизм асинхронной отмены, возникает подозрение, что рассматриваемые потоки (из-за отсутствия независимости), возможно, не являются чисто вычислительными. или написаны в стиле асинхронно-отмена-безопасно.

   POSIX определяет только три функции как безопасные для асинхронной отмены: pthread_cancel(3), pthread_setcancelstate(3) и pthread_setcancelmode(3) — см. IEEE Std 1003.1, издание 2013 г., 2.9.5. Этот режим отмены подходит только для чисто вычислительных задач, которые не вызывают (кроме чисто вычислительных) библиотечных функций; такой код не предоставил бы точки отмены, если бы потоки были настроены на выполнение в режиме отложенной отмены по умолчанию. Отсюда обоснование определения такого режима.

   Можно написать безопасный для асинхронной отмены код, отключив отмену во время критических секций. Но авторы библиотек (включая разработчиков библиотек POSIX) в целом не должны заботиться об асинхронной безопасности по причинам следования общему соглашению, избежания сложности и даже снижения производительности. Поскольку авторам библиотек все равно, вы никогда не должны ожидать асинхронной безопасности, если явно не указано иное.

   Если ваш код не является асинхронно-безопасным (например, из-за вызова других библиотек, включая POSIX/стандартные библиотеки C, без временного отключения отмены или изменения режима отмены) и происходит асинхронная отмена, вы можете утечь ресурсы (память и т. д.), оставить несогласованные состояния и заблокированные мьютексы, блокирующие другие потоки, и вызывают множество других проблем, которые в настоящее время вообразимы и невообразимы. (Если вы пишете на C++, похоже, у вас будут другие проблемы, связанные с отменой потока POSIX, тесно связанной с обработкой исключений.)