Date: Fri, 18 Apr 2003 14:26:55 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <005b01c30573$821cf6a0$f001a8c0@davidw2k> References: <Pine.GSO.4.10.10304180208140.2703-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20 From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> To: "David Xu" <davidxu@freebsd.org> Cc: <freebsd-threads@freebsd.org> Sent: Friday, April 18, 2003 2:12 PM Subject: Re: libpthread patch > On Fri, 18 Apr 2003, David Xu wrote: >=20 > >=20 > > ----- Original Message -----=20 > > From: "Juli Mallett" <jmallett@FreeBSD.org> > > To: "David Xu" <davidxu@freebsd.org> > > Cc: "Daniel Eischen" <eischen@pcnet1.pcnet.com>; = <freebsd-threads@freebsd.org> > > Sent: Friday, April 18, 2003 2:04 PM > > Subject: Re: libpthread patch > >=20 > >=20 > > > * De: David Xu <davidxu@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. > > > > >=20 > > > > 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. > > >=20 > > > 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? > >=20 > > I want to use code to detect LOR not just human eyes, I can accept > > any reasonable method. >=20 > 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. >=20 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. > --=20 > Dan Eischen >=20 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to = "freebsd-threads-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005b01c30573$821cf6a0$f001a8c0>