Date: Wed, 6 Jan 1999 01:19:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, nate@mt.sri.com, rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901060119.SAA23425@usr05.primenet.com> In-Reply-To: <199901060013.RAA11201@mt.sri.com> from "Nate Williams" at Jan 5, 99 05:13:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Notice that I can't enter both at the same time without blocking > > because I'm locking the object instead of the code. > > That's one way of doing it, yes. If the *only* place where both lists > was being modified was a single piece of code, then you don't need to > lock-down both lists separately, hence you could use a single lock. > > If you there are multiple places where the list could be locked down, > you have no choice in the matter. You *must* use object locks, (or > something similar to them), else you end up with the 'Big Giant Lock' > problem. I think it's a lesser problem than that, but that's just a matter of scale, not of kind, so yeah, given a specific way of looking at it, you're right. I think that having multiple places that need to lock is Bad(tm). I think that, architecturally, you need to constrain the conflict zones to avoid the problem. One way of doing this would be to use an inline accessor function and not change the code layout, but that's the same thing in all but name. If I lock code in a constrained path, and I further avoid any constrained paths as mush as I can, I think that code locks end up causing less contention. You would need to to instance "lockables" into a hierarchical relationship so that you could do very fast deadlock detection, but most of the time other CPU's would not be in the same place at the same time, so acquisition would be ~4 clocks for the common case. Consider the case where you are doing advisory locking. You could lock the object before passing it down to the common lock manager code, but this would prevent other contexts from entering the object in the FS during the whole time you are doing the lock, even if they are doing something unrelated to advisory locking. This is an artificial collision. I guess you could call the nodes in the hierarchy relationship "objects", and the locks on the lockables "object locks" if you wanted to. > > Yes, this is a gross oversimplification: I could deal with this > > with list locks or two locks associated with the object, or whatever. > > But to obtain the list lock, I'd need to lock the object anyway > > before it was safe to dereference the pointer and acquire the lock > > on the list object (assuming that you had to lock the list object > > to remove references to it). > > Right, and how do you propose to do this w/out object locks? By locking entry to the code that does the manipulation instead. I guess a function could be considered an object too... 8-). This also lets me document my lock state in and out, and ASSERT() the lock state in an out in the DIAGNOSTIC case. That's very close to the code coverage you would get from a full branch path analysis, with the side benefit that the function gets a bit of protection against obvious coding errors by making them obvious in context without a code reviewer having to get his or her head around the whole thing. A bit of an improvement in process over what you have to do when trying to go through some of the existing code, you have to admit... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901060119.SAA23425>