From owner-svn-src-head@FreeBSD.ORG Mon Mar 19 15:55:48 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 9578B106566B; Mon, 19 Mar 2012 15:55:48 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64AB28FC1E; Mon, 19 Mar 2012 15:55:48 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JFtkYZ005965; Mon, 19 Mar 2012 15:55:46 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F675701.1020807@gmail.com> Date: Mon, 19 Mar 2012 23:55:45 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: davidxu@freebsd.org References: <201203180022.q2I0MThr093557@svn.freebsd.org> <201203190833.08153.jhb@freebsd.org> <4F6753C1.4060800@gmail.com> In-Reply-To: <4F6753C1.4060800@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin Subject: Re: svn commit: r233103 - head/lib/libthr/thread X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org 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:55:48 -0000 On 2012/3/19 23:41, David Xu wrote: > On 2012/3/19 20:33, John Baldwin wrote: >> 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. > > They have handshake code to indicate that the mutex is no longer used > by previous > holder. e.g: > > thread 1: > pthread_mutex_lock(&mutex); > done = 1; > pthread_mutex_unlock(&mutex); > thread 2: > pthread_mutex_lock(&mutex); > temp = done; > pthread_mutex_unlock(&mutex); > if (temp == 1) > pthread_mutex_destroy(&mutex); > > I guess one crash of Python is also caused by the logic, though they > use semaphore > instead of mutex + condition variable to mimic lock. > POSIX even explicitly requires a condition variable to be destroyable > after broadcast, > once you have correct teardown code. Please read its example section: > http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_cond_destroy.html > > > >> Also, being able to safely inline the common case for pthread locks >> is a very >> useful optimization and one we should pursue IMO. >> > Yes. Following topics are interesting: http://sourceware.org/bugzilla/show_bug.cgi?id=12674 http://sourceware.org/bugzilla/show_bug.cgi?id=13690 http://sourceware.org/bugzilla/show_bug.cgi?id=13065 http://sourceware.org/bugzilla/show_bug.cgi?id=12683 http://sourceware.org/bugzilla/show_bug.cgi?id=13165 http://sourceware.org/bugzilla/show_bug.cgi?id=13165