From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 13:12:10 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 0458C16A4CF for ; Sat, 6 Dec 2003 13:12:10 -0800 (PST) Received: from owl.melbpc.org.au (owl.melbpc.org.au [203.12.152.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A1DC43FEA for ; Sat, 6 Dec 2003 13:12:06 -0800 (PST) (envelope-from kpeter@melbpc.org.au) Received: from 127.0.0.1 (localhost.melbpc.org.au [127.0.0.1]) by av.domain.name (Postfix) with SMTP id 9A83D535D for ; Sun, 7 Dec 2003 08:12:04 +1100 (EST) Received: by owl.melbpc.org.au (Postfix, from userid 1005) id 91CC65337; Sun, 7 Dec 2003 08:12:04 +1100 (EST) Received: from melbpc.org.au (dsl-47.42.221.203.lns02-dryb-mel.dsl.comindico.com.au [203.221.42.47]) by owl.melbpc.org.au (Postfix) with ESMTP id DD85F5392 for ; Sun, 7 Dec 2003 08:11:31 +1100 (EST) Message-ID: <3FD245FF.3040003@melbpc.org.au> Date: Sun, 07 Dec 2003 08:11:27 +1100 From: Peter Kostouros Organization: Melbourne PC User Group User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: threads@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-15.4 required=8.0 tests=AWL,BAYES_00,SIGNATURE_SHORT_SPARSE,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kpeter@melbpc.org.au List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2003 21:12:10 -0000 Hi 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. 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? Note, I am running FreeBSD 5.2-BETA i386 with SCHED_ULE. -- Regards Peter As always the organisation disavows knowledge of this email