From owner-freebsd-hackers Tue Jan 5 16:14:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA09441 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:14:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09432 for ; Tue, 5 Jan 1999 16:14:01 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA18927; Tue, 5 Jan 1999 17:13:21 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA11201; Tue, 5 Jan 1999 17:13:20 -0700 Date: Tue, 5 Jan 1999 17:13:20 -0700 Message-Id: <199901060013.RAA11201@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. In-Reply-To: <199901060008.RAA20555@usr05.primenet.com> References: <199901052242.PAA10308@mt.sri.com> <199901060008.RAA20555@usr05.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >A 'critical section of code' is a portion of the code that is accessing > > > >a shared resource, which can be protected by using an object lock. > > > > > > Erm, make that "...accessing *one or more* shared resources.", which is why > > > it isn't the same thing as an object lock (except in the degenerate case). > > > > Sure it is. The object lock is used to 'protect' the shared resources. > > This is multithreading/tasking 101 stuff, not rocket science. > > > OK. > > Think about it like this. > > I have an object that's on two lists at the same time: > > struct some_object { > struct some_object *list_1_next; > struct some_object *list_1_prev; > struct some_object *list_2_next; > struct some_object *list_2_prev; > ... > } > > This happens all the time with all sorts of kernel structures. > > > If I have a lock associated with the object, I have two functions: > > LRU_object_on_list_1( struct some_object *objp) > { > LOCK(objp); > move_to_head( &objp->list_1_next, list_1_head); > UNLOCK(objp); > } > > LRU_object_on_list_2( struct some_object *objp) > { > LOCK(objp); > move_to_head( &objp->list_2_next, list_2_head); > UNLOCK(objp); > } > > 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. > 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? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message