Date: Thu, 7 Jan 1999 02:21:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: Don.Lewis@tsc.tdk.com (Don Lewis) 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: <199901070221.TAA08125@usr09.primenet.com> In-Reply-To: <199901062300.PAA01961@salsa.gv.tsc.tdk.com> from "Don Lewis" at Jan 6, 99 03:00:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> } > 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. > > What do you do when you want to do different operations on the object > while the lock is held? If you want to treat this as a critical > section, then you have to use a parameter that tells the code what > operation to do between the lock and unlock. You are locking code entrancy based on exactly that: the operation you intend to do is represented by the code you are about to run. The code that you are about to run doesn't necessarily touch all parts of the object, nor does it necessarily apply to only one object or one list of objects of which the object you intend to operate upon is a member. The "paramenter" you use to distinguish this is the identity of the lock you are holding. That lock applies to the set of operations that you intend to perform on the set of objects you intend to perform the operations upon. > } 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. > > ... and pass it a parameter. > > frob_object(obj, MODIFY, ...); > > frob_object(obj, DELETE, ...); > > ... > > You could even use <stdargs.h> ;-) You could do it this way, if you needed to marshal the data across interfaces. This is, in fact, exactly the reason that John Heideimann gave for using operation argument descriptors instead of simple parameter lists. You can know the size and byte order of a descriptor before you marshall it to another machine for use of remotely located VFS stacking layers (this is one of the examples in his thesis: how to make an NFS replacement that can operate correctly in the face of extensions to semantings that the NFS client or server layers can't know about because they were compiled before the extensions were invented; extensions like this are also the reason that a default VNOPS vector is a bad idea). > } This also lets me document my lock state in and out, and ASSERT() > } the lock state in an out in the DIAGNOSTIC case. > > How do you know that someone else hasn't grabbed the lock between > the time you unlock and when your ASSERT() gets executed? Because you are asserting that *you* have the lock or that *you* don't have the lock. If someone else has the lock, then *you* don't. 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?199901070221.TAA08125>