Date: Sun, 27 Jun 1999 23:17:27 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alan Cox <alc@cs.rice.edu> Cc: Terry Lambert <tlambert@primenet.com>, Bakul Shah <bakul@torrentnet.com>, julian@whistle.com, freebsd-smp@FreeBSD.ORG Subject: Re: high-efficiency SMP locks - submission for review Message-ID: <199906280617.XAA17806@apollo.backplane.com> References: <199906272253.SAA04385@chai.torrentnet.com> <199906280521.WAA27383@usr04.primenet.com> <19990628003639.N2738@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906280617.XAA17806>