From owner-freebsd-threads@FreeBSD.ORG Thu Jan 29 06:06:46 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B787E16A4CE for ; Thu, 29 Jan 2004 06:06:46 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 036BE43D1F for ; Thu, 29 Jan 2004 06:06:45 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i0TE6giw003866; Thu, 29 Jan 2004 09:06:42 -0500 (EST) Date: Thu, 29 Jan 2004 09:06:42 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Mike Makonnen In-Reply-To: <20040129082122.GA1439@mobile.acsolutions.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org cc: Peter Kostouros Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 14:06:46 -0000 On Thu, 29 Jan 2004, Mike Makonnen wrote: > On Wed, Jan 28, 2004 at 12:01:27PM -0500, Daniel Eischen wrote: > > On Wed, 28 Jan 2004, Mike Makonnen wrote: > > > > > On Sun, Dec 07, 2003 at 01:34:31AM -0500, Daniel Eischen wrote: > > > > > > > > The man page may not mention it, and that may be a bug, but I > > > > think a pthread_mutex_trylock() on a non-recursive mutex is allowed > > > > to return EDEADLK. > > > > > > > > http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html > > > > > > > > If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error > > > > checking shall be provided. If a thread attempts to relock a > > > > mutex that it has already locked, an error shall be returned. > > > > If a thread attempts to unlock a mutex that it has not locked > > > > or a mutex which is unlocked, an error shall be returned. > > > > > > > > ... > > > > > > If you look further down in the spec you will see: > > > > > > The pthread_mutex_trylock() function shall be equivalent to > > > pthread_mutex_lock(), except that if the mutex object referenced > > > by mutex is currently locked (by any thread, including > > > the current thread), the call shall return immediately... > > > > Yes, but the implementation has to use internal locks to > > keep the mutex in a consistent state. There is no problem > > here. > > Apologies, I was commenting on the EDEADLK vs. EBUSY issue, not the "is an > internal lock allowed to block in pthread_mutex_trylock" issue. I should > have also explained better instead of just throwing out the quote. > > EDEADLK is returned by pthread_mutex_lock() only on error > checking mutexes that would otherwise deadlock if they were not error > checking. Since pthread_mutex_trylock() must return immediately whether > the mutex is error-checking or not, I think for consistency sake it should > return EBUSY regardless of what type of mutex it is operating on. Also, > the 'ERRORS' section lists EDEADLK as a _possible_ return value only for > pthread_mutex_lock(). I looked at "pthread_mutex_trylock() function shall be equivalent to pthread_mutex_lock()" and inferred that it even meant returned errors should be equivalent. > I'm not a standards expert but I think it is permissable for an > implementation to return EDEADLK from pthread_mutex_trylock(). However, > I think it's better to always return EBUSY, rather than EDEADLK in > some cases and EBUSY in others. Well, anything that relies on pthread_mutex_trylock() != EBUSY to mean that the function worked is broken (clearly 0 is the only return that means success). And if the application wants to know if the current thread has the mutex locked, then returning EBUSY doesn't tell you anything, whereas EDEADLK does. Yeah, I know, applications should keep track of which mutexes they have locked! -- Dan Eischen