From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21947 invoked by alias); 24 Feb 2004 04:23:37 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 21934 invoked from network); 24 Feb 2004 04:23:36 -0000 Received: from unknown (HELO ns1.daronmont.com.au) (150.101.16.97) by sources.redhat.com with SMTP; 24 Feb 2004 04:23:36 -0000 Received: from pd001649.daronmont.com.au by ns1.daronmont.com.au via smtpd (for sources.redhat.com [67.72.78.213]) with SMTP; 24 Feb 2004 04:23:35 UT Received: by mail.daronmont.com.au with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 14:53:34 +1030 Message-ID: <8179ED123ECCD611A5490000F822E6EA3825E4@mail.daronmont.com.au> From: Simon Gerblich To: vc Cc: pthreads-win32@sources.redhat.com Subject: RE: problem using pthread_cancel and pthread_mutex_lock Date: Tue, 24 Feb 2004 04:23:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2004/txt/msg00013.txt.bz2 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. Cheers, Simon