Date: Wed, 6 Jan 1999 15:00:59 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Terry Lambert <tlambert@primenet.com>, nate@mt.sri.com (Nate Williams) Cc: 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: <199901062300.PAA01961@salsa.gv.tsc.tdk.com> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: question about re-entrancy." (Jan 6, 1:19am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 6, 1:19am, Terry Lambert wrote: } Subject: Re: question about re-entrancy. } > 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. } 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> ;-) } > 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. How do you know that someone else hasn't grabbed the lock between the time you unlock and when your ASSERT() gets executed? 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?199901062300.PAA01961>