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