libpthread patch

[Daniel Eischen]

On Fri, 18 Apr 2003, David Xu wrote:

> 
> ----- Original Message ----- 
> From: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
> To: "David Xu" <davidxu at freebsd.org>
> Cc: <freebsd-threads at freebsd.org>
> 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" <jmallett at FreeBSD.org>
> > > To: "David Xu" <davidxu at freebsd.org>
> > > Cc: "Daniel Eischen" <eischen at pcnet1.pcnet.com>; <freebsd-threads at freebsd.org>
> > > Sent: Friday, April 18, 2003 2:04 PM
> > > Subject: Re: libpthread patch
> > > 
> > > 
> > > > * De: David Xu <davidxu at freebsd.org> [ 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.

-- 
Dan Eischen