From owner-svn-src-head@FreeBSD.ORG Tue Mar 20 19:04:00 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 E885B1065677; Tue, 20 Mar 2012 19:03:59 +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 A24688FC12; Tue, 20 Mar 2012 19:03:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 584D646B17; Tue, 20 Mar 2012 15:03:59 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C06A0B96C; Tue, 20 Mar 2012 15:03:58 -0400 (EDT) From: John Baldwin To: davidxu@freebsd.org Date: Tue, 20 Mar 2012 14:13:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203180022.q2I0MThr093557@svn.freebsd.org> <201203191350.51888.jhb@freebsd.org> <4F67C707.8080006@gmail.com> In-Reply-To: <4F67C707.8080006@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201203201413.30668.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Mar 2012 15:03:58 -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: Tue, 20 Mar 2012 19:04:00 -0000 On Monday, March 19, 2012 7:53:43 pm David Xu wrote: > On 2012/3/20 1:50, John Baldwin wrote: > > 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(). > This is implementation detail,thread1 does unlocking in two steps: > first it clears lock bit, but leaves contention bit there, > then thread2 enters and sets lock bit, and then destroy it. > T1: > clear lock bit, contention bit is still set. > T2: > lock the mutex by setting lock bit. > do some work. > unlock the mutex by clearing lock it, > enters kernel, and see no waiters, clears contention bit. > destroy the mutex, unmap memory > T1: > enter kernel to clear contention bit, because the memory > is unmmaped, it returns EINVAL. Ah, ok. So we should still be able to do an uncontested unlock in userland directly. -- John Baldwin