From owner-freebsd-smp Tue Dec 5 14: 2:59 2000 From owner-freebsd-smp@FreeBSD.ORG Tue Dec 5 14:02:57 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id AE93737B400 for ; Tue, 5 Dec 2000 14:02:56 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.11.1/8.9.3) with ESMTP id eB5M2mm04439; Tue, 5 Dec 2000 15:02:48 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200012052202.eB5M2mm04439@berserker.bsdi.com> To: Jason Evans Cc: Julian Elischer , smp@FreeBSD.ORG Subject: Re: Mutex types. In-reply-to: Your message of "Tue, 05 Dec 2000 13:07:55 PST." <20001205130755.C2312@canonware.com> From: Chuck Paterson Date: Tue, 05 Dec 2000 15:02:48 -0700 Sender: cp@berserker.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org }Building SIX locks on top of mutexes would IMO be the correct way to go. BSD/OS doesn't have low level reader/write locks because the lock manager had the basic functionality and we haven't got to the point were chasing the performance has come close to the top of the queue. Having said this, there is a case for actually building low level reader/writer locks. They can be made to as fast in the uncontested case as a mutex, at least on hardware like Sparc, Intel and Alpha. Reader/Write Locks built on top of mutices will be roughly half as fast as a mutex because a mutex acquire and release is needed for both acquiring and releasing the reader/write locks. For this reason I believe we should just stick with lock manager locks until we have a chance to build real reader write locks. There are tricks which can be done by mixing atomic counting and swap and compare to gate entry. I pretty clearly understand how this can be done, but its still unclear to me how well this maps onto standard counting semaphores. If the protection for the netgraph is encapsulated in netgraph specific macros we ought to be able to switch this out to whatever mechanism we choose when we have time to design/implement one or more of the alternatives. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message