Date: Tue, 23 Nov 1999 11:51:02 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Alan Cox <alc@cs.rice.edu>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@netplex.com.au>, Tommy Hallgren <thallgren@yahoo.com>, freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation Message-ID: <199911231951.LAA11203@apollo.backplane.com> References: <Pine.BSF.4.21.9911231156020.4557-100000@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: mem write A
: mem read B
: mem write C
: RELEASE lock
: GOT lock
:
: A, B C aren't garanteed
: to be complete at this point
: and could be committed to
: memory at any point following
: the lock release?
The key thing to focus on here is the pentium's multiple execution
units. We actually don't care when main memory is read or written,
only when the execution units read or write the L2 cache relative
to the execution of other instructions (The L2 cache operates under
an SMP cache coherency protocol).
Since there are multiple execution units we have to depend on Intel's
rules for allowing out of order execution to determine whether a
problem exists or not. In this case a problem does exist in a very
small window due to Intel potentially allowing a read+write (or
write+read) to be executed out of order, at least according to their
documentation.
I don't think the original code had a problem since it ran enough
instructions to clear the pipeline and issued a write-APIC write-unlock
rather then read+write or write+read, and write ordering is guarenteed,
but you have to ask yourself if you trust Intel that far and the answer,
at least for me, is "no".
-Matt
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?199911231951.LAA11203>