From owner-freebsd-smp Sun Jan 5 05:48:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA00173 for smp-outgoing; Sun, 5 Jan 1997 05:48:58 -0800 (PST) Received: from hda.hda.com (ip32-max1-fitch.ziplink.net [199.232.245.32]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA00163; Sun, 5 Jan 1997 05:48:53 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id IAA28862; Sun, 5 Jan 1997 08:44:55 -0500 From: Peter Dufault Message-Id: <199701051344.IAA28862@hda.hda.com> Subject: Re: atomic locking and In-Reply-To: <12453.852121399@critter.dk.tfs.com> from Poul-Henning Kamp at "Jan 1, 97 01:23:19 pm" To: phk@freebsd.org Date: Sun, 5 Jan 1997 08:44:54 -0500 (EST) Cc: smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Would it make sense to make a version of the various queues that had > built in locking ? Yes, but I think you should also package them up as functions with opaque structures. In addition to locking there is the issue of illegal access even with locking - consider naively traversing a circular queue and having the node you started with vanish off the queue even if each individual step is "properly" locked. Strict access to the queue structures will force a visit to each place they are used when moving over to the new interface. I also bet that these will grow more complicated anyway with items like object IDs for lock hierarchy and locker priority for priority boosting. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936