From owner-freebsd-smp Sun Jun 27 23:17:31 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1FAFE15399 for ; Sun, 27 Jun 1999 23:17:29 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA17806; Sun, 27 Jun 1999 23:17:27 -0700 (PDT) (envelope-from dillon) Date: Sun, 27 Jun 1999 23:17:27 -0700 (PDT) From: Matthew Dillon Message-Id: <199906280617.XAA17806@apollo.backplane.com> To: Alan Cox Cc: Terry Lambert , Bakul Shah , julian@whistle.com, freebsd-smp@FreeBSD.ORG Subject: Re: high-efficiency SMP locks - submission for review References: <199906272253.SAA04385@chai.torrentnet.com> <199906280521.WAA27383@usr04.primenet.com> <19990628003639.N2738@cs.rice.edu> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :On Mon, Jun 28, 1999 at 05:21:05AM +0000, Terry Lambert wrote: :> :> I also have a slight problem with relying on a test-and-set :> instruction any more complicated than that which can be :> implemented with P/V semaphores. Many processors (e.g. MIPS) :> don't have an atomic test and set, and you'd want to avoid :> architecting against them ever working. 8-(. :> : :That is true. They, including MIPS and Alpha, have something :better: Load-locked and store conditional. :-) : :I think this is a non-issue. : :Alan I think the key is to create a reasonably efficient primitive that can be used as a building block for more sophisticated functions. A simple test-and-set isn't quite powerful enough, because using it in a more complex setting requires multiple instances of the primitive. For example, you could use it to implement spin locks to protect counters but you could not use it to implement the lock counters directly. For this reason, I expect that using a compare-and-exchange primitive will be much more useful to us even if it does not devolve into a single instruction on some processors. Being a much more powerful mechanism, the single use of a compare-and-exchange primitive would yield approximately the *same* number of instructions as the multiple use of a test-and-set primitive on those processors that only support test-and-set, for those operations that require sophistication beyond what a test-and-set can give you. So, my feeling is that a compare-and-exchange primitive is optimal across all process types. In fact, both types of primitives are useful. But one should not throw away compare-and-exchange just to try to reach the lowest-common-denominator amoung cpus, because this severely degrades performance on those processors that support the more sophisticated primitives while at the same time does not significantly improve performance on those processors that only support test-and-set. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message