svn commit: r233103 - head/lib/libthr/thread

[David Xu]

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