From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29627 invoked by alias); 24 Jan 2005 14:22:24 -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 29576 invoked from network); 24 Jan 2005 14:22:18 -0000 Received: from unknown (HELO quokka.dot.net.au) (202.147.68.16) by sourceware.org with SMTP; 24 Jan 2005 14:22:18 -0000 Received: from [202.147.83.86] (helo=ip-83-86.dot.net.au) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1Ct56e-0006ye-00 for ; Tue, 25 Jan 2005 01:22:17 +1100 Subject: Re: issue with recursive mutex From: Ross Johnson To: pthreads-win32@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Date: Mon, 24 Jan 2005 14:22:00 -0000 Message-Id: <1106576535.22573.58.camel@desk.home> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005/txt/msg00008.txt.bz2 On Fri, 2005-01-21 at 10:06 -0500, Kubis, Ralf wrote: > Hello, > > I apologize if that issue came already up in this list but I can't see > it in the archive. > Got snapshot 2005-01-03 and ran into a deadlock with recursive mutexes. > Hi Ralf, Snapshots since 2004-11-03 have been trying a new mutex implementation. So the issue is new, and the error is in the way that I've adapted Alexander Terekhov's new implementation for 'normal' mutexes (see links below) to the pre-existing code for recursive mutexes. Re where does the [current] implementation come from - please see the following list messages: http://sources.redhat.com/ml/pthreads-win32/2003/msg00108.html http://sources.redhat.com/ml/pthreads-win32/2004/msg00119.html Although it's a little out of date w.r.t. the current implementation, there's more information on the reasons behind using a new implementation here: http://sources.redhat.com/ml/pthreads-win32/2004/msg00118.html Thanks for isolating the problem and providing the patch. I'll modify it a little so it won't result in additional unnecessary events. I should be able to get a new snapshot out tuesday including this and other recently reported problems fixed. Thanks, and apologies for the inconvenience. Ross > Looking at the code in pthread_mutex_lock.c and pthread_mutex_unlock.c I > see the following problem. > > > mutex m; > > > Thread 0 > -------- > m.lock() > > Thread 1 > -------- > m.lock() <- is waiting now > > Thread 0 > -------- > m.lock() <- refcount is now 2 and mx->lock_idx is now 1 !!!! > > Thread 0 > -------- > > m.unlock() <- refcount is now 1 > m.unlock() <- refcount is now 0 and mx->lock_idx is now 0. > no event was send because mx->lock_idx was not less than 0 > > > Thread 1 > -------- > still locked :( > > > After a small modification in pthread_mutex_lock.c, listed below, the > mutex behaved like expected but > indeed this has the cost of sending unnecessary events. > Where does your implementation come from ? >