Date: Tue, 20 Mar 2012 14:13:30 -0400 From: John Baldwin <jhb@freebsd.org> To: davidxu@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233103 - head/lib/libthr/thread Message-ID: <201203201413.30668.jhb@freebsd.org> In-Reply-To: <4F67C707.8080006@gmail.com> References: <201203180022.q2I0MThr093557@svn.freebsd.org> <201203191350.51888.jhb@freebsd.org> <4F67C707.8080006@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203201413.30668.jhb>