From owner-svn-src-head@FreeBSD.ORG Mon Mar 19 20:41:48 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC661065673; Mon, 19 Mar 2012 20:41:47 +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 C0AD18FC12; Mon, 19 Mar 2012 20:41:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6354846B3B; Mon, 19 Mar 2012 16:41:46 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E790EB960; Mon, 19 Mar 2012 16:41:45 -0400 (EDT) From: John Baldwin To: davidxu@freebsd.org Date: Mon, 19 Mar 2012 13:50:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203180022.q2I0MThr093557@svn.freebsd.org> <201203190833.08153.jhb@freebsd.org> <4F6753C1.4060800@gmail.com> In-Reply-To: <4F6753C1.4060800@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201203191350.51888.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 19 Mar 2012 16:41:46 -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 20:41:48 -0000 On Monday, March 19, 2012 11:41:53 am 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); Hmm, so how does this result in the crash you fixed? That is, thread 1 has to fully finish pthread_mutex_unlock() before thread2's pthread_mutex_lock() can succeed, so I don't see how thread 1 could still be in pthread_mutex_unlock() when thread 2 calls pthread_mutex_destroy(). > 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 This is quite different as assuming a broadcast marks all the threads as runnable and removes them from the cv's queue, none of the threads will have references to the cv so it will be safe to destroy. It would not be safe to destroy the mutex in that case though (and the example does not destroy the mutex, only the cv). -- John Baldwin