30

When does one use pthread_cancel and not pthread_kill?

Community
  • 1
  • 1
Sashi
  • 3,069
  • 6
  • 20
  • 18

2 Answers2

37

I would use neither of those two but that's just personal preference.

Of the two, pthread_cancel is the safest for terminating a thread since the thread is only supposed to be affected when it has set its cancelability state to true using pthread_setcancelstate().

In other words, it shouldn't disappear while holding resources in a way that might cause deadlock. The pthread_kill() call sends a signal to the specific thread, and this is a way to affect a thread asynchronously for reasons other than cancelling it.

Most of my threads tends to be in loops doing work anyway and periodically checking flags to see if they should exit. That's mostly because I was raised in a world when pthread_kill() was dangerous and pthread_cancel() didn't exist.

I subscribe to the theory that each thread should totally control its own resources, including its execution lifetime. I've always found that to be the best way to avoid deadlock. To that end, I simply use mutexes for communication between threads (I've rarely found a need for true asynchronous communication) and a flag variable for termination.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • 1
    Agreed re: execution life-time. In our app it has proven easier to manage the difficulty of having to wait for a thread to die (because the thread only picks up its "go terminate yourself" message at fixed points, e.g. after running a single job in a run-loop to completion) than to make sure that every single bit of threaded code is capable of being killed randomly at any point without leaking any memory or leaving a data structure inconsistent. We have a small number of code sites that must wait fora thread to terminate, but a lot of work items run on threads. – Ben Supnik Dec 07 '10 at 16:57
  • 3
    I mostly agree, except when the thread's job is partly or fully IO. In this case, it's possible to get stuck in blocking syscall that will never return, and cancellation and interrupting signals are the only way to get un-stuck. Further, use of interrupting signals for this purpose always has a race condition unless you just go in a loop bombarding the target thread with signals until it exits, leaving cancellation as the most practical choice. IMO it's just a shame that cancellation was specified with horrible exception-like unwinding instead of making syscalls return with `ECANCELLED`... – R.. GitHub STOP HELPING ICE Feb 16 '12 at 16:36
  • Could you clarify regard to race condition of sending interrupt signals to thread ? – user1502776 Jun 06 '19 at 00:29
7

You can not "kill" a thread with pthread_kill(). If you try to send SIGTERM or SIGKILL to a thread with pthread_kill(), it will terminate the entire process.

I subscribe to the theory that the PROGRAMMER and not the THREAD (nor the API designers) should totally control its own software in all aspects, including which threads cancel which.

I once worked in a firm where we developed a server that used a pool of worker threads and one special master thread that had the responsibility to create, suspend, resume and terminate the worker threads at any time it wanted. Of course the threads used some sort of synchronization, but it was of our design and not some API-enforced dogmas. The system worked very well and efficiently!

This was under Windows. Then I tried to port it for Linux and I stumbled at the pthreads' stupid "theories" about how wrong it is to suspend another thread etc. So I had to abandon pthreads and directly use the native Linux system calls (clone()) to implement the threads for our server.

roschach
  • 8,390
  • 14
  • 74
  • 124
ohcul
  • 71
  • 1
  • 1