From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23695 invoked by alias); 26 Feb 2004 15:59:43 -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 23677 invoked from network); 26 Feb 2004 15:59:40 -0000 Received: from unknown (HELO hotmail.com) (65.54.246.97) by sources.redhat.com with SMTP; 26 Feb 2004 15:59:40 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Feb 2004 07:59:37 -0800 Received: from 62.245.182.10 by bay2-dav40.bay2.hotmail.com with DAV; Thu, 26 Feb 2004 15:59:36 +0000 X-Originating-IP: [62.245.182.10] X-Originating-Email: [vcotirlea1@hotmail.com] X-Sender: vcotirlea1@hotmail.com From: "vc" To: "Simon Gerblich" Cc: References: <8179ED123ECCD611A5490000F822E6EA3825E4@mail.daronmont.com.au> Subject: Re: problem using pthread_cancel and pthread_mutex_lock Date: Thu, 26 Feb 2004 15:59:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 26 Feb 2004 15:59:37.0169 (UTC) FILETIME=[88BEC410:01C3FC81] X-SW-Source: 2004/txt/msg00018.txt.bz2 Thanks to all of you for your answers. Viv ----- Original Message ----- From: "Simon Gerblich" To: "vc" Cc: Sent: Tuesday, February 24, 2004 5:23 AM Subject: RE: problem using pthread_cancel and pthread_mutex_lock > 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 > >