Date: Wed, 17 Nov 2010 09:52:46 +0000 From: David Xu <davidxu@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r215170 - in user/davidxu/libthr/sys: kern sys Message-ID: <4CE3A5EE.9060803@freebsd.org> In-Reply-To: <20101116222621.GA44741@stack.nl> References: <201011120934.oAC9YLN1002510@svn.freebsd.org> <20101116222621.GA44741@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Jilles Tjoelker wrote: > 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. per-thread limit is uncertain. I don't know if I should let pthread_mutex_lock fail, because I saw so much code do not check error code, unlike java, C programmer tends to ignore error code, while java can throw exception in abnormal case, force you to handle it. I even want to change default mutex from error-check to normal. > >> [...] >> + 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. > Good catch. > 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. > Yes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE3A5EE.9060803>