From owner-freebsd-hackers  Wed Jan  6 15:02:07 1999
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA18960
          for freebsd-hackers-outgoing; Wed, 6 Jan 1999 15:02:07 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18954
          for <hackers@FreeBSD.ORG>; Wed, 6 Jan 1999 15:02:06 -0800 (PST)
          (envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id PAA24895;
	Wed, 6 Jan 1999 15:01:03 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id PAA19484;
	Wed, 6 Jan 1999 15:01:01 -0800 (PST)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id PAA01961;
	Wed, 6 Jan 1999 15:00:59 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199901062300.PAA01961@salsa.gv.tsc.tdk.com>
Date: Wed, 6 Jan 1999 15:00:59 -0800
In-Reply-To: Terry Lambert <tlambert@primenet.com>
       "Re: question about re-entrancy." (Jan  6,  1:19am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Terry Lambert <tlambert@primenet.com>, nate@mt.sri.com (Nate Williams)
Subject: Re: question about re-entrancy.
Cc: rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com,
        bright@hotjobs.com, hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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