From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 22:34:34 2003 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 4159616A4CE for ; Sat, 6 Dec 2003 22:34:34 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 231CF43F75 for ; Sat, 6 Dec 2003 22:34:33 -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 hB76YVml028230; Sun, 7 Dec 2003 01:34:32 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Peter Kostouros In-Reply-To: <3FD245FF.3040003@melbpc.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org 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: , Date: Sun, 07 Dec 2003 06:34:34 -0000 X-Original-Date: Sun, 7 Dec 2003 01:34:31 -0500 (EST) X-List-Received-Date: Sun, 07 Dec 2003 06:34:34 -0000 On Sun, 7 Dec 2003, Peter Kostouros wrote: > I have been tracking mozilla (cvs) that terminates when linked against > libkse: basically a routine checks whether a mutex variable is locked > with a call to pthread_mutex_trylock() before it attempts to unlock it > with pthread_mutex_unlock(). The return value of pthread_mutex_trylock > is checked against EBUSY and terminates the process if it is otherwise. > In my particular scenario, pthread_mutex_trylock() returns EDEADLK: the > pthread_mutex_trylock man page does not mention EDEADLK as an error code. 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 the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively lock the mutex results in undefined behavior. Attempting to unlock the mutex if it was not locked by the calling thread results in undefined behavior. Attempting to unlock the mutex if it is not locked results in undefined behavior. 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. If the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex is currently owned by the calling thread, the mutex lock count shall be incremented by one and the pthread_mutex_trylock() function shall immediately return success. > When the application is linked against libc_r or libthr, > pthread_mutex_trylock returns EBUSY in the scenario described above. > > I suppose my question is how do you safely (and quickly) check the state > of a mutex variable? I think you (the application) are supposed to remember whether a thread has or has not locked a mutex. By default, mutexes under FreeBSD are error checking mutexes and will return EDEADLK when a thread attempts pthread_mutex_trylock() on a mutex it already owns. -- Dan Eischen