svn commit: r233103 - head/lib/libthr/thread
David Xu
listlog2011 at gmail.com
Mon Mar 19 15:55:48 UTC 2012
On 2012/3/19 23:41, 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);
>
> 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.
Following topics are interesting:
http://sourceware.org/bugzilla/show_bug.cgi?id=12674
http://sourceware.org/bugzilla/show_bug.cgi?id=13690
http://sourceware.org/bugzilla/show_bug.cgi?id=13065
http://sourceware.org/bugzilla/show_bug.cgi?id=12683
http://sourceware.org/bugzilla/show_bug.cgi?id=13165
http://sourceware.org/bugzilla/show_bug.cgi?id=13165
More information about the svn-src-all
mailing list