Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Mar 2012 23:41:53 +0800
From:      David Xu <listlog2011@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David Xu <davidxu@freebsd.org>
Subject:   Re: svn commit: r233103 - head/lib/libthr/thread
Message-ID:  <4F6753C1.4060800@gmail.com>
In-Reply-To: <201203190833.08153.jhb@freebsd.org>
References:  <201203180022.q2I0MThr093557@svn.freebsd.org> <201203190833.08153.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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);

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


> Also, being able to safely inline the common case for pthread locks is a very
> useful optimization and one we should pursue IMO.
>
Yes.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F6753C1.4060800>