Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Nov 1999 12:38:46 -0600
From:      Alan Cox <alc@cs.rice.edu>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Peter Wemm <peter@netplex.com.au>, Tommy Hallgren <thallgren@yahoo.com>, freebsd-smp@freebsd.org
Subject:   Re: Matt's new unlock optimiazation
Message-ID:  <19991123123846.E20514@cs.rice.edu>
In-Reply-To: <28648.943366199@critter.freebsd.dk>; from Poul-Henning Kamp on Tue, Nov 23, 1999 at 03:09:59PM %2B0100
References:  <19991123140128.3A7D41C6D@overcee.netplex.com.au> <28648.943366199@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
What Linus says is definitely true of non-x86 architectures,
such as Alpha, but I had thought (not to be confused with
"know for a fact") that the x86 was "sequentially
consistent", making Matt's optimization legal.

I've definitely seen the statement in the Intel manuals
that writes are not reordered.  Thus, if the
program on processor 1 writes X to location A followed
by Y to location B, then processor 2 is guaranteed to
see X in A (and not some old value) if it's seen Y in B.

Suppose that B is our spinlock and Y is the value that
indicates the lock is available/unlocked.  If I'm able
to determine that the lock is available, then I'm guaranteed
to see any changes written before the unlock.

Before the general area of "memory consistency" models
(not to be confused with cache coherence) was widely
understood by architects, there were some optimizations,
such as delaying the application of cache line invalidation
directives from the bus, that broke sequential consistency
without people realizing it.  I had presumed that the x86
got this right.

Alan

P.S. If this distinction between "memory consistency" models
and cache coherence (protocols) sounds a bit strange, think
of it this way: the cache coherence protocol governs what
happens when two processors are modifying the same cache line
and the memory consistency model deals with the ordering
of modifications to different cache lines.



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?19991123123846.E20514>