From owner-svn-src-head@FreeBSD.ORG Mon Mar 19 15:25:44 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32ECC106564A; Mon, 19 Mar 2012 15:25:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 06E408FC14; Mon, 19 Mar 2012 15:25:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id B592F46B39; Mon, 19 Mar 2012 11:25:43 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 028EDB960; Mon, 19 Mar 2012 11:25:43 -0400 (EDT) From: John Baldwin To: David Xu Date: Mon, 19 Mar 2012 08:33:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203180022.q2I0MThr093557@svn.freebsd.org> In-Reply-To: <201203180022.q2I0MThr093557@svn.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201203190833.08153.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 19 Mar 2012 11:25:43 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233103 - head/lib/libthr/thread X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:25:44 -0000 On Saturday, March 17, 2012 8:22:29 pm David Xu wrote: > Author: davidxu > Date: Sun Mar 18 00:22:29 2012 > New Revision: 233103 > URL: http://svn.freebsd.org/changeset/base/233103 > > Log: > Some software think a mutex can be destroyed after it owned it, for > example, it uses a serialization point like following: > pthread_mutex_lock(&mutex); > pthread_mutex_unlock(&mutex); > pthread_mutex_destroy(&muetx); > They think a previous lock holder should have already left the mutex and > is no longer referencing it, so they destroy it. To be maximum compatible > with such code, we use IA64 version to unlock the mutex in kernel, remove > the two steps unlocking code. But this means they destroy the lock while another thread holds it? That seems wrong. It's one thing if they know that no other thread has a reference to the lock (e.g. it's in a refcounted object and the current thread just dropped the reference count to zero). However, in that case no other thread can unlock it after this thread destroys it. Code that does this seems very buggy, since if the address can be unmapped it can also be remapped and assigned to another lock, etc., so you could have a thread try to unlock a lock it doesn't hold. Also, being able to safely inline the common case for pthread locks is a very useful optimization and one we should pursue IMO. -- John Baldwin