Date: Tue, 16 Nov 2010 23:26:21 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: David Xu <davidxu@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r215170 - in user/davidxu/libthr/sys: kern sys Message-ID: <20101116222621.GA44741@stack.nl> In-Reply-To: <201011120934.oAC9YLN1002510@svn.freebsd.org> References: <201011120934.oAC9YLN1002510@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 12, 2010 at 09:34:21AM +0000, David Xu wrote: > Author: davidxu > Date: Fri Nov 12 09:34:21 2010 > New Revision: 215170 > URL: http://svn.freebsd.org/changeset/base/215170 > Log: > Limit total number of robust mutexes a process can hold. I think a per thread limit is better as it is more predictable. If the limit is exceeded, pthread_mutex_lock() will fail. > [...] > + error = msleep(&max_robust_per_proc, > + &max_robust_lock, 0, "maxrob", 0); I think a PCATCH flag was intended here. If you want to do it this way, it needs to wake up if another thread in the process unlocks something. If one thread uses up max_robust_per_proc, it is stuck forever. It is also possible though rare that this wait forms a cycle with lock waits. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101116222621.GA44741>