libpthread patch

[David Xu]

----- 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.

> -- 
> Dan Eischen
> 
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"