Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 1399 invoked by uid 500); 19 Jun 2001 16:07:52 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 1347 invoked from network); 19 Jun 2001 16:07:46 -0000 Message-ID: <004101c0f8d9$e8bbfe40$7f00a8c0@VAIO> From: "David Reid" To: "APR Development List" References: Subject: Re: nested mutexes Date: Tue, 19 Jun 2001 17:06:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N If we already own a lock we should be able to lock it again shouldn't we? Part of the problem was my initial assumption that if we didn't have threads we didn't have locks, but of course we do :) Jeff's suggestion of using the pid was a good one I think to get us around this problem. Are you adding that Jeff or did you want me to? david > On 19 Jun 2001, Jeff Trawick wrote: > > | no, by "nested mutex" I mean that this is allowed > | > | Thread A holds mutex 1 > | Thread A obtains mutex 1 again > | > | what I call "nested mutex acquire" is sometimes called "recursive > | mutex acquire" > > Wouldnt an attempt to aquire a mutex that is already owned (by the > calling thread or another thread) fail with EDEADLK, so anything obtaining > something more than once is not possible without error? > > Perhaps something like a "mutex keychain" would be good to help a thread > keep track of mutexes it currently owns/are globaly owned so that attempts > to aquire owned ones would be thwarted?