Killing a pthread waiting on a condition variable

Question

Hi,

I have a pthread waiting on a condition variable using pthread_cond_wait. It's waiting for data from a queue structure that is filled by another thread. I want to kill this thread, preferably without pthread_kill. On Linux and WinPthreads doing a pthread_cancel(); pthread_join() is enough to kill it. However, on OS X it hangs on the pthread_join call. Any suggestions?

Answer 1

The first thing I would try would be to kick the condition variable in between the cancel and the join, and have your target thread check for cancellation explicitly after it returns from the condition wait.

That's because it may be that the thread is not responding to cancellation while it's in the condition wait (or at all).

POSIX.1c-2004 (v6) states:

The cancelability state and type of any newly created threads, including the thread in which main() was first invoked, shall be PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DEFERRED respectively.

That means you have to explicitly check for cancellation with pthread_testcancel().

The other option is to actually set the threads cancel type to PTHREAD_CANCEL_ASYNCHRONOUS when it first starts to run, something like:

int junk;
pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, &junk);
std::cout
    << ((junk==PTHREAD_CANCEL_DEFERRED) ? "Was deferred" : "Wasn't")
    << std::endl;

That is, of course, assuming that's what the problem is. You should be able to test if it is by examining the output of that third line above.

Cancellation is a request to the target thread which it is free to ignore if it wishes, as opposed to the far more evil pthread_kill(). I'm a great believer in letting threads control their own lifetimes since I've found it invariably leads to fewer concurrency problems.

Aside: In fact, having been bought up in very early editions of pthreads, even before integration into DCE, I still find myself just using a global variable for each thread indicating when it should exit, along with manually kicking mutexes or condition variables to wake the threads up. I guess I should update my methods (or I would if I could see a clear advantage). :-)

Answer 2

pthread_cancel should wake a thread that is blocked in pthread_cond_wait --- this is one of the required cancellation points. If it doesn't work then something is wrong.

The first thing to check is that cancellation is indeed enabled on the target thread --- explicitly call pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,&oldstate) on the target thread to make sure. If that doesn't work, then cancellation is broken on your platform and you'll have to resort to alternatives such as setting a "please stop now" flag and signalling the condition variable.

Do not use asynchronous cancellation unless you really know what you are doing --- it can trigger the cancellation in the middle of any operation (e.g. in the middle of setting up a function call stack frame or running a destructor), and thus can leave your code in a thoroughly inconsistent state. Writing async-cancel-safe code is hard.

Incidentally pthread_kill does not kill a thread --- it sends a signal to it.

Answer 3

Do you have access to the queue, and control of the object schema for enqueued items? If so, define a queue object type that when de-queued, instructs the thread that is processing the item to exit gracefully.

Now, to shut down these threads, simply post a number of these "quit" objects to the HEAD of the queue that corresponds to the number of threads that are servicing the queue, and join on the threads.

This seems much cleaner than the "nuclear option" of pthread_cancel/kill.