Date: Fri, 18 Apr 2003 00:51:37 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <3E9FAE89.4D656F38@mindspring.com> References: <Pine.GSO.4.10.10304180208140.2703-100000@pcnet1.pcnet.com> <005b01c30573$821cf6a0$f001a8c0@davidw2k>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> > > 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. You are allowed to recurse on a mutex in the kernel, because there's some depth to code paths that shouldn't be there, but it's easier to allow recursion than it is to correct the code. Because of this, Witness is able to catch mutex2 mutex1, but it won't catch mutex1 mutex2 mutex1, which is technically a reversal, for all intents and purposes, if the code happens to unlock the first mutex1 first (this will be seen as an unlock of the second mutex1, and so won't trigger any alarm). Daniel's stuff works fine (better than witness!), if you disallow recursion. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9FAE89.4D656F38>