From owner-freebsd-threads@FreeBSD.ORG Fri Apr 18 00:23:29 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 4772A37B401; Fri, 18 Apr 2003 00:23:29 -0700 (PDT) Date: Fri, 18 Apr 2003 02:23:29 -0500 From: Juli Mallett To: Daniel Eischen Message-ID: <20030418022329.A11963@FreeBSD.org> References: <005b01c30573$821cf6a0$f001a8c0@davidw2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from eischen@pcnet1.pcnet.com on Fri, Apr 18, 2003 at 02:28:32AM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-Negacore: Yes X-Title: Code Maven X-Authentication-Warning: localhost: juli pwned teh intarweb cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 07:23:29 -0000 * De: Daniel Eischen [ Data: 2003-04-18 ] [ Subjecte: Re: libpthread patch ] > On Fri, 18 Apr 2003, David Xu wrote: > > > > > ----- Original Message ----- > > From: "Daniel Eischen" > > To: "David Xu" > > Cc: > > Sent: Friday, April 18, 2003 2:12 PM > > Subject: Re: libpthread patch > > > > > > > On Fri, 18 Apr 2003, David Xu wrote: > > > > > > > > > > > ----- Original Message ----- > > > > From: "Juli Mallett" > > > > To: "David Xu" > > > > Cc: "Daniel Eischen" ; > > > > Sent: Friday, April 18, 2003 2:04 PM > > > > Subject: Re: libpthread patch > > > > > > > > > > > > > * De: David Xu [ Data: 2003-04-18 ] > > > > > [ Subjecte: Re: libpthread patch ] > > > > > > > There are a few issues we've got to go over, as well as > > > > > > > looking closely at any locking order problems. > > > > > > > > > > > > > I have ever tried to port some kernel code to userland (e.g > > > > > > mutex and witness), but now they were left there for > > > > > > several days without be touched. > > > > > > > > > > This seems like overkill, in fact, it is by definition. If you > > > > > want some primitive private-locks-only mutex tracing/auditing, > > > > > I've done a bit of that and could give you some hints. Using the > > > > > casuptr facility introduced by thr may be a good idea, no? It > > > > > is known to work, and is relatively un-complex? Or am I missing > > > > > something? > > > > > > > > I want to use code to detect LOR not just human eyes, I can accept > > > > any reasonable method. > > > > > > We can do that now with the locks that I have in place. > > > Each consumer of a lock has a "lock user". Threads and > > > KSEs have an array of 3 lock users; probably 2 is enough > > > because I don't think we need more than a nesting of 2. > > > When you decrement the lock user index when releasing > > > a lock, you make sure that the lock being released > > > matches the one owned. In fact, I implemented it this > > > way so you couldn't possible have lock order reversals. > > > The locks will not work if you reverse them. > > > > > > > witeness in kernel records locking order, not lock instance. > > for example, at one time, code uses locking order > > mutex1 mutex2, and release them, next time if another > > code locks them in the order mutex2 mutex1, it would detect > > it. > > Ahh, OK. There aren't that many locks used by the library. > We can probably come up with something that does what you > want. TAILQ makes this exceedingly trivial. -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli;