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>