svn commit: r233103 - head/lib/libthr/thread
John Baldwin
jhb at freebsd.org
Tue Mar 20 19:04:00 UTC 2012
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
More information about the svn-src-all
mailing list