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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
