I've always thought APIs like `pthread_cancel` are too nasty to use. Glad to see well documented evidence of my crank opinion
Imagine cpu-bound worker threads that do nothing but consume work via condition variables and spend long periods of time in hot compute-only loops working on said work... Instead of adding a conditional in the compute you're probably not interested in slowing down at all, you turn on async cancellation and pthread_cancel() the workers when you need to interrupt what's going on.
But it's worth noting pthread_cancel() is also rarely supported anywhere outside first-class pthreads-capable systems like modern linux. So if you have any intention of running elsewhere, forget about it. Thread cancellation support in general is actually somewhat rare IME.
Having written some of the implementation for a non x86 commercial Unix well over 30 years ago now (yeah, I know), pthread_cancel is not that rare. A carve out like “modern linux” is io_uring or even inotify and epoll. AIX and HP-UX, fuck even OSF/1 had pthread_cancel.
Windows has TerminateThread. Most RTOS have some kind of thread level task killing interface.
While they have different semantics than pthread_cancel, that doesn’t really affect the example you’re giving - they can all be used for the “cpu-bound worker”
> Originally, there was no TerminateThread function. The original designers felt strongly that no such function should exist because there was no safe way to terminate a thread, and there’s no point having a function that cannot be called safely. But people screamed that they needed the TerminateThread function, even though it wasn’t safe, so the operating system designers caved and added the function because people demanded it. Of course, those people who insisted that they needed TerminateThread now regret having been given it.
`pthread_cancel` is different
If your code is running in a hot loop, you would have to insert that branch into the hot loop (even well-predicted branches add a few cycles, and can do things like break up decode groups) or have the hot loop bail out every once in a while to go execute the branch and code, which would mean tiling your interior hot loop and thus adding probably significant overhead that way.
Also, you say "cached memory address" but I can almost guarantee that unless you're doing that load a lot more frequently than once every 10 milliseconds the inner loop is going to knock that address out of l1 and probably l2 by the time you get back around to it.
Also, don’t you have to hit a pthread cancellation point for pthread_cancel to take effect?
Those are way more expensive than a branch, but if you want the exact behavior, you could do “if (done) { break; } else { pthread_??? }”
No, the whole point here is async cancellation - you don't test for it and you don't enter a cancellation point.
Excerpt from pthread_setcancelstate(3):
> Asynchronous cancelability
> Setting the cancelability type to PTHREAD_CANCEL_ASYNCHRONOUS is rarely useful.
> Since the thread could be canceled at any time, it cannot safely reserve resources
> (e.g., allocating memory with malloc(3)), acquire mutexes, semaphores, or locks, and
> so on. Reserving resources is unsafe because the application has no way of knowing
> what the state of these resources is when the thread is canceled; that is, did cance-
> lation occur before the resources were reserved, while they were reserved, or after
> they were released? Furthermore, some internal data structures (e.g., the linked
> list of free blocks managed by the malloc(3) family of functions) may be left in an
> inconsistent state if cancelation occurs in the middle of the function call. Conse-
> quently, clean-up handlers cease to be useful.
>
> Functions that can be safely asynchronously canceled are called async-cancel-safe
> functions. POSIX.1-2001 and POSIX.1-2008 require only that pthread_cancel(3),
> pthread_setcancelstate(), and pthread_setcanceltype() be async-cancel-safe. In gen-
> eral, other library functions can't be safely called from an asynchronously cance-
> lable thread.
>
> One of the few circumstances in which asynchronous cancelability is useful is for
> cancelation of a thread that is in a pure compute-bound loop.