public inbox for
 help / color / mirror / Atom feed
From: Simon Gerblich <>
To: vc <>
Subject: RE: problem using pthread_cancel and pthread_mutex_lock
Date: Tue, 24 Feb 2004 04:23:00 -0000	[thread overview]
Message-ID: <> (raw)

Hi Viv,

>So, my question is: how can a thread cleanly cancel another thread
>which is waiting in a 'pthread_mutex_lock' call, so that this mutex is
>available again ?
I can see a few problems in what you are doing.

A mutex is not really designed to be locked in a thread for a long time and
unlocked by another thread.  When I use a mutex in a thread I lock it - do
what I have to do  - and then unlock it ASAP.  I don't use mutexes to
synchronise threads.  I use them to protect data.  Pthread mutexes are not
cancellation points.

I use deferred cancellation instead of asynchronous cancellation because of
recommendations in "Programming with POSIX Threads" by David Butenhof.
Page 150 "Avoid asynchronous cancellation.  It is difficult to use correctly
and is rarely useful."
Page 151 "Asynchronous cancellation can occur at any hardware instruction.
On some computers it may even be possible to interrupt some instructions in
the middle.  That makes it really difficult to determine what the canceled
thread was doing."
Page 151 "Call no code with asynchronous cancellation enabled unless you
wrote it to be async-cancel safe - and even then, think twice!"

I write my applications with deferred cancellation and the threads blocking
on message queues, which are cancellation points.  When a cancel is
requested the threads exit cleanly when they next go to read the message
queue.  I have minimal cancellation points in my code so that I know exactly
where my threads will cancel.  

Without knowing exactly what you are trying to do I think you should have a
look at using a condition variable instead of a mutex for your thread
syncing.  Waiting on a condition variable is a cancellation point.

Be aware that the Sleep() function on windows is not a cancellation point.
I have written my own sleep functions to use with pthreads-win32 that waits
on condition variables with timeouts.

If your not lurking in the google groups comp.programming.threads I'd
recommend it.  I've learnt a lot following threads on pthreads, etc.


             reply	other threads:[~2004-02-24  4:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-24  4:23 Simon Gerblich [this message]
2004-02-26 15:59 ` vc
  -- strict thread matches above, loose matches on Subject: below --
2004-03-09 23:25 Simon Gerblich
2004-03-10  0:57 ` Will Bryant
2004-03-10 11:11 ` vc
2004-02-23 17:43 vc
2004-03-01 16:27 ` vc
2004-03-04 23:13   ` Ross Johnson
2004-03-09 14:06     ` vc
2004-03-09 14:15     ` Brano Kemen
2004-03-09 15:09       ` Panagiotis E. Hadjidoukas
2004-03-09 15:42         ` Brano Kemen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).