From owner-freebsd-smp Wed Jan 1 04:21:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA25573 for smp-outgoing; Wed, 1 Jan 1997 04:21:10 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id EAA25568 for ; Wed, 1 Jan 1997 04:21:08 -0800 (PST) Received: from schizo.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vfPeu-0003whC; Wed, 1 Jan 97 04:20 PST Received: from critter.dk.tfs.com (critter-home [193.162.32.19]) by schizo.dk.tfs.com (8.8.2/8.7.3) with ESMTP id NAA24977 for ; Wed, 1 Jan 1997 13:20:33 +0100 (MET) Received: from critter.dk.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id NAA12455 for ; Wed, 1 Jan 1997 13:23:20 +0100 (MET) To: smp@freebsd.org Subject: atomic locking and Reply-to: phk@freebsd.org Date: Wed, 01 Jan 1997 13:23:19 +0100 Message-ID: <12453.852121399@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My intuition tells me that we could avoid a great deal of cluttering "lock(); foo; unlock();" in our sources if (some of) the macros in were made to be atomic. Would it make sense to make a version of the various queues that had built in locking ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.