libpthread patch

[Daniel Eischen]

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.

-- 
Dan Eischen