4

Hello I have an question about cancelling a thread that uses mutexes and conditional variables. The thread has cancel type deferred. When I use only the functions pthread_mutex_lock/unlock and pthread_cond_wait, and a cancel request arrives, the thread's cancelation point is only pthread_cond_wait. Will it lock the mutex or not? I am not sure, if thread always leaves the mutex unlock. Or are the pthread_mutex_lock/unlock functions also cancellation points? Thank you.

Kouros
  • 341
  • 5
  • 19

3 Answers3

4

I doubt that I can phrase this better than the documentation:

A condition wait (whether timed or not) is a cancellation point. When the cancelability type of a thread is set to PTHREAD_CANCEL_DEFERRED, a side effect of acting upon a cancellation request while in a condition wait is that the mutex is (in effect) re-acquired before calling the first cancellation cleanup handler. The effect is as if the thread were unblocked, allowed to execute up to the point of returning from the call to pthread_cond_timedwait() or pthread_cond_wait(), but at that point notices the cancellation request and instead of returning to the caller of pthread_cond_timedwait() or pthread_cond_wait(), starts the thread cancellation activities, which includes calling cancellation cleanup handlers.

Also just be sure you are aware that other functions are cancellation points as well.

Community
  • 1
  • 1
Scis
  • 2,934
  • 3
  • 23
  • 37
  • Bet me be 15 secs ...;-) – alk Jun 21 '14 at 09:42
  • Yep, I believe I did ^^ – Scis Jun 21 '14 at 09:45
  • Ok so pthread_cond_wait may or may not lock the mutex when cancelled. I better disable thread’s cancebility, because if my cleanup handler unlocks the mutex without owning it, it would be a disaster. Is there a function like sigpending to see if a cancellation request is pending? – Kouros Jun 22 '14 at 11:50
  • 1
    Not that I know of ([this](http://stackoverflow.com/questions/13010257) might be related) Why not have your own cancellation mechanism (which can be simple and predictable [(take a look here)](http://stackoverflow.com/questions/4760687))? – Scis Jun 22 '14 at 13:07
  • 1
    If you absolutely have to use `cancel`, you could use a hacky solution in which you start off by having a [`pthread_setcancelstate`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setcancelstate.html) as disabled and then enable it at points in which you're ready to cancel and call [`pthread_testcancel`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_testcancel.html) just right after that (but this is a hack and I would advise against it :) ). And please consider [accepting the answer](http://meta.stackexchange.com/a/5235/262472) using the V sign . – Scis Jun 22 '14 at 13:07
  • Ok I drop the idea of canceling a thread, I will use a shared variable. When a thread doesn't respond, then I will cancel it. Cancel is than my last resort. Thank you all! – Kouros Jun 25 '14 at 09:59
0

If you have multiple threads waiting on pthread_cond_wait and you call pthread_cancel before sending out some of kind of broadcast using pthread_cond_broadcast or pthread_cond_signal, then it may lead to a deadlock where the pthread_cond_wait is waiting on thread to cancel and thread is waiting on the pthread_cond_wait to come out.

Axel
  • 3,331
  • 11
  • 35
  • 58
Nishikant Deshmukh
  • 1
0

Per "The Linux Programming Interface" book pages 667-678 the mutex will be locked. So you can use

pthread_mutex_lock(&mutex);
pthread_cleanup_push((void (*)(void *))pthread_mutex_unlock, &mutex);
while (var == 0)) {
    pthread_cond_wait(&cond, &mutex);
}
pthread_cleanup_pop(1);
Mike Dubrovskiy
  • 1
  • 1
  • You *can* do that, but then you reap undefined behavior upon cancellation as a result of `pthread_mutex_unlock()` being called via a pointer to an incompatible function type. As a separate matter, this is an old question with an accepted answer that is still perfectly valid. Your contributions are welcome, but they would be more helpful if directed toward questions that don't already have good answers. – John Bollinger Oct 20 '20 at 14:06