From owner-freebsd-threads@FreeBSD.ORG Thu Apr 17 23:12:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9965737B401; Thu, 17 Apr 2003 23:12:25 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F34843F75; Thu, 17 Apr 2003 23:12:24 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3I6CNBg003282; Fri, 18 Apr 2003 02:12:23 -0400 (EDT) Received: from localhost (eischen@localhost)h3I6CNod003279; Fri, 18 Apr 2003 02:12:23 -0400 (EDT) Date: Fri, 18 Apr 2003 02:12:23 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <003d01c30571$0edb1cf0$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 06:12:25 -0000 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. -- Dan Eischen